On Tue, 11 Sep 2012 09:17:52 +1000 Lex Trotman elextr@gmail.com wrote:
All settings in Edit -> Preferences and Project -> Properties are saved ASA the dialog is confirmed. Some time ago, Build -> Set Build Commands were modified to be saved immediately as well.
The only settings that are really saved on exit are the interface ones (check/radio menu items, find/FIF settings etc.). The Preferences and Properties are still saved on exit, but only because nobody cared to separate them.
The idea is that anything in geany.conf (or project.conf) would be saved on change.
So what should geany.conf contain? If the interface preferences remain there, we still must "rush at quit time" to save it...
- Save session data periodically, or as it changes, or whenever,
without touching the config/project files. So the config isn't at risk if the session save goes wrong.
...and if we keep these preferences it in the .session file(s?), we risk damaging them on some periodic save. Not so bad as losing geany.conf, of course, but still unpleasant.
(> > Would be nice, but saving the session only (without the settings)
in the current files is completely possible.
Sadly its not, keyfiles re-write the whole file, not just the bits that are changed. So to save something by itself it has to be in another file.
I meant that loading a keyfile, replacing the session entries and saving it is possible. But yes, that's irrelevant.)
The proposal is that each project gets a UUID generated when it is created (or when its opened without one) which is saved in the project file. This uuid is the name of the session file in the ${GEANY_CONFIG}/sessions directory. [...]
The number of session files can be left to grow like weeds, or can be trimmed to a (configurable) maximum number deleting the oldest when needed.
[...] So we are only speaking about the users that want the future settings-only project file [in VCS] but not the session.
Yes, and I would expect that to be everyone who keeps a project file in *public* VCSes, nobody else in the world cares which files you had open last time you did something on the project.
If by "public" you mean "somewhere in the internet", I haven't seen a single OSS that includes with $project.geany, not even Geany itself or geany plugins.
Surely they can make a little effort to achieve that?..
Clearly you are not one of them or havn't had to try to repair commits that have included extra files because you forgot to edit .gitignore or equivalent. :)
No, I use mostly svn. But removing file(s) from finished commits should not be easy (and Mercurial does not even allow it IIRC). Yet how is that our problem? And if it is, why should we even allow project files in the project tree? They can be shipped by mistake equally well.
Moving the projects and sessions in ~/projects, ${GEANY_CONFIG}/projects or wherever can somehow be justified. But having the projects here-or- there, and the sessions yet somewhere else via redirection, is a mess. It's a bit surprising that you, of all people, proposed such a thing.
[...] The situation has improved a bit, now that Xfce will have proper sm, and handling the quit message under Win~1 is only a matter of somebody writing it (not me, I don't use Geany inder Win~1). I'm sure that MAC notifies the programs too, but have no idea how.
The word *portable* still applies, but if you create dimitars_all_platform_window_management_library_including_osx_windows_gnome_and_unity then maybe :)
There are ~90 "#if[n]def G_OS_WIN32" in Geany source. Expecting the session save to be operating-system portable is a bit too much.
I have previously asked for somebody to check if SM works under GNOME3 and Unity, but there was no response.
On Sun, 09 Sep 2012 21:50:02 -0700 Matthew Brush mbrush@codebrainz.ca wrote:
By session data I mean the list of currently open files and MRU list.
I guess it could support some other stuff too like window/find dialogs geometry/position, active tab, position within the file, etc.
Just to clarify, "stuff too like window/find dialogs" means the interface options. If they are per session file, each project will have it's own "appearance", something that Geany does not currently support. (Except with SM, and I find it very useful.)
But why stop half way? Let's have the current geany.conf/foo.geany for the Preferences and Properties respectively, a *.session file for the session and active tab [position within the file and the per-file settings are always stored along with the file name], and an *.interface file for the interface settings. This is the most logical solution, corresponding exactly to the different groups of settings. (Should I add a :) here? Hmmm...)
What? Why not a file per setting, then it would all work fine. Just make geany.conf a directory and switch to project.geany directories. :)
If we decide to continue with the single "appearance" (interface settings) for all projects, then a ${GEANY_CONFIG}/geany.interface would suffice, and geany.conf will be stable.
(Note: the project files currectly contain the settings from Project -> Properties and a session, but no "interface" options. The plugins can only place their own settings in the projects either, except by using the Project -> Properties dialog.)