Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Save main and project configuration whenever documents are opened/closed #2114
The main idea is to save the session file list more often to prevent
IIRC at the very beginning I was a bit concerned about IO access and performance when writing the settings too often. At least performance doesn't seem to be a problem:
Even though I tested the code, I would like to use it "in production" for some time to get sure there are no unseen side effects or similar.
I guess the only issue is if the config directory is on a slow drive like a network share or something. We could try it and if it causes people problems in reality, maybe look at adding a preference to disable it. I can't see it being much of an issue though as most programs do similar things.
The only thing I don't like, which could be improved later, is that it's still pretty arbitrary where the settings are being saved. In a perfect world, it would queue a save whenever the contents of the config file need to be saved.
Oh my, all those people who have two Geanys using the same config are gonna have many more races
And an occasional failure when both try to write at the same time (on those file systems where such access is exclusive).
If by "where" you mean "when" then I thought settings are now pretty much always saved when they are changed, its only the session that saved at the end, and thats what this addresses. Of course because of the way g_key_files work the whole lot has to be saved.
But as @codebrainz points out there are potential problems with slow or flakey drives maybe there needs to be a setting to disable it instead of forcing it on everyone.
Of course since it only writes to
Agree best to commit immediately after next release.
I mean this PR only adds more places where configuration is saved (compared to only on prefs dialog applied, plugin manager closed, app closed, etc.) but it's still not comprehensive. In a perfect world there would be an interface/abstraction for the config system that whenever any setting is changed, a save is automatically queued, similar to something like Xfconf or GSettings or such. To give an example, even after this PR, if you used
@elextr this PR doesn't address the issue with multiple instances which overwrite the config mutually. I think we should stop writing the config at all in new instances but again, another story.
@elextr I'm not sure how useful a setting for this feature would be. the config we write is only a few kilobytes and I have no clue if there are still any users out there who actually store configs on network shares or the like.
Oh, and I think this should not go into the SaveActions plugin as the plugin is for (auto) saving documents not Geany's settings. And actually, the code of this PR is triggered by the SaveActions plugin already via the "document-save" signal. So what you request is already done :).
Agree that multiple instances sharing the same config or project is a separate problem. I always try to discourage people running more than one geany using the same config or project, thats why I had the evil grin icon on the comment
Given that NAS appliances are now only a few hundred dollars and as the US consumer market was half a billion dollars in 2017 and growing I suspect that the numbers of user configs and project files on network devices may be increasing, not reducing.
I do hope your aggregation algorithm works.
To be clear, In general this change is a good thing to do, I'm just trying to anticipate any issues, and would like having the "off" option hidden in various as a workaround for the ones we didn't think of.
Apr 14, 2019
It would be good to reduce file writes e.g. to prolong hard disk life. What if we track when session data changes but only write the keyfile when the main window loses focus? That would seem to solve the user clicking logout problem and drastically reduce disk/network writes.
I don't think its neccessary to worry about disk IO unless its having an effect on performance, but since save only occurs when config data changes and that is when there is a major screen update (new document, close document etc) its not likely to be noticed. If it does cause performance issues, eg because the config file is on some slow remote filesystem then there is now an option to turn this saving off.
As for saving disk life, on my systems something in the OS writes to disk every few seconds (with no user apps open), so I doubt the Geany config saving will have a material effect on lifetime.
Only aggregating and only saving on focus loss is ok for user logout since it will be hard to invoke logout or shutdown without de-focussing geany, but it will not handle a crash though.
I agree with @elextr: better saving the config too often than too few. The primary intention is to save data loss on crashes (of Geany or the host).