On 11 September 2012 04:30, Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
On Mon, 10 Sep 2012 14:36:32 +1000 Lex Trotman elextr@gmail.com wrote:
Its about that time of year when we have our annual discussion on separating session data from config/project data :)
Let's not forget the multiply instances that share their configuration to (some) extent. We love to discuss them. :)
Well, thats the *next* discussion :) (no its not)
By session data I mean the list of currently open files and MRU list.
The advantages (that I can see):
- Save config/project as its changed and not rushed at quit time (and
the quit save doesn't happen in the absence of a working, portable, session management capability)
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.
(There is more to it, but I don't want to start the
multiply instances discussion now.)
Me neither. For me thats dangerous and deprecated :)
- 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.
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.
In what situation saving the
session will damage Geany configuration, but saving the interface sessings on exit will not?..
Did I say the current situation was right? Thats why I am proposing to change it :)
The only disadvantage for user config (that I can see) is that it adds one file, say geany.session.conf alongside geany.conf
For project sessions just using another file in the same place as the project file is more of a problem since project files can be in the project tree and some people like to save them in VCS. So users would have to make sure that their git.ignore (or whatever the other VCSes use) is edited each time so that the session file isn't saved in the VCS.
A better option, especially since sessions are inherently user related, is to store them in the user config location (or subdirectory thereof). But how to link these files to the project files?
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.
Oh c'mon. Is adding a file to git.ignore so serious problem that we need to implement redirection and bother to control the list of session files? The "ignore" in VCS-es is specifically _designed_ to ignore files. The users that prefer to keep their foo.geany in the project directory, but don't want them in the VCS, have already exlcuded it. The ones that prefer to keep foo.geany in the VCS will not ignore the .session file either. So we are only speaking about the ones that want the future settings-only project file, 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.
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. :)
This proposal isn't about a proper session management capability, there isn't one that works on enough platforms to be worth including.
Unfortunately. 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 :)
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.
So that with periodic save, in the situations that Lex will describe (#2 above), not only the session, but your interface options will break too.
Which settings are session and which are config is somewhat arbitrary, but I think at least some of the interface settings could profitably be per session, the others saved on change.
OTOH, geany.config and the project files will be very stable...
Which is the idea :)
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. :)
Cheers Lex
-- E-gards: Jimmy _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel