What is the GUI, when do you own it, when does it flow as you want, when do you have the features that you are satisfied with as high-tech enough to outshine Win3.1? Even WfW3.11 Well my friends, for each of us it is a different answer, and for myself I have been quite accustomed to the wonderful part of the web browsing experience where I can resize fonts with a Control-MouseWheel, fonts increasing and decreasing instantly giving my system fantastic feedback making me feel at ease and relaxed as my eyes relax as fonts and GUI elements grow large. And then grow small again, or smallify, so that I can see the entirety in its entirety, in a glance. So then, we have [pack], and [grid] (which unfortunately I am not as jazzed about as I probably would be if it didn't have it's own mini-shorthand-language. So many of us have fought with [pack]. Of course they both are very very nice (especially when we compare with other languages/systems) but perhaps we can improve, at least so that we can have widgets many of them on a single toplevel, and we can scroll around, so the widgets are not limited to the size of the containing 'master' frame. In other words, think of a webpage, or 'webapp', where we are used to the idea of scrolling GUI elements. In Tcl/Tk we call this a scrollable frame, and a while back (10 years+) I used to use bwidgets for this. Now I feel comfortable enough to just use the canvas and a few tiny bindings and have the same sort of functionality, with more extensibility. LoL power. There is also something I haven't explored which is using the [text] widget as a container widget, because widgets managed by a [text] widget would then flow. This is the default? Like I said I have no real experience with complex widget layout inside of a [text] widget. Widgets in a [canvas] are great, a few niggles, you have to make sure the managed widgets are a child of the [canvas] so they scroll properly, you have to set the [canvas] bounding box, and you have to give the x,y position to the [canvas] for the widget and its width and height. When the canvas, now our widget container, is resized, we catch that event by binding to , and then update the positions of the managed widgets, as well resetting our bounding box which signals any scrollbars we have on our container canvas to also change shape. ---- im basically mimicking a web browser with css -- not sticking to css, just the idea of flowable layout in a viewport, im used to how the GUI works in a browser, flowable widgets nice and scrollable all around and the ability to increase font sizes for all gui elements with a control-mousewheel using [place] i dont know how to make it scrollable, and i didnt think of using the [text] widget. so im using the [canvas] right now and it seems to work for at least a basic version (font changes work, on master resize the childs resize to fill width, floating layout where widgets get a percentage of the width not implemented) the font changing feels so good, feels flexible ---- Mixing pack and place seems to work, placed widgets get put on top of the packed ones, and are positioned absolutely. How does this mixing work, what is the geometry code doing, is it running the pack on the toplevel and then the place? How does it work?? [RLE] (25 Aug 2011) : It does not put placed widgets on top of packed ones. That is determined by the window stacking order, which is controlled by [raise], [lower] and the order in which you create the windows (last window is created on top of the stack). [Ro]: Which is a very interesting trick, and one that I use. I first pack a text widget in a scrolled frame, and then I place absolutely positioned elements right on top of it, so even when I scroll the text widget, the absolutely placed widgets are fixed at an x,y position. My question is how does this work, in the sense of first [pack] must arrange the widgets, and [place] must run last, and it also seems that you can place a widget in any other widget type. Strange tricks. [KPV] I use the place/pack technique in [Slippy Map Demo]. I don't know exactly how it works but suspect that place totally ignores what pack is doing and just lays out its widgets in the window. [RLE] (25 Aug 2011): "''It does quite easily put placed widgets on top of packed ones.''" Yes, but not for the reason which is implied by your statement. Try reversing your widget creation order in a test wish console. Create the placed widget first, then create the packed widget. You will find your placed widgets appear to disappear when you pack the later created widget. Note: ====== wish % button .b -text "Hi There" .b % place .b -x 10 -y 10 % # the button appears % text .t .t % pack .t % # button has disappeared % raise .b % # button reappears % lower .b % # button disappears % ====== The reason that [place] appears to [place] widgets "on top" of your [pack]ed widgets is that you are likely creating the [place]d widgets after you create the [pack]ed widgets. Sibling widgets are initially ordered in the stacking order in order of their creation. It is the [stacking order] that determines which widget obscures another. The [raise] and [lower] commands allow you to adjust the [stacking order] of widgets. [Ro] RLE, It's great that you keep pointing out the stacking order, but that's really not here nor there. Wonderful to note that you understand it. Now perhaps you can point out exactly why [place] ignores [pack] and just maps the widget there. Or perhaps you don't know how the geometry managers interact, and you can also learn something. KPV, I see how you used the same trick to put your map controls and make them absolutely positioned on your map. Nice. [RLE] (Aug 25, 2011): "''Now perhaps you can point out exactly why [place] ignores [pack] and just maps the widget there.''" Because that is what [place] is does. That is why it is named [place]. It ''places'' a widget at a user defined location within another window. Note the manpage quote again: It provides simple fixed placement of windows, where you specify the exact size and location of one window, called the slave, within another window, called the master. [Place] simply positions the slave at the location you tell it to position the slave. "''Or perhaps you don't know how the geometry managers interact''" Actually, that would be your misunderstanding. The geometry managers do not interact. Each is blind to the presence of the other geometry managers. What matters is which manager a widget belongs. Any individual widget is only ever managed by one geometry manager at any given instant. The widgets you "[place]" are managed by [place], the widgets you [pack] are managed by [pack], and neither geometry manager knows about, nor talks to, the other. Which is why it appears that [place] ignores [pack]. "''It's great that you keep pointing out the stacking order, but that's really not here nor there.''" It is both here and there. Your writings were implying that the reason the widgets you placed were on top was due to being placed. But they were not on top because they were placed, they were on top because of their position in the stacking order. Someone who does not yet fully understand Tk's system could read your statements, be led to think that [place] means "always on top" and then be later surprised when a widget they attempted to [place] never appears because it happens to be lower in the stacking order. <> GUI