[Geany-devel] More Per-Project Configuration Options
meoblast at xxxxx
Tue Jul 10 03:43:01 UTC 2012
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 at 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
> 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
> 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.
>> On 07/09/2012 10:26 PM, Lex Trotman wrote:
>>> On 10 July 2012 09:57, Braden Walters <meoblast at 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
>>>> affects me right now, but possibly not for others, and I feel this may
>>>> affect me again eventually. The problem I noticed is that not all
>>>> configuration options that may change from project-to-project are
>>>> settings you can change on a per-project basis. The options that concern
>>>> the most are those that deal with the format of the saved file (line
>>>> 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
>>> 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
>>>> per-project, the global application options might be rendered useless (as
>>>> project settings will override everything). Perhaps this could be solved
>>>> 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
>>>> 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
>>>> I'd definitely be interested in helping make it possible (although I
>>>> 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.
>>>> Geany-devel mailing list
>>>> Geany-devel at uvena.de
>>> Geany-devel mailing list
>>> Geany-devel at uvena.de
>> Geany-devel mailing list
>> Geany-devel at uvena.de
> Geany-devel mailing list
> Geany-devel at uvena.de
More information about the Devel