Hello, Allan.
Let me start with a justification of all this: I'd like to ease the pain of
porting the dialogs to other GUIs by ensuring that they have only a minimum
of things to do. We have occasional complaints from John and Marco about
breaking their ports. Matthias Ettrich was rather more vocal. They are
expressing a valid point. It's hard to keep up when the rules keep changing.
Each dialog exists to change some variables. Nothing more. It should,
therefore, be passed only those variables (preferably as a Param struct). It
should also have access to functions linked to the four Apply, Ok, Cancel,
Reset buttons. Nothing more.
Everything else about the dialog, the signals it connects and disconnects to
etc, should be controlled by a common Controller class. The GUIs need not
worry about this. I've implemented this successfully.
In the same way, we can define a subset of the ButtonController class that is
GUI-I. The GUI View need know about only the BC::valid() method called when
an input is made and in the xforms case, about methods passed an FL_OBJECT *.
You've written the Controller beautifully (serious here) so that the
BC::apply(), ok() etc buttons know nothing about the xforms implementation.
I have it all working here. A ButtonController base class and a
FormButtonController derived class containing xforms-specific stuff. I have a
ControlledButtonDialog abstract class that has a ButtonController * and 4
methods, ApplyButton(), OkButton, CancelButton() and RestoreButton() that
does exactly as the static ApplyBC() etc used to do. All dialog-specific
controllers can be derived from this.
It looks and feels clean and elegant and MINIMAL. That means, it should be
readily understandable to John, Marco, whoever wants to implement another GUI.
If you want a look, just ask. Otherwise, I'll post when it's clean. I send
enough junk to this list as-is!
Angus
On Saturday 13 January 2001 04:45, Allan Rae wrote:
> On Fri, 12 Jan 2001, Angus Leeming wrote:
> > Allan,
> >
> > I've worked out how to put an abstract ButtonControllerBase in the
> > ControlCitation class, or rather in a class that ControlCitation can be
> > derived from.
>
> Are you sure you want an inheritance relationship?
>
> I'm not sure what sort of separations you are hoping to achieve here. At
> this point in time I'd prefer to continue with what we already have and
> then develop a separation later if it really is necessary. Are you sure
> that what you are doing is actually going to be reusable by either John
> or Marko or any other port for that matter? If there is a good chance
> that it won't, then steady your beating heart and direct your passions
> elsewhere ;-)
>
> Perhaps now would be a good time to explain in detail what you are
> separating and why. Or maybe I should read that other email from earlier
> in the week if I can find it in the mess that is my mailbox.
>
> > I have one question regarding your ButtonController class. In the header
> > file there is:
> >
> > // Somebody else owns the FL_OBJECTs we just manipulate them.
> > // so? (Lgb)
> > //~ButtonController() {}
> >
> > Well and good. But SURELY the ButtonController owns its ButtonPolicy and
> > so this pointer should be deleted by the ButtonController d-tor?
>
> Yes. This will soon spot anyone who is doing it wrong.
>
> Allan. (ARRae)
