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 <Configure>, 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 packed widgets is that you are likely creating the placed widgets after you create the packed 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.