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

Lex Trotman elextr at xxxxx
Mon Sep 10 04:36:32 UTC 2012


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



More information about the Devel mailing list