Re: Beyond GDK threads and gtk_dialog_run - What to use?

[Chris Vine <chris cvine freeserve co uk>]

On Tue, 6 Mar 2012 17:15:21 +0100
Åan DoberÅek <zandobersek gmail com> wrote:
> I'm running an effort to add support for modal dialogs in WebKitGTK+,
> bug report is located at WebKit's bugzilla[1]. When a web page
> requests a modal dialog, the user agent is required to create a new
> window that will represent the modal dialog, set it transient to its
> parent and set it as modal. The window will be shown and after that
> the WebKit library will take over, running a loop to prevent user
> interaction with other windows. When the modal dialog window is
> closed, the loop is ended.
>
> gtk_dialog_run was a perfect example to follow, using main loops with
> GDK_THREADS_LEAVE and GDK_THREADS_ENTER calls. These, however, seem
> to be on their way to become deprecated.[2] WebKitGTK+ should,
> however, still provide the modal effect when modal dialogs are to be
> shown and run (i.e. there's no signals or similar workarounds as with
> gtk_dialog_run), meaning a main loop should probably be established
> and run until the dialog itself is destroyed.
>
> I'd like some input on what's the best and most (thread-)safe way to
> set up the main loop or if there are any other options to avoid using
> GDK threads calls and make the implementation future-complaint today.

You could test for the symbol GTK_DISABLE_DEPRECATED and for the gtk+
version with GTK_CHECK_VERSION, in order to conditionally compile the
calls to GDK_THREADS_LEAVE and GDK_THREADS_ENTER, if you think you need
to do that.  If so, you would have to make sure that all other calls to
the GDK global lock in webkit-gtk (if any) are similarly removed.  All
that these calls do is to unlock and lock the GDK global lock
respectively if gdk_threads_init() has been called where the X11
backend is in use: otherwise I think they are no-ops.

If you are also concerned about the proposed deprecation of
gtk_dialog_run() as you say I should ignore it unless you also feel
compelled to force users to connect to a "response" signal to run their
continuations.  It seems odd that the GTK+ developers should want to do
this however, as a blocking 'run' call is a common GUI programming
idiom for modal dialogs and I don't know of any proposal corresponding
proposal to deprecate nested main loops in glib.  However, you may want
to inquire on the gtk-devel list why this proposal has been made.

Chris