On Wed, Aug 22, 2001 at 01:38:44PM +1000, Allan Rae wrote:
> Unless the codes been changed you don't tell the button-controller what
> state to move to but what state-machine input has arrived. The
> state-machine (BC) then moves to the appropriate state from its current
> state.
yes, that's what I meant, I wasn't clear.
> > but determining STATE is not trivial. For example, I click the UP arrow of
>Citation.
> > Now, I want OK to be enabled, but I have no real idea that another widget's value
> > isn't invalidating the contents (in which case it shouldn't be enabled).
> >
> > So that means whenever I do something like that, I have to recalculate the validity
> > of the dialog. This will be no fun form QPreferences ...
>
> That is correct on both counts. You need to recheck validity but there
ok, thanks for sanity checking my claim. What I'm doing now is having a changed()
slot in Qt2Base, and an isValid() virtual method :
void Qt2Base::changed()
{
if (isValid())
bc().valid();
else
bc().invalid();
}
dialogs that need to can override the isValid() member function.
> Now for the idea:
> In a tabbed dialog (or one where there is some way of selecting multiple
> separate pages of a dialog whether that be a tree structure or a bunch of
> icons) we know what the current tab is. We also know when a user picks a
A simpler, and better IMHO, idea is to what the gnome/kde control dialogs do.
When a tab is changed, if the input is changed, it asks the user what to do.
We can adapt that scheme to point out entries are invalid or whatever.
Though I think that is something per-frontend to handle.
> I'd like to get my StateMachineEngine finished sometime but I'd also
> like to give the whole dialog hierarchy a major overhaul. The inheritence
> tree is a great, big, long, almost-single-stranded vine instead of a tree
> with branches. There are things being inherited high up the hierarchy
> that should be inherited at the final controller level IMO.
I suppose that is something to talk to Angus about whilst I look confused ;)
> Why not just use the IgnorantPolicy until you have the rest of the dialog
> working? This is the equivalent of how LyX used to run before I got
Policy is dictated by the controllers right now.
But since I think I follow what's happening now, I should be OK to extend and expand
where needed.
thanks
john
--
"That's just kitten-eating wrong."
- Richard Henderson