On Sat, Nov 12, 2011 at 3:26 AM, Nick Treleaven <nick.trelea...@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. Cheers Lex _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
