[Geany-devel] Stub project files for sharing

[Lex Trotman]

[...]
> I see that 'based on' could be useful for making subprojects, and could be
> added to my proposal.

As I see it, this is the same as your proposal, just that we have an
explicit pointer from the project file to the stub project file so
they don't *have* to be in the same directory and we don't have to go
searching for the stub to know if we need to open it, that can be slow
on networked locations.

>
>> 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
>> complication.
>
> I don't think this is a good requirement. Plugins already can write settings
> so I think it will be hard to enforce. But also rewriting existing code can
> be avoided and would be better.

Unfortunately this is a requirement for any overriding scheme like
stubs, if all the settings are written to the users project file no
settings will be read from the stub file.
The no write unless changed rule only applies to settings that can go
in the stub file of course.  Build settings already adhere to this
rule.  Of course splitting the project file does not have this
problem, but as you point out has other problems.

Just to note, going the other way and having the stub file override
the user settings is likely to make the code harder and the user
interface more confused.  Since we agree that the stub file isn't
written in normal operation, users (and plugins) will need to be
prevented from changing settings which are overridden by the stub,
otherwise the changes will be written to the user file and overridden
again by the stub when next opened.  Having changes silently disappear
is bad design.  But I think the code to block the UI and plugins is
likely to be even worse than the alternative of write only on change.

>
> Rewriting code is what made me think supporting VCS project files was not
> worth it, but if that can be avoided and the new code is fairly minimal I
> think it's acceptable.

Agree.

>
>> 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
>> doesn't matter.
>
> I know that using Geany to create the VCS project would be easier, but stub
> creation is something that needs to be done rarely. I don't think it's worth
> rewriting existing code to support something that gets used rarely - use of
> projects depending on a stub is something that might be a popular feature (I
> realized eventually ;-)), but the actual stub creation and modifications is
> probably rare.

I think you are underestimating how often the project settings,
particularly build commands, change in the early stages.  For mature
projects it would be rare as most by then would also be fully
integrated into make or similar, but early stages commands change more
as the system develops.  If the stub file is still a project file then
no extra code is needed.

>
> I think having a separate filetype for the VCS file is good design because
> it shouldn't be written to, so it is different from a normal geany project
> file.

Agree it shouldn't be written to in normal use.

I don't see any point in writing code to save the contents in a
different structure to the standard one, that adds code, makes it hard
to hand edit since you have to translate settings from one structure
to the other, you can't just copy an existing file etc.  But I don't
think that is actually what you meant.  Just changing the extension
would reduce accidental use, but even calling it fred.manglewurzle
won't actually prevent you from choosing it from the project->open
dialog and editing the settings rather than doing it by hand.

>From Nicks answer to Thomas (so quoting poor, sorry, blame gmail paste)

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

As I said above, i think you underestimate the change rate.


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

I actually thought you meant it was this way around, see above for reasoning.


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

Agree

Cheers
Lex