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 751598 - Stop 'handle-local-options' propagation when callback reports an error
Stop 'handle-local-options' propagation when callback reports an error
Status: RESOLVED FIXED
Product: glib
Classification: Platform
Component: gapplication
unspecified
Other All
: Normal normal
: ---
Assigned To: gtkdev
gtkdev
: 750796 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2015-06-27 18:06 UTC by Christophe Fergeau
Modified: 2015-09-09 15:31 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
gapplication: Stop handle-local-options emission on errors (1.95 KB, patch)
2015-06-27 18:06 UTC, Christophe Fergeau
committed Details | Review
gapplication: Fix typos in handle-local-options API doc (1.21 KB, patch)
2015-06-27 18:06 UTC, Christophe Fergeau
committed Details | Review

Description Christophe Fergeau 2015-06-27 18:06:32 UTC
'handle-local-options' callbacks can return a < 0 value if they want to
stop commandline processing because an error happened, but this is currently
not working as expected because of an inverted check. This commit fixes that,
and another one fixes small typos in 'handle-local-options' API documentation.
Comment 1 Christophe Fergeau 2015-06-27 18:06:36 UTC
Created attachment 306219 [details] [review]
gapplication: Stop handle-local-options emission on errors

A signal accumulator can return TRUE to continue signal emission, and
FALSE to stop signal emission. handle-local-options callbacks can return
« return a non-negative option if you have handled your options and
want to exit the process ».

Currently, g_application_handle_local_options_accumulator (the
accumulator for the handle-local-options signal) returns TRUE on
non-negative return value (ie continue signal emission), and returns
FALSE on negative return values (ie when the default option processing
should continue).
This return value seems backward as on >= 0 values, subsequent
handle-local-options callbacks could overwrite the 'exit request' from
the handler, while on < 0 values, the handle-local-options processing
could end up early if several callbacks are listening for this signal.
In particular, the default handler for this signal
(g_application_real_handle_local_options) always returns -1 and will
overwrite >= 0 return values from other handlers.

This commit inverts the check so that signal emission stops early when
one of the handle-local-options callbacks indicates it wants processing
to stop and the process to exit.
Comment 2 Christophe Fergeau 2015-06-27 18:06:43 UTC
Created attachment 306220 [details] [review]
gapplication: Fix typos in handle-local-options API doc

The @options parameter was missing an 's', and the name of
g_application_command_line_get_options_dict() was not correct.
Comment 3 Matthias Clasen 2015-07-26 18:46:22 UTC
Review of attachment 306220 [details] [review]:

sure
Comment 4 Matthias Clasen 2015-07-26 18:49:46 UTC
Review of attachment 306219 [details] [review]:

This looks right to me. It would be really nice to have test cases for this.
Comment 5 Matthias Clasen 2015-07-27 01:42:01 UTC
Attachment 306219 [details] pushed as 243d740 - gapplication: Stop handle-local-options emission on errors
Attachment 306220 [details] pushed as 2551685 - gapplication: Fix typos in handle-local-options API doc
Comment 6 Murray Cumming 2015-09-09 15:31:34 UTC
*** Bug 750796 has been marked as a duplicate of this bug. ***