Re: [Geany-devel] More Per-Project Configuration Options
I'm pretty sure my last email didn't go through because I did not receive it, so I will resend it. If it did actually go through the first time, I am sorry for the duplicate. 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. ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] More Per-Project Configuration Options
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. ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
[Geany-devel] More Per-Project Configuration Options
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). ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] More Per-Project Configuration Options
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 meobl...@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
Re: [Geany-devel] More Per-Project Configuration Options
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 meobl...@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 meobl...@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
