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