On Fri, 2 Mar 2001, Angus Leeming wrote:
> Allan,
>
> I've implemented your "tri-state output for input()" method exactly as you've
> described it below. (This implementation is in my local tree only).
>
> In order for it to work, (and it works perfectly) I have to modify
> ButtonController::input() to:
>
> void ButtonControllerBase::input(ButtonPolicy::SMInput in)
> {
> bp().input(in);
> + if (ButtonPolicy::SMI_NOOP == in) return;
> refresh();
> }
>
> (excuse the change of class name here.)
>
> I have to do this because refresh() is set up as:
_have_ to?
> void xformsBC::refresh()
> {
> if (okay_) {
> if (bp().buttonStatus(ButtonPolicy::OKAY)) {
> fl_activate_object(okay_);
> fl_set_object_lcol(okay_, FL_BLACK);
> } else {
> fl_deactivate_object(okay_);
> fl_set_object_lcol(okay_, FL_INACTIVE);
> }
> ...
> }
>
> (Again, this is the xforms implementation of the refresh() method).
>
> My modification seems like the cleanest solution (well, actually, move it up
> to line of ButtonController::input(), not line 2).
>
> Is it acceptable?
Your mod to my plan appears to me to just be an optimisation not an
essential. If the NOOP check (that same one-liner) was done in
nextState() then when refresh() is called you just end up refreshing what
was there before since the buttonStatus(Okay) will still be the same since
you haven't changed state -- remember it's the state that defines the
outputs (the button activations are the outputs of the state machine).
Since no transition was done on a NOOP the state remains the same so the
outputs remain the same.
So I don't see that you _have_ to but this is certainly an optimization.
Not a significant one and unless I've completely missed something there is
no other reason for it.
Actually, thinking about it, I don't like the idea of putting policy stuff
into the controller. It's only a shortcut and in this case a simple one
but its not that good an optimisation because it doesn't catch two
consecutive identical inputs (two SMI_VALIDs still cause two redraws) so
if you really want to optimise you need to change the algorithm for
refresh() to only operate on those buttons that actually changed state
(de/activated). [all these "state"s is getting confusing]
If you want to go down this route then you need to remember the previous
state. This means yet another variable for the button policy. This is
where Lars' suggestion that ButtonPolicy should be stateless comes in
(that is it doesn't have any variables of its own -- BC passes it the
variables it works on). A pair<State, State> should be sufficient.
Gosh, I probably could have implemented it in the time it's taken to write
this email ;-)
> > Yes, it will mean extending all the state machine definitions slightly --
> > add a line that says:
> > if (SMI_NOOP == in) return;
> >
> > to the top of nextState() in ButtonPolicies.C.
> >
> > Too easy?
Still too easy?
Please enlighten me why you think you have to implement it the way you
suggest.
Allan. (ARRae)
