Re: dialog enhancements



Tim Janik wrote:
> 
> On 25 Mar 2000, Havoc Pennington wrote:
> 
> > Fritz Jetzek <fritz.jetzek@i-dmedia.com> writes:
> > > So when rethinking the GtkDialog API one should possibly rethink whether
> > > the call to gtk_main is really necessary. Apart from not being able to
> >
> > It's necessary if you want to block the flow of execution, of course
> > you don't have to use gnome_dialog_run(), you can just use callbacks
> > instead.
> 
> not at all ;)
> the simple solution to fritz's (urg, do you actually apostrophe-s
> such a name? ;) 

up to you ;)

> which also takes care of carrying on the main_quit
> flag is (and that's what BEAST's procedure dialog does):
> 
> dialog_run (GtkWidget *dialog)
> {
>   [...]
> 
>   gtk_widget_ref (dialog);
> 
>   [...]
> 
>   gtk_widget_show (dialog); /* GtkWindow.modal cares about modality here */
>   do
>     g_main_iteration (TRUE);
>   while (GTK_WIDGET_VISIBLE (dialog));
> 
>   [...]
> 
>   gtk_widget_unref (dialog);
> 
>   [...]
> }
> 

Alright. These Event loops are still a bit beyond my scope but I roughly
seem to understand that the replacement of the call to gtk_main() with
the above code fixes what I complained about.
Just found the relevant section in Havoc's book (3.4. The Main Loop, pp.
63/64) that describes the freezing-GUI-effect and a solution to the
problem looking similar to the code above. Now just apply the changes to
gtk_dialog_run() and I'll happily resume being a lurker ;)

(I was tempted to suggest passing the blocking function with the call to
gtk/gnome_dialog_run() in order to let the user decide about this issue.
Seems like that point is obsolete then :) 

Fritz



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]