After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 750796 - Strange behaviour of GApplication::handle-local-options
Strange behaviour of GApplication::handle-local-options
Status: RESOLVED DUPLICATE of bug 751598
Product: glib
Classification: Platform
Component: gapplication
2.45.x
Other Linux
: Normal normal
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2015-06-11 14:53 UTC by Kjell Ahlstedt
Modified: 2015-09-09 15:31 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
patch: gapplication: Abort ::handle-local-options on exit code >= 0 (867 bytes, patch)
2015-06-13 10:11 UTC, Kjell Ahlstedt
none Details | Review

Description Kjell Ahlstedt 2015-06-11 14:53:52 UTC
The GApplication::handle-local-options signal has its own accumulator,
g_application_handle_local_options_accumulator(), with a strange behaviour.
As soon as a signal handler returns a negative value (e.g. -1), the accumulator
returns FALSE, thus aborting signal emission. The default signal handler
returns -1.

If I connect my signal handler after the default handler, my handler is not
called.

If I connect it before the default handler, it is called. If it returns >= 0,
the accumulator returns TRUE, and the default handler is called.
The return value of the signal emission is the return value of the last called
signal handler, which will always be -1 as long as the default handler is not
overridden. Is this really the intended behaviour?

It would be more reasonable to abort the signal emission when a signal handler
returns >= 0. Let the accumulator finish with
  return value < 0;
instead of
  return value >= 0;

Alternatively, use g_signal_accumulator_first_wins(), like ::command-line.
Comment 1 Kjell Ahlstedt 2015-06-13 10:11:06 UTC
Created attachment 305192 [details] [review]
patch: gapplication: Abort ::handle-local-options on exit code >= 0
Comment 2 Ignacio Casal Quinteiro (nacho) 2015-07-21 09:53:46 UTC
I've just reached to this problem as well. In order to avoid it I had to set the default handler to NULL before connecting to the signal, so my signal handler return value would take priority over the default one.
Comment 3 Matthias Clasen 2015-07-27 10:41:55 UTC
fixed in 243d740c0430a2fa123c2428bf25ae80768ed633
Comment 4 Murray Cumming 2015-09-09 15:31:34 UTC

*** This bug has been marked as a duplicate of bug 751598 ***