On 6/14/10 3:44 PM, rantingrick wrote: > On Jun 14, 2:30 pm, Stephen Hansen <me+list/pyt...@ixokai.io> wrote: > > Stephan speaking of Wx geometry managers... > >> Ahem. /Rant. I'm not saying its the best layout system in the world, but >> like your DOM/HTML example -- its resolution independant (and >> cross-platform), so you can start resizing things and changing the >> window size and it all reflows things as the window resizes. Lots of >> toolkits can do that, but I just really find the sizer approach both >> flexible and very powerful to achieve very usable interfaces. (And its >> very web-like, except the semantic difference of the two hierarchies) > > Oh Stephan i strongly disagree with that assessment. Tkinter blows Wx > away with it's simultaneousness powerful AND elegantly simplistic > geometry managers, grid, pack, and place. If you have not used them to > any extent i strongly encourage you do so before boasting on the > superiority of Wx geometry management. It's like night and day really. > Wx is very ugly in this respect, again due to fact it has a C base > developer pool.
I am familiar with grid, pack and place.
Are you arguing from an API point of view, or a functionality point of
view? I have no interest in debating the Pythonisity of Tkinter's API to
wxPython's -- its pointless, neither are particularly Pythonic, and I've
never argued wx does not have an API difficulty and learning curve.
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 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.
I've no interest in talking about "place"; absolute positioning is
simply pointless to me.
Now, from an API perspcetive? I'll not debate the merits of which is
better, except that your conclusion of 'why' its 'ugly' and difficult
that its a C based tool, is wrong. The API difficulty comes from the
fact that "sizers" are separate from containers, and that individual
items added to them don't actually have any internal knowledge of their
sizer environment. This creates some cumbersome interactions. However,
this can be largely made easier (And vastly more Pythonic) by simply
basing wx.lib.sized_controls as the base.
Then, instead of explicit sizer tweaking, you do things like:
import wx.lib.sized_controls as sc
class MyPanel(sc.SizedPanel):
def __init__(self):
sc.SizedPanel(self, -1)
self.SetSizerType("horizontal")
b1 = wx.Button(self, -1, "OK")
b2 = wx.Button(self, -1, "Cancel")
b1.SetSizerProps(expand=True)
b2.SetSizerProps(expand=True)
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.
My original comments were about function, not form. I mean, we're
discussing the DOM here. There's never been a more hideous designed API
in the history of API's.
--
Stephen Hansen
... Also: Ixokai
... Mail: me+list/python (AT) ixokai (DOT) io
... Blog: http://meh.ixokai.io/
signature.asc
Description: OpenPGP digital signature
-- http://mail.python.org/mailman/listinfo/python-list
