From: Joel VanderWerf <vjoel@...>
Date: 2009-09-09T07:16:28+09:00
Subject: Re: Zoomable TkCanvas?

Josef Wolf wrote:
> On Wed, Sep 09, 2009 at 05:29:47AM +0900, Joel VanderWerf wrote:
> 
> Thanks for your patience with me, Joel!
> 
>> Josef Wolf wrote:
>>> But how do I override the methods to create the items? In Perl/Tk, that
>>> would be easy, since item creation is done via canvas methods.  But in
>>> Ruby/Tk, items are created via their own classes (e.g. TkcLine.new(args)
>>> or something). There don't seem to exist methods in the Canvas class to
>>> create items, which could easily be overridden.
>> Maybe subclass (or delegate to) the Tk classes:
>>
>> class MyRectangle < TkcRectangle
>>   def initialize(x,y,w,h)
>>     super(...) # adjust args depending on zoom level etc.
>>   end
>> end
> 
> That would result in:
>  - lots of new subclasses, polluting namespaces
>  - lots of code duplication
>  - it would not be a drop-in replacement: one would have to change the
>    class names of the items when switching from standard canvas to the
>    improved canvas

It's a matter of taste, I suppose. Preserving the existing Tk classes 
has an advantage: if you want to place objects on the canvas that are 
not affected by zoooming (foreground, OSD-type display, controls, etc), 
you can still use the base classes.

Keep namespaces clean by putting everything in a module:

module MyTk
   class TkcRectangle < ::TkcRectangle
   ...

That way, you have both:

MyTk::TkcRectangle.new # new kind
TkcRectangle           # old kind
::TkcRectangle         # old kind even when in MyTk scope

I don't see a problem with new subclasses or code duplication.

-- 
       vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407