On Thu, 12 Apr 2001, Allan Rae wrote:
> > 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.
And this will be the situation for a long time...
> 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.
...as you admit here.
However, your resolution of the problem seems arbitrary: You decide that
enabling/disabling of buttons is ok, while hiding is not ok. For some
reason it suddenly is suspicious interface design to hide irrelevant
stuff. It might be a good place to draw a line regarding what the
controller should do, but you have to find a better argument than that.
I think I can give you one.
Implementing the showing/hiding of buttons according to states is a fair
wish, but it has two consequences:
- The controller has to be extended with hiding/showing of buttons
- The state machines will be customized to each dialog, since it's
not realistic that the specialized state machines can be reused
across dialogs
And then, you have to balance the score: Is it really simpler to use
the state machine controller to define the logic in the dialog when
you have to do it separately for each dialog that want that feature?
In other words, maybe we indeed have discovered a good point to draw a
line in the sand: As long as a controller abstracts both across different
dialogs within the same toolkit, and across different toolkits, it
probably is a good idea to introduce it.
However, if the controller does not provide both of these benefits,
it might not be worth it. You certainly have to argue a better case in
those situations before you start coding.
In conclusion: As long as the current proposal still extends the framework
in the direction of abstraction along both the dialog axis and the toolkit
axis, you are on the right track.
So all of this leaves us with the same old lesson once again:
Small steps. It's important always to understand why you are doing
things, and consider why they are such a good idea.
Greets,
Asger
