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