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.

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.

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.
_______________________________________________
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Reply via email to