On Wednesday 24 May 2006 07:28, Ed Leafe wrote: > There is a fairly long thread on the wxPython list, and in it Alex > Tweedly responded to a post of mine with a different way he's > approaching defining sizer settings for controls. I'm forwarding it > to the two Dabo lists in the hope of getting some feedback from > others in the Dabo community about the pros and cons of such an > approach. > > -- Ed > > Begin forwarded message: > > From: Alex Tweedly <[EMAIL PROTECTED]> > Date: May 24, 2006 9:51:12 AM EDT > To: [EMAIL PROTECTED] > Subject: Re: [wxPython-users] Why can't we get rid of sizers? > > 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.
This sounds very interesting. I support anything that allows the developer to set the control resizing behavior within the control. It might eliminate the need for grid sizers. Just use H or V boxers. You have done wonders already but I know more can be done. BTW there is a .Net resizing activeX object (or what ever they call them) called Xsizer. It proportionally resizes everything in a form. You need .Net to run it so I haven't seen what it does but it sounds interesting. John _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-dev
