Re: Update Preference Model

[Adam Jocksch <ajocksch at redhat dot com>]

Thanks, this is exactly the kind of guidance we were looking for :)

Your points about auto-generated GUIs are well taken, and I will admit 
that the auto-generated window as it stands now is not one of the more 
clearer dialogs I've ever seen. When we were originally putting 
preferences into frysk, we followed exactly the model you'd suggested: 
Hardcoded glade dialog, and the just grab the preferences by name when 
we needed them in the code. What I found after a while is that it 
quickly became unmaintainable and changing things relating to the 
preferences became more complicated with every preference added. The aim 
of this new model was to bypass that complication and make it easier to 
make changes, but as you've correctly pointed out we've paid the price 
for it in usability. I like the way the new preference model works 
internally and attaching a hardcoded window to that shouldn't be too 
difficult. There will still be some maintenance issues but hopefully we 
can find a pretty (aesthetically and implementation-wise) solution to this.
> (Since you asked for feedback...)
>
> I'm not a fan of this at all!  Autogenerated and automatic preferences
> are a pretty classic user-interface mistake, though a common one.  It
> leads to an incoherent dialog, a bad set of preferences, and poorly
> thought out dialogs.  It interacts badly when you have conflicting
> preferences, doesn't give you a way to give good feedback, and
> invariably grows complicated beyond bool/int as you hit special cases.
> It's occasionally okay to do if you have a complicated plug-in system,
> and patient users, but if you can at all avoid it, please do so!
>
> It's not too hard to mock out the preferences in glade and hook them up
> -- especially if you're going for such a simple commit model.  It also
> forces you to think about which preferences are important to include,
> and which ones aren't needed, or could be done in a better way.
>
> Rather than write a system to handle preferences, it's better to figure
> out what those preferences should be, and try to do a reasonable effort
> based on that.
>
> Thanks,
> -Jonathan