[Geany-devel] Stub project files for sharing

[Nick Treleaven]

On 04/11/2011 21:31, Lex Trotman wrote:
> [...]
>> I see that 'based on' could be useful for making subprojects, and could be
>> added to my proposal.
>
> As I see it, this is the same as your proposal, just that we have an
> explicit pointer from the project file to the stub project file so
> they don't *have* to be in the same directory and we don't have to go
> searching for the stub to know if we need to open it, that can be slow
> on networked locations.

Yes.

>>> Note that this requires that projects not write a setting unless it is
>>> set by the user, that is not always the case now IIRC and is an added
>>> complication.
>>
>> I don't think this is a good requirement. Plugins already can write settings
>> so I think it will be hard to enforce. But also rewriting existing code can
>> be avoided and would be better.
>
> 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.

Note that doing that does not require code per-setting, which is what I 
think can be avoided to mean much less of an impact on our codebase.

   But I think the code to block the UI and plugins is
> likely to be even worse than the alternative of write only on change.

Don't understand where this idea comes from, sorry.

>>> This way the VCS file is still a project file and can be edited using
>>> the Geany UI, albeit at the cost of writing session crap into it, but
>>> as that is overridden by the user session crap on next open so it
>>> doesn't matter.
>>
>> I know that using Geany to create the VCS project would be easier, but stub
>> creation is something that needs to be done rarely. I don't think it's worth
>> rewriting existing code to support something that gets used rarely - use of
>> projects depending on a stub is something that might be a popular feature (I
>> realized eventually ;-)), but the actual stub creation and modifications is
>> probably rare.
>
> I think you are underestimating how often the project settings,
> particularly build commands, change in the early stages.  For mature
> projects it would be rare as most by then would also be fully
> integrated into make or similar, but early stages commands change more
> as the system develops.  If the stub file is still a project file then
> no extra code is needed.

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.

>> I think having a separate filetype for the VCS file is good design because
>> it shouldn't be written to, so it is different from a normal geany project
>> file.
>
> Agree it shouldn't be written to in normal use.
>
> I don't see any point in writing code to save the contents in a
> different structure to the standard one, that adds code, makes it hard
> to hand edit since you have to translate settings from one structure
> to the other, you can't just copy an existing file etc.  But I don't
> think that is actually what you meant.

No. The contents would be a subset (user decidable for my proposal) of a 
normal project file.

Just changing the extension
> would reduce accidental use, but even calling it fred.manglewurzle
> won't actually prevent you from choosing it from the project->open
> dialog and editing the settings rather than doing it by hand.

But Geany could recognise a .geanystub file and ask the user 'This is a 
master/stub project. Do you want to create a user project from it?' - or 
some better worded question. Geany could protect writing to the VCS file 
quite easily.

BTW, we don't have to have a .geanystub file extension, this could be 
done with a master=true keyfile setting.

Regards,
Nick