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.
> 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.
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.
I do not consider a single thing I've asked for as "fancy", especially as I
could easily cope with the "fancy" features without the help of a button
controller. Look back at my old comments on exactly this subject. As it is here,
though, I would prefer to use it if possible ... but you seem to be suggesting
I shouldn't ?
> 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.
> specific then we'll probably either see different ports restricting their
> interface implementations to match someone else's policy or have a massive
> flood of policies (not necessarily a bad thing but it could be a
> maintenance pain later).
so it can go back to an ad-hoc per-frontend approach. That's fine by me...
thanks
john
--
"What, so the microchips are in the MCU ?"
- Sam Burton learning about the PC architecture
