Re: dialog enhancements
- From: Fritz Jetzek <fritz jetzek i-dmedia com>
- To: gtk-devel-list redhat com
- Subject: Re: dialog enhancements
- Date: Sat, 25 Mar 2000 13:59:07 +0100
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]