[Geany-devel] Stub project files for sharing
elextr at xxxxx
Thu Nov 3 23:46:41 UTC 2011
On 4 November 2011 01:45, Nick Treleaven <nick.treleaven at btinternet.com> wrote:
> I think I can improve on Lex's recent proposal to split up project settings
> into two files, one for version control and one for local changes.
> The problems with that are:
> * How do we decide which settings are in each - e.g. build menu commands - a
> project might want to override the make command in the VC settings file, but
> the user will want to add their own build commands too. There's a conflict.
> This becomes increasingly messy as we add project settings.
> * Backwards compatibility - we would need to handle existing project files
> anyway, which makes code more complex. I don't think we need to break
> * If the user changes a setting which is stored in the VC file they may end
> up committing it, or perhaps sometimes not even realizing they are
> overriding the VC setting.
> My solution:
> A foo.geanystub project file goes in version control. It is never written
> to. It should be prepared by manually editing a copy of a local project
> On opening a foo.geanystub file, Geany creates foo.geany in the same path
> then opens it.
> When opening foo.geany, if foo.geanystub exists, then override settings with
> the stub contents.
> This way the VC file can decide which settings are not overridable.
> My solution shouldn't require much code to implement. I've only noted the
> bare bones of it, there are some things that could be added to make it
> better. Even with these I think it's simpler and neater.
I like simple, why don't we just add a setting to projects, say "based
on", that allows a project file to import settings from another. Then
the user project is "based on" the one in the VCS working directory.
Simple and explicit and can adapt to any locations, on opening the
project, settings are taken from the "based on" file if it exists and
the setting exists unless it is overridden by the user project file.
Based on is not recursive.
Note that this requires that projects not write a setting unless it is
set by the user, that is not always the case now IIRC and is an added
This way the VCS file is still a project file and can be edited using
the Geany UI, albeit at the cost of writing session crap into it, but
as that is overridden by the user session crap on next open so it
> Geany-devel mailing list
> Geany-devel at uvena.de
More information about the Devel