[Anygui-devel] push() double-inherited when creating Canvas Wrapper when naively following deprecated backend examples

[Andrew S. <som...@al...>]

I'm trying to get the not-super-up-to-date canvas stuff 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.

For convenience, the hierarchy goes like this:
gtkgui.ComponentWrapper -->
   Wrappers.AbstractWrapper defines
      push(self, state)

Canvases.Canvas -->
   Components.Component -->
      Proxies.Proxy defines
         push(self, *names, **kwds)
         (originally abstractly defined in Attrib)

Things only crash when Attrib.set(...) tries to spread a set of 2 arguments to 
a call to self.push(...) and unexpectedly ends up calling 
AbstractWrapper.push(self, state), which doesn't like 3 arguments.  
Presumably things aren't working right at all before this point anyways.

I felt the need to inherit from both classes because the Canvas class requires 
you to subclass it to provide key methods like drawPolygon.  It also has its 
wrapperFactory method call the reigning backend's CanvasWrapper constructor.  
This effectively requires the wrapper to extend Canvas, which also has the 
proxy code thrown in there.  I suspect the deprecated backends javagui2 and 
tkgui2 did not have this problem because they subclass AbstractCanvas (the 
larval form of Canvas), which at that time inherited from Attrib directly 
rather than through Proxy.

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.  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.

Thanks,
Andrew