Move search positions and layout to session.conf
This will remember the x,y positions as well as the find/replace dialog expanders as part of session.conf.
To implemenet this, a new interface configuration_add_session_group() is created that connects a StashGroup to session.conf. You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany/pull/3003
-- Commit Summary --
* session.conf split follow-up #3
-- File Changes --
M src/keyfile.c (60) M src/search.c (5)
-- Patch Links --
https://github.com/geany/geany/pull/3003.patch https://github.com/geany/geany/pull/3003.diff
@kugel- pushed 1 commit.
d5dd86c7bfae50b47b6fb9cd780c48e2bae5ba42 session.conf split follow-up #3
Agree with the intent, and code looks ok at a first glance.
Thanks for having a look. I'll merge this into the session_split development branch in a few days. If I don't find any obvious candidates for transitioning to session.conf I would like to merge that branch into master shortly thereafter.
@kugel One of the stash settings changes I've been pondering is to add split config/session support. Basically, a session flag would be set in the GroupPref struct. Then separate functions to save_config or save_session could be used.
@kugel- maybe a dumb question, but why can't you simply have two keyfiles, one for session and one for config and load/store the groups from the appropriate keyfile with `stash_group_load_from_keyfile()` and `stash_group_save _to_keyfile()`?
There are two keyfiles but not everything uses the stash framework (actually a lot of the prefs).
Oh, Ok.
What I've found annoying when dealing with settings (in my own plugins, so it's my fault for implementing it this way) is the duplicate code... each setting appears in a preference structure, in a loading function, in a saving function. Then with sessions, the places to keep track of preferences doubles. Times however many groups there are. Then switching a setting between config and session requires moving code around ×3. If only there were a way to register settings just once and let software take care of the rest automatically.
@xiota do your plugins need to worry about the split of `geany.conf` and `session.conf`? The plugin should store its prefs in its own files, not in those files, so the split should not worry the plugin.
As @kugel- sagely points out, lots of Geany prefs don't use stash, either because it wasn't invented when they were added, the person who added them didn't understand stash, or they needed something too complicated for stash (like variable numbers of entries or variable key values).
do your plugins need to worry about the split of geany.conf and session.conf?
No. But the same issues affect Geany. Geany is worse in some ways because different systems are used in different places.
As @kugel- sagely points out, lots of Geany prefs don't use stash, either because it wasn't invented when they were added, the person who added them didn't understand stash, or they needed something too complicated for stash (like variable numbers of entries or variable key values).
Preferences can be migrated. Stash can be extended.
The session-split branch makes managing preferences more complicated than it already is. In the long run, wouldn't it be better to migrate to the stash system?
The current near-duplicate save/load code would become a single "add". Then the stash system could be extended with session support. The add/save/load functions could take a bool or have session variants. Not all preferences would need to be migrated to stash at once. Just the session preferences could be migrated initially.
wouldn't it be better to migrate to the stash system?
TL;DR it would be nice if somebody(s) did it but not before the session-split branch and its follow ups is merged.
Clunky duplicated code is common for open source projects which accept contributions, especially conversions of existing code to new mechanisms are often incomplete, since nobody is forced to do it (especially if the existing code already works).
The session-split branch and its follow ups should be merged first because stash migration and stash improvements can happen afterwards progressively in many small easy to review and test PRs.
Trying to do such a conversion before merging the split branch will just delay it a lot and likely cause it to get merge conflicts, or somebody will try to do the migration in one large PR which will sit for ages because nobody has time to review or test something large. Same delay.
It is important to work in a way that matches the available volunteer resources. Not reviewing and testing enough is how you get bugs and clunky code.
Closed #3003.
github-comments@lists.geany.org