Here are two programs that implement through the text viewer widget what you
are asking for:
- The Python console in gimp
- GemTcl - a tcl interpreter
The way I set up the interaction is to listen to both the key-press-event
and the insert-text events of the text-viewer. The key-press-event signals
to the insert-event handler that it is supposed to enter eval mode:
if (!(event->state & GDK_SHIFT_MASK)) {
switch(event->keyval) {
case GDK_Return:
do_eval = true;
break;
}
}
and the insert-event catches this before the newline is inserted into the
buffer, runs the eval and inserts the result into the buffer:
if (do_eval) {
// Extract the text between the prompt and the end of the line
output = eval(command);
gtk_text_buffer_insert(text_buffer, output);
}
Have a look in GemTcl:gemtcl.cc cb_insert_text() and cb_key_press_command()
for details.
Hope this helps,
Regards,
Dov
2009/7/21 Allin Cottrell <cottr...@wfu.edu>
> In the context of my gtk app I have an optional "console" -- not
> a real shell, but a means of sending commands to the app besides
> point-and-click. It's working OK, but for various reasons I'd
> like to reformulate it so that I have a loop like this:
>
> while (command != quit) {
> get_a_command();
> do_stuff();
> }
>
> I'm having trouble with get_a_command(). The criterion for a
> command being entered is that Return is pressed in a certain
> GtkTextView, to which I have a pointer. But how does the
> get_a_command() function know that this has happened?
>
> I've implemented this via a static int, "command_entered" (a
> file-scope global), which is set to 1 by Return and is monitored
> by the function in question:
>
> void get_a_command () {
> while (!command_entered) {
> if (gtk_events_pending()) {
> gtk_main_iteration();
> }
> }
> command_entered = 0;
> }
>
> This works, but not surprisingly it uses a lot of CPU running
> around its tight loop waiting for Return. I then tried adding
> g_usleep(10000) into the loop on "while (!command_entered)".
> That brought CPU usage down to a sane level, but of course it made
> the whole GUI quite gummy.
>
> It seems there must be a smarter way of doing this, probably using
> some of the g_main* apparatus or g_threads, which I'm not really
> familiar with, and at my current level of ignorance looking at the
> API docs leaves me guessing. Any pointers to get me started would
> be very helpful.
>
> Allin Cottrell
> _______________________________________________
> gtk-app-devel-list mailing list
> gtk-app-devel-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
>
_______________________________________________
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
