On Fri, Dec 11, 2015 at 02:40:36PM -0200, Eduardo Lima (Etrunko) wrote: > Signed-off-by: Eduardo Lima (Etrunko) <etrunko@xxxxxxxxxx> > --- > configure.ac | 2 +- > src/remote-viewer.c | 9 +++++++++ > src/virt-glib-compat.c | 29 +++++++++++++++++++++++++++++ > src/virt-viewer-app.c | 15 +++++++++++++++ > src/virt-viewer-app.h | 8 ++++++++ > src/virt-viewer.c | 9 +++++++++ > 6 files changed, 71 insertions(+), 1 deletion(-) [snip] You've added an awful lot of back compat code here to deal with this. I can't help thinking a better approach is to just not use the g_application_add_main_option_entries() method in the first place instead of adding piles of copy+pasted code. Reading the description of that method does not make it sound like it is a critical feature we absolutely need to have. [quote] This function is new in GLib 2.40. Before then, the only real choice was to send all of the commandline arguments (options and all) to the primary instance for handling. GApplication ignored them completely on the local side. Calling this function "opts in" to the new behaviour, and in particular, means that unrecognised options will be treated as errors. [/quote] IMHO we could just do as that suggested, and send the options to the primary instance for handling instead of parsing them locally. Or alternatively just carry on using the GOptionContext for parsing CLI args locally, and only use GApplication for the non-CLI arg handling parts Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| _______________________________________________ virt-tools-list mailing list virt-tools-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/virt-tools-list
