Alright, just tried it and it's true. I guess I'll postpone the 3.3.1 release then, as it makes no sense that way.

This is probably due to GtkApplication not running the Gtk mainloop anymore due to changes in GApplication (we seem to have a locking issue with GdkThreads now).

ouch this sucks.

I didn't realise that it would be necessary to enter the gdk threads before g_application_run() in order to avoid problems with gtk_main().

Ideally, that would not be required, and the obvious eog fix would be to drop the thread enter call.

I'm not sure I like what that says about compatibility with older versions, though...

Another way to fix this could be to make the gdkthreads mutex recursive.

(In reply to comment #3)
> Another way to fix this could be to make the gdkthreads mutex recursive.

this wouldn't work at all, you fool!

*** Bug 663043 has been marked as a duplicate of this bug. ***

I think the best solution at this point is to change the eog code.

I really consider this to be an unintended effect of the API -- it was never meant to interact with GdkThreads in this way.

Trying to fix it in glib or gtk would necessarily introduce some ugly hacks...

(In reply to comment #6)
> I think the best solution at this point is to change the eog code.

I'm not exactly sure how to do that without making big changes to make sure that calls to GDK won't happen outside of the default mainloop.

GdkThreads is slightly mind-bending to me at the moment.

> I really consider this to be an unintended effect of the API -- it was never
> meant to interact with GdkThreads in this way.

You mean using G(tk)Application together with GdkThreads?

> Trying to fix it in glib or gtk would necessarily introduce some ugly hacks...

Wouldn't it be more safe to fix the original problem in Gtk+ and allow executing the Gtk mainloop? AFAIR GdkThreads-handling isn't the only thing the gtk mainloop does different than the normal glib mainloop.

The only difference between gtk_main() and what GApplication does now is that gtk_main does this (copy/pasting):


  if (g_main_loop_is_running (main_loops->data))
    {
      GDK_THREADS_LEAVE ();
      g_main_loop_run (loop);
      GDK_THREADS_ENTER ();
      gdk_flush ();
    }


so you could fix the issue in eog main() by simply dropping the two gdkthreads calls.

As for dispatches, the difference only happens if you do gdk_threads_add_timeout() and so on -- and that will still continue to work, even with the changes.

Created attachment 200513 [details] [review]
Don't lock GDK around g_application_run()

An unintended interaction between GtkApplication and GDK threading made
this necessary before.  That code has since been simplified, breaking
this formerly-working code.

Hmm, I thought that the removal of these lock calls would only qualify as a diagnostic/workaround. Thanks, for clarification. :)

commit ee4f6b27027421ee1e7cb14948f587da83171668
Author: Ryan Lortie <>
Date:   Wed Nov 2 10:08:14 2011 -0400

    Don't lock GDK around g_application_run()
    
    An unintended interaction between GtkApplication and GDK threading made
    this necessary before.  That code has since been simplified, breaking
    this formerly-working code.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=662630

This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.

@Felix: Would you consider applying this patch to the gnome-3-2 branch too?

(In reply to comment #11)
> @Felix: Would you consider applying this patch to the gnome-3-2 branch too?

Well, I didn't have any plans for that as 3.2.x is supposed to run with glib-2.30 which requires the lines removed by the patch.

Do you have any specific reasons for having it?

Oh, I am wrong then. I thought this can be dropped nevertheless and wouldn't have greater effects running with glib 2.30.

Running eog 3.0.2 (built with glib 2.28) runs with glib 2.31+ though which made me think this is some kind of regression.

(In reply to comment #13)
> Oh, I am wrong then. I thought this can be dropped nevertheless and wouldn't
> have greater effects running with glib 2.30.
> 
> Running eog 3.0.2 (built with glib 2.28) runs with glib 2.31+ though which made
> me think this is some kind of regression.

Ah yes, 3.0.x is not affected by this problem because eog only moved to G(tk)Application with version 3.1.2. Beforehand eog had it's own code to handle application uniqueness and had to execute the Gtk mainloop itself.