Re: [Geany-devel] Stub project files for sharing
On Sat, Nov 12, 2011 at 3:26 AM, Nick Treleaven 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
Re: [Geany-devel] Stub project files for sharing
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
Re: [Geany-devel] Stub project files for sharing
On Thu, Nov 10, 2011 at 7:45 AM, Dimitar Zhekov wrote: > On Wed, 9 Nov 2011 08:11:45 +1100 > Lex Trotman wrote: > >> 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. > > If that's the easy solution... Our instance will not know if another > instance has changed something, so a backup stash value won't suffice - > the keyfile would have to be re-read. Unless we tolerate a mix of > settings, that is... > Thats no different to the current behavior IIRC, so not relevant. > And the vte prefs may or may not appear in stash on Geany start, due > to the runtime load vte behaviour. > ? > (Excuse me if these were already discussed - TL;DR) > No. >> Whilst the problem is worth solving, neither suggestion is resolved. >> >> So in time honoured tradition I'm going to do nothing, until the >> issues are sorted. > > +1. :) > Cheers Lex > -- > E-gards: Jimmy > ___ > Geany-devel mailing list > Geany-devel@uvena.de > https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel > ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Stub project files for sharing
On Wed, 9 Nov 2011 08:11:45 +1100 Lex Trotman wrote: > 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. If that's the easy solution... Our instance will not know if another instance has changed something, so a backup stash value won't suffice - the keyfile would have to be re-read. Unless we tolerate a mix of settings, that is... And the vte prefs may or may not appear in stash on Geany start, due to the runtime load vte behaviour. (Excuse me if these were already discussed - TL;DR) > Whilst the problem is worth solving, neither suggestion is resolved. > > So in time honoured tradition I'm going to do nothing, until the > issues are sorted. +1. :) -- E-gards: Jimmy ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Stub project files for sharing
[...] >> 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. > 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. > Plugins can't set build settings since you removed the build plugin interface ;D [...] 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 Whilst the problem is worth solving, neither suggestion is resolved. So in time honoured tradition I'm going to do nothing, until the issues are sorted. Cheers Lex ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Stub project files for sharing
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
Re: [Geany-devel] Stub project files for sharing
[...] > 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. > >> 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. 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. 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. 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. > > Rewriting code is what made me think supporting VCS project files was not > worth it, but if that can be avoided and the new code is fairly minimal I > think it's acceptable. Agree. > >> 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. > > 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. 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. >From Nicks answer to Thomas (so quoting poor, sorry, blame gmail paste) >Normally you don't need to touch such project files at all, but you >require not only that, but also that the people know which parts to take >out. > > >It really isn't that difficult, and it only has to be done once, plus any >minor modifications later. For something rarely done, Geany shouldn't need to >alter its existing code >too much - see my answer to Lex for more explanation. >Supporting GUI creation is much more work for Geany. As I said above, i think you underestimate the change rate. >Also, one could argue that foo.geany should override the stub file. >Anyway this is a feature not covered by the separate-file approach. > > > This could be added to the stub approach (if we decide we want it). I don't > think it could be added to Lex's proposal. I actually thought you meant it was this way around, see above for reasoning. >So, it seems more complicated for users, since the separate-file >approach would just work (no hand-editing required), so I disagree it's >simpler. OTOH it's probably simpler to implement (just load the stub >after, so things get overridden automagically) and >backward-
Re: [Geany-devel] Stub project files for sharing - creation plugin
On 04/11/2011 15:22, Nick Treleaven wrote: That solution seems awkward to me. Especially the creation part where you need to copy, then hand-edit. Normally you don't need to touch such project files at all, but you require not only that, but also that the people know which parts to take out. It really isn't that difficult, and it only has to be done once, plus any minor modifications later. For something rarely done, Geany shouldn't need to alter its existing code too much - see my answer to Lex for more explanation. Supporting GUI creation is much more work for Geany. Also someone could write a plugin to create stub project files that supports the common settings that would go in a stub project file. That would be less effort as it would only need to support a fraction of project settings. ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Stub project files for sharing
(There was no reply-to list address set for Thomas's mail (weird), so I'm now sending this to the list - possibly a Thunderbird issue). On 04/11/2011 09:56, Thomas Martitz wrote: Am 03.11.2011 15:45, schrieb Nick Treleaven: My solution: A foo.geanystub project file goes in version control. It is never written to. It should be prepared by manually editing a copy of a local project file. On opening a foo.geanystub file, Geany creates foo.geany in the same path then opens it. When opening foo.geany, if foo.geanystub exists, then override settings with the stub contents. This way the VC file can decide which settings are not overridable. My solution shouldn't require much code to implement. I've only noted the bare bones of it, there are some things that could be added to make it better. Even with these I think it's simpler and neater. That solution seems awkward to me. Especially the creation part where you need to copy, then hand-edit. Normally you don't need to touch such project files at all, but you require not only that, but also that the people know which parts to take out. It really isn't that difficult, and it only has to be done once, plus any minor modifications later. For something rarely done, Geany shouldn't need to alter its existing code too much - see my answer to Lex for more explanation. Supporting GUI creation is much more work for Geany. Also, one could argue that foo.geany should override the stub file. Anyway this is a feature not covered by the separate-file approach. This could be added to the stub approach (if we decide we want it). I don't think it could be added to Lex's proposal. So, it seems more complicated for users, since the separate-file approach would just work (no hand-editing required), so I disagree it's simpler. OTOH it's probably simpler to implement (just load the stub after, so things get overridden automagically) and backward-compatibility is not an issue. Also there is the problem with the original idea of deciding which settings go in each project file - there isn't always a right answer. Regards, Nick ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Stub project files for sharing - based on
On 04/11/2011 15:05, Nick Treleaven wrote: I like simple, why don't we just add a setting to projects, say "based on", that allows a project file to import settings from another. Then the user project is "based on" the one in the VCS working directory. Simple and explicit and can adapt to any locations, on opening the project, settings are taken from the "based on" file if it exists and the setting exists unless it is overridden by the user project file. Based on is not recursive. I see that 'based on' could be useful for making subprojects, and could be added to my proposal. Actually only when based on a stub project, not a full project. The latter would require too much reworking of code to be worthwhile IMO. ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Stub project files for sharing
On 03/11/2011 23:46, Lex Trotman wrote: On 4 November 2011 01:45, Nick Treleaven wrote: My solution: A foo.geanystub project file goes in version control. It is never written to. It should be prepared by manually editing a copy of a local project file. On opening a foo.geanystub file, Geany creates foo.geany in the same path then opens it. When opening foo.geany, if foo.geanystub exists, then override settings with the stub contents. This way the VC file can decide which settings are not overridable. My solution shouldn't require much code to implement. I've only noted the bare bones of it, there are some things that could be added to make it better. Even with these I think it's simpler and neater. Hi Nick, I like simple, why don't we just add a setting to projects, say "based on", that allows a project file to import settings from another. Then the user project is "based on" the one in the VCS working directory. Simple and explicit and can adapt to any locations, on opening the project, settings are taken from the "based on" file if it exists and the setting exists unless it is overridden by the user project file. Based on is not recursive. I see that 'based on' could be useful for making subprojects, and could be added to my proposal. 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. Rewriting code is what made me think supporting VCS project files was not worth it, but if that can be avoided and the new code is fairly minimal I think it's acceptable. 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 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. ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Stub project files for sharing
Am 03.11.2011 15:45, schrieb Nick Treleaven: My solution: A foo.geanystub project file goes in version control. It is never written to. It should be prepared by manually editing a copy of a local project file. On opening a foo.geanystub file, Geany creates foo.geany in the same path then opens it. When opening foo.geany, if foo.geanystub exists, then override settings with the stub contents. This way the VC file can decide which settings are not overridable. My solution shouldn't require much code to implement. I've only noted the bare bones of it, there are some things that could be added to make it better. Even with these I think it's simpler and neater. That solution seems awkward to me. Especially the creation part where you need to copy, then hand-edit. Normally you don't need to touch such project files at all, but you require not only that, but also that the people know which parts to take out. Also, one could argue that foo.geany should override the stub file. Anyway this is a feature not covered by the separate-file approach. So, it seems more complicated for users, since the separate-file approach would just work (no hand-editing required), so I disagree it's simpler. OTOH it's probably simpler to implement (just load the stub after, so things get overridden automagically) and backward-compatibility is not an issue. Best regards. ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Stub project files for sharing
On 4 November 2011 01:45, Nick Treleaven wrote: > Hi, > I think I can improve on Lex's recent proposal to split up project settings > into two files, one for version control and one for local changes. > > The problems with that are: > > * How do we decide which settings are in each - e.g. build menu commands - a > project might want to override the make command in the VC settings file, but > the user will want to add their own build commands too. There's a conflict. > This becomes increasingly messy as we add project settings. > > * Backwards compatibility - we would need to handle existing project files > anyway, which makes code more complex. I don't think we need to break > compatibility. > > * If the user changes a setting which is stored in the VC file they may end > up committing it, or perhaps sometimes not even realizing they are > overriding the VC setting. > > My solution: > > A foo.geanystub project file goes in version control. It is never written > to. It should be prepared by manually editing a copy of a local project > file. > > On opening a foo.geanystub file, Geany creates foo.geany in the same path > then opens it. > > When opening foo.geany, if foo.geanystub exists, then override settings with > the stub contents. > > This way the VC file can decide which settings are not overridable. > > My solution shouldn't require much code to implement. I've only noted the > bare bones of it, there are some things that could be added to make it > better. Even with these I think it's simpler and neater. Hi Nick, I like simple, why don't we just add a setting to projects, say "based on", that allows a project file to import settings from another. Then the user project is "based on" the one in the VCS working directory. Simple and explicit and can adapt to any locations, on opening the project, settings are taken from the "based on" file if it exists and the setting exists unless it is overridden by the user project file. Based on is not recursive. 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. 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. Cheers Lex > > Nick > ___ > Geany-devel mailing list > Geany-devel@uvena.de > https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel > ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
[Geany-devel] Stub project files for sharing
Hi, I think I can improve on Lex's recent proposal to split up project settings into two files, one for version control and one for local changes. The problems with that are: * How do we decide which settings are in each - e.g. build menu commands - a project might want to override the make command in the VC settings file, but the user will want to add their own build commands too. There's a conflict. This becomes increasingly messy as we add project settings. * Backwards compatibility - we would need to handle existing project files anyway, which makes code more complex. I don't think we need to break compatibility. * If the user changes a setting which is stored in the VC file they may end up committing it, or perhaps sometimes not even realizing they are overriding the VC setting. My solution: A foo.geanystub project file goes in version control. It is never written to. It should be prepared by manually editing a copy of a local project file. On opening a foo.geanystub file, Geany creates foo.geany in the same path then opens it. When opening foo.geany, if foo.geanystub exists, then override settings with the stub contents. This way the VC file can decide which settings are not overridable. My solution shouldn't require much code to implement. I've only noted the bare bones of it, there are some things that could be added to make it better. Even with these I think it's simpler and neater. Nick ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
