On Wed, 11 Apr 2001, Asger K. Alstrup Nielsen wrote:
> > Thoughts?
>
> I think you should consider once more whether this big and complicated
> machinery is really the best approach.
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.
A state-machine is the best match for what we need IMO. But what I want
and others want may be different. A suggestion of a suitable tool for
designing and documenting state-machines is welcome. I will eventually
get around to drawing state-machine diagrams for existing policies with
Dia or XFig (hopefully this weekend).
> It seems to be, looking from the sideline, that you have come to this
> point like this: First, an initial buttoncontroller was build.
Targetted at just controlling the Okay, Apply, Cancel and Restore buttons
with the facility to disable any widgets people didn't want enabled when
the document was made read-only. This last feature is redundant because
the Okay and Apply buttons are disabled on readonly policies.
> This turned out to be not as general as it could be, so it was rebuild
> in a better self.
The button controller was split along the same lines of the view/control
split done for the dialogs so the same controller could be used in the
non-XForms ports rather than copy-and-paste a new one with minor changes.
> Then, this was introduced, but once again, it turned out that it was
> insufficient. Now, you can come up with a fairly general, but also
> quite complicated design. This general design looks like a kind of
> state machine facility. For each widget, you define a mapping to
> reflect whether it should be enabled or not.
It is completely state machine driven -- just like it always was only
instead of being specific to four buttons it should now support as many
groups of widgets as you care to define and you specify in the policy
which groups are active in which states. That is the activation of the
widgets is the output of the state machine. All group names, states and
state-machine inputs are defined in the policy, then the user of the
button controller chooses the policy and then adds widgets to the groups.
> At first, this does indeed look fairly general, and certainly a
> step in the right direction. However, my bet is that you will need to
> extend even this general mechanism fairly soon. Then, you will discover
> that some dialog should enable and disable buttons according to what a
> certain input field contains, what item is selected in a drop list,
> and so on.
For the examples you give this means extending the policy to have more
states and possibly adding more groups. Thus the policy in use becomes
more dialog specific. The button controller remains the same. All
existing policies with the exception of the Preferences policy are
general-purpose (and the Preferences policy just has a special treatment
of the 4 buttons which is unlikely to be reused elsewhere). Of course
there will come a time when people have to consider just how complex a
state machine they are prepared to design and document just to have clever
control of the dialogs widgets.
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.
Also note that adding an extra constraint can mean doubling the number of
states in some state machines. As a result any future revisions are more
likely to occur in the implementation rather than the design I think (to
limit memory requirements).
> It seems to me that the problem is very hard: It's not by accident that
> there does not exist a one-size-fits-all GUI design. Every toolkit does
> things it's own way, and so far, nobody has come up with a design that
> is general enough to support all needs. Now, this is not to say that it
> is not possible to come up with such a design at all. It's just a word
> of caution: It will prove harder than it seems.
>
> Given this, it's worth stopping and considering the best way to support
> the GUII work. Is it really worth the effort to develop the best and most
> general controller abstraction?
> Would it not be better to hold it, and just do the Model/ViewController
> split as discussed earlier?
Angus has already said he has split all the existing GUII dialogs into
completely separate MVC units now. The button controller has been
similarly split and now a generalization is being proposed.
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. They could extend the actions taken in a particular
state within their dialog if they really, really, really wanted to and
that wouldn't require an extension to the BC (except offering a callback
on a change of state -- using a Signal1<State>). In addition I've already
mentioned in other emails that if we start making the policies too
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).
Also Baruch has mentioned he doesn't want Cancel/Close button relabelling
for Gnome but this is easily avoided by not setCancel()ing the cancel
button since that button doesn't have anything else about it controlled by
the controller -- either that or just instantiate the BC with both label
entries identical.
Thanks,
Allan. (ARRae)
P.S. Long enough for you Angus? :P
