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 reply to Re^3: A 2D layout of graphs in Perl/Tk by rcseege
in thread A 2D layout of graphs in Perl/Tk by tcarmeli

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.