Re: [Usability] instant-apply issue

[George <jirka 5z com>]

On Sat, Jan 12, 2002 at 11:04:25PM -0500, Havoc Pennington wrote:
> My opinion is fairly strongly that this is a bad idea - I have to
> disagree with Jeff and Nils here.
> 
> Here are the reasons:
> 
>  1) The situation basically won't ever happen in practice.

Imagine multiple logins.  Imagine one key, such as say the proxy settings
being settable from multiple places.  I can think of places where it happens,
and it would make for weird results if you didn't handle it.

>  2) It makes prefs dialogs far harder to implement, you have to write
>     a bunch of code to monitor gconf changes.

PonG!  I can't see an issue with why people say prefs dialogs are hard to
write.  It's a few minutes with pong and one or two lines of code in your
program.

>  3) It introduces a lot of potential for bizarre infinite loops 
>     in the prefs dialog code, if you change the key yourself
>     then get a notify then set the widget then change the 
>     key yourself, etc. etc.

This is a problem with GConf.  There are ways around it.  It is a problem for
any sort of "view" of GConf.  Say the GConf editor NEEDS to reflect the
current state, not the state that was there when it was open.

>  4) I don't like it from a UI standpoint, because the chances are much
>     higher that the gconf key was suddenly set by some system
>     implementation detail or something, than that the user has
>     switched to a terminal and started using "gconftool" - so if you
>     update prefs widgets on gconf key changes, you are blowing away
>     what the user had typed in. i.e. there's potential for losing user
>     data. Granted with instant-apply this is less of an issue, but
>     e.g. if you apply on focus out of a text entry, you could
>     overwrite the text before the focus out, for example.

This is instant apply and so the dialog REPRESENTS the state of the
preferences and should be 100% synced.

Imageine you have a setup wizard (druid, whatever you call it) that say sets
up your connection and a bunch of other things.  Now you have a prefs window
open and you run the druid.  What happens when you now touch the widgets in
the prefs window.

>  5) I don't like it from a UI standpoint, because the user won't 
>     understand why the value suddenly changed in the dialog
>     all by itself.

The user won't understand why the dialog says one thing and the reality is
something else if you don't do it.

> Overall: the situation will hardly ever arise, and when it does it's a
> tossup whether updating the dialog widgets is even nice UI, and doing
> this adds a ton of bug-prone code. So my guess is that from a
> practical standpoint trying to do this will just be visible to users
> in the form of bugs rather than features.

PonG, PonG, PonG, PonG!

Why are we still talking about coding preference dialogs by hand.
Of course people ARE masochistic and seem to LOVE doing lots of boiler plate
buggy code for preference dialogs and so no one uses PonG.

(Of course disclaimer is that PonG isn't yet ported to 2.0, but given the
 utter lack of interest it gets it's understandable that I'm not that keen any
 more on working on it as much.  That said I want to port it, there are just
 more important things like gdm, panel and such if I find the time to code)

George

-- 
George <jirka 5z com>
   I know not with what weapons World War III will be fought, but
   World War IV will be fought with sticks and stones.
                       -- Albert Einstein