*** tpj4.orig Sun Nov 10 18:51:24 1996 --- tpj4 Sun Nov 10 18:57:37 1996 *************** *** 18,24 **** This means that in order to calculate the final look of an application, geometry information propagates outwards from the innermost masters to the MainWindow. We'll see why and how to defeat ! this behaviour later. Before any widget can appear on the display it must be managed by a geometry manager. There can actually be multiple geometry managers --- 18,24 ---- This means that in order to calculate the final look of an application, geometry information propagates outwards from the innermost masters to the MainWindow. We'll see why and how to defeat ! this behavior later. Before any widget can appear on the display it must be managed by a geometry manager. There can actually be multiple geometry managers *************** *** 87,94 **** (insert prob1.gif here) ! Suprisingly, the names are *not* left justified, but appear to be ! centered, and the numbers, which we thought might be left justifed, seem to be right justified! Something must be amiss. To figure out what's going on, try applying --- 87,94 ---- (insert prob1.gif here) ! Surprisingly, the names are *not* left justified, but appear to be ! centered, and the numbers, which we thought might be left justified, seem to be right justified! Something must be amiss. To figure out what's going on, try applying *************** *** 254,260 **** to a 4x4 square, you can choose N, the length of a side, from the set (3, 4, 6, 8). To make the puzzle solution more difficult, the numbered squares have been replaced with real puzzle images from the ! offical Perl/Tk icon, which we all know as *Camelus bactrianus*. (insert npuz.gif here) --- 254,260 ---- to a 4x4 square, you can choose N, the length of a side, from the set (3, 4, 6, 8). To make the puzzle solution more difficult, the numbered squares have been replaced with real puzzle images from the ! official Perl/Tk icon, which we all know as *Camelus bactrianus*. (insert npuz.gif here) *************** *** 306,318 **** subroutine *xy* does, and then grid it. The @ORDER list in effect shuffles the pieces so the game doesn't start already solved. (Perhaps @ORDER isn't an appropriate variable name, since the end ! result is to increase the games's entrophy, or add disorder to it.) Running *simp* creates this display: (insert simp.gif here) ! The -sticky => 'nsew' attribute is analagous to the packer's -fill => 'both', and ensures that all buttons completely fill their allocated space. Notice that grid column zero is wider than the other columns. This is because the grider assigns the column a width equal to that of the --- 306,318 ---- subroutine *xy* does, and then grid it. The @ORDER list in effect shuffles the pieces so the game doesn't start already solved. (Perhaps @ORDER isn't an appropriate variable name, since the end ! result is to increase the game's entropy, or add disorder to it.) Running *simp* creates this display: (insert simp.gif here) ! The -sticky => 'nsew' attribute is analogous to the packer's -fill => 'both', and ensures that all buttons completely fill their allocated space. Notice that grid column zero is wider than the other columns. This is because the grider assigns the column a width equal to that of the *************** *** 326,332 **** numbers with a portion of the image. . Keep track of every button widget and its grid position so we know when it's adjacent to the space piece. ! . Devise a button callback to actually regrid a piece when its eligible to move. Since we view the puzzle pieces as a list, the variable @PUZ will --- 326,332 ---- numbers with a portion of the image. . Keep track of every button widget and its grid position so we know when it's adjacent to the space piece. ! . Devise a button callback to actually re-grid a piece when its eligible to move. Since we view the puzzle pieces as a list, the variable @PUZ will *************** *** 378,384 **** sub-region using the *copy()* method, which copies from the source image $CAMEL to the new image $gif. * ! After updating @PUZ with the new button, the piece is grided and a callback to *move_piece()* is created, passing a reference to the button. --- 378,384 ---- sub-region using the *copy()* method, which copies from the source image $CAMEL to the new image $gif. * ! After updating @PUZ with the new button, the piece is gridded and a callback to *move_piece()* is created, passing a reference to the button. *************** *** 385,392 **** * footnote ( It's important to note that when you are finished with an image it ! must be explicity deleted - it doesn't magically go away if a widget, ! which just happens to use it, is destroyed. (After all, serveral widgets might be sharing the same image.) To prevent a memory leak when a new game is started and all previous buttons are deleted, we first delete all their images: --- 385,392 ---- * footnote ( It's important to note that when you are finished with an image it ! must be explicitly deleted - it doesn't magically go away if a widget, ! which just happens to use it, is destroyed. (After all, several widgets might be sharing the same image.) To prevent a memory leak when a new game is started and all previous buttons are deleted, we first delete all their images: *************** *** 455,461 **** The frame $PF represents the puzzle frame, and artificially fixes the width of the application's display to 300 pixels. I did this so there's unused space for the menubuttons to move about in to help ! illustrate gridder mechanics. The goal in this example is to grid the File and Prefs menubuttons side by side west, the Help menubutton east, with unused space in the center of the frame. Instead, this is the result: --- 455,461 ---- The frame $PF represents the puzzle frame, and artificially fixes the width of the application's display to 300 pixels. I did this so there's unused space for the menubuttons to move about in to help ! illustrate grider mechanics. The goal in this example is to grid the File and Prefs menubuttons side by side west, the Help menubutton east, with unused space in the center of the frame. Instead, this is the result: *************** *** 486,497 **** columns are weightless, the Prefs column gets 100% of the unallocated space. It's important that Prefs be west sticky, but the other two columns don't need to be sticky at all, since they get no unused ! space. Although the current version of grid acccepts floating point weight values, the next one will not, so always use integers. Sometimes it's desirable to disable the outward propagation of geometry configuration information. For instance, suppose you want to ! manage a frame of a particlular size, and within the frame pack/grid other widgets. This example grids a frame with an embedded button but prevents the grider from shrink-wrapping the frame around the button: --- 486,497 ---- columns are weightless, the Prefs column gets 100% of the unallocated space. It's important that Prefs be west sticky, but the other two columns don't need to be sticky at all, since they get no unused ! space. Although the current version of grid accepts floating point weight values, the next one will not, so always use integers. Sometimes it's desirable to disable the outward propagation of geometry configuration information. For instance, suppose you want to ! manage a frame of a particular size, and within the frame pack/grid other widgets. This example grids a frame with an embedded button but prevents the grider from shrink-wrapping the frame around the button: