[Geany-devel] Stub project files for sharing

[Nick Treleaven]

(There was no reply-to list address set for Thomas's mail (weird), so 
I'm now sending this to the list - possibly a Thunderbird issue).

On 04/11/2011 09:56, Thomas Martitz wrote:
> Am 03.11.2011 15:45, schrieb Nick Treleaven:
>>
>> 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 file.
>>
>> 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.
>>
>
> That solution seems awkward to me. Especially the creation part where
> you need to copy, then hand-edit.
>
> Normally you don't need to touch such project files at all, but you
> require not only that, but also that the people know which parts to take
> out.

It really isn't that difficult, and it only has to be done once, plus 
any minor modifications later. For something rarely done, Geany 
shouldn't need to alter its existing code too much - see my answer to 
Lex for more explanation. Supporting GUI creation is much more work for 
Geany.

> Also, one could argue that foo.geany should override the stub file.
> Anyway this is a feature not covered by the separate-file approach.

This could be added to the stub approach (if we decide we want it). I 
don't think it could be added to Lex's proposal.

> So, it seems more complicated for users, since the separate-file
> approach would just work (no hand-editing required), so I disagree it's
> simpler. OTOH it's probably simpler to implement (just load the stub
> after, so things get overridden automagically) and
> backward-compatibility is not an issue.

Also there is the problem with the original idea of deciding which 
settings go in each project file - there isn't always a right answer.

Regards,
Nick