From: rantingrick on 14 Jun 2010 22:05 On Jun 14, 6:27 pm, Stephen Hansen <me+list/pyt...(a)ixokai.io> wrote: > I am familiar with grid, pack and place. Apparently not, read on... > Are you arguing from an API point of view, or a functionality point of > view? <snip> I going to argue that Tkinter offers the most "elegant" interface for geometry management. And i'll leave it at that. > From a functionality perspective, "pack" and "grid" are both distinctly > less capable then wx sizers. In the simpliest of interfaces, they > achieve similar goals in similar ways: but the lack of proportional > sizing kills it for me, unless I've been long mistaken <snip> YOU HAVE BEEN LONG MISTAKEN MY FRIEND! :-). It seems the answer was right under your nose and like bad breath you failed to smell it. Here is the first paragraph for the docs of place geometry manager... """The Place geometry manager is the simplest of the three general geometry managers provided in Tkinter. It allows you explicitly set the position and size of a window, either in absolute terms, or relative to another window.""" > I've no interest in talking about "place"; absolute positioning is > simply pointless to me. That argument ceases to be "relevant". See the triple quoted text for an explanation as to why it is irrelevant and based on ignorance. > unless I've been long mistaken in pack not > having a proportional option. A combination of "fill/expand" and > "anchor" do most of everything else, though, that wx's flags and > alignment options. <snip code> > You can rewrite something very similar in Tkinter, sure. And you'll have > shorter names, and maybe you can argue 'pack' is more pythonic then > 'SetSizerProps', but debating API pythonicity is just uneventful. What is this fascination with "pack" all about Stephan? The "pack" geometry manager is the least useful of the three. Grid is your most useful "all around" manager for laying out complex widget displays. However that fact is not obvious to most Tkinter noobs because they do not know about the "rowconfigure" and "columnconfigure" options that allow for dynamic resizing of widgets within a container based on a weight factor. There are also options for "sticky" behavior. The following is my suggestions on when to use and *not* to use grid, pack, and/or place. GRID: Try to use grid for almost everything because it is the most versatile of the three. However there are specific corner cases for pack and place. Also never use grid and pack within the same "container" widget or you'll cause Tk to lock up. You *can* however use both managers in the same application as long as the widgets you call "pack" and "grid" for do not share the same parent. Also like i mentioned before you can get a dynamic resizing behavior on *any* or *all* cols and rows by calling "parent.rowconfigure(weight)" and "parent.columnconfigure(weight)". Use a weight of 1 to get full elasticity ;). We all could use a bit more elasticity, no? PACK: Only use pack if you have one widget and you wish it to fill it's entire parent OR if you are stacking widgets in a horizontal or vertical alignments (like a toolbar). This is where pack really shines! PLACE: Offers absolute and relative placements of widgets. Place will not be used often but most of it's functionality can not be reproduced with the other two options. Take for example the masks that are part of a notebook widget, or placing a small button in the top left corner of a frame or whatever... The only people who like Wx geometry managers are the same who have no experience with Tkinter's beautiful geometry managers. I encourage you to investigate them for yourself. If anyone needs help feel free to send me a private email or ask here on c.l.p.
From: rantingrick on 14 Jun 2010 22:22 On Jun 14, 6:27 pm, Stephen Hansen <me+list/pyt...(a)ixokai.io> wrote: > From a functionality perspective, "pack" and "grid" are both distinctly > less capable then wx sizers. Are you just flapping your gums or can you prove it Stephen? I will accept any "Pepsi Challenge" you can muster in Wx code and echo that same capability using Tkinter[1] in what will be no less than elegant simplicity. So bring it on baby! [1] But please, make sure to post code that will run as-is. The last block of wx code you posted is missing an application instance and will not run without modification. There are noobs watching and we to provide code that can be used to teach!
From: Stephen Hansen on 14 Jun 2010 22:41 On 6/14/10 7:05 PM, rantingrick wrote: > """The Place geometry manager is the simplest of the three general > geometry managers provided in Tkinter. It allows you explicitly set > the position and size of a window, either in absolute terms, or > relative to another window.""" > >> I've no interest in talking about "place"; absolute positioning is >> simply pointless to me. > > That argument ceases to be "relevant". See the triple quoted text for > an explanation as to why it is irrelevant and based on ignorance. I didn't make an argument, so it can't be relevant or not. It remains pointless. >> unless I've been long mistaken in pack not >> having a proportional option. A combination of "fill/expand" and >> "anchor" do most of everything else, though, that wx's flags and >> alignment options. > > <snip code> > >> You can rewrite something very similar in Tkinter, sure. And you'll have >> shorter names, and maybe you can argue 'pack' is more pythonic then >> 'SetSizerProps', but debating API pythonicity is just uneventful. > > What is this fascination with "pack" all about Stephan? The "pack" > geometry manager is the least useful of the three. Grid is your most > useful "all around" manager for laying out complex widget displays. > However that fact is not obvious to most Tkinter noobs because they do > not know about the "rowconfigure" and "columnconfigure" options that > allow for dynamic resizing of widgets within a container based on a > weight factor. There are also options for "sticky" behavior. The > following is my suggestions on when to use and *not* to use grid, > pack, and/or place. I wasn't aware of [row|column]configure, no: however, I am dubious of how it directly applies. Consider this relatively simple user interface layout: http://ixokai.io/get/layout-grid.jpg In this context, we have two principle columns, A and B. A has a set size, B grows to fill the rest of the dialog. Inside of A, there are four items in a vertical line. The bottom which takes up half of the total vertical space (poorly drawn, trust me, F should be half :)), and the top three share the rest. Inside of B, G is one third the size of H. The layout should fully resize itself as the window is resized. How would you implement that in tkinter? It sounds like you'd have a grid with a pair of one-column grids, which is slightly bizarre seeming. > The only people who like Wx geometry managers are the same who have no > experience with Tkinter's beautiful geometry managers. I encourage you > to investigate them for yourself. If anyone needs help feel free to > send me a private email or ask here on c.l.p. And exactly what's so great about it? All of the things you said it can do, wx can do easily. -- Stephen Hansen ... Also: Ixokai ... Mail: me+list/python (AT) ixokai (DOT) io ... Blog: http://meh.ixokai.io/
From: Stephen Hansen on 14 Jun 2010 22:42 On 6/14/10 7:22 PM, rantingrick wrote: > On Jun 14, 6:27 pm, Stephen Hansen <me+list/pyt...(a)ixokai.io> wrote: > [1] But please, make sure to post code that will run as-is. The last > block of wx code you posted is missing an application instance and > will not run without modification. There are noobs watching and we to > provide code that can be used to teach! No. -- Stephen Hansen ... Also: Ixokai ... Mail: me+list/python (AT) ixokai (DOT) io ... Blog: http://meh.ixokai.io/
From: AD. on 14 Jun 2010 22:43
On Jun 15, 1:21 pm, pyt...(a)bdurham.com wrote: > Anton, > > Very nice. > > As an aside: I don't think you need to explicitly set your image size, Yeah, I only did that because I was assuming the image path would actually be broken (and it was for me too) - it was just to 'simulate' a 100x100 image :) -- Cheers Anton |