Re: push() double-inherited when creating Canvas Wrapper when naively following deprecated backend examples

Andrew Sutherland <[email protected]>:
>
> I'm trying to get the not-super-up-to-date canvas stuff

Not-super-up-to-date indeed... Actually, not up to date at all :]

> going on in my local copy of anygui by adapting Fred L. Drake, Jr.'s
> piddleGTK code into the gtk backend.  However, I'm running into the
> problem that it seems like I need to inherit from both
> anygui.backends.gtkgui.ComponentWrapper and anygui.Canvases.Canvas,
> each of which have a push method in their hierarchy.

Hm. That doesn't sound right. My intuition would be to have a
CanvasWrapper in the back-end (which inherits from ComponentWrapper),
and to make Canvas communicate with it through the push/pull protocol,
just like with other components. The fact that the current Canvas
isn't really designed for that is just a consequence of its
not-super-up-to-dateness :)

Subclassing one class from the front-end and one from the back-end
sounds a bit scizophrenic (or, rather, MPDish ;). The architecture
wasn't designed to deal with this; hence the name clash.

> I felt the need to inherit from both classes because the Canvas
> class requires you to subclass it to provide key methods like
> drawPolygon.

Right. But (as can be seen from the somewhat dated comment in the
Canvases module) it is really meant to build an internal model, which
is subsequently to be communicated to the back-end through the push
method.

[snip]

The reason why the old back-ends did not have the same problems with
Canvas is that Canvas hasn't been properly updated to the new
architecture. No work has been done on it yet.

> My instinct is to strip the user-visible Canvas class of all its
> canvas-specific functionality, leaving it strictly as a proxy that
> dispatches its method calls to the wrapper.

That is one approach -- but you'd lose the default implementations of
arcs and Béziers etc.

> The existing canvas functionality would then go in something like
> AbstractCanvas once more.  To those who actually know what they're
> doing vis a vis anygui, does this sound reasonable?  Better ideas
> are also appreciated.

Well; the idea was (as I said) to build a model of the graphics, which
is stored in the Canvas (proxy) object. This model is then pushed back
to the back-end CanvasWrapper, which then renders it. However, the
proxy/wrapper design was meant to allow the wrapper so be very simple;
having them be able to draw a complex graphics model isn't quite in
keeping with this spirit. It would be better to, for example, only
have drawPolygon or something defined there... Or, at least, to have
that be the only required method. But then we're moving away from the
push/pull thing anyway, and your idea of delegating everything to the
wrapper, and have the defaults in an AbstractCanvas  (or, perhaps, an
AbstractCanvasWrapper, even) might actually be worth investigating.

I guess (to sum up :) that the Canvas functionality doesn't
immediately fit the idea behind the current front-end/back-end
communication mechanism, and that the current Canvas module isn't
updated to deal with this situation *at all*. Updating it would
certainly be a Good Thing(tm), but I haven't been too eager to start
working on either that or the menu design before we have an actual
release using the new architecture -- and I have no idea when that
might happen at the moment...

> Thanks,
> Andrew

-- 
Magnus Lie Hetland                "In this house we obey the laws of
http://hetland.org                 thermodynamics!"    Homer Simpson


-------------------------------------------------------
This SF.net email sponsored by: Enterprise Linux Forum Conference & Expo
The Event For Linux Datacenter Solutions & Strategies in The Enterprise 
Linux in the Boardroom; in the Front Office; & in the Server Room 
http://www.enterpriselinuxforum.com