I appreciate the sentiments. I really do. But you're once again dismissing any complaints about sizers and blaming it on the need for "retraining" or "first impressions", "learning curve", or "getting used" to it.
For the record I didn't find sizers confusing and difficult. They *seem* rather straightforward, at least once I understood the proportions and flags thing. It's when actually trying to coerce them into giving sensible results that the torture sets in with the hours of tweaking proportions, flags, spanning of rows and columns, etc. I've been working with sizers fairly steadily for about a year and a half now. I'm way past first impressions.
Michael
···
----- Original Message -----
From: "Ed Leafe" <ed@leafe.com>
To: wxPython-users@lists.wxwidgets.org
Subject: Re: [wxPython-users] Why can't we get rid of sizers?
Date: Tue, 23 May 2006 16:18:41 -0400
On May 23, 2006, at 10:25 AM, Michael Hipp wrote:
>> I have to say I am completely baffled at these sentiments. Granted I've
>> been
>> using wx for a while for a multitude of projects, so I'm somewhat insulated
>> from what the impressions might be for a new coder. But I do remember the
>> progression I went through (I started with layout constraints) and how
>> happy
>> I was when I finally figured out a sizer 'idiom' that worked for me.
>
> Ok, another variant on "The reason you people don't love sizers is
> because you're too uneducated/inexperienced/dumb/lazy."
I think you're reading way too much into such comments. I took them to
mean that sizers address a complex issue, and while complex themselves, are
no more complex than they have to be. The learning curve is appropriate to
the size of the task involved.
Nothing about being dumb or lazy; it's simply that the majority of GUI
design tools work completely differently than the approach required by
sizers, so most people (including myself) get a first impression that
sizers are confusing and difficult. IMO, they simply take time to retrain
your brain to think in a sizer-centric manner when laying out a form. Once
you get used to that, they really aren't any more of a pain than any other
UI tool.
Ed Leafe wrote:
I think that the biggest problem here is trying to create UIs using code. A visual design tool is essential in order to be productive when creating UIs. It helps to have immediate feedback as you change the various sizer properties so that you know that what you're actually doing is what you wanted to do. Also, getting rid of the decidedly non-Pythonic system of using ugly constants and flags (why is alignment part of the flag, but not proportion?), so that you can think of each aspect of a sizer's setting independently, is also important. That's why I've spent so much time in the past 18 months developing the Dabo Class Designer. The dabo.ui module had already abstracted out the non-Pythonic ugliness out of wxPython, and now with the Designer tool you can create sizer-centric designs visually, with immediate feedback as you change the properties of the sizers.
I think the Designer could abstract it out further; today when you select "Edit Sizer Settings" of a control which is currently within a Box Sizer, you are still presented with a dialog containing
- border (integer)
- Expand (checkbox)
- Halign (or Valign) (choice from list of left, centre, right)
- Proportion (integer)
and if you subsequently move that control to a different sizer (once that becomes possible) you would have a different set of choices.
For PythonCard's sizers, I'm making the sizer settings for a control (or sizer) be:
border (integer)
horizontal growth (integer)
horizontal align (choice)
vertical growth (integer)
vertical align (choice)
and then use them appropriately depending on the kind of sizer it is within. So if it is placed within a Vertical sizer, then "vertical growth" becomes the proportion, while "horizontal growth" determines whether Expand is set true (if growth > 0) or the horizontal align value is used (if growth == 0).
This lets the user consider how they want the *control* to behave, rather than on how the sizer should make the control behave - and makes it much easier to later change from box sizers to grid sizer, or even to the other orientation of box sizer.
···
--
Alex Tweedly http://www.tweedly.net
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.7.0/346 - Release Date: 23/05/2006
I'll have to think about this a bit. On first impression it sounds like an interesting approach. If it looks like it might be something that would improve Dabo, I may have to steal it!
;-)
-- Ed Leafe
-- http://leafe.com
-- http://dabodev.com
···
On May 24, 2006, at 9:51 AM, Alex Tweedly wrote:
For PythonCard's sizers, I'm making the sizer settings for a control (or sizer) be:
border (integer)
horizontal growth (integer)
horizontal align (choice)
vertical growth (integer)
vertical align (choice)
and then use them appropriately depending on the kind of sizer it is within. So if it is placed within a Vertical sizer, then "vertical growth" becomes the proportion, while "horizontal growth" determines whether Expand is set true (if growth > 0) or the horizontal align value is used (if growth == 0).
This lets the user consider how they want the *control* to behave, rather than on how the sizer should make the control behave - and makes it much easier to later change from box sizers to grid sizer, or even to the other orientation of box sizer.
That's already being implemented in Dabo; each type of control has a default sizer setting. E.g., panels are added with expand=True and proportion=1, while buttons are added with expand=False and proportion=0. On the drawing board are plans to make this entirely user-configurable, but this will have to wait until our underlying preference engine is re-written for version 0.7.
-- Ed Leafe
-- http://leafe.com
-- http://dabodev.com
···
On May 24, 2006, at 10:17 AM, Nitro wrote:
This sounds good, how about going one step further and making sizers even a little more transparent to the user? It would be nice if the user could only specify how the controls should behave and then the needed sizer(s) and their types (box, gridbag, ...) get automatically determined by the designer?
Don Dwiggins wrote:
Of course, this may be what the original poster had in mind: getting rid of sizers by taking away their functions. Personally, I like the concept of factoring layout concerns out of the container-contained relationship, and using explicit elements to express the layout.
I'm not sure that's possible. There are properties of how a group of controls work together that need something like a sizer.
However, we could put all the properties of the object that apply to only that object with the object. See my other posts.
-Chris
···
--
Christopher Barker, Ph.D.
Oceanographer
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chris.Barker@noaa.gov