Skip to content

application: Fix #260 (--help and --version closing the main instance)

Luiz Françarequested to merge
luizgfc/gnome-system-monitor:fix/cli-help-version into master

This is a fix for the issue #260 (closed)

The big problem behind this issue was that when commands were executed in in the CLI they did not run in the local instance, but in the main Gnome System Monitor instance. So when --help or --version were passed the main application instance closed because directly or internally (in the help case) exit() was executed on it. The same thing happened to any CLI output behavior.

So to solve this it was necessary to make --help and --version be handled in the local instance and the tab options in the main instance, because they need work with the main AdwViewStack.

To execute stuff in the local instance, and decide to delegate to the main instance or not, it is necessary to handle the handle-local-options signal which is exposed by Gtk::Application::signal_handle_local_options() and it receives the CLI arguments as key/value pairs in a Glib::VariantDict. But to receive those it is first required to register which arguments are expected to be received as keys using Gtk::Application::add_main_option_entry(), I really wanted to use Gtk::Application::add_option_group() passing our procman:OptionGroup instead, but when this is done we can't also handle our arguments locally There's a issue in bugzilla for this weird behavior that can be found here: https://bugzilla.gnome.org/show_bug.cgi?id=727602. A consequence of this is that we cannot just parse the arguments from Glib::ApplicationCommandLine on GsmApplication::on_command_line() as it is done now, because when Gtk::Application::add_main_option_entry() is used we only receive CLI options information from a Glib::VariantDict that should be obtained using ApplicationCommandLine::get_options_dict.

That's why in the end what i did in this merge request to solve the issue was:

  • creation of GsmApplication::handle_local_options() method and setup of it as handler for Gtk::Application::signal_handle_local_options() to execute local instance behavior.
  • creation of new procman::OptionGroup method to get a list with all our options settings and creation of the method GsmApplication::load_command_line_options() to be called on the application constructor to get this list and call Gtk::Application::add_main_option_entry() for all the entries returned from it.
  • creation of procman::OptionGroup::load() to load the group's option flags from a Glib::VariantDict, and calling it to load the content of the signal in our handle-local-options handler and to replace the Glib::OptionContext::parse() in GsmApplication::on_command_line now using the result of ApplicationCommandLine::get_options_dict()
  • creation of handling to --version in the local handler, (--help is deferred to the Gtk::Application automatic behavior) and ignore anything else so tab commands should still be handled by GsmApplication::on_command_line() as it is done today

I think this solves the problem in a good enough way for the time being, in the future it would be nice if the weird behavior for CLI handling of Glib described above was to be solved , and then we should be able to load the procman::OptionGroup directly and still be able to handle arguments within the local instance (i will try to take a look at it, no guarantees though, this is my first contribution to the Gnome project, so i'm still a newbie).

But what do you think? I would be happy if someone could review this and give any feedback.

Merge request reports