GNOME Bugzilla – Bug 727602
Add g_application_set_main_option_group() ?
Last modified: 2014-05-02 09:07:29 UTC
Unlike GOptionContext's g_option_context_set_main_group(), or g_option_context_add_group() https://developer.gnome.org/glib/stable/glib-Commandline-option-parser.html#g-option-context-set-main-group , the new g_application_add_main_option_entries() function https://developer.gnome.org/gio/unstable/GApplication.html#g-application-add-main-option-entries does not use an intermediate GOptionGroup. So glibmm can't use GOptionGroup's g_option_group_set_parse_hooks() to map between C and C++ values such as const char* and std::string. If we could add a whole group, whose parse hooks would be used, then we could still do this like we do for our Glib::OptionContext's parse(). Note that g_option_context_add_main_entries(), which is mentioned in g_application_add_main_option_entries()'s documentation, is just a (C) convenience function. It would make sense to document g_application_add_main_option_entries() as being just a C convenience function. The existing g_application_add_option_group() function isn't good enough because it doesn't let us pass any command line options to the primary instance. https://developer.gnome.org/gio/unstable/GApplication.html#g-application-add-option-group
Doesn't ::handle-local-options give you the post-parse hook you need ?
Maybe, yes. Do you mean that the GOptionEntry::arg_data would be set already for us in our handle-local-options handler (in which case that could be clearer in the documentation)? Or do you mean that we should just always let GOptionEntry::arg_data be NULL and use the options GVariantDict? I do wonder if you should clearly discourage non-null GOptionEntry::arg_data anyway because the VariantDict options seems to be the only way to let the primary (not local) instance parse some of the options (afer optional modification by the local instance). Deprecating non-NULL arg_data would be one way to simplify the documentation which is confusing now because it has to discuss what happens, and what to do, in multiple situations.
I didn't write this code, so I'll let Ryan answer here
I'm not in favour of this -- we tried the "replace the guts" approach with g_application_set_action_group() and it didn't work out for us... Can you not just suggest that people use C strings and/or GVariant?
(In reply to comment #4) > Can you not just suggest that people use C strings Sorry,t hat would be rather unpleasant from our point of view. > and/or GVariant? Maybe. Could you please try to answer my two questions in comment #2. If you want to discourage use of GOptionEntry::arg_data for this anyway, then it gets simpler for us.
(In reply to comment #2) > Maybe, yes. Do you mean that the GOptionEntry::arg_data would be set already > for us in our handle-local-options handler (in which case that could be clearer > in the documentation)? We set arg_data, but only in our local copy of the struct, as an implementation detail. You will never see this. > Or do you mean that we should just always let GOptionEntry::arg_data be NULL > and use the options GVariantDict? Yes. If you cannot use C strings, then I would have to recommend doing this for every string that you need to parse. > I do wonder if you should clearly discourage > non-null GOptionEntry::arg_data anyway because the VariantDict options seems to > be the only way to let the primary (not local) instance parse some of the > options (afer optional modification by the local instance). Some arguments are meant to be parsed locally, exclusively. Things like the simple boolean flags --help and --version. Deprecating this, therefore, does not make a lot of sense. > Deprecating > non-NULL arg_data would be one way to simplify the documentation which is > confusing now because it has to discuss what happens, and what to do, in > multiple situations. That's true... and it's possible to do everything with the new API... but there is also no harm in having this extra support, and it meshes better with people's preconceived notions of how GOptionContext works...
OK. Thanks for the clarity. We will try to just use the GVariantDict way in glibmm's Gio::Application.
Does g_application_add_option_group() also only exist to help people who want to keep using OptionGroup/OptionEntry, or is it ever useful in addition to (or instead of) g_application_add_main_option_entries()? Its documentation talks a lot about what it's not good for, so much that it feels like it should just be deprecated.
This is for libraries that give you a GOptionGroup. The mention of g_option_context_add_group() is sort of meant to motivate this... ie: use it for the same thing.