[...]
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.
No, what I would do is:
- Read the user config file content
- Append the content of the VCS file
- Pass the data into a GKeyFile
The key file will let the later entries naturally override the earlier user settings. This means we hardly have to change any code.
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.
Build settings are unique ;-) IMO it's unjustified to change all project settings in core and plugins, plus require all future settings to follow the write-if-changed rule, which needs extra code per setting.
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.
On saving I think you could detect a conflicting setting by comparing the keyfile values as strings, so warning the user they have made a change (and which one) that will be overriden. That is good enough IMO.
[...]
I think you might have missed that there is a contradiction between the statement above, tell the user but don't do anything to fix it, and the statement below (which I agree with) that they must be able to save changes to settings. That means user project settings must be loaded after the base project settings, the opposite of what you said above. But if user settings override base settings and all settings are written to the user file then no base settings will ever be used, so only changed settings should be saved in the user file. I think you overstate the amount of work, the project file doesn't hold much outside build (which does it), and session (which doesn't matter).
The simple solution is to add "only save if changed" as a new feature in stash so its easy to use for the settings that need it.
Hold on, build commands should be overridable by the user. The VCS file can provide initial commands, but the user should definitely be able to override them IMO.
Also, I don't understand why using a visual merge program like Meld/WinMerge couldn't be used to update the VCS project file from a user file. This would make updating the VCS file quite easy IMO.
And remember that probably only a minority of Geany users would be using shared project files, so I think the code should be minimal. If people disagree, write a plugin.
Plugins can't set build settings since you removed the build plugin interface ;D
[...]
To summarise, no suitable solution has been proposed so far:
1. splitting the files has backward compatibility unresolved so far 2. stub/base proposal has issues of overriding order vs save only changed unresolved so far
Whilst the problem is worth solving, neither suggestion is resolved.
So in time honoured tradition I'm going to do nothing, until the issues are sorted.
Cheers Lex