From: Joel VanderWerf <vjoel@...>
Date: 2009-09-09T02:05:34+09:00
Subject: Re: Zoomable TkCanvas?

Josef Wolf wrote:
> On Tue, Sep 08, 2009 at 07:35:31AM +0900, Joel VanderWerf wrote:
>> Josef Wolf wrote:
>>>  - maintain original coordinates at all zoom factors. Thus even after
>>>    zoom operations, events as well as querying/moving/adding items are
>>>    done as if the canvas is at zoom factor 1.0. So zoom is handled
>>>    completely transparent to the user of the module..
>> Yep, tkar does that too--object coordinates are independent of zoom level. 
>> TkCanvas coordinates are hidden in the abstraction.
> 
> Hmm, somehow I fail to see how this is supposed to work.
> 
> I see zoom_by does the scaling, adjusts the scrollregion and updates the
> view. IMHO, to keep coordinates independent from zoom level, you would need
> to intercept query/movement/creation of the items. Without that
> 
>  TkcRectangle.new(canvas, [100,100], [300, 200])
>  canvas.zoom_by(2.0)
>  TkcRectangle.new(canvas, [100,100], [300, 200])
> 
> would result in two rectangles with different sizes.

Tkar is intended to be used as a _process_ not as a library. Another 
process (doesn't have to be ruby, doesn't have to be a Tk gui) sends 
commands to tkar over a pipe or socket. Those commands use the abstract 
coordinate system.

If you use the _Tk_ methods such as TkcRectangle.new, they will use Tk's 
native coordinates.

The corresponding methods in Tkar are in the primitives.rb file. For 
example the #rect method. This method understands scaling. It also 
understands rotation, which Tk primitives do not. These methods aren't 
designed to be used as a library, though.

> This is done with the help of the Window class, AFAICS. So it is not as
> transparent as the Tk::AbstractCanvas module.

Different kind of abstraction here--tkar implements a little language to 
drive animations over IO, it's not a library API.

I think a ruby port of the perl Tk::AbstractCanvas would be useful, but 
in a different way from tkar. I wrote tkar primarily so that I could do 
2D animations in simulink--a ruby library isn't much use for that, but a 
socket interface is fine (and has the advantage of distributing 
workload). Also, with a little munging, you can pipe the output of 
real-time log files and get useful animations. See ps.rb for an 
example--it filters the output of ps to show a graphical representation 
of the cpu usage of running processes.

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