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

Lex Trotman elextr at xxxxx
Wed Sep 12 01:35:48 UTC 2012

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


> --
> E-gards: Jimmy
> _______________________________________________
> Geany-devel mailing list
> Geany-devel at uvena.de
> https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

More information about the Devel mailing list