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

[Dimitar Zhekov]

On Tue, 11 Sep 2012 09:17:52 +1000
Lex Trotman <elextr at 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 <mbrush at codebrainz.ca> wrote:
> >
> >> > By session data I mean the list of currently open files and MRU list.
> >> >
> >>
> >> I guess it could support some other stuff too like window/find dialogs
> >> geometry/position, active tab, position within the file, etc.

Just to clarify, "stuff too like window/find dialogs" means the
interface options. If they are per session file, each project will have
it's own "appearance", something that Geany does not currently support.
(Except with SM, and I find it very useful.)

> > But why stop half way? Let's have the current geany.conf/foo.geany
> > for the Preferences and Properties respectively, a *.session file for
> > the session and active tab [position within the file and the per-file
> > settings are always stored along with the file name], and an *.interface
> > file for the interface settings. This is the most logical solution,
> > corresponding exactly to the different groups of settings. (Should I
> > add a :) here? Hmmm...)
> >
> 
> What? Why not a file per setting, then it would all work fine.  Just
> make geany.conf a directory and switch to project.geany directories.
> :)

If we decide to continue with the single "appearance" (interface
settings) for all projects, then a ${GEANY_CONFIG}/geany.interface
would suffice, and geany.conf will be stable.

(Note: the project files currectly contain the settings from Project ->
Properties and a session, but no "interface" options. The plugins can
only place their own settings in the projects either, except by using
the Project -> Properties dialog.)

-- 
E-gards: Jimmy