Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Config file loading options #1012

Closed
wants to merge 5 commits into from
Closed
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
32 changes: 28 additions & 4 deletions tutorials/gui_config.md
Original file line number Diff line number Diff line change
Expand Up @@ -15,10 +15,34 @@ There are a few places where the GUI configuration can come from:
2. A `<gui>` element inside an SDF file
3. The default configuration file at `$HOME/.ignition/gazebo/gui.config` \*

Each of the items above takes precedence over the ones below it. For example,
if a user chooses a `--gui-config`, the SDF's `<gui>` element is ignored. And
the default configuration file is only loaded if no configuration is passed
through the command line or the SDF file.
Each of the items above takes precedence over the ones below it by default.
For example, if a user chooses a `--gui-config`, the SDF's `<gui>` element is
ignored. And the default configuration file is only loaded if no configuration
is passed through the command line or the SDF file.

The default behaviour can be overridden using the `--gui-config-options`
command line argument, which offers options:

* `force`: Force the use of the GUI config file, ignoring the SDF file. If a
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about making force override --gui-config as well? Specifying both --gui-config-options force and --gui-config is a bit odd, and probably will never be done. However, it seems easier and cleaner to remember that force is a complete force without a caveat.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure I understand the proposal. Are you saying that --gui-config <path_to_file> should imply force? I believe that's already in the current proposal. If --gui-config is provided and --gui-config-option is empty, it works like a force.

See these lines on the table below:

--gui-config     | SDF `<gui>`  | --gui-config-option      | Result
---------------- | ------------ | ------------------------ | ------
provided         | no plugins   | empty / force / prepend  | Load plugins from `--gui-config`
provided         | has plugins  | empty / force            | Load plugins from `--gui-config`

`--gui-config` is provided explicitly, that is used, otherwise, the default
config file is used.
* `ignore`: Ignore the config file completely and load only plugins from SDF.
* `prepend`: Load plugins from both the config file and the SDF file. The config
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The only thing that I think could be troublesome here is if you had duplicate plugins. The scenario that I'm thinking of would be having "specific" configuration in the SDF file and "generic" configuration in the gui.config file.

In that case, I think that you would want to prefer the "specific" configuration from the SDF file.

The implementation should take into account this scenario as well as the possibility of having duplicated plugins from the two configurations available.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah that's complicated to handle, because there are valid use cases for duplicate plugins, on both the GUI and the server. You may want multiple ImageDisplays or multiple WindEffects, for example.

I don't have a good idea on how to handle that. Maybe each plugin can be responsible for shortcutting multiple instantiation?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I added a merge option to cover this use case, with an example. Let me know what you think 4ab37d6. Coming back to this after so many months, now I think this will be my favorite option.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I reduced the number of options to 2 in d7a7677 and will work on the implementation now

file is loaded first.

The table below summarizes how all the options behave together:

--gui-config | SDF `<gui>` | --gui-config-option | Result
---------------- | ------------ | ------------------------ | ------
empty | no plugins | empty / force / prepend | Load plugins from `$HOME/.ignition/gazebo/gui.config`
empty / provided | no plugins | ignore | Load no plugins
provided | no plugins | empty / force / prepend | Load plugins from `--gui-config`
empty | has plugins | empty / ignore | Load plugins from SDF
empty | has plugins | force | `$HOME/.ignition/gazebo/gui.config`
empty | has plugins | prepend | Load plugins from `$HOME/.ignition/gazebo/gui.config` and SDF
provided | has plugins | empty / force | Load plugins from `--gui-config`
provided | has plugins | ignore | Load plugins from SDF
provided | has plugins | prepend | Load plugins from `--gui-config` and SDF

> \* For log-playback, the default file is
> `$HOME/.ignition/gazebo/playback_gui.config`
Expand Down