[Github-comments] [geany/geany-plugins] New Plugin, maybe... (mostly) user-interface tweaks. (Issue #1131)

xiota notifications at xxxxx
Fri Nov 12 01:58:08 UTC 2021


I'm thinking about something like the following:

* Preference variables are registered through a function, like `register_config_variable(key_id, group, name, type, ...)`.  Session variables could use the same registration system with a different `key_id`.  Maybe project files also.
* All registered variables would be loaded/saved with `load_config(key_id)` and `save_config(key_id)`.  (It would use something like `for_each_config_variable`.)
  - Adding and using a new variable would consist of adding it to the appropriate struct and registering it with the config management system.  No more manually adding load/save code to separate functions.  Existing structs would stay intact.
* Preferences could be set/get with something like `get_config_variable(key_id, group, name)` and `set_config_variable(key_id, group, name, ...)`.
  -   Existing code would continue to work.  The registration system could use pointers to access the same variables.
* There could be a runtime override `override_config_variable(key_id, group, name, ...)` that sets an override flag so preferences can set sensitivity or display notices.  It would also prevent writing override values to the config/session files.
  - Plugin identity could also be tracked, similar to `plugin_signal_connect`, so when the plugin is unloaded, the previous setting can be restored.

This could all be implemented in a plugin to manage its own settings as proof of concept to ensure that it makes sense before modifying Geany.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany-plugins/issues/1131#issuecomment-966756151
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.geany.org/pipermail/github-comments/attachments/20211111/5276dd1e/attachment.htm>


More information about the Github-comments mailing list