On Wed, 30 May 2001, Angus Leeming wrote:
> On Wednesday 30 May 2001 14:33, Jean-Marc Lasgouttes wrote:
> > >>>>> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
> >
> > Angus> does the attached patch do what you want? If so, can I leave
> > Angus> this for you to apply to head and to 1.1.6?
> >
> > Close, but not perfect. If I am in a section (where Left and Block are
> > allowed (for an unknown reason BTW)) and select 'left', then the
> > center and right choices are available again.
>
> I change the title of this mail as the proposed patch changes the
> ButtonController and I think that Allan should be made aware of it!
>
> The problem lies (as ever) with the button controller. Specifically, the
> state of all widgets in the list of read_only widgets is refreshed every time
> we input anything. Clearly, they should be refreshed only when the read-only
> status of the document changes.
s/should/could/ (the fact they are refreshed everytime is _not_ a bug)
Sure, that is a nice optimization. That in this case also hides the lack
of support for groups in the current button controller -- at least for a
while until someone finds another case. I think I'd rather see a scheme
that kept the single refresh() but used a second bool variable to track
readonly status but this is just an implementation detail -- in other
words a:
bool current_readonly_status;
bool previous_readonly_status;
This state info should be moved out of the BC (and is in SME). Anyway,
I'm sure that my proposed StateMachineEngine would handle all this easily
(because of its support for groups). Have you managed to look at that yet?
I hope to get back to it to finish it off next week (maybe) -- it just
needs some final implementation coding. I just haven't had time this last
month and now I'm fighting the flu.
> The patch attached implements this. This may cure a lot of our problems with
> the ButtonController; let's hope so.
>
> This is the clean solution IMO. I think that you should test it out and, if
> it does as you originally desired, then it should be applied to both head and
> 1.1.6.
I suspect that you'll still find some case where it activates widgets that
you want left deactivated all because there is only one readonly group and
you attempt additional control of some of those widgets. With multiple
widget groups you could define a state machine that turned on and off
various groups at will. The old Paragraph dialog was such a beast when it
wanted to turn some widgets on and off based on radiobutton selections.
There may be dialogs that don't map well to state machines, or at least
not efficiently, in which case it may be better to have some procedural
controller for them. I still think a state machine can do any dialog we
want -- it's just that some dialogs may be easier with some specific
coding. I can't see a simple way to provide generic support for such
procedural coding although it could well use the same group structures as
the StateMachineEngine does.
Allan. (ARRae)
