search

WayfireWM / wf-config

A library for managing configuration files, written for wayfire
https://wayfire.org/
MIT License
18 stars 19 forks source link

Options are not removed from after being removed from config file #26

Closed soreau closed 3 years ago

soreau commented 4 years ago

After an option that does not exist in xml files is registered, it is not unregistered when removing the option from the config file. This means for plugins such as command and workspace-names, removing a list option leaves a stagnant option in the config. On the plugin side, there is no way of knowing that the option has been removed because it's forever part of the config object and section->get_registered_options() reflects this.

ammen99 commented 4 years ago

On the other hand, there are cases where we don't want to delete these options: for example, output configuration options in Wayfire. Consider this if we do delete the options not present in the config file:

  1. User starts with output mode in config file. Option is "owned" by wf-config.
  2. User comments out output mode. Option is deleted by wf-config, core holds reference to the old option because it is a shared_ptr.
  3. User uncomments output mode. Now a NEW option is created, which core doesn't know about.

In general, I do not like deleting options, this can have various unexpected effects. For the problem with command and workspace-names, I consider this more a problem that we don't have a list option type.

soreau commented 4 years ago

Yes I agree we need an officiated list option type. This is one quick solution to the problem http://ix.io/2q6f where things like output-layout can call register_custom_option (or could be s/custom/permanent/ or w/e) which would make sure it's never removed.

soreau commented 4 years ago

To reproduce this, set a command/binding in command plugin and after saving it, remove it from the config file. The binding will still run the command.