[Geany-devel] Stub project files for sharing

[Lex Trotman]

[...]

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