Re: [Geany-devel] Separating session file lists from config (again)

[Lex Trotman]

On 4 October 2012 03:06, Dimitar Zhekov  wrote:

> On Tue, 2 Oct 2012 13:03:00 +1000
> Lex Trotman  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)

[Dimitar Zhekov]

On Tue, 2 Oct 2012 13:03:00 +1000
Lex Trotman  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?..

-- 
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)

[Lex Trotman]

[...]

> >
> > 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 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.
> >
>

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 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.
>

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 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
> > 

Re: [Geany-devel] Separating session file lists from config (again)

[Colomban Wendling]

Le 02/10/2012 05:03, Lex Trotman a écrit :
> 
> 
> On 2 October 2012 00:43, 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.
> 
> 
> 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
> > platform

Re: [Geany-devel] Separating session file lists from config (again)

[Lex Trotman]

On 2 October 2012 00:43, 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.
>

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 s

Re: [Geany-devel] Separating session file lists from config (again)

[Colomban Wendling]

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)

[Matthew Brush]

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)

[Colomban Wendling]

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)

[Matthew Brush]

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)

[Colomban Wendling]

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)

[Lex Trotman]

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  wrote:

> On Wed, 12 Sep 2012 11:35:48 +1000
> Lex Trotman  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)

[Dimitar Zhekov]

On Wed, 12 Sep 2012 11:35:48 +1000
Lex Trotman  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)

[Thomas Martitz]

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)

[Lex Trotman]

[...]
> 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)

[Dimitar Zhekov]

On Tue, 11 Sep 2012 09:17:52 +1000
Lex Trotman  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  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 di

Re: [Geany-devel] Separating session file lists from config (again)

[Lex Trotman]

On 11 September 2012 04:30, Dimitar Zhekov  wrote:
> On Mon, 10 Sep 2012 14:36:32 +1000
> Lex Trotman  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):
>>
>> 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.

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 :)

>
>> 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.

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  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.

Re: [Geany-devel] Separating session file lists from config (again)

[Dimitar Zhekov]

On Mon, 10 Sep 2012 14:36:32 +1000
Lex Trotman  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  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)

[Matthew Brush]

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

[Geany-devel] Separating session file lists from config (again)

[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):

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
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel