On Wed, 15 May 2002, Angus Leeming wrote:
> On Wednesday 15 May 2002 7:28 pm, John Levon wrote:
> > > > This is heading dangerously close to re-implementing a widget toolkit
> > > > and I'm not sure I like the idea.
> > >
> > > Bollocks. It's just OO-code. Nothing more.
> >
> > As long as it stays optional I suppose it's OK. But, for example,
> > assuming a frontend has even grouped things in a similar fashion is an
> > over-assumption of the generic code imo.
>
> The idea about the "suspect" widgets is for the button controller to have an
> addSuspect method. I'd invoke it within the View's build method:
>
> bc().addSuspect(&widgets().someSuspectWidget);
>
> Then when bc.valid() gets called, it could loop over this list of widgets
>
> list<XFwidget *> suspect;
> list<XFwidget *>::const_iterator it = suspect.begin();
> list<XFwidget *>::const_iterator end = suspect.end();
> bool valid = true;
> for (; it != end; ++it) {
> if (!isValid(*it))
> valid = false;
> }
>
> if (valid)
> // enable Apply/Ok
>
> So, if you don't want this, then don't invoke addSuspect!
>
> I'd like to see what you come up with instead in QPreferences though...
I don't believe it! You are proposing to work around the abuse of
input() by adding an extra way of handling inputs (what you
euphamistically call "Suspects") while retaining the overuse and abuse
of input().
Why not make a cleaner separation of the callbacks the widgets use so
that input() doesn't get called by command/control widgets but only by
input widgets (ones which may be able to have an invalid value).
That way you separate the code in the BC so you handle like-with-like
instead of a heterogeneous mix like it is now. *And* you no longer
need to pass bogus values to the BC.
Personally, I think BC changes should not be done in the 1.3cvs
(partly to keep the cycle shorter, partly to work out what hierarchy
reworking is needed and then figure out what/how a BC should work).
But you are writing code and I am writing a thesis so you ultimately
get to choose.
Allan. (ARRae)
