On Fri, 13 Apr 2001, John Levon wrote:
> On Thu, 12 Apr 2001, Allan Rae wrote:
>
> > I have been. Trouble is other people want to do more with it than I
> > originally meant it for. In particular people want to disable entries for
> > read-only documents when AFAIAC this is unnecessary because the OK and
> > Apply buttons are disabled in those policies.
>
> It is very necessary for well-behaved feedback to the user.
Sure. Not everyone reads the "This buffer is readonly -- you can't change
stuff" dialog. But you are right though.
> > How much complexity in the policy state machine is it worth to have clever
> > interactive dialogs? Each dialog designer should be asking themselves if
> > they need the extra fancy control at all or whether they should be
> > thinking up a better interface design.
>
> FWIW, the KDE frontend was managing just fine without an explicit controller.
> I am perfectly happy for each frontend to NOT use a button controller at all.
As am I.
> And frankly I think it is somewhat lax of you to blame the controller design
> problems on poor dialog design ! Especially as we have inherited some, erm,
> interesting dialog designs from xforms that take some time to re-assess.
How complex a dialog do people want? If you follow the KISS principle you
get simple elegent designs. Fancy stuff like Angus' colour selection
switcheroo is possible with the new controller but is it really necessary?
After all the button controller did what it was designed for very well.
Trouble is, people wanted more than what I did which looks like a design
flaw. It was meant to really simple and small. The new one will see most
of the controller hierarchy for XForms at least shuffled around and has a
more general state machine engine.
> I do not consider a single thing I've asked for as "fancy"
I don't remember saying you did.
> > If anyone thinks of some fancy feature they want that this new group
> > activation model doesn't support I'm prepared to tell them to rethink
> > their interface -- such as if someone wants to hide/show widgets rather
> > than activating them.
>
> In 90% of cases this is a terrible idea. The user should be able to
> see roughly what a dialog can do when they first see it, *without* having
> to mess around with the widgets. One commone exception is tabbed dialogs,
> and as I'm sure you know they are awfully overused anyway.
Gotta put all those configuration items somewhere the screen isn't big
enough for one dialog and having multiple dialogs that you blaze a trail
through like W2k networking config is a bigger pain than tabs IMO.
Anyway, we need to try setting shortcuts for the tab folders in XForms --
this should be doable but may need to be done manually because they are
available in the data structures.
> so it can go back to an ad-hoc per-frontend approach. That's fine by me...
Did it ever leave there?
Allan. (ARRae)
