Hi. I noticed a problem that affected me back in 0.2x that thankfully is (mostly) solved in 1.22. When I say mostly, I mean it fixes how the problem affects me right now, but possibly not for others, and I feel this may also affect me again eventually. The problem I noticed is that not all configuration options that may change from project-to-project are actually settings you can change on a per-project basis. The options that concern me the most are those that deal with the format of the saved file (line ending characters, new line at end of file (fixed in 1.22), tabs/spaces (not a problem), file encoding). I'm interested in the developers' opinions on this.
Someone in IRC also mentioned that if many more options become configurable per-project, the global application options might be rendered useless (as project settings will override everything). Perhaps this could be solved by having a way to reset individual project options (perhaps a list of all things that have been changed, and a "Reset to Global" button to reset that individual item so it does not appear in that project's file).
I'm curious what the core developers' opinion is on this. If it sounds good, I'd definitely be interested in helping make it possible (although I don't know the Geany code base, I could learn my way around relevant parts).
On 10 July 2012 09:57, Braden Walters meoblast@aol.com wrote:
Hi. I noticed a problem that affected me back in 0.2x that thankfully is (mostly) solved in 1.22. When I say mostly, I mean it fixes how the problem affects me right now, but possibly not for others, and I feel this may also affect me again eventually. The problem I noticed is that not all configuration options that may change from project-to-project are actually settings you can change on a per-project basis. The options that concern me the most are those that deal with the format of the saved file (line ending characters, new line at end of file (fixed in 1.22), tabs/spaces (not a problem), file encoding). I'm interested in the developers' opinions on this.
The "right" answer to this is that everything should be able to be configured in a project, but that not everything has to be. This just means that project settings override global/user ones. But it does make the UI more complex, it needs another preferences dialog for projects with an extra checkbox per field which indicates if that value is to be saved in the project file.
This is the way the build system settings work ATM, two dialogs, and in an effort to reduce confusion the user settings are greyed out if the setting is set in the project file. But it ends up needing a very complex UI and still not all build settings supported by the system are configurable by UI, no agreement could be reached over how to make it non-threatening for noobs but still powerful for advanced users. And ocassionally it provakes screems of confusion, though usually from those who havn't RTFM and wiki.
All these problems would apply to the whole preferences system if it worked this way.
Also it would require consideration of how this would interact with plugin prefs. How much visibility would plugins need and how much more complicated would it make plugins handling of their prefs?
On the implementation side, not all of Geany prefs are handled in one place, so it would probably mean touching quite a lot of the system.
Someone in IRC also mentioned that if many more options become configurable per-project, the global application options might be rendered useless (as project settings will override everything). Perhaps this could be solved by having a way to reset individual project options (perhaps a list of all things that have been changed, and a "Reset to Global" button to reset that individual item so it does not appear in that project's file).
Just a "save in project" checkbox, that lets you save/unsave it w/o changing the value.
I'm curious what the core developers' opinion is on this. If it sounds good, I'd definitely be interested in helping make it possible (although I don't know the Geany code base, I could learn my way around relevant parts).
The principle is fine, but the build system experience is that the practice is harder to balance simplicity with power. Also, whilst the capabilities are absolutely essential for a few use-cases, most of the time it will go unused.
Therefore given the effort required and the likely intrusiveness of the implementation, I don't think it should be implemented at the moment, unless someone wants to do it in a separate fork and can get comprehensive testing of that fork without merging it back into Geany.
Cheers Lex
Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Regarding the UI, I don't think it's necessary to put a checkbox next to everything. You could include a separate tab (something like "Details") which would then have a list of all changes made to the individual project. And then a button to remove that and restore to defaults. This would simplify at least the UI, because it'd just be a subset of the global preferences with an extra tab for the "Details" (or whatever it'd be called). Does this concept make sense?
Regarding plugins. That could be a problem. Perhaps at first plugin preferences should not be available on a per-project basis, as I could imagine that could be something quite complex to tag onto an already big job. Or is there another problem regarding plugins that I am not recognizing?
On 07/09/2012 10:26 PM, Lex Trotman wrote:
On 10 July 2012 09:57, Braden Walters meoblast@aol.com wrote:
Hi. I noticed a problem that affected me back in 0.2x that thankfully is (mostly) solved in 1.22. When I say mostly, I mean it fixes how the problem affects me right now, but possibly not for others, and I feel this may also affect me again eventually. The problem I noticed is that not all configuration options that may change from project-to-project are actually settings you can change on a per-project basis. The options that concern me the most are those that deal with the format of the saved file (line ending characters, new line at end of file (fixed in 1.22), tabs/spaces (not a problem), file encoding). I'm interested in the developers' opinions on this.
The "right" answer to this is that everything should be able to be configured in a project, but that not everything has to be. This just means that project settings override global/user ones. But it does make the UI more complex, it needs another preferences dialog for projects with an extra checkbox per field which indicates if that value is to be saved in the project file.
This is the way the build system settings work ATM, two dialogs, and in an effort to reduce confusion the user settings are greyed out if the setting is set in the project file. But it ends up needing a very complex UI and still not all build settings supported by the system are configurable by UI, no agreement could be reached over how to make it non-threatening for noobs but still powerful for advanced users. And ocassionally it provakes screems of confusion, though usually from those who havn't RTFM and wiki.
All these problems would apply to the whole preferences system if it worked this way.
Also it would require consideration of how this would interact with plugin prefs. How much visibility would plugins need and how much more complicated would it make plugins handling of their prefs?
On the implementation side, not all of Geany prefs are handled in one place, so it would probably mean touching quite a lot of the system.
Someone in IRC also mentioned that if many more options become configurable per-project, the global application options might be rendered useless (as project settings will override everything). Perhaps this could be solved by having a way to reset individual project options (perhaps a list of all things that have been changed, and a "Reset to Global" button to reset that individual item so it does not appear in that project's file).
Just a "save in project" checkbox, that lets you save/unsave it w/o changing the value.
I'm curious what the core developers' opinion is on this. If it sounds good, I'd definitely be interested in helping make it possible (although I don't know the Geany code base, I could learn my way around relevant parts).
The principle is fine, but the build system experience is that the practice is harder to balance simplicity with power. Also, whilst the capabilities are absolutely essential for a few use-cases, most of the time it will go unused.
Therefore given the effort required and the likely intrusiveness of the implementation, I don't think it should be implemented at the moment, unless someone wants to do it in a separate fork and can get comprehensive testing of that fork without merging it back into Geany.
Cheers Lex
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
On 10 July 2012 12:34, Braden Walters meoblast@aol.com wrote:
Regarding the UI, I don't think it's necessary to put a checkbox next to everything. You could include a separate tab (something like "Details") which would then have a list of all changes made to the individual project. And then a button to remove that and restore to defaults. This would simplify at least the UI, because it'd just be a subset of the global preferences with an extra tab for the "Details" (or whatever it'd be called). Does this concept make sense?
Its not just settings that have different values that should be saved in projects. Ones that you want to make sure that they do *not* change when user settings change also need to be stored (that was covered on IRC).
Therefore it still needs the checkbox per setting (or some other boolean UI mechanism), and it should be on the same page so you can see which are set by the project and which are not.
Regarding plugins. That could be a problem. Perhaps at first plugin preferences should not be available on a per-project basis, as I could imagine that could be something quite complex to tag onto an already big job. Or is there another problem regarding plugins that I am not recognizing?
Well plugins are maintained by people outside the project, with varying skills and experience, time availability etc. The Geany project can't force plugins to do anything, so any changes need to work as-is unless the plugin maintainer opts in to using the extra functionality. This is a decision by the *plugin* not Geany and so Geany has to somehow notice and accomodate that decision as plugins are loaded.
Cheers Lex
On 07/09/2012 10:26 PM, Lex Trotman wrote:
On 10 July 2012 09:57, Braden Walters meoblast@aol.com wrote:
Hi. I noticed a problem that affected me back in 0.2x that thankfully is (mostly) solved in 1.22. When I say mostly, I mean it fixes how the problem affects me right now, but possibly not for others, and I feel this may also affect me again eventually. The problem I noticed is that not all configuration options that may change from project-to-project are actually settings you can change on a per-project basis. The options that concern me the most are those that deal with the format of the saved file (line ending characters, new line at end of file (fixed in 1.22), tabs/spaces (not a problem), file encoding). I'm interested in the developers' opinions on this.
The "right" answer to this is that everything should be able to be configured in a project, but that not everything has to be. This just means that project settings override global/user ones. But it does make the UI more complex, it needs another preferences dialog for projects with an extra checkbox per field which indicates if that value is to be saved in the project file.
This is the way the build system settings work ATM, two dialogs, and in an effort to reduce confusion the user settings are greyed out if the setting is set in the project file. But it ends up needing a very complex UI and still not all build settings supported by the system are configurable by UI, no agreement could be reached over how to make it non-threatening for noobs but still powerful for advanced users. And ocassionally it provakes screems of confusion, though usually from those who havn't RTFM and wiki.
All these problems would apply to the whole preferences system if it worked this way.
Also it would require consideration of how this would interact with plugin prefs. How much visibility would plugins need and how much more complicated would it make plugins handling of their prefs?
On the implementation side, not all of Geany prefs are handled in one place, so it would probably mean touching quite a lot of the system.
Someone in IRC also mentioned that if many more options become configurable per-project, the global application options might be rendered useless (as project settings will override everything). Perhaps this could be solved by having a way to reset individual project options (perhaps a list of all things that have been changed, and a "Reset to Global" button to reset that individual item so it does not appear in that project's file).
Just a "save in project" checkbox, that lets you save/unsave it w/o changing the value.
I'm curious what the core developers' opinion is on this. If it sounds good, I'd definitely be interested in helping make it possible (although I don't know the Geany code base, I could learn my way around relevant parts).
The principle is fine, but the build system experience is that the practice is harder to balance simplicity with power. Also, whilst the capabilities are absolutely essential for a few use-cases, most of the time it will go unused.
Therefore given the effort required and the likely intrusiveness of the implementation, I don't think it should be implemented at the moment, unless someone wants to do it in a separate fork and can get comprehensive testing of that fork without merging it back into Geany.
Cheers Lex
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 mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Well, here's how I imagined it. Suppose you have global settings and you have it set to UNIX line endings and end files with a new line. You open a new project and by default, it's set to UNIX line endings and end files with a new line, but this _does not_ appear in the projects file nor in the list on what I below referred to as the "Details" tab. If at this point you change the global settings, settings in the project change as well (because nothing is actually defined in the project file). Now suppose you switch to Windows line endings in the project. Now it will add an entry to the project file, and this will also appear in the Details list as "Default end of line characters". If you change the global settings for line endings, this would not change the settings for this project (the project would still override the settings, because it's still defined in the project file). If you, in the project settings, change back to UNIX line endings, you will now have UNIX line endings in the project file, "Default end of line characters" will still appear in the Details list, and it'll still override any changes in the global configuration. To make it stop overriding changes in the global configuration, you would go to the Details list, select the configuration option, and select "Restore to Global Configuration" or something like this. This would remove that item from the project configuration and it'd return to the original state.
Does this make sense? Is this possible and would this be both user friendly and feasible to implement?
On 07/09/2012 10:49 PM, Lex Trotman wrote:
On 10 July 2012 12:34, Braden Walters meoblast@aol.com wrote:
Regarding the UI, I don't think it's necessary to put a checkbox next to everything. You could include a separate tab (something like "Details") which would then have a list of all changes made to the individual project. And then a button to remove that and restore to defaults. This would simplify at least the UI, because it'd just be a subset of the global preferences with an extra tab for the "Details" (or whatever it'd be called). Does this concept make sense?
Its not just settings that have different values that should be saved in projects. Ones that you want to make sure that they do *not* change when user settings change also need to be stored (that was covered on IRC).
Therefore it still needs the checkbox per setting (or some other boolean UI mechanism), and it should be on the same page so you can see which are set by the project and which are not.
Regarding plugins. That could be a problem. Perhaps at first plugin preferences should not be available on a per-project basis, as I could imagine that could be something quite complex to tag onto an already big job. Or is there another problem regarding plugins that I am not recognizing?
Well plugins are maintained by people outside the project, with varying skills and experience, time availability etc. The Geany project can't force plugins to do anything, so any changes need to work as-is unless the plugin maintainer opts in to using the extra functionality. This is a decision by the *plugin* not Geany and so Geany has to somehow notice and accomodate that decision as plugins are loaded.
Cheers Lex
On 07/09/2012 10:26 PM, Lex Trotman wrote:
On 10 July 2012 09:57, Braden Walters meoblast@aol.com wrote:
Hi. I noticed a problem that affected me back in 0.2x that thankfully is (mostly) solved in 1.22. When I say mostly, I mean it fixes how the problem affects me right now, but possibly not for others, and I feel this may also affect me again eventually. The problem I noticed is that not all configuration options that may change from project-to-project are actually settings you can change on a per-project basis. The options that concern me the most are those that deal with the format of the saved file (line ending characters, new line at end of file (fixed in 1.22), tabs/spaces (not a problem), file encoding). I'm interested in the developers' opinions on this.
The "right" answer to this is that everything should be able to be configured in a project, but that not everything has to be. This just means that project settings override global/user ones. But it does make the UI more complex, it needs another preferences dialog for projects with an extra checkbox per field which indicates if that value is to be saved in the project file.
This is the way the build system settings work ATM, two dialogs, and in an effort to reduce confusion the user settings are greyed out if the setting is set in the project file. But it ends up needing a very complex UI and still not all build settings supported by the system are configurable by UI, no agreement could be reached over how to make it non-threatening for noobs but still powerful for advanced users. And ocassionally it provakes screems of confusion, though usually from those who havn't RTFM and wiki.
All these problems would apply to the whole preferences system if it worked this way.
Also it would require consideration of how this would interact with plugin prefs. How much visibility would plugins need and how much more complicated would it make plugins handling of their prefs?
On the implementation side, not all of Geany prefs are handled in one place, so it would probably mean touching quite a lot of the system.
Someone in IRC also mentioned that if many more options become configurable per-project, the global application options might be rendered useless (as project settings will override everything). Perhaps this could be solved by having a way to reset individual project options (perhaps a list of all things that have been changed, and a "Reset to Global" button to reset that individual item so it does not appear in that project's file).
Just a "save in project" checkbox, that lets you save/unsave it w/o changing the value.
I'm curious what the core developers' opinion is on this. If it sounds good, I'd definitely be interested in helping make it possible (although I don't know the Geany code base, I could learn my way around relevant parts).
The principle is fine, but the build system experience is that the practice is harder to balance simplicity with power. Also, whilst the capabilities are absolutely essential for a few use-cases, most of the time it will go unused.
Therefore given the effort required and the likely intrusiveness of the implementation, I don't think it should be implemented at the moment, unless someone wants to do it in a separate fork and can get comprehensive testing of that fork without merging it back into Geany.
Cheers Lex
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 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
On 10 July 2012 13:43, Braden Walters meoblast@aol.com wrote:
Well, here's how I imagined it. Suppose you have global settings and you have it set to UNIX line endings and end files with a new line. You open a new project and by default, it's set to UNIX line endings and end files with a new line, but this _does not_ appear in the projects file nor in the list on what I below referred to as the "Details" tab. If at this point you change the global settings, settings in the project change as well (because nothing is actually defined in the project file). Now suppose you switch to Windows line endings in the project. Now it will add an entry to the project file, and this will also appear in the Details list as "Default end of line characters". If you change the global settings for line endings, this would not change the settings for this project (the project would still override the settings, because it's still defined in the project file). If you, in the project settings, change back to UNIX line endings, you will now have UNIX line endings in the project file, "Default end of line characters" will still appear in the Details list, and it'll still override any changes in the global configuration. To make it stop overriding changes in the global configuration, you would go to the Details list, select the configuration option, and select "Restore to Global Configuration" or something like this. This would remove that item from the project configuration and it'd return to the original state.
Yes the basic mechanism is fine.
Does this make sense? Is this possible and would this be both user friendly and feasible to implement?
Anything can be implemented, but some things should not be :)
Two problems with your UI,
1. to tell it "I want this to be stored in the project file with the current value" I have to change the value and then change it back, thats poor UI technique.
2. by having your list on another page, looking at the project prefs dialog you can't tell what is set by the project and what is just default from the global settings, thats definitely poor UI design
Also just to add extra confusion to the mix, some settings (eg indent) are stored in the filetypes as well, but ATM the project can't say "for this project C files should be tab indented and Python files space indented". I am not sure how project indent settings and filetype indent settings interact ATM.
Cheers Lex
[...]
On 12-07-09 04:57 PM, Braden Walters wrote:
Hi. I noticed a problem that affected me back in 0.2x that thankfully is (mostly) solved in 1.22. When I say mostly, I mean it fixes how the problem affects me right now, but possibly not for others, and I feel this may also affect me again eventually. The problem I noticed is that not all configuration options that may change from project-to-project are actually settings you can change on a per-project basis. The options that concern me the most are those that deal with the format of the saved file (line ending characters, new line at end of file (fixed in 1.22), tabs/spaces (not a problem), file encoding). I'm interested in the developers' opinions on this.
Someone in IRC also mentioned that if many more options become configurable per-project, the global application options might be rendered useless (as project settings will override everything). Perhaps this could be solved by having a way to reset individual project options (perhaps a list of all things that have been changed, and a "Reset to Global" button to reset that individual item so it does not appear in that project's file).
I'm curious what the core developers' opinion is on this. If it sounds good, I'd definitely be interested in helping make it possible (although I don't know the Geany code base, I could learn my way around relevant parts).
Hi,
What about just adding new settings to the project config file without messing with the UI? Those who need them can RTM and see what settings are available, those who are content with what exists currently can go on happily ever after. You can add as many project preferences as you care to code and document this way.
If a user sets something in the project config file, it overrides the global config file when that project is open, end of story, no UI tricks needed to tell her this, it's "just how it is" (documented).
The other way(s) discussed seem like they would Eclipse the UI's usability.
My $0.02
Cheers, Matthew Brush
Am 10.07.2012 07:37, schrieb Matthew Brush:
On 12-07-09 04:57 PM, Braden Walters wrote:
Hi. I noticed a problem that affected me back in 0.2x that thankfully is (mostly) solved in 1.22. When I say mostly, I mean it fixes how the problem affects me right now, but possibly not for others, and I feel this may also affect me again eventually. The problem I noticed is that not all configuration options that may change from project-to-project are actually settings you can change on a per-project basis. The options that concern me the most are those that deal with the format of the saved file (line ending characters, new line at end of file (fixed in 1.22), tabs/spaces (not a problem), file encoding). I'm interested in the developers' opinions on this.
Someone in IRC also mentioned that if many more options become configurable per-project, the global application options might be rendered useless (as project settings will override everything). Perhaps this could be solved by having a way to reset individual project options (perhaps a list of all things that have been changed, and a "Reset to Global" button to reset that individual item so it does not appear in that project's file).
I'm curious what the core developers' opinion is on this. If it sounds good, I'd definitely be interested in helping make it possible (although I don't know the Geany code base, I could learn my way around relevant parts).
Hi,
What about just adding new settings to the project config file without messing with the UI? Those who need them can RTM and see what settings are available, those who are content with what exists currently can go on happily ever after. You can add as many project preferences as you care to code and document this way.
I hate needing to edit config files directly. This is not user friendly.
If a user sets something in the project config file, it overrides the global config file when that project is open, end of story, no UI tricks needed to tell her this, it's "just how it is" (documented).
The other way(s) discussed seem like they would Eclipse the UI's usability.
I actually quite like how Eclipse handles this, it should be considered for Geany too:
Each global settings tab (given it can be overridden by a project) has a line at the top saying that it can be overridden on a per-project basis.
Then, for each project, each tab in the project preferences have a checkbox at the top that choose whether to inherit from global settings or override all settings in the tab. Unchecking the checkbox immediatly applies the global settings to the project. Checking the box prefills the settings with the values from the current global settings but can be changed obviously.
Note that settings are grouped in tabs, so there is not one checkbox per setting, but per tab.
This UI makes it easy to discover if stuff can be/is overriden by a project. It makes it easy to revert to global settings. It makes it possible without a massive amount new per-setting checkboxes to decide whether to override.
PS: Eclipse's way to handle per-file settings is also quite OK IMO but I guess that's another topic.
Best regards.
On 07/10/2012 02:56 AM, Thomas Martitz wrote:
Am 10.07.2012 07:37, schrieb Matthew Brush:
On 12-07-09 04:57 PM, Braden Walters wrote:
Hi. I noticed a problem that affected me back in 0.2x that thankfully is (mostly) solved in 1.22. When I say mostly, I mean it fixes how the problem affects me right now, but possibly not for others, and I feel this may also affect me again eventually. The problem I noticed is that not all configuration options that may change from project-to-project are actually settings you can change on a per-project basis. The options that concern me the most are those that deal with the format of the saved file (line ending characters, new line at end of file (fixed in 1.22), tabs/spaces (not a problem), file encoding). I'm interested in the developers' opinions on this.
Someone in IRC also mentioned that if many more options become configurable per-project, the global application options might be rendered useless (as project settings will override everything). Perhaps this could be solved by having a way to reset individual project options (perhaps a list of all things that have been changed, and a "Reset to Global" button to reset that individual item so it does not appear in that project's file).
I'm curious what the core developers' opinion is on this. If it sounds good, I'd definitely be interested in helping make it possible (although I don't know the Geany code base, I could learn my way around relevant parts).
Hi,
What about just adding new settings to the project config file without messing with the UI? Those who need them can RTM and see what settings are available, those who are content with what exists currently can go on happily ever after. You can add as many project preferences as you care to code and document this way.
I hate needing to edit config files directly. This is not user friendly.
If a user sets something in the project config file, it overrides the global config file when that project is open, end of story, no UI tricks needed to tell her this, it's "just how it is" (documented).
The other way(s) discussed seem like they would Eclipse the UI's usability.
I actually quite like how Eclipse handles this, it should be considered for Geany too:
Each global settings tab (given it can be overridden by a project) has a line at the top saying that it can be overridden on a per-project basis.
Then, for each project, each tab in the project preferences have a checkbox at the top that choose whether to inherit from global settings or override all settings in the tab. Unchecking the checkbox immediatly applies the global settings to the project. Checking the box prefills the settings with the values from the current global settings but can be changed obviously.
Note that settings are grouped in tabs, so there is not one checkbox per setting, but per tab.
This UI makes it easy to discover if stuff can be/is overriden by a project. It makes it easy to revert to global settings. It makes it possible without a massive amount new per-setting checkboxes to decide whether to override.
PS: Eclipse's way to handle per-file settings is also quite OK IMO but I guess that's another topic.
Best regards. _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
That actually sounds like a good idea. Here's another idea I had last night. If there is no context menu for any item in the settings, that could be added for each item. If you change anything to where it'd be included in the project configuration and override the global settings, perhaps change the colour of the option's label or create some simple way of making this noticeable. Then, if the user wants to revert to the global settings, he/she could secondary click and select "Restore to Global Settings". This would allow full customization (you don't have to do it on a per-tab basis) and it's not very intrusive into the UI.
On 12-07-09 11:56 PM, Thomas Martitz wrote:
Am 10.07.2012 07:37, schrieb Matthew Brush:
On 12-07-09 04:57 PM, Braden Walters wrote:
Hi. I noticed a problem that affected me back in 0.2x that thankfully is (mostly) solved in 1.22. When I say mostly, I mean it fixes how the problem affects me right now, but possibly not for others, and I feel this may also affect me again eventually. The problem I noticed is that not all configuration options that may change from project-to-project are actually settings you can change on a per-project basis. The options that concern me the most are those that deal with the format of the saved file (line ending characters, new line at end of file (fixed in 1.22), tabs/spaces (not a problem), file encoding). I'm interested in the developers' opinions on this.
Someone in IRC also mentioned that if many more options become configurable per-project, the global application options might be rendered useless (as project settings will override everything). Perhaps this could be solved by having a way to reset individual project options (perhaps a list of all things that have been changed, and a "Reset to Global" button to reset that individual item so it does not appear in that project's file).
I'm curious what the core developers' opinion is on this. If it sounds good, I'd definitely be interested in helping make it possible (although I don't know the Geany code base, I could learn my way around relevant parts).
Hi,
What about just adding new settings to the project config file without messing with the UI? Those who need them can RTM and see what settings are available, those who are content with what exists currently can go on happily ever after. You can add as many project preferences as you care to code and document this way.
I hate needing to edit config files directly. This is not user friendly.
I never meant to imply it would be "user friendly" (ie. like something my Grandma could use), just that it would avoid messing with the UI until most of the coding is actually done. In the future some (or all) of the preferences could be moved to the GUI and we could discuss the colour of the bikeshed at that point once the code is actually working.
Besides, it's not like it's unheard of for Geany (or even other editors like ST2) to make you edit config files.
If a user sets something in the project config file, it overrides the global config file when that project is open, end of story, no UI tricks needed to tell her this, it's "just how it is" (documented).
The other way(s) discussed seem like they would Eclipse the UI's usability.
I actually quite like how Eclipse handles this, it should be considered for Geany too:
Last time I tried it I got very confused and was overwhelmed with the sheer volume of user-interface elements I was seeing. It may be logical but it's not very simple, IMO.
Each global settings tab (given it can be overridden by a project) has a line at the top saying that it can be overridden on a per-project basis.
Then, for each project, each tab in the project preferences have a checkbox at the top that choose whether to inherit from global settings or override all settings in the tab. Unchecking the checkbox immediatly applies the global settings to the project. Checking the box prefills the settings with the values from the current global settings but can be changed obviously.
Note that settings are grouped in tabs, so there is not one checkbox per setting, but per tab.
This UI makes it easy to discover if stuff can be/is overriden by a project. It makes it easy to revert to global settings. It makes it possible without a massive amount new per-setting checkboxes to decide whether to override.
PS: Eclipse's way to handle per-file settings is also quite OK IMO but I guess that's another topic.
Best regards. _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Cheers, Matthew Brush