Thanks for the response. I'd like to avoid checking with GTK_DISABLE_DEPRECATED, and would rather implement this in a way that would be future-compatible.
I'm not against the deprecations, I can see why they are being pushed forward. I'm just interested in how it will be possible to replicate that behavior. Like suggested, I'm off to gtk-devel list with this inquiry. Regards, Zan On Tue, Mar 6, 2012 at 8:28 PM, Chris Vine <ch...@cvine.freeserve.co.uk>wrote: > On Tue, 6 Mar 2012 17:15:21 +0100 > Žan Doberšek <zandober...@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 > _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
