From: rantingrick on
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
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
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
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
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