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