[Geany-devel] More Per-Project Configuration Options

[Braden Walters]

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