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 302632 - no way to have a no-arg G_OPTION_ARG_CALLBACK
no way to have a no-arg G_OPTION_ARG_CALLBACK
Status: RESOLVED FIXED
Product: glib
Classification: Platform
Component: general
2.6.x
Other Linux
: Normal minor
: ---
Assigned To: gtkdev
gtkdev
: 308020 (view as bug list)
Depends on:
Blocks: 307312
 
 
Reported: 2005-05-01 15:11 UTC by Dan Winship
Modified: 2011-02-18 16:11 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
patch (7.40 KB, patch)
2005-06-10 18:59 UTC, Dan Winship
none Details | Review

Description Dan Winship 2005-05-01 15:11:51 UTC
There's no way to have a G_OPTION_ARG_CALLBACK option that doesn't consume
an argument, meaning you can't have a no-arg option with custom behavior.
There are a few things that this functionality would be useful for:

  - Toggle args, where passing it once turns it on and passing it again
    turns it off

  - Args that count the number of times they were passed, like
    "tcpdump -vvv"

  - In garbage-collected languages, you generally can't take the address of
    a variable, making most of the arg types awkward to use (you have to
    allocate temporary memory, copy the initial value of the variable in,
    pass that to GOption, and then copy the final value out at the end).
    In Gtk# at least, it would be easier for us to tell glib that all of the
    entries are ARG_CALLBACK entries, and use reflection to get the values
    into the right variables from the callback. But right now this won't
    work for boolean args.

This could be implemented either by having a new G_OPTION_ARG type or by
having a G_OPTION_FLAG value. (Since G_OPTION_FLAG_REVERSE is specific to
ARG_NONE arguments, having flag values specific to ARG_CALLBACK arguments
doesn't seem like a big problem.) If it was going to be done as a flag, it
would also be nice to have a flag saying that the callback expects to
receive a filename, as opposed to a plain string, so goption can do the
right encoding-munging in that case too.
Comment 1 Matthias Clasen 2005-05-17 15:04:05 UTC
I think adding a flag for that would be ok. 
Comment 2 Dan Winship 2005-06-10 18:59:26 UTC
Created attachment 47568 [details] [review]
patch

This implements both G_OPTION_FLAG_NO_ARG and G_OPTION_FLAG_FILENAME.
The fact that G_OPTION_FLAG_FILENAME only affects CALLBACK options (and not
STRING or STRING_ARRAY options) is a little odd, but it didn't seem to make
sense to have it affect those option types too if we were still going to
leave FILENAME and FILENAME_ARRAY around, which we have to, so...
Comment 3 Matthias Clasen 2005-06-17 18:01:34 UTC
*** Bug 308020 has been marked as a duplicate of this bug. ***
Comment 4 Matthias Clasen 2005-06-18 04:55:34 UTC
2005-06-18  Matthias Clasen  <mclasen@redhat.com>

	* glib/goption.h: 
	* glib/goption.c: Add G_OPTION_FLAG_NO_ARG and
	G_OPTION_FLAG_FILENAME to allow greater control of
	G_OPTION_ARG_CALLBACK options. (#302632, Dan Winship)

	* tests/option-test.c: test callback args