Re: [Usability] instant-apply issue



Jonathan Blandford <jrb redhat com> writes: 
> Well, if you have multiple versions of the same dialog, it can happen
> (like the nautilus preferences dialog.)

True, I didn't think about that case. (It's still an unusual case, but
less so.)

> >  2) It makes prefs dialogs far harder to implement, you have to write
> >     a bunch of code to monitor gconf changes.
> 
> Most of the time this isn't too bad.

It's pretty ugly without a convenience wrapper thingy.
gconf-property-editor.c isn't a tiny amount of code.

> >  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.
> 
> You just have to only propagate the change if the value is different.
> Just make sure you don't set a different value.

Another bit of complexity, though. (And even that check isn't good
enough if people do the bad thing they often want to do where they set
a value in response to a notify.)
 
> I doubt that changes will occur in a vacuum on a regular basis.  I bet
> you're more likely to see it when you leave a dialog open, forget about
> it, reopen it on a different terminal and come back to the first
> one.

Even there I really don't see that much harm in showing the old value
- as soon as the user changes it things will re-sync, and they'll
realize the old value is due to their other change on the other
terminal.
 
> That's probably fine, but there's nothing wrong in going the extra mile
> to handle the situation.  It's pretty slick when it works, and for
> numbers, lists and booleans it's really easy to implement.

OK, you convinced me that it's fine to do this if you're feeling
ambitious and careful enough to avoid the issues. However I'm
personally too lazy I think. ;-)

Havoc



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]