Re: [gtk-list] Re: [patch] mainloop
- From: johannes nada kth se (Johannes Keukelaar)
- To: gtk-list redhat com
- Subject: Re: [gtk-list] Re: [patch] mainloop
- Date: Tue, 21 Oct 1997 10:06:26 +0200
//email@example.com (Johannes Keukelaar) writes:
//> Does that mean that it was already possible to call the main loop
//> recursively from a signal callback? If that is so, is that the way to go
//> about building functions like, for example, my_ask_yes_or_no( "Really want
//> to quit?" ), which would pop up a modal dialog box and return after the
//> user clicks on the yes or no button?
// The way to implement modality is to use gtk_grab_add and
//gtk_grab_remove see the below example.
Yeah, I know about gtk_grab_(add|remove). However, I want a single function that I can call, and when it returns I will know which button the user clicked in the dialog. Something like this:
void QuitMenuItemCallback( GtkWidget *wid, gpointer foo )
/* Let's see if the user is sure (s)he wants to quit. */
gchar *clicked = my_ask_yes_or_no( "Really want to quit?" );
if ( strcmp( clicked, "Yes" ) == 0 )
This keeps the number of callback functions I have to code down, if I use a couple of these yes/no dialogs. From the previous mails, I'd imagine this hypothetical my_ask_yes_or_no function could be coded something like this:
gchar *my_ask_yes_or_no( gchar *question )
/* Make a new dialog, with question as a label and 'Yes' and 'No' as
* Set up some callback functions, linked to the buttons, that get &res
* as user_data parameter. They can then set this variable to point to
* a constant string containing either 'Yes' or 'No', depending on which
* button was pressed, of course. They also call gtk_main_quit at their end.
gtk_grab_add( dialog );
gtk_main( ); /* Wait for one of the callbacks to be called. */
gtk_grab_remove( dialog );
gtk_widget_destroy( dialog );
This, in my eyes, would greatly simplify my code in a way, since I'd have about half(?) as many functions. This would make the thread of control (for as much as such a thing exists in an event-driven environment; i.e. only when modal dialogs come into play) much more obvious. A Good Thing, surely?
People who claim they don't let small things bother them have never
slept in a room with a single mosquito.
Virtually researching virtual behaviour in a virtual world.
] [Thread Prev