[Geany-devel] Stub project files for sharing

Lex Trotman elextr at xxxxx
Fri Nov 11 20:18:18 UTC 2011

On Sat, Nov 12, 2011 at 3:26 AM, Nick Treleaven
<nick.treleaven at btinternet.com> wrote:
> On 08/11/2011 21:11, Lex Trotman wrote:
>> [...]
>>>> 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.
> There is no contradiction - the VCS file overrides the user settings (which
> are the same as now) as I have explained.
> You detect conflicts and warn the user with the keyfile keyname.
> Detection is done just before saving the user project file - the user
> settings are stored in a GKeyFile - then the VCS file is loaded as a keyfile
> struct also. For each key in the VCS keyfile you read the corresponding
> string value of the key and compare it with a lookup in the prepared user
> keyfile. If there is a conflict, tell the user, and you could even prevent
> the prepared keyfile being saved to disk (but I'm undecided about that).
> The code I've described stays the same irrespective of which settings are in
> either keyfile, and doesn't require modifying existing code, just adds
> stuff.
> I don't mind if you don't like this solution, but it is probably the
> simplest in terms of code changed & added.

I don't like it because as a user I can't save any of my settings,
thats unacceptable.

>>> 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.
> BTW you may want to disallow overriding build commands for some projects,
> this is Ok. I just think that at least run commands often need to be
> overridable.

Placing arbitary limits on things like that is bad.

>>> 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
> If there was a general build API a plugin would not be able to use it in the
> way you imagine, it would need extra API elements to do so.
>> 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
> I don't think (2) is true, it may have other limitations which personally I
> think don't matter, but it would work and be simple.

Not saving user settings is an unacceptable limitation of your
resolution of 2.  Simplicity doesn't matter.


More information about the Devel mailing list