Re: [Geany-devel] Separating session file lists from config (again)
On 4 October 2012 03:06, Dimitar Zhekov dimitar.zhe...@gmail.com wrote: On Tue, 2 Oct 2012 13:03:00 +1000 Lex Trotman ele...@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 ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Separating session file lists from config (again)
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.
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.
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.
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Separating session file lists from config (again)
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): 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. 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. ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Separating session file lists from config (again)
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): 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. 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 ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Separating session file lists from config (again)
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): 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. 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 ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Separating session file lists from config (again)
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): 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. 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 ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Separating session file lists from config (again)
On 2 October 2012 00:43, Colomban Wendling lists@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):
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
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. 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
Re: [Geany-devel] Separating session file lists from config (again)
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.zhe...@gmail.com wrote: On Wed, 12 Sep 2012 11:35:48 +1000 Lex Trotman ele...@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 ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Separating session file lists from config (again)
On Wed, 12 Sep 2012 11:35:48 +1000 Lex Trotman ele...@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. -- E-gards: Jimmy ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Separating session file lists from config (again)
On Tue, 11 Sep 2012 09:17:52 +1000
Lex Trotman ele...@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...
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.
...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 mbr...@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
Re: [Geany-devel] Separating session file lists from config (again)
[...]
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
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Separating session file lists from config (again)
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. ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Separating session file lists from config (again)
On Mon, 10 Sep 2012 14:36:32 +1000
Lex Trotman ele...@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):
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)
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.)
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.
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 mbr...@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...)
--
E-gards: Jimmy
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Separating session file lists from config (again)
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 ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
