I'm still not 100% sure on what you're looking for, but Zentara is right about zoom and Tk::Zinc, it's capabilities far outmatch Tk::Canvas.

Unfortunately, you would have to adapt one of the Canvas charting modules for use on Zinc if you decided to use it. I'm not aware of any charting modules that use Zinc as a base.

Here is a quick and dirty example I threw together using Pane and 16 Scrolled Canvas widgets. Aside from plotting (I just threw some random blocks in), is this something like you were looking to do? It's a start if nothing else. Something I didn't do that you might want to consider is to adjust the scrollregion for the canvas as you are zooming in/out.

Thanks, that's an excellent demonstration!
In fact, the zooming you implemented is excellent for me so I guess moving to Zinc is not required.
I will change it a bit to have a set of zoom in/out buttons per each column, not per each Tile.

I know my question was a bit generelized but what I wanted to know is if my idea in general is feasible. Knowing that packing each canvas in a frame may save me some problems is very valuable.

As for packing each Canvas inside a frame, I think I was off in my first comment. It wasn't as bad as I remembered it being. I must have been remembering how it used to be before a patch was put in Pane some time back. It doesn't make any difference if you put the Canvas in a frame or not.

The only reason I put each Cavas in a frame in the example was so that I could put controls along with the Canvas, and correctly manage resizing. In terms of the example, there's actually a benefit of not having each Canvas in a Frame (Aside from the Scrolled Frame). Typically, when you create something like this, you have to either store a variable pointing to each Canvas so that you can directly access it later. You can still do this, but if each Canvas has been gridded, then you can use grid methods to access a row, column, one cell, or all of the gridded widgets. The way I currently have it, this is inconvenient because the easy access is to the frame. It would simplify things a bit if you modified createTile to something like this:

sub createTile
{
   my ($parent, $x, $y) = @_;

   my $sc = $parent->Scrolled('Canvas',
      -scrollbars => 'osoe',
      -scrollregion => [0, 0, 200, 200],
      -width => 125,
      -height => 125,
      -background => randColor()
   )->pack(
     -padx => 5,
     -pady => 5,
     -row => $x, 
     -column => $y, 
     -sticky => 'nsew'
   );

   my $count = int(rand(6)) + 2;
   foreach my $i (1 .. $count) {
      my ($x, $y) = (randNumber(), randNumber());
      my $size = randNumber();
      $sc->createRectangle($x, $y, $x+$size, $y+$size,
         -fill => randColor(),
         -outline => 'black',
         -width => 2
      );
   }
}
[download]

Now access to each Canvas is a bit easier using gridSlaves or gridLocation.

As an aside, the interface choice seems a little odd to me. The zooming part strikes me as a bit user unfriendly. It probably makes sense for your problem, but it seems frustrating to me that the views are separated into so many small boxes that I can only resize so far. Zooming only exasperates the problem - Now I have more information that I can potentially look at, but I have to scroll more to see it all.

Why not pack as much information as is useful within the size constraints for each Canvas in the grid. And then have a way of drilling down or at least temporarily hide the others using gridForget, and allow the user to focus on one Canvas with an expanded information set and zooming capabilities? Anyway... just a few random thoughts.

Rob

In Tk terms, you probably want to stack 20 Scrolled Canvases into a Scrolled Pane. There may be expansion problems with a complex pack like that, so you "may" need to fiddle with putting each Scrolled Canvas, into it's own Frame before packing into the Scrolled Pane. As always, the devil is in the details.

Can you post some specifics? Perhaps some sample code demonstrating the problem?

I know that Pane can have pitfalls for the unwary, but at this point it would all be guesswork. I know that I've often had more success packing one frame containing lots of widgets into Pane, rather than directly packing them into Pane.