Hi All,
Its about that time of year when we have our annual discussion on separating session data from config/project data :)
By session data I mean the list of currently open files and MRU list.
The advantages (that I can see):
1. 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)
2. 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.
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. That way, when a project is opened, it is easy to uniquely find the session file if it exists. Using things like filenames, project names etc will always have clashes. Libuuid is used by GTK so it will always be available on all platforms we use and so making the UUID is one call. (Pity GTK doesn't expose it though)
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.
This proposal isn't about a proper session management capability, there isn't one that works on enough platforms to be worth including.
Any thoughts welcome.
Cheers Lex
On 12-09-09 09:36 PM, Lex Trotman wrote:
Hi All,
Its about that time of year when we have our annual discussion on separating session data from config/project data :)
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.
[...]
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.
Could add a "Tools->Purge Session files" or something if they're left to grow like weeds.
This proposal isn't about a proper session management capability, there isn't one that works on enough platforms to be worth including.
Any thoughts welcome.
Generally I think it's a good idea, would be interested in testing some implementation(s).
Cheers, Matthew Brush
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. :)
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. (There is more to it, but I don't want to start the multiply instances discussion now.)
- 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. In what situation saving the session will damage Geany configuration, but saving the interface sessings on exit will not?..
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. Surely they can make a little effort to achieve that?..
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.
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. OTOH, geany.config and the project files will be very stable...
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...)
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
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.)
[...]
So what should geany.conf contain? If the interface preferences remain there, we still must "rush at quit time" to save it...
Getting buried in specifics far too early, need to get the principles right first, but in general "interface" things that are changed rarely, like window layouts, would be in geany.conf, things like search data is definitely session. I'm sure there is more discussion here :)
[...]> ...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.
Yes, losing session data is mildly annoying, but losing long term settings is much more annoying. Again this distinction helps to separate which goes where.
[...]
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.
No, by "public" I just mean used by more than one person. And the fact that you have to either give away sessions, or put up with the project file changing each time you commit, could be a big part of why "nobody" uses that capability.
[...]
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.
Its a very common use-case to have the project files in the project tree. And it has become a general user expectation from other IDEs. And since we keep adding settings to the project files they are slowly becoming "project" files, rather than named session files that they were originally. Maybe they should have been called "named sessions" not projects, then everyone, me included, might not put so many settings in them. Then we wouldn't have to separate them again as is the point of the discussion.
Moving the projects and sessions in ~/projects, ${GEANY_CONFIG}/projects or wherever can somehow be justified. But having the projects here-or- there,
Projects are already here or there, thats not a change.
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.
Maybe its because I want to have both project files in VCS *and* project sessions without VCS noise, I learned in my MBA that, given a choice, take both :)
Better implementation suggestions welcome, its just the only one I came up with so far that does the job :)
[...]
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.
Yeah, thats why it should be wrapped up in some library (even if its a part of Geany) we don't want more #ifdefs in the general code.
I have previously asked for somebody to check if SM works under GNOME3 and Unity, but there was no response.
Can't help, don't have either.
[...]
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.)
Wasn't the intention of the discussion, but if it comes as a side effect fine.
[...]
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.
As I said, the user settings is easy, except for agreeing what goes in which file :)
(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.)
Plugins access to the project files is another discussion.
Cheers Lex
-- E-gards: Jimmy _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Wed, 12 Sep 2012 11:35:48 +1000 Lex Trotman elextr@gmail.com wrote:
[...]
So what should geany.conf contain? If the interface preferences remain there, we still must "rush at quit time" to save it...
Getting buried in specifics far too early, need to get the principles right first, but in general "interface" things that are changed rarely, like window layouts, would be in geany.conf, things like search data is definitely session. I'm sure there is more discussion here :)
Since it's an early discussion, I have a proposition for something I always wanted to have in the other IDE-s: several sessions per project.
For example, currently I have one project for Geany sm, another for regenerating my patches (the ones in sf patch tracker except sm, plus some others), and I usually open another (temporary) project when working on something else. Aside from the session, these projects are, and must be, absolutely identical. So:
The project menu contains a "Sessions" item, which displays a dialog to add/remove/switch to a session.
Each new project starts with a Default session, which can not be deleted.
Whoever prefers a project for each session can simply ignore "Sessions".
Possible storage:
$project.geany contains an UUID.
$confdir/UUID contains a list of names sessions and the interface options, including the current session name.
The larger a project, the more useful several sessions will be.
I'm not sure about several project-less sessions. It will be somewhat confusing - should I use a project, or only a session? - but OTOH, the line between projects and sessions will be drawn once and for all: a project has it's own set of options, while a session is simply a set of files.
RFC.
(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.)
Plugins access to the project files is another discussion.
They must be discussed at some later point, we have "save-settings" and "project-save".
Sorry for the delay in responding, somehow the mail didn't get marked as new and I only just noticed it.
On 14 September 2012 03:15, Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
On Wed, 12 Sep 2012 11:35:48 +1000 Lex Trotman elextr@gmail.com wrote:
[...]
So what should geany.conf contain? If the interface preferences remain there, we still must "rush at quit time" to save it...
Getting buried in specifics far too early, need to get the principles right first, but in general "interface" things that are changed rarely, like window layouts, would be in geany.conf, things like search data is definitely session. I'm sure there is more discussion here :)
Since it's an early discussion, I have a proposition for something I always wanted to have in the other IDE-s: several sessions per project.
Well, if sessions and projects are separated then it might be a useful extension.
For example, currently I have one project for Geany sm, another for regenerating my patches (the ones in sf patch tracker except sm, plus some others), and I usually open another (temporary) project when working on something else. Aside from the session, these projects are, and must be, absolutely identical. So:
The project menu contains a "Sessions" item, which displays a dialog to add/remove/switch to a session.
Each new project starts with a Default session, which can not be deleted.
Whoever prefers a project for each session can simply ignore "Sessions".
Possible storage:
$project.geany contains an UUID.
$confdir/UUID contains a list of names sessions and the interface options, including the current session name.
Apart from having an intermediate link file between projects and sessions making an extra step, what is the difference between this implementation and the one I originally proposed? The one that you said was too complex, even before you added the intermediate step? :)
For those following along at home, the problem is how to find the session file(s) when the project is opened, without saving the path in the project file. Any alternate ideas welcome.
The larger a project, the more useful several sessions will be.
I'm not sure about several project-less sessions. It will be somewhat confusing - should I use a project, or only a session? - but OTOH, the line between projects and sessions will be drawn once and for all: a project has it's own set of options, while a session is simply a set of files.
Thats certainly another way of looking at it, yes. Makes it simple to implement and understand. But I bet it won't last :)
RFC.
(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.)
Plugins access to the project files is another discussion.
They must be discussed at some later point, we have "save-settings" and "project-save".
I guess plugins can still access project files, but either they can't access session files (preferred initial position until someone needs it) or another signal is needed.
Cheers Lex
-- E-gards: Jimmy _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Am 11.09.2012 19:48, schrieb Dimitar Zhekov:
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.
That's because it's not a sensible thing to do currently, because session information is in $project.geany as well. See $topic.
Best regards.
Le 10/09/2012 06:36, Lex Trotman a écrit :
Hi All,
Its about that time of year when we have our annual discussion on separating session data from config/project data :)
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)
TBH until proper multi-instance configuration sharing, I don't see what's so great with "not rushing at quit time" since we already also save one pref/project-prefs apply.
- 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.
Why would the session save go wrong? There is no reason I can think of that would make periodical session saving less safe than settings saving.
The only disadvantage for user config (that I can see) is that it adds one file, say geany.session.conf alongside geany.conf
That's definitely not a problem in the $GEANY_CONF_DIR.
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.
I agree with Dimitar, if somebody is able to add a file to a VCS she must be able *not* to add that file. Is there *any* VCS around that adds files without asking before, unless explicitly told so? Nobody sane will do `git add .` or `svn add .` for committing changes.
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. That way, when a project is opened, it is easy to uniquely find the session file if it exists. Using things like filenames, project names etc will always have clashes. Libuuid is used by GTK so it will always be available on all platforms we use and so making the UUID is one call. (Pity GTK doesn't expose it though)
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.
PLEASE, no. This is IMO the easiest solution to make the fix worst than the issue. Not removing files would leave more and more useless files (not an option), and cleaning is almost impossible to do well -- your proposition might remove actually used sessions as easily as having > MAX_SESSION projects (not an option either).
This proposal isn't about a proper session management capability, there isn't one that works on enough platforms to be worth including.
Any thoughts welcome.
Reading my mail above, I see it might sound like I think $subject is just a bad idea. No, I think it would be a quite good thing, and for weird people adding project files to their VCS [1] would be most welcome. I also think that separating session and settings will probably help to someday improve the settings sharing between instances.
The only problem is that I don't see immediate and tremendous gain, and that I don't like the proposed solution -- not that I have a better one. On the first point, I'd be happy to be proven wrong though, maybe I just don't see the light.
Regards, Colomban
[1] Yes, I don't really see the point. OK, the settings we have in project files might be useful for the project. Indentation type & with, and EOL style. First two are saved in each file by well known editors (vim, emacs). Generally when people put project files in their VCS it's because those project files are used as build system too.
On 12-10-01 07:43 AM, Colomban Wendling wrote:
Le 10/09/2012 06:36, Lex Trotman a écrit :
Hi All,
Its about that time of year when we have our annual discussion on separating session data from config/project data :)
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)
TBH until proper multi-instance configuration sharing, I don't see what's so great with "not rushing at quit time" since we already also save one pref/project-prefs apply.
Open your favourite project in Geany and open a specific set of files you need to work on a task, get the order of the files just right, adjust the Geany window position and size and then get your find dialogs positioned just perfect on your second screen. Now unplug your computer. You will see :)
For me it takes more time to get Geany back in order (finding project file since it's not saved in the recent project list[1], finding open files related to current task, since they aren't saved in recent files list[2], etc.) than it does to restart the whole computer.
P.S. My workaround (because my computer crashes a lot due to Flash) is to get everything set up how I want for the current task, and then to close Geany normally to force saving of all settings and then to reopen it :)
Cheers, Matthew Brush
[1] Well for favourite projects it might be saved, but not if it's a new project that hasn't experienced a closing before.
[2] Unless you count the lame GTK+ open dialog recent files list which is quite useless.
Le 01/10/2012 23:15, Matthew Brush a écrit :
On 12-10-01 07:43 AM, Colomban Wendling wrote:
Le 10/09/2012 06:36, Lex Trotman a écrit :
Hi All,
Its about that time of year when we have our annual discussion on separating session data from config/project data :)
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)
TBH until proper multi-instance configuration sharing, I don't see what's so great with "not rushing at quit time" since we already also save one pref/project-prefs apply.
Open your favourite project in Geany and open a specific set of files you need to work on a task, get the order of the files just right, adjust the Geany window position and size and then get your find dialogs positioned just perfect on your second screen. Now unplug your computer. You will see :)
For me it takes more time to get Geany back in order (finding project file since it's not saved in the recent project list[1], finding open files related to current task, since they aren't saved in recent files list[2], etc.) than it does to restart the whole computer.
P.S. My workaround (because my computer crashes a lot due to Flash) is to get everything set up how I want for the current task, and then to close Geany normally to force saving of all settings and then to reopen it :)
As I read Lex's sentence, he spoke about settings, not open files. And anyway, I don't see what separating file list from the rest of the config change in that matter. It doesn't magically brings immediate/periodical saving of the file list, and we can very well save everything *including the file list* without that. So I don't see why it's an argument in favor (or against) $subject.
Cheers, Matthew Brush
[1] Well for favourite projects it might be saved, but not if it's a new project that hasn't experienced a closing before.
[2] Unless you count the lame GTK+ open dialog recent files list which is quite useless. _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On 12-10-01 03:05 PM, Colomban Wendling wrote:
Le 01/10/2012 23:15, Matthew Brush a écrit :
On 12-10-01 07:43 AM, Colomban Wendling wrote:
Le 10/09/2012 06:36, Lex Trotman a écrit :
Hi All,
Its about that time of year when we have our annual discussion on separating session data from config/project data :)
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)
TBH until proper multi-instance configuration sharing, I don't see what's so great with "not rushing at quit time" since we already also save one pref/project-prefs apply.
Open your favourite project in Geany and open a specific set of files you need to work on a task, get the order of the files just right, adjust the Geany window position and size and then get your find dialogs positioned just perfect on your second screen. Now unplug your computer. You will see :)
For me it takes more time to get Geany back in order (finding project file since it's not saved in the recent project list[1], finding open files related to current task, since they aren't saved in recent files list[2], etc.) than it does to restart the whole computer.
P.S. My workaround (because my computer crashes a lot due to Flash) is to get everything set up how I want for the current task, and then to close Geany normally to force saving of all settings and then to reopen it :)
As I read Lex's sentence, he spoke about settings, not open files. And anyway, I don't see what separating file list from the rest of the config change in that matter. It doesn't magically brings immediate/periodical saving of the file list, and we can very well save everything *including the file list* without that. So I don't see why it's an argument in favor (or against) $subject.
It's an argument in favour of "not rushing at quite time" (ie. periodically saving the .conf file(s) instead of only on closing) since you said you didn't see what was so great about it.
Cheers, Matthew Brush
Le 02/10/2012 00:26, Matthew Brush a écrit :
On 12-10-01 03:05 PM, Colomban Wendling wrote:
Le 01/10/2012 23:15, Matthew Brush a écrit :
On 12-10-01 07:43 AM, Colomban Wendling wrote:
Le 10/09/2012 06:36, Lex Trotman a écrit :
Hi All,
Its about that time of year when we have our annual discussion on separating session data from config/project data :)
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)
TBH until proper multi-instance configuration sharing, I don't see what's so great with "not rushing at quit time" since we already also save one pref/project-prefs apply.
Open your favourite project in Geany and open a specific set of files you need to work on a task, get the order of the files just right, adjust the Geany window position and size and then get your find dialogs positioned just perfect on your second screen. Now unplug your computer. You will see :)
For me it takes more time to get Geany back in order (finding project file since it's not saved in the recent project list[1], finding open files related to current task, since they aren't saved in recent files list[2], etc.) than it does to restart the whole computer.
P.S. My workaround (because my computer crashes a lot due to Flash) is to get everything set up how I want for the current task, and then to close Geany normally to force saving of all settings and then to reopen it :)
As I read Lex's sentence, he spoke about settings, not open files. And anyway, I don't see what separating file list from the rest of the config change in that matter. It doesn't magically brings immediate/periodical saving of the file list, and we can very well save everything *including the file list* without that. So I don't see why it's an argument in favor (or against) $subject.
It's an argument in favour of "not rushing at quite time" (ie.
yes, but I don't see the probably obvious link between "not rushing at quit time" and $subject.
periodically saving the .conf file(s) instead of only on closing) since you said you didn't see what was so great about it.
what I meant is that *we already save when prefs changes* so I don't see what's the problem with saving *also* at quit time. Anyway, I think you got my point, I got yours so there's probably no need to go further in the explanations -- but maybe why $subject helps for that matter.
Cheers, Matthew Brush
Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On 2 October 2012 00:43, Colomban Wendling lists.ban@herbesfolles.orgwrote:
Le 10/09/2012 06:36, Lex Trotman a écrit :
Hi All,
Its about that time of year when we have our annual discussion on separating session data from config/project data :)
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)
TBH until proper multi-instance configuration sharing, I don't see what's so great with "not rushing at quit time" since we already also save one pref/project-prefs apply.
Are all settings saved on apply? not just the prefs/project prefs ones? I thought there were some that still didn't for one reason or another, maybe that should be changed as a separate thing anyway, in which case you are right, the "rush" only applies to session data.
- 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.
Why would the session save go wrong? There is no reason I can think of that would make periodical session saving less safe than settings saving.
Read "not happen" for "go wrong" then. Not happening because Geany is killed by the WM/user is the most common way saving settings/sessions goes wrong. If the save happens its unlikely to be a problem so long as its on a local disk which isn't full. If the project file is on a network share or worse still, on a ftpfs/sshfs/httpfs file system then lots can "go wrong" and the chances are increased by periodic saving (not to mention potential performance issues).
The only disadvantage for user config (that I can see) is that it adds one file, say geany.session.conf alongside geany.conf
That's definitely not a problem in the $GEANY_CONF_DIR.
Agree, but I had to think of *some* disadvantage to seem fair and even handed :)
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.
I agree with Dimitar, if somebody is able to add a file to a VCS she must be able *not* to add that file. Is there *any* VCS around that adds files without asking before, unless explicitly told so? Nobody sane will do `git add .` or `svn add .` for committing changes.
Well, git add is part of the normal workflow, editing .gitignore isn't. But I guess if the project file is being stored in VCS then you would expect .gitignore (or whatever svn etc use) to be edited already to exclude .session and .gitignore to be stored in the VCS as well.
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. That way, when a project is opened, it is easy to uniquely find the session file if it exists. Using things like filenames, project names etc will always have clashes. Libuuid is used by GTK so it will always be available on all platforms we use and so making the UUID is one call. (Pity GTK doesn't expose it though)
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.
PLEASE, no. This is IMO the easiest solution to make the fix worst than the issue. Not removing files would leave more and more useless files (not an option), and cleaning is almost impossible to do well -- your proposition might remove actually used sessions as easily as having > MAX_SESSION projects (not an option either).
Heh, heh, I was going to just say, sort by access time and delete the oldest one before creating a new one, but then I remembered that all my disks are mounted noatime :)
This proposal isn't about a proper session management capability, there isn't one that works on enough platforms to be worth including.
Any thoughts welcome.
Reading my mail above, I see it might sound like I think $subject is just a bad idea. No, I think it would be a quite good thing, and for weird people adding project files to their VCS [1] would be most welcome. I also think that separating session and settings will probably help to someday improve the settings sharing between instances.
The only problem is that I don't see immediate and tremendous gain, and that I don't like the proposed solution -- not that I have a better one.
Damn! The point of starting the thread was to see what other implementations there are :) If I thought it was a perfect solution I'd have made a PR by now :)
On the first point, I'd be happy to be proven wrong though, maybe I just don't see the light.
Regards, Colomban
[1] Yes, I don't really see the point. OK, the settings we have in project files might be useful for the project. Indentation type & with, and EOL style. First two are saved in each file by well known editors (vim, emacs). Generally when people put project files in their VCS it's because those project files are used as build system too.
Yes ATM the main use-case is build system settings, but that could also change if it was easier to share project files.
Cheers Lex
Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Le 02/10/2012 05:03, Lex Trotman a écrit :
On 2 October 2012 00:43, Colomban Wendling <lists.ban@herbesfolles.org mailto:lists.ban@herbesfolles.org> wrote:
Le 10/09/2012 06:36, Lex Trotman a écrit : > Hi All, > > Its about that time of year when we have our annual discussion on > separating session data from config/project data :) > > By session data I mean the list of currently open files and MRU list. > > The advantages (that I can see): > > 1. 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) TBH until proper multi-instance configuration sharing, I don't see what's so great with "not rushing at quit time" since we already also save one pref/project-prefs apply.Are all settings saved on apply? not just the prefs/project prefs ones?
I doubt we make a difference when saving the config file -- since as you said yourself saving only a part of a keyfile isn't that easy --, but I don't know for sure.
I thought there were some that still didn't for one reason or another, maybe that should be changed as a separate thing anyway, in which case you are right, the "rush" only applies to session data.
> 2. 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. Why would the session save go wrong? There is no reason I can think of that would make periodical session saving less safe than settings saving.Read "not happen" for "go wrong" then. Not happening because Geany is killed by the WM/user is the most common way saving settings/sessions goes wrong.
Again, I don't see the point. If saving the configuration doesn't happen because Geany get killed, if it was separated and still only saved on change wouldn't change anything.
If the save happens its unlikely to be a problem so long as its on a local disk which isn't full. If the project file is on a network share or worse still, on a ftpfs/sshfs/httpfs file system then lots can "go wrong" and the chances are increased by periodic saving
Oh dear, configuration on an unsafe remote. OK, that's an argument why saving config periodically might not be that safe -- although normally a network failures would result in *not* saving the file, not corrupting it (given that we use an atomic write like g_file_set_contents()).
(not to mention potential performance issues).
Well, performance issue is inherent to periodic saving, it being session only or whole config doesn't change anything.
> The only disadvantage for user config (that I can see) is that it adds > one file, say geany.session.conf alongside geany.conf That's definitely not a problem in the $GEANY_CONF_DIR.Agree, but I had to think of *some* disadvantage to seem fair and even handed :)
Hehe, you should've rather have listed advantages ;)
> 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. I agree with Dimitar, if somebody is able to add a file to a VCS she must be able *not* to add that file. Is there *any* VCS around that adds files without asking before, unless explicitly told so? Nobody sane will do `git add .` or `svn add .` for committing changes.Well, git add is part of the normal workflow, editing .gitignore isn't.
Yeah, but you *choose* what you add, you don't add the whole project directory but maybe on the first import.
But I guess if the project file is being stored in VCS then you would expect .gitignore (or whatever svn etc use) to be edited already to exclude .session and .gitignore to be stored in the VCS as well.
> 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. That way, when a project is > opened, it is easy to uniquely find the session file if it exists. > Using things like filenames, project names etc will always have > clashes. Libuuid is used by GTK so it will always be available on all > platforms we use and so making the UUID is one call. (Pity GTK doesn't > expose it though) > > 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. PLEASE, no. This is IMO the easiest solution to make the fix worst than the issue. Not removing files would leave more and more useless files (not an option), and cleaning is almost impossible to do well -- your proposition might remove actually used sessions as easily as having > MAX_SESSION projects (not an option either).Heh, heh, I was going to just say, sort by access time and delete the oldest one before creating a new one, but then I remembered that all my disks are mounted noatime :)
Even if access time was reliable you'll never know how many project files one has, and you can't rely on the user changing some weird magic value for them not to loose session data.
> This proposal isn't about a proper session management capability, > there isn't one that works on enough platforms to be worth including. > > Any thoughts welcome. Reading my mail above, I see it might sound like I think $subject is just a bad idea. No, I think it would be a quite good thing, and for weird people adding project files to their VCS [1] would be most welcome. I also think that separating session and settings will probably help to someday improve the settings sharing between instances. The only problem is that I don't see immediate and tremendous gain, and that I don't like the proposed solution -- not that I have a better one.Damn! The point of starting the thread was to see what other implementations there are :) If I thought it was a perfect solution I'd have made a PR by now :)
No no, what I asked was "why is $subject useful?", because I thought (and somewhat still think) that the arguments weren't for $subject but for "periodic save" ;)
On the first point, I'd be happy to be proven wrong though, maybe I just don't see the light. Regards, Colomban [1] Yes, I don't really see the point. OK, the settings we have in project files might be useful for the project. Indentation type & with, and EOL style. First two are saved in each file by well known editors (vim, emacs). Generally when people put project files in their VCS it's because those project files are used as build system too.Yes ATM the main use-case is build system settings,
Hum, what I meant that our project files *are no* a build system, so the current use case I see is only indentation settings and maybe line ending settings.
Cheers, Colomban
but that could also change if it was easier to share project files.
Cheers Lex
[...]
Are all settings saved on apply? not just the prefs/project prefs ones?
I doubt we make a difference when saving the config file -- since as you said yourself saving only a part of a keyfile isn't that easy --, but I don't know for sure.
I didn't mean that only part of the file was changed, I meant that the configuration save is triggered by *all* the dialogs and menu items that can change settings, for eg unless I missed it, the set build commands dialog doesn't trigger a configuration save after an ok (though it does save filetypes).
I thought there were some that still didn't for one reason or another, maybe that should be changed as a separate thing anyway, in which case you are right, the "rush" only applies to session data.
Every UI or programatic change to a setting needs to be checked that the configuration/project is saved, unless you have already done that?
I agree that we should do that but its another discussion, although it does affect this one.
[...]
If the save happens its unlikely to be a problem so long as its on a local disk which isn't full. If the project file is on a network share or worse still, on a ftpfs/sshfs/httpfs file system then lots can "go wrong" and the chances are increased by periodic saving
Oh dear, configuration on an unsafe remote. OK, that's an argument why saving config periodically might not be that safe -- although normally a network failures would result in *not* saving the file, not corrupting it (given that we use an atomic write like g_file_set_contents()).
For project files in the tree it is reasonable that they may be on the remote, and well, on those funny file systems, g_file_set_contents() doesn't work :(
My cunning? implementation puts the session file in the user config directory, which *hopefully* is local, or at least on a fast reliable nfs/samba share.
(not to mention potential performance issues).
Well, performance issue is inherent to periodic saving, it being session only or whole config doesn't change anything.
But only the session needs to be periodically saved, and that should be local in my split implementation.
[...]
> For project sessions just using another file in the same place asthe
> 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 userswould
> have to make sure that their git.ignore (or whatever the otherVCSes
> use) is edited each time so that the session file isn't saved inthe
> VCS. I agree with Dimitar, if somebody is able to add a file to a VCS she must be able *not* to add that file. Is there *any* VCS around that adds files without asking before, unless explicitly told so? Nobody sane will do `git add .` or `svn add .` for committing changes.Well, git add is part of the normal workflow, editing .gitignore isn't.
Yeah, but you *choose* what you add, you don't add the whole project directory but maybe on the first import.
But I guess if the project file is being stored in VCS then you would expect .gitignore (or whatever svn etc use) to be edited already to exclude .session and .gitignore to be stored in the VCS as well.
What I mean here is that I agree that putting a session file in the same directory as the project file isn't a big issue.
[...] PLEASE, no. This is IMO the easiest solution to make the fix worst
than
the issue. Not removing files would leave more and more uselessfiles
(not an option), and cleaning is almost impossible to do well -- your proposition might remove actually used sessions as easily as having > MAX_SESSION projects (not an option either).Heh, heh, I was going to just say, sort by access time and delete the oldest one before creating a new one, but then I remembered that all my disks are mounted noatime :)
Even if access time was reliable you'll never know how many project files one has, and you can't rely on the user changing some weird magic value for them not to loose session data.
I wasn't being so complex as you seem to think, I was just saying keep the last N project related sessions, like the recent files list, we could even use the recent projects list and only keep sessions for those?
> This proposal isn't about a proper session management capability, > there isn't one that works on enough platforms to be worthincluding.
> > Any thoughts welcome. Reading my mail above, I see it might sound like I think $subject is just a bad idea. No, I think it would be a quite good thing, and for weird people adding project files to their VCS [1] would be most welcome. I also think that separating session and settings will probably help to someday improve the settings sharing betweeninstances.
The only problem is that I don't see immediate and tremendous gain,and
that I don't like the proposed solution -- not that I have a betterone.
Damn! The point of starting the thread was to see what other implementations there are :) If I thought it was a perfect solution I'd have made a PR by now :)
No no, what I asked was "why is $subject useful?", because I thought (and somewhat still think) that the arguments weren't for $subject but for "periodic save" ;)
Heh, yeah the two issues are a bit mixed,
1. as I said to Dimitar, the main reason for the proposal is to put projects in VCS without the noise from session data while still allowing users project sessions. 2. any possible improvements to the reliability of session saving via periodic save or even save on file open/close are a secondary (but still useful) by product.
On the first point, I'd be happy to be proven wrong though, maybe I just don't see the light. Regards, Colomban [1] Yes, I don't really see the point. OK, the settings we have in project files might be useful for the project. Indentation type &with,
and EOL style. First two are saved in each file by well knowneditors
(vim, emacs). Generally when people put project files in their VCSit's
because those project files are used as build system too.Yes ATM the main use-case is build system settings,
Hum, what I meant that our project files *are no* a build system, so the current use case I see is only indentation settings and maybe line ending settings.
I don't understand what you are saying here, the project files *do* store build commands, if your project uses different tools, eg scons not make, then that is stored in the project file and gets restored in Geany whenever you open the project file. This is *very* useful and is the original reason I extended the Geany "build system" back in 0.19. And having that information in a project file in VCS distributed with the project source is then *very* useful as well, but ATM you have to turn off project sessions to avoid lots of noise commits, and so we are back to the original reason for the thread :)
Cheers Lex
Cheers, Colomban
but that could also change if it was easier to share project files.
Cheers Lex
Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Tue, 2 Oct 2012 13:03:00 +1000 Lex Trotman elextr@gmail.com wrote:
Are all settings saved on apply? not just the prefs/project prefs ones? I thought there were some that still didn't for one reason or another, maybe that should be changed as a separate thing anyway, in which case you are right, the "rush" only applies to session data.
Edit -> Preferences -> OK|Apply saves the entire geany.conf: dialog preferences, UI settings and file list.
Project -> Properties -> OK saves the entire $project.conf: project settings and file list.
File -> Quit does both.
Saving dialog preferences and project settings on Quit does not make real sense, but it's the same file, so there is no reason to separate them. Yet they are internally separate (static) functions, see keyfile.c:configuration_save() and project.c:write_config().
--
No interest in having 2+ sessions for a project?..
On 4 October 2012 03:06, Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
On Tue, 2 Oct 2012 13:03:00 +1000 Lex Trotman elextr@gmail.com wrote:
Are all settings saved on apply? not just the prefs/project prefs ones?
I
thought there were some that still didn't for one reason or another,
maybe
that should be changed as a separate thing anyway, in which case you are right, the "rush" only applies to session data.
Edit -> Preferences -> OK|Apply saves the entire geany.conf: dialog preferences, UI settings and file list.
Project -> Properties -> OK saves the entire $project.conf: project settings and file list.
File -> Quit does both.
AFAICT build->set build commands->ok does neither, it assumes save at the end, thats the problem, and why the save on quit is still needed and why failing to save on shutdown is a breakage. The build one is the one I know, my question is then what other dialogs or menu items etc change settings but fail to cause a save because they still assume save on exit?
Saving dialog preferences and project settings on Quit does not make real sense, but it's the same file, so there is no reason to separate them. Yet they are internally separate (static) functions, see keyfile.c:configuration_save() and project.c:write_config().
Not sure what you mean by "its the same file", its not the same file and doesn't have the same contents?
Cheers Lex
--
No interest in having 2+ sessions for a project?..
-- E-gards: Jimmy _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Thu, 4 Oct 2012 10:51:29 +1000 Lex Trotman elextr@gmail.com wrote:
Are all settings saved on apply? not just the prefs/project prefs ones?
Edit -> Preferences -> OK|Apply saves the entire geany.conf: dialog preferences, UI settings and file list.
Project -> Properties -> OK saves the entire $project.conf: project settings and file list.
File -> Quit does both.
AFAICT build->set build commands->ok does neither, it assumes save at the end, thats the problem, and why the save on quit is still needed and why failing to save on shutdown is a breakage.
Unless you are looking at some really old sources, a project-less build -> set build commands -> ok saves the changes under filedefs/ immediately ("save filetypes now" in the mailing list). Just fill some commands, OK, and grep ~/.config/geany.
Save on Quit is needed for the interface preferences, such as View -> Show Sidebar, and the project-less file list. Unfortunately, the file list is saved even with a project open, but attempts to fix it trigger a "multiply instances" discussion.
The build one is the one I know, my question is then what other dialogs or menu items etc change settings but fail to cause a save because they still assume save on exit?
The ones from save_ui_prefs(). You can't reasonably expect a file save each time the side bar is shown/hidden, or the main window is moved/sized...
Saving dialog preferences and project settings on Quit does not make real sense, but it's the same file, so there is no reason to separate them. Yet they are internally separate (static) functions, see keyfile.c:configuration_save() and project.c:write_config().
Not sure what you mean by "its the same file", its not the same file and doesn't have the same contents?
The dialog preferences are in the same file (geany.conf) as UI settings and the project-less file list, which need save on quit; and the project properties are in the same file ($project.geany) as the project file list, which needs save on quit. So (not) saving the formers does not make real difference, the entire file must be re-written anyway.
On 10 October 2012 06:58, Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
On Thu, 4 Oct 2012 10:51:29 +1000 Lex Trotman elextr@gmail.com wrote:
Are all settings saved on apply? not just the prefs/project prefs
ones?
Edit -> Preferences -> OK|Apply saves the entire geany.conf: dialog preferences, UI settings and file list.
Project -> Properties -> OK saves the entire $project.conf: project settings and file list.
File -> Quit does both.
AFAICT build->set build commands->ok does neither, it assumes save at the end, thats the problem, and why the save on quit is still needed and why failing to save on shutdown is a breakage.
Unless you are looking at some really old sources,
Oh dear it is *yesterdays* git :)
a project-less build -> set build commands -> ok saves the changes under filedefs/ immediately ("save filetypes now" in the mailing list). Just fill some commands, OK, and grep ~/.config/geany.
It doesn't save the config file though, so no non-filetype settings saved.
Save on Quit is needed for the interface preferences, such as View -> Show Sidebar, and the project-less file list. Unfortunately, the file list is saved even with a project open, but attempts to fix it trigger a "multiply instances" discussion.
Yes, Geany does *not* do multiple instances properly, therefore being ignored for now. If you do multiple instances with the same project or config file it will break (ie not do what you wanted), its just a matter of when.
The build one is the one I know, my question is then what other dialogs
or
menu items etc change settings but fail to cause a save because they
still
assume save on exit?
The ones from save_ui_prefs(). You can't reasonably expect a file save each time the side bar is shown/hidden, or the main window is moved/sized...
1. why not? 2. which is why they should be in the session file not the prefs file, also, to me, if I arranged windows to fit what I was looking at, it would be good it that was restored with the project session as well.
Saving dialog preferences and project settings on Quit does not make real sense, but it's the same file, so there is no reason to separate them. Yet they are internally separate (static) functions, see keyfile.c:configuration_save() and project.c:write_config().
Not sure what you mean by "its the same file", its not the same file and doesn't have the same contents?
The dialog preferences are in the same file (geany.conf) as UI settings and the project-less file list, which need save on quit; and the project properties are in the same file ($project.geany) as the project file list, which needs save on quit. So (not) saving the formers does not make real difference, the entire file must be re-written anyway.
Yeah, which is why I want to split 'em
Cheers Lex
-- E-gards: Jimmy _______________________________________________ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
On Wed, 10 Oct 2012 10:07:19 +1100 Lex Trotman elextr@gmail.com wrote:
On 10 October 2012 06:58, Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
a project-less build -> set build commands -> ok saves the changes under filedefs/ immediately ("save filetypes now" in the mailing list). Just fill some commands, OK, and grep ~/.config/geany.
It doesn't save the config file though, so no non-filetype settings saved.
Yes. Curiosly enough, these are "ui prefs"...
Save on Quit is needed for the interface preferences, such as View -> Show Sidebar, and the project-less file list. Unfortunately, the file list is saved even with a project open, but attempts to fix it trigger a "multiply instances" discussion.
Yes, Geany does *not* do multiple instances properly, therefore being ignored for now. If you do multiple instances with the same project or config file it will break (ie not do what you wanted), its just a matter of when.
But not saving the file list in geany.conf, if we have a project open and so the list is already saved in $project.geany, is _not_ actually related to multiply instances. Maybe I should propose it again, it's a very simple change.
The ones from save_ui_prefs(). You can't reasonably expect a file save each time the side bar is shown/hidden, or the main window is moved/sized...
- why not?
Why not save the document in a temporary file on each SCN_MODIFIED? You will never lose a single edit action, and surely a current document content is no less important than, say, the sidebar state. :)
- which is why they should be in the session file not the prefs file,
also, to me, if I arranged windows to fit what I was looking at, it would be good it that was restored with the project session as well.
Definitely, from using xsm, I know very well how convinient per-project interface is. But it doesn't really require a session file - we can store the ui_prefs in our current project file, which is saved on project close and geany quit.
(Now that I think of it, multiply sessions per project do not require a session file either.)
Splitting has it's own merits, of course, and if implemented, the ui prefs should logically go in the session file.
On 11 October 2012 06:06, Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
On Wed, 10 Oct 2012 10:07:19 +1100 Lex Trotman elextr@gmail.com wrote:
On 10 October 2012 06:58, Dimitar Zhekov dimitar.zhekov@gmail.com
wrote:
a project-less build -> set build commands -> ok saves the changes under filedefs/ immediately ("save filetypes now" in the mailing list). Just fill some commands, OK, and grep ~/.config/geany.
It doesn't save the config file though, so no non-filetype settings
saved.
Yes. Curiosly enough, these are "ui prefs"...
Eh? not sure I understand you? In case I wasn't clear if in the build->set build commands dialog you modify the make command to say fred, click ok, cat geany.conf it isn't stored, close Geany, cat again and it is stored. That is it is not saved on ok.
Save on Quit is needed for the interface preferences, such as View -> Show Sidebar, and the project-less file list. Unfortunately, the file list is saved even with a project open, but attempts to fix it trigger a "multiply instances" discussion.
Yes, Geany does *not* do multiple instances properly, therefore being ignored for now. If you do multiple instances with the same project or config file it will break (ie not do what you wanted), its just a matter
of
when.
But not saving the file list in geany.conf, if we have a project open and so the list is already saved in $project.geany, is _not_ actually related to multiply instances. Maybe I should propose it again, it's a very simple change.
Unless the project was open in multiple instances, then you can have issues with both geany.conf and project.geany, so no improvement I'm afraid.
The ones from save_ui_prefs(). You can't reasonably expect a file save each time the side bar is shown/hidden, or the main window is moved/sized...
- why not?
Why not save the document in a temporary file on each SCN_MODIFIED? You will never lose a single edit action, and surely a current document content is no less important than, say, the sidebar state. :)
Ok, but why not save the entire program state after each instruction :-D
- which is why they should be in the session file not the prefs file,
also, to me, if I arranged windows to fit what I was looking at, it would be good it that was restored with the project session as well.
Definitely, from using xsm, I know very well how convinient per-project interface is. But it doesn't really require a session file - we can store the ui_prefs in our current project file, which is saved on project close and geany quit.
Agree, though its a separate discussion from this one about separation. (and much simpler)
(Now that I think of it, multiply sessions per project do not require a session file either.)
Agree
Splitting has it's own merits, of course, and if implemented, the ui prefs should logically go in the session file.
Agree
So far the only algorithms presented so far are:
1. sessions in the user directory and identified by UUID in the project file
Pros, retains the session when working tree deleted, minor VCS advantages, single session even if multiple copies of project
Cons, need to set .ignore, when to delete the session files, single session even if multiple copies of project
2. Dimitars version of 1. with an extra indirection
Pros, supports multiple sessions per project (though as said above may not be needed to support that)
Cons, as 1.
3. put session file in the same directory as geany.conf or project.geany
Pros, simple, deletion of session files explicit, multiple copies of the project can have different sessions
Cons, loses project session file if the working tree is deleted, sessions not shared by all copies of the project
In general 3. looks like the least worst, any further comments?
Cheers Lex
-- E-gards: Jimmy _______________________________________________ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
On Thu, 11 Oct 2012 10:16:13 +1100 Lex Trotman elextr@gmail.com wrote:
On 10 October 2012 06:58, Dimitar Zhekov dimitar.zhekov@gmail.com
wrote:
a project-less build -> set build commands -> ok saves the changes under filedefs/ immediately ("save filetypes now" in the mailing list). Just fill some commands, OK, and grep ~/.config/geany.
It doesn't save the config file though, so no non-filetype settings
saved.
Yes. Curiosly enough, these are "ui prefs"...
Eh? not sure I understand you? In case I wasn't clear if in the build->set build commands dialog you modify the make command to say fred, click ok, cat geany.conf it isn't stored, close Geany, cat again and it is stored. That is it is not saved on ok.
You were very clear, and your description is entirely correct.
Unlike the normal filetype settings, the non-project, non-filetype settings internally belong to the ui_prefs, the same class as sidebar position etc. They are not file type settings at all.
But not saving the file list in geany.conf, if we have a project open and so the list is already saved in $project.geany, is _not_ actually related to multiply instances. Maybe I should propose it again, it's a very simple change.
Unless the project was open in multiple instances, then you can have issues with both geany.conf and project.geany, so no improvement I'm afraid.
The point of this change would be not to improve reliability, storage, multiply instances or whatever, but to stop losing the project-less file list by replacing it with the project file list, which is completely unnecessary.
So far the only algorithms presented so far are:
- sessions in the user directory and identified by UUID in the project file
Pros, retains the session when working tree deleted, minor VCS advantages, single session even if multiple copies of project
Cons, need to set .ignore, when to delete the session files, single session even if multiple copies of project
- Dimitars version of 1. with an extra indirection
Pros, supports multiple sessions per project (though as said above may not be needed to support that)
Cons, as 1.
- put session file in the same directory as geany.conf or project.geany
Pros, simple, deletion of session files explicit, multiple copies of the project can have different sessions
Cons, loses project session file if the working tree is deleted, sessions not shared by all copies of the project
In general 3. looks like the least worst, any further comments?
As I realized later, (2) is orthogonal to separation/storage, and can be implemented even with the current files, for example by extending [files] to [files_#]. So the real options are (1) and (3).
(It seems to me that, with an extra signal or two, multi-sessions can be implemented as a plugin; but it should be written after the splitting, if any, takes place.)
Am 10.09.2012 06:36, schrieb Lex Trotman:
Hi All,
Its about that time of year when we have our annual discussion on separating session data from config/project data :)
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)
- 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.
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. That way, when a project is opened, it is easy to uniquely find the session file if it exists. Using things like filenames, project names etc will always have clashes. Libuuid is used by GTK so it will always be available on all platforms we use and so making the UUID is one call. (Pity GTK doesn't expose it though)
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.
This proposal isn't about a proper session management capability, there isn't one that works on enough platforms to be worth including.
Any thoughts welcome.
Reviving this old thread because the annual discussion naturally came up again this year.
Your proposal lists issues that are rather orthogonal to separating the session file list, thus I think these should be dealt with later. As a first step I would propose we split out the session file lists to separate files (normal session: in the same folder as geany.conf, for projects in the same folder as $project.geany). This should solve the problem checking project files in as well as enabling to sync geany.conf across machines without affecting opened files.
If one made such a patch, would it be accepted? It should be relatively trivial, only complicated by backward compat code to read session informations from the old location.
Best regards.
Am 16.11.2013 23:52, schrieb Thomas Martitz:
Your proposal lists issues that are rather orthogonal to separating the session file list, thus I think these should be dealt with later. As a first step I would propose we split out the session file lists to separate files (normal session: in the same folder as geany.conf, for projects in the same folder as $project.geany). This should solve the problem checking project files in as well as enabling to sync geany.conf across machines without affecting opened files.
Not sure which hacks this will need, but I'd like it for the same reasons (putting geany.conf into a git)
Cheers, Frank
Reviving this old thread because the annual discussion naturally came up again this year.
It must be the change of season that triggers it, and it wasn't even one of the usual suspects this time :-)
Your proposal lists issues that are rather orthogonal to separating the session file list, thus I think these should be dealt with later. As a first step I would propose we split out the session file lists to separate files (normal session: in the same folder as geany.conf, for projects in the same folder as $project.geany). This should solve the problem checking project files in as well as enabling to sync geany.conf across machines without affecting opened files.
If one made such a patch, would it be accepted? It should be relatively trivial, only complicated by backward compat code to read session informations from the old location.
I think we got fairly close to an agreed solution on IRC, but I don't think there was an exact common understanding. Since the IRC discussion was fairly noisy (communication wise) I have tried to describe my best understanding of the most agreed with solution.
Please note this is what I think the majority agreed with, its not necessarily any individuals solution.
The basic idea is to separate the user session files list into a separate file. The discussion applied mostly to the projects, since only the OP who triggered the discussion is trying to store user config in a VCS. For the user config it is expected that simply having a session.conf file containing the session specific data (files list, open project at least) stored in the same directory as geany.conf is a suitable solution.
Since there are lots of project config files, and they can be stored in ~/projects or in the project trees (or anywhere) and because existing projects are single files the solution is more complex. The majority agreed:
1. instead of being a single file, the project config becomes a directory like the user config
2. various names were suggested, but no clear winner emerged, suggestions included $project.geany, geany.$project and $project.conf.d. Objections included $project.geany is the existing name and may be confused or overwritten by an old version of geany and $project.conf.d is ugly. Making it a define was suggested, which is fine during development, but a permanent solution must be selected prior to merging the change.
3. initially that directory contains the config file (which is the existing project file without the session files list) and the session files list file. Retaining the $project.geany name for the config file or changing it to geany.conf to match the user config were suggested, no conclusion was reached. Similarly using $project.session.conf or just session.conf were suggested for the session file.
4. over time more data can be added to the project directory, possibly becoming pretty much the same as the user config directory.
5. the user is responsible for setting their .gitignore (or equivalent for other VCSes) to ignore the session file.
I say again, this may not be anybodys exact solution, but its what I think was agreed by the majority. If you think I have misunderstood then shout, but don't complain just because its not your personal solution. I am posting this because I don't think we all had the same understanding of what we were agreeing.
Now for the further discussions.
Assuming the above to be correct I suggest:
1. Project and user session file formats should match to allow the same code to store both. The fact that the storing the current project in the project session file is not needed doesn't matter.
2. For user config, keeping the same name for geany.conf is ok since a new geany can simply ignore session info in the geany.conf file if the session.conf is present. Accidently overwriting geany.conf with an old version won't damage anything but won't update session.conf.
3. For project config the new version should use names that don't match existing project file names since the new config is a directory and an old geany trying to read it would get very confused. An old geany may also overwrite the directory with a file if its the same name. Also I see no point in including the project name on the config and session files inside the project config directory, its just more filepath manipulation needed for no gain, use the fixed names project.conf and session.conf. The project config file should not be geany.conf as it is currently not the same format.
4. Although partly orthogonal to the current discussion, we should find any places in Geany where config is not stored on each change and fix them so the now separate config file does not need to be saved at quit. So only the session file needs saving on quit and we don't lose config changes when the desktop shuts Geany down abruptly (or the rare crash :-).
Personally I would be willing to accept the above solution despite my misgivings about the need to .gitignore the session file and previous attempts to work around that need.
Cheers Lex
Best regards.
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
How about $project.geany.d?
;)
On 18/11/2013 10:12, Lex Trotman wrote:
- various names were suggested, but no clear winner emerged,
suggestions included $project.geany, geany.$project and $project.conf.d. Objections included $project.geany is the existing name and may be confused or overwritten by an old version of geany and $project.conf.d is ugly. Making it a define was suggested, which is fine during development, but a permanent solution must be selected prior to merging the change.
On 18 November 2013 20:22, Thomas Young thomasyoung@free.fr wrote:
How about $project.geany.d?
;)
heh, but thats a D source file isn't it ;-)
On 18/11/2013 10:12, Lex Trotman wrote:
- various names were suggested, but no clear winner emerged,
suggestions included $project.geany, geany.$project and $project.conf.d. Objections included $project.geany is the existing name and may be confused or overwritten by an old version of geany and $project.conf.d is ugly. Making it a define was suggested, which is fine during development, but a permanent solution must be selected prior to merging the change.
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Am 18.11.2013 10:22, schrieb Thomas Young:
How about $project.geany.d?
;)
On 18/11/2013 10:12, Lex Trotman wrote:
- various names were suggested, but no clear winner emerged,
suggestions included $project.geany, geany.$project and $project.conf.d. Objections included $project.geany is the existing name and may be confused or overwritten by an old version of geany and $project.conf.d is ugly. Making it a define was suggested, which is fine during development, but a permanent solution must be selected prior to merging the change.
I thought we $project.geany as the new directory name was accepted. I guess we'll find an accceptable name until it's ready for merging. But I do think the string "geany" should be there to avoid potential clashes with other IDEs. Also, remember that $project.geany can also be foobar.geany, it must not be called after the project. And it must not be within the project's root directory (see Matthew's case for ~/.Projects/*.geany). This should be maintained.
Best regards.
On 18 November 2013 20:49, Thomas Martitz < thomas.martitz@student.htw-berlin.de> wrote:
Am 18.11.2013 10:22, schrieb Thomas Young:
How about $project.geany.d?
;)
On 18/11/2013 10:12, Lex Trotman wrote:
- various names were suggested, but no clear winner emerged,
suggestions included $project.geany, geany.$project and $project.conf.d. Objections included $project.geany is the existing name and may be confused or overwritten by an old version of geany and $project.conf.d is ugly. Making it a define was suggested, which is fine during development, but a permanent solution must be selected prior to merging the change.
I thought we $project.geany as the new directory name was accepted.
I posted the summary because I was sure there were places where we were agreeing on different things :)
My only problem with this name is, what will an old Geany do with it since it matches the current naming convention?
I guess we'll find an accceptable name until it's ready for merging. But I do think the string "geany" should be there to avoid potential clashes with other IDEs.
I totally agree with that, just not as the extension since thats the existing convention.
Also, remember that $project.geany can also be foobar.geany, it must not be called after the project.
I am not sure what you mean here, yes it can actually be any name, .geany extension is only a convention, but why can't it be named after the project?
And it must not be within the project's root directory (see Matthew's case for ~/.Projects/*.geany). This should be maintained.
Why can't it be in the projects root directory? Currently it can be anywhere, in ~/projects, in ~/.Projects, in the root of the tree, why does that need to change just because the config becomes a directory not a file?
Cheers Lex
Best regards.
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Am 18.11.2013 11:03, schrieb Lex Trotman:
On 18 November 2013 20:49, Thomas Martitz <thomas.martitz@student.htw-berlin.de mailto:thomas.martitz@student.htw-berlin.de> wrote:
Am 18.11.2013 10:22, schrieb Thomas Young: How about $project.geany.d? ;) On 18/11/2013 10:12, Lex Trotman wrote: 2. various names were suggested, but no clear winner emerged, suggestions included $project.geany, geany.$project and $project.conf.d. Objections included $project.geany is the existing name and may be confused or overwritten by an old version of geany and $project.conf.d is ugly. Making it a define was suggested, which is fine during development, but a permanent solution must be selected prior to merging the change. I thought we $project.geany as the new directory name was accepted.I posted the summary because I was sure there were places where we were agreeing on different things :)
My only problem with this name is, what will an old Geany do with it since it matches the current naming convention?
I guess we'll find an accceptable name until it's ready for merging. But I do think the string "geany" should be there to avoid potential clashes with other IDEs.I totally agree with that, just not as the extension since thats the existing convention.
Also, remember that $project.geany can also be foobar.geany, it must not be called after the project.I am not sure what you mean here, yes it can actually be any name, .geany extension is only a convention, but why can't it be named after the project?
And it must not be within the project's root directory (see Matthew's case for ~/.Projects/*.geany). This should be maintained.Why can't it be in the projects root directory? Currently it can be anywhere, in ~/projects, in ~/.Projects, in the root of the tree, why does that need to change just because the config becomes a directory not a file?
I meant to say that we should keep the ability to use non-project related names for the directory and to place it outside the project's root directory, in the same way that's possible with the current geany. Yes, it can be called after the project and it can be within the directory.
Sorry, I misused "must not", not a native speaker. Should have been "does not have to be".
Best regards.
[...]
I meant to say that we should keep the ability to use non-project related names for the directory and to place it outside the project's root directory, in the same way that's possible with the current geany. Yes, it can be called after the project and it can be within the directory.
Sorry, I misused "must not", not a native speaker. Should have been "does not have to be".
No problem, consider it a complement to your normal English that I didn't even consider the possibility that there was a language problem :)
Cheers Lex
Best regards. _______________________________________________ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Am 18.11.2013 10:12, schrieb Lex Trotman:
Reviving this old thread because the annual discussion naturally came up again this year.It must be the change of season that triggers it, and it wasn't even one of the usual suspects this time :-)
Your proposal lists issues that are rather orthogonal to separating the session file list, thus I think these should be dealt with later. As a first step I would propose we split out the session file lists to separate files (normal session: in the same folder as geany.conf, for projects in the same folder as $project.geany). This should solve the problem checking project files in as well as enabling to sync geany.conf across machines without affecting opened files. If one made such a patch, would it be accepted? It should be relatively trivial, only complicated by backward compat code to read session informations from the old location.I think we got fairly close to an agreed solution on IRC, but I don't think there was an exact common understanding. Since the IRC discussion was fairly noisy (communication wise) I have tried to describe my best understanding of the most agreed with solution.
Please note this is what I think the majority agreed with, its not necessarily any individuals solution.
The basic idea is to separate the user session files list into a separate file. The discussion applied mostly to the projects, since only the OP who triggered the discussion is trying to store user config in a VCS. For the user config it is expected that simply having a session.conf file containing the session specific data (files list, open project at least) stored in the same directory as geany.conf is a suitable solution.
Since there are lots of project config files, and they can be stored in ~/projects or in the project trees (or anywhere) and because existing projects are single files the solution is more complex. The majority agreed:
- instead of being a single file, the project config becomes a
directory like the user config
- various names were suggested, but no clear winner emerged,
suggestions included $project.geany, geany.$project and $project.conf.d. Objections included $project.geany is the existing name and may be confused or overwritten by an old version of geany and $project.conf.d is ugly. Making it a define was suggested, which is fine during development, but a permanent solution must be selected prior to merging the change.
- initially that directory contains the config file (which is the
existing project file without the session files list) and the session files list file. Retaining the $project.geany name for the config file or changing it to geany.conf to match the user config were suggested, no conclusion was reached. Similarly using $project.session.conf or just session.conf were suggested for the session file.
- over time more data can be added to the project directory, possibly
becoming pretty much the same as the user config directory.
- the user is responsible for setting their .gitignore (or equivalent
for other VCSes) to ignore the session file.
I say again, this may not be anybodys exact solution, but its what I think was agreed by the majority. If you think I have misunderstood then shout, but don't complain just because its not your personal solution. I am posting this because I don't think we all had the same understanding of what we were agreeing.
That matches my understanding: For each Geany project a directory is created that follows the $HOME/.config/geany layout, except that geany.conf is replaced by $project.conf (but I agree it could be just fixed at project.conf). Initially this is only for the specific issue at hand: the session file list and the rest of $project.geany. The layout would also allow plugins to store project-specific stuff plus potentially allow projects to override some $user config (though this is not something we have talked about yet).
Now for the further discussions.
Assuming the above to be correct I suggest:
- Project and user session file formats should match to allow the
same code to store both. The fact that the storing the current project in the project session file is not needed doesn't matter.
I agree.
- For user config, keeping the same name for geany.conf is ok since a
new geany can simply ignore session info in the geany.conf file if the session.conf is present. Accidently overwriting geany.conf with an old version won't damage anything but won't update session.conf.
- For project config the new version should use names that don't
match existing project file names since the new config is a directory and an old geany trying to read it would get very confused. An old geany may also overwrite the directory with a file if its the same name. Also I see no point in including the project name on the config and session files inside the project config directory, its just more filepath manipulation needed for no gain, use the fixed names project.conf and session.conf. The project config file should not be geany.conf as it is currently not the same format.
Old Geany couldn't read it since it's a directory, and I don't think you can possibly overwrite a directory with a file, even accidentally. You'd need to delete the directory first. But it may be confusing to the users, indeed.
- Although partly orthogonal to the current discussion, we should
find any places in Geany where config is not stored on each change and fix them so the now separate config file does not need to be saved at quit. So only the session file needs saving on quit and we don't lose config changes when the desktop shuts Geany down abruptly (or the rare crash :-).
Right but this should be a separate step. Let's get this separate session file up first.
Personally I would be willing to accept the above solution despite my misgivings about the need to .gitignore the session file and previous attempts to work around that need.
Awesome.
Le 18/11/2013 11:29, Thomas Martitz a écrit :
Am 18.11.2013 10:12, schrieb Lex Trotman:
[...]
- initially that directory contains the config file (which is the
existing project file without the session files list) and the session files list file. Retaining the $project.geany name for the config file or changing it to geany.conf to match the user config were suggested, no conclusion was reached. Similarly using $project.session.conf or just session.conf were suggested for the session file.
I'd prefer keeping things as simple as possible, and I don't see why we should have project-specific names under the project-specific directory. So I vote for <dir>/project.conf and <dir>/session.conf or static names alike.
- over time more data can be added to the project directory,
possibly becoming pretty much the same as the user config directory.
[...]
The layout would also allow plugins to store project-specific stuff plus potentially allow projects to override some $user config (though this is not something we have talked about yet).
Yes. And no, we don't have to talk about future use yet but designing it to support those without needing a second rewrite is a good thing we all agreed on (I think) :)
- Project and user session file formats should match to allow the
same code to store both. The fact that the storing the current project in the project session file is not needed doesn't matter.
It looks like a good idea, I agree, but we need to keep on allowing to save user-wide settings when a project is open. I mean, we shouldn't save all settings changes to the project settings just because one is open, the user might want to change a general setting.
I think this was discussed one day already, and I think it should be a separate thread.
- For user config, keeping the same name for geany.conf is ok
since a new geany can simply ignore session info in the geany.conf file if the session.conf is present. Accidently overwriting geany.conf with an old version won't damage anything but won't update session.conf.
Agreed.
- For project config the new version should use names that don't
match existing project file names since the new config is a directory and an old geany trying to read it would get very confused. An old geany may also overwrite the directory with a file if its the same name. Also I see no point in including the project name on the config and session files inside the project config directory, its just more filepath manipulation needed for no gain, use the fixed names project.conf and session.conf. The project config file should not be geany.conf as it is currently not the same format.
Old Geany couldn't read it since it's a directory, and I don't think you can possibly overwrite a directory with a file, even accidentally. You'd need to delete the directory first.
I agree, I don't think this should be an issue. Older Geany would not be able to load the project, but that should be all. And if the config part starts with the same format as old $project.geany, a user could workaround that by loading $project.geany/project.conf manually.
But it may be confusing to the users, indeed.
Well, I don't think it's more confusing that having the name change, and it would keep on working exactly the same: `geany $project.geany`
Regards, Colomban
[...]
- Project and user session file formats should match to allow the
same code to store both. The fact that the storing the current project in the project session file is not needed doesn't matter.
It looks like a good idea, I agree, but we need to keep on allowing to save user-wide settings when a project is open. I mean, we shouldn't save all settings changes to the project settings just because one is open, the user might want to change a general setting.
I think this was discussed one day already, and I think it should be a separate thread.
I said **session** file format, not the config files, as you say ATM the only change to config should be to remove the session info. All further changes are indeed another topic.
[...]
Old Geany couldn't read it since it's a directory, and I don't think you can possibly overwrite a directory with a file, even accidentally. You'd need to delete the directory first.
I agree, I don't think this should be an issue. Older Geany would not be able to load the project, but that should be all. And if the config part starts with the same format as old $project.geany, a user could workaround that by loading $project.geany/project.conf manually.
I'm happy for it to be the same so long as someone can assure me that geany saving a file can't overwrite a directory on the most common file system arrangements which includes windows and includes windows file systems on a NAS mounted via Samba (a sadly increasing situation with cheep NAS boxes).
Note that config saving will use g_file_set_contents() if the option is set, which writes to a temp file, and renames it over the old file. I agree that on Linux it can't rename a file over a directory, but on what it thinks is a windows file system it deletes the old file first and then renames the temp to it. Are we sure that won't allow it to overwrite directories?
But it may be confusing to the users, indeed.
Well, I don't think it's more confusing that having the name change, and it would keep on working exactly the same: `geany $project.geany`
If my concerns above are allayed then yes its an advantage for operation to remain the same.
Cheers Lex
Regards, Colomban _______________________________________________ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Le 19/11/2013 00:14, Lex Trotman a écrit :
[...]
>> 1. Project and user session file formats should match to allow the >> same code to store both. The fact that the storing the current >> project in the project session file is not needed doesn't matter. It looks like a good idea, I agree, but we need to keep on allowing to save user-wide settings when a project is open. I mean, we shouldn't save all settings changes to the project settings just because one is open, the user might want to change a general setting. I think this was discussed one day already, and I think it should be a separate thread.I said **session** file format, not the config files, as you say ATM the only change to config should be to remove the session info. All further changes are indeed another topic.
Oops, misread you :)
Am 19.11.2013 00:14, schrieb Lex Trotman:
[...]
>> 1. Project and user session file formats should match to allow the >> same code to store both. The fact that the storing the current >> project in the project session file is not needed doesn't matter. It looks like a good idea, I agree, but we need to keep on allowing to save user-wide settings when a project is open. I mean, we shouldn't save all settings changes to the project settings just because one is open, the user might want to change a general setting. I think this was discussed one day already, and I think it should be a separate thread.I said **session** file format, not the config files, as you say ATM the only change to config should be to remove the session info. All further changes are indeed another topic.
[...]
> > Old Geany couldn't read it since it's a directory, and I don't think > you can possibly overwrite a directory with a file, even > accidentally. You'd need to delete the directory first. I agree, I don't think this should be an issue. Older Geany would not be able to load the project, but that should be all. And if the config part starts with the same format as old $project.geany, a user could workaround that by loading $project.geany/project.conf manually.I'm happy for it to be the same so long as someone can assure me that geany saving a file can't overwrite a directory on the most common file system arrangements which includes windows and includes windows file systems on a NAS mounted via Samba (a sadly increasing situation with cheep NAS boxes).
Note that config saving will use g_file_set_contents() if the option is set, which writes to a temp file, and renames it over the old file. I agree that on Linux it can't rename a file over a directory, but on what it thinks is a windows file system it deletes the old file first and then renames the temp to it. Are we sure that won't allow it to overwrite directories?
I would consider it a bug in g_file_set_contents() if doesn't check permissions and type of the original object (file) before doing the temp&rename approach. Because that would mean different semantics compared to direct save.
FWIW, let's not overcomplicate this. We can easily chose another naming scheme for the directory.
Best regards.