Why can't we get rid of sizers?

John_Fabiani2 · May 20, 2006, 6:07pm

Hi,

I wonder why we need to have sizers? Why can't someone develop a GUI editor
that automaticly determines what is required to keep the relative proportions
and positions of widgets on a frame.

Sizers work but they are a pain to work with. Robin spent a whole chapter
(11) just to explain sizers. So you create a nice looking frame with sizers
and then someone says "Look's great but could you add these two other
widgets". It's just a pain to work with. There has to be something better.

Does anyone know of any sort of project trying to get rid of sizers?

John

Arnold_Chen · May 20, 2006, 6:23pm

Hi,

I think wxGlade (http://wxglade.sourceforge.net/) should be what you are looking for. A GUI editor that generate wxPython code.

Arnold

johnf wrote:

···

Hi,

I wonder why we need to have sizers? Why can't someone develop a GUI editor that automaticly determines what is required to keep the relative proportions and positions of widgets on a frame.

Sizers work but they are a pain to work with. Robin spent a whole chapter (11) just to explain sizers. So you create a nice looking frame with sizers and then someone says "Look's great but could you add these two other widgets". It's just a pain to work with. There has to be something better.

Does anyone know of any sort of project trying to get rid of sizers?

John

---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-users-unsubscribe@lists.wxwidgets.org
For additional commands, e-mail: wxPython-users-help@lists.wxwidgets.org

--
Arnold Chen
[ mailto:arnold@design97.com ]
[ tel: +852 9250 0063]

Design 97
[ http://www.design97.com ]
[ tel: +852 2802 8900]

John_Fabiani2 · May 20, 2006, 6:30pm

I think wxGlade uses sizers. Am I wrong?
John

···

On Saturday 20 May 2006 11:23, Arnold Chen wrote:

Hi,

I think wxGlade (http://wxglade.sourceforge.net/) should be what you are
looking for. A GUI editor that generate wxPython code.

Arnold

johnf wrote:
> Hi,
>
> I wonder why we need to have sizers? Why can't someone develop a GUI
> editor that automaticly determines what is required to keep the relative
> proportions and positions of widgets on a frame.
>
> Sizers work but they are a pain to work with. Robin spent a whole
> chapter (11) just to explain sizers. So you create a nice looking frame
> with sizers and then someone says "Look's great but could you add these
> two other widgets". It's just a pain to work with. There has to be
> something better.
>
> Does anyone know of any sort of project trying to get rid of sizers?
>
> John
>

Robin · May 20, 2006, 7:01pm

johnf wrote:

Hi,

I wonder why we need to have sizers? Why can't someone develop a GUI editor that automaticly determines what is required to keep the relative proportions and positions of widgets on a frame.

But what would it do instead of sizers? Absolute positioning and sizing breaks as soon as you change platforms or even change the default font size on the same platform, because widget min sizes and such change. So that leaves doing something dynamic at runtime to manage the layout. Sure a gui editor could generate code that measures min or best sizes of widgets, checks rules that contorl expandability of some widgets, calculates the minimum needs of the container, and then call all of this code from the container's EVT_SIZE handler. But why bother? Sizers already do all of that and more, and the gory details are hidden from the programmer instead of requiring you to deal with pages and pages of generated code in a EVT_SIZE handler that would have to be duplicated in any program that uses this approach.

Sizers work but they are a pain to work with. Robin spent a whole chapter (11) just to explain sizers. So you create a nice looking frame with sizers and then someone says "Look's great but could you add these two other widgets". It's just a pain to work with. There has to be something better.

There's the predecessor of the sizers, layout constraints. They're still in the library although they've been marked for many years in the docs as deprecated. Personally I think they are much more complex than sizers, but some people like them. There is also wx.lib.anchors which is based on layout constraints.

Does anyone know of any sort of project trying to get rid of sizers?

Nope. If you're really interested in doing this I would suggest that as an exercise you should take a complex layout done with sizers and convert it to raw code in a EVT_SIZE handler that handles fixed size items, best or min sized items, and expandable items, along with borders, alignments, and etc. Then try to think of ways that what you did by hand could be generalized for nearly any layout requirements.

···

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

Dave_Rose · May 20, 2006, 7:11pm

I use wxGlade. It uses sizers, but you can click on a horizontal or vertical grid-sizer and right-click, then select Add or Insert (position) and it'll place another spot for your new widget. Actually, I really enjoy using wxGlade. It's not perfect, but darned good.

There is a style, however, to using it most effectively. You have to create your GUI (Save reasonably-regularly incase of a crash) . There are a few pre-created widget buttons on the tool pallette. One of which is a custom-widget button.Use this for everything else you'd want, but isn't defined as a widget-button. Suppose you want to drop in an LED-control. You'd select Custom Widget button, and in the class name, you'd enter gizmos.LEDNumberCtrl and for the name, you'd maybe use self.led. That's give you self.led = gizmos.LEDNumberCtrl(self.panel_liveWindow, -1), wit the size and location information being automatically entered via the sizer. You'd have to manually update the generated code with the correct import line. Also, the generated code can't (really, really shouldn't) be manually altered. There are REM-med lines like # wxGlade Begin and # wxGlade End lines meant to show you where to avoid coding, so you can write your code either above or below those REM lines.

However, I've recently taken to creating all code to a wxGUI.py file, then sub-classing each class like this:

import wx
import wxGUI
import locale
import wx.lib.printout as printout

FONTSIZE = 10

class SalesTaxReport_Dialog(wxGUI.SalesTaxReport_Dialog):
    def __init__(self, *args, **kwds):
        self.con = kwds['dbCon'] # I've added a few arguments to the instantiation of the object, to help configure it.
        self.cur = kwds['dbCur'] # Here I just place the values into a variable, and then delete the index from the dictionary of arguments.
        kwds.__delitem__('dbCon')
        kwds.__delitem__('dbCur')
        locale.setlocale(locale.LC_ALL, '')

        # begin wxGlade: AppFrame.__init__
        wxGUI.SalesTaxReport_Dialog.__init__(self, *args, **kwds) # Rem: Here I call the __init__ of the superclass
        # end wxGlade

        self.pdata = wx.PrintData()
        self.pdata.SetPaperId(wx.PAPER_LETTER)
        self.pdata.SetOrientation(wx.PORTRAIT)
        self.margins = (wx.Point(15,15), wx.Point(15,15))

So, what I've done is extract all the generated code lines (which are quite visually 'bloaty') out of sight, and now it's just imported, sub-classed, and called. I think using wxGlade this way is easy and effective. But I'm not the savviest nor smartest pythoneer so maybe I'm just doing it the hard way and now knowing it .....

-Dave

···

----- Original Message ----- From: "Arnold Chen" <arnold@design97.com>
Newsgroups: gmane.comp.python.wxpython
Sent: Saturday, May 20, 2006 2:23 PM
Subject: Re: Why can't we get rid of sizers?

Hi,

I think wxGlade (http://wxglade.sourceforge.net/) should be what you are looking for. A GUI editor that generate wxPython code.

Arnold

johnf wrote:

Hi,

I wonder why we need to have sizers? Why can't someone develop a GUI editor that automaticly determines what is required to keep the relative proportions and positions of widgets on a frame.
Sizers work but they are a pain to work with. Robin spent a whole chapter (11) just to explain sizers. So you create a nice looking frame with sizers and then someone says "Look's great but could you add these two other widgets". It's just a pain to work with. There has to be something better.
Does anyone know of any sort of project trying to get rid of sizers?

John

---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-users-unsubscribe@lists.wxwidgets.org
For additional commands, e-mail: wxPython-users-help@lists.wxwidgets.org

--
Arnold Chen
[ mailto:arnold@design97.com ]
[ tel: +852 9250 0063]

Design 97
[ http://www.design97.com ]
[ tel: +852 2802 8900]

Marc_Hedlund · May 20, 2006, 7:16pm

Or try it in Java. Then you'll love wxPython a lot more than you already do.

-M

···

On Sat, 20 May 2006, Robin Dunn wrote:

Does anyone know of any sort of project trying to get rid of sizers?

Nope. If you're really interested in doing this I would suggest that as an exercise you should take a complex layout done with sizers and convert it to raw code in a EVT_SIZE handler that handles fixed size items, best or min sized items, and expandable items, along with borders, alignments, and etc. Then try to think of ways that what you did by hand could be generalized for nearly any layout requirements.

Kevin_Ollivier4 · May 20, 2006, 8:09pm

Hi Robin and all,

johnf wrote:

Hi,
I wonder why we need to have sizers? Why can't someone develop a GUI editor that automaticly determines what is required to keep the relative proportions and positions of widgets on a frame.

But what would it do instead of sizers? Absolute positioning and sizing breaks as soon as you change platforms or even change the default font size on the same platform, because widget min sizes and such change. So that leaves doing something dynamic at runtime to manage the layout. Sure a gui editor could generate code that measures min or best sizes of widgets, checks rules that contorl expandability of some widgets, calculates the minimum needs of the container, and then call all of this code from the container's EVT_SIZE handler. But why bother? Sizers already do all of that and more, and the gory details are hidden from the programmer instead of requiring you to deal with pages and pages of generated code in a EVT_SIZE handler that would have to be duplicated in any program that uses this approach.

Of course I wholeheartedly agree. But he raises an interesting point in terms of why widgets don't automatically determine the correct relative proportions and positions. Why shouldn't they? What about, for common cases, removing the user's need to deal with sizers by creating one internally? i.e. as he said, why can't widgets have "default" sizers that just "do the right thing" to maintain the proportion and position of widgets, in accordance with the platform's HIGs? Of course, this would always be overrideable by changing the sizer or the sizer flags, but I can think of a ton of cases in my own code where I just want to use the platform's defaults/HIGs, and in fact have to currently write conditional code in order to do that.

If all controls in the hierarchy have default sizers, and they simply add controls to their sizer when the control is added as a child, then sizers could become almost transparent to the user, and become more a property of the control. Controls could simply have a function such as SetSizer or SetSizerProps(wxSizerFlags&) for any case in which the user wants to provide custom behavior, and using explicit sizes turns off the sizer, of course. This approach would also be backwards compatible because old code would always create and assign the sizers itself, overriding the defaults. For container controls, such as wxPanel, we could have a simple default such as a vertical wxBoxSizer that again just needs to be overridden by the user.

I've had this in my mind for a while, but I was wondering if others think this sort of system would make sense. Sizers are absolutely essential for good cross-platform apps, but I think we could actually internalize the sizer code for 80% of cases, which would not only simplify things but save users a whole lot of largely tedious sizer coding, and provide a much more favorable initial impression of dealing with wxPython.

Regards,

Kevin

···

On May 20, 2006, at 12:01 PM, Robin Dunn wrote:

Sizers work but they are a pain to work with. Robin spent a whole chapter (11) just to explain sizers. So you create a nice looking frame with sizers and then someone says "Look's great but could you add these two other widgets". It's just a pain to work with. There has to be something better.

There's the predecessor of the sizers, layout constraints. They're still in the library although they've been marked for many years in the docs as deprecated. Personally I think they are much more complex than sizers, but some people like them. There is also wx.lib.anchors which is based on layout constraints.

Does anyone know of any sort of project trying to get rid of sizers?

Nope. If you're really interested in doing this I would suggest that as an exercise you should take a complex layout done with sizers and convert it to raw code in a EVT_SIZE handler that handles fixed size items, best or min sized items, and expandable items, along with borders, alignments, and etc. Then try to think of ways that what you did by hand could be generalized for nearly any layout requirements.

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-users-unsubscribe@lists.wxwidgets.org
For additional commands, e-mail: wxPython-users-help@lists.wxwidgets.org

Josiah_Carlson · May 20, 2006, 8:16pm

I wonder why we need to have sizers? Why can't someone develop a GUI editor
that automaticly determines what is required to keep the relative proportions
and positions of widgets on a frame.

Sizers aren't necessary, but I find them far more convenient than
guessing and checking with a static layout, or even

Sizers work but they are a pain to work with. Robin spent a whole chapter
(11) just to explain sizers. So you create a nice looking frame with sizers
and then someone says "Look's great but could you add these two other
widgets". It's just a pain to work with. There has to be something better.

self.newc = ...
sizer.Add(self.newc)

Wow, that was a pain. I can't imagine how anyone manages to use sizers
to layout their controls.

In Python 2.5 there will be a method to manage 'contexts' via the 'with'
statement. Using with, you can define context managers to help defining
layout of your controls in a structural manner. Something like the
following perhaps...

    with wx.Panel(self, -1) as self.panel:
        with my.BoxLayout(self.panel, wx.HORIZONTAL, border=5):
            self.b1 = my.Button(self.panel, -1, "click me!")
            self.b2 = my.Button(self.panel, -1, "or click me!")

Where my.Layout could be defined as:

layout_stack =

@context
def BoxLayout(control, which_layout, weight=0, flags=wx.ALL,
           border=0, fit=0):
    l = wx.BoxSizer(which_layout)
    def layout(c):
        l.Add(c, weight, flags, border)
    try:
        try:
            yield
        except:
            pass
        else:
            if fit:
                control.SetSizerAndFit(l)
            else:
                control.SetSizer(l)
                control.SetAutoLayout(1)
    finally:
        _ = layout_stack.pop()

Where my.Button could be defined as:

def Button(parent, id=-1, text="", ...):
    b = wx.Button(...)
    layout_stack[-1](b)
    return b

- Josiah

···

johnf <jfabiani@yolo.com> wrote:

John_Fabiani2 · May 20, 2006, 11:14pm

Everyone agrees that sizers are pain in (you know where). But little is being
done about it. I think your ideas have merit. But I doubt anything will be
done.

I was thinking of an editor that could inspect the frame run some sort of
routine to add sizers (based on vbox and hbox). Anyway, just a drag and
drop, adjust and then process. The generated code would include the sizers.
Then we could sub-class the generated code. If a change was required just do
it again.

John

···

On Saturday 20 May 2006 13:09, Kevin Ollivier wrote:

Hi Robin and all,

On May 20, 2006, at 12:01 PM, Robin Dunn wrote:
> johnf wrote:
>> Hi,
>> I wonder why we need to have sizers? Why can't someone develop a
>> GUI editor that automaticly determines what is required to keep
>> the relative proportions and positions of widgets on a frame.
>
> But what would it do instead of sizers? Absolute positioning and
> sizing breaks as soon as you change platforms or even change the
> default font size on the same platform, because widget min sizes
> and such change. So that leaves doing something dynamic at runtime
> to manage the layout. Sure a gui editor could generate code that
> measures min or best sizes of widgets, checks rules that contorl
> expandability of some widgets, calculates the minimum needs of the
> container, and then call all of this code from the container's
> EVT_SIZE handler. But why bother? Sizers already do all of that
> and more, and the gory details are hidden from the programmer
> instead of requiring you to deal with pages and pages of generated
> code in a EVT_SIZE handler that would have to be duplicated in any
> program that uses this approach.

Of course I wholeheartedly agree. But he raises an interesting point
in terms of why widgets don't automatically determine the correct
relative proportions and positions. Why shouldn't they? What about,
for common cases, removing the user's need to deal with sizers by
creating one internally? i.e. as he said, why can't widgets have
"default" sizers that just "do the right thing" to maintain the
proportion and position of widgets, in accordance with the platform's
HIGs? Of course, this would always be overrideable by changing the
sizer or the sizer flags, but I can think of a ton of cases in my own
code where I just want to use the platform's defaults/HIGs, and in
fact have to currently write conditional code in order to do that.

If all controls in the hierarchy have default sizers, and they simply
add controls to their sizer when the control is added as a child,
then sizers could become almost transparent to the user, and become
more a property of the control. Controls could simply have a function
such as SetSizer or SetSizerProps(wxSizerFlags&) for any case in
which the user wants to provide custom behavior, and using explicit
sizes turns off the sizer, of course. This approach would also be
backwards compatible because old code would always create and assign
the sizers itself, overriding the defaults. For container controls,
such as wxPanel, we could have a simple default such as a vertical
wxBoxSizer that again just needs to be overridden by the user.

I've had this in my mind for a while, but I was wondering if others
think this sort of system would make sense. Sizers are absolutely
essential for good cross-platform apps, but I think we could actually
internalize the sizer code for 80% of cases, which would not only
simplify things but save users a whole lot of largely tedious sizer
coding, and provide a much more favorable initial impression of
dealing with wxPython.

Regards,

Kevin

>> Sizers work but they are a pain to work with. Robin spent a whole
>> chapter (11) just to explain sizers. So you create a nice looking
>> frame with sizers and then someone says "Look's great but could
>> you add these two other widgets". It's just a pain to work
>> with. There has to be something better.
>
> There's the predecessor of the sizers, layout constraints. They're
> still in the library although they've been marked for many years in
> the docs as deprecated. Personally I think they are much more
> complex than sizers, but some people like them. There is also
> wx.lib.anchors which is based on layout constraints.
>
>> Does anyone know of any sort of project trying to get rid of sizers?
>
> Nope. If you're really interested in doing this I would suggest
> that as an exercise you should take a complex layout done with
> sizers and convert it to raw code in a EVT_SIZE handler that
> handles fixed size items, best or min sized items, and expandable
> items, along with borders, alignments, and etc. Then try to think
> of ways that what you did by hand could be generalized for nearly
> any layout requirements.
>
> --
> Robin Dunn
> Software Craftsman
> http://wxPython.org Java give you jitters? Relax with wxPython!
>

Horst_Herb2 · May 20, 2006, 11:55pm

Well, I don't.

I have been programming GUIs for more than 20 years - including writing event
driven GUI systems from scratch in Pascal and C at a time when Windows 2.0
was only a vague announcement - and I find sizers are the greatest thing
since sliced bread. I cannot think of any way making flexible layout even
simpler.

People disliking sizers have probably not grokked the concept behind them - I
found that especially people used to statically positioned point-and-click UI
generators simply can't dislodge their minds from the statical paradigm.

I found that the syntax of Tk sizers is perhaps a bit easier to understand -
maybe thosehaving difficulties with Python should play a bit interactively
with Tk in order to "get it"

Horst

···

On Sunday 21 May 2006 09:14, johnf wrote:

Everyone agrees that sizers are pain in (you know where).

Peter_Decker · May 21, 2006, 3:54am

Sizers are wonderful, IMO. The goal is to create rich applications,
and this requires developers to make an effort, rather than make users
work harder.

Have looked at Dabo? They have embraced a sizer-centric approach in
their development tools. I resisted it at first, since it seemed too
confusing. But since I've been able to grok sizers, it seems like
these guys really have insight into the way to develop apps that are
cross-platform without having to hack things for each platform.

I love wxPython and all it offers, but once I got hooked on Dabo's ui
module, I can't go back. Yes, there is a learning curve, but isn't
that true of any worthwhile tool? If you haven't seen Dabo, you should
really take a look at it: http://dabodev.com.

···

On 5/20/06, johnf <jfabiani@yolo.com> wrote:

I wonder why we need to have sizers? Why can't someone develop a GUI editor
that automaticly determines what is required to keep the relative proportions
and positions of widgets on a frame.

--

# p.d.

John_Fabiani2 · May 21, 2006, 4:18am

Actually dabo is what started me thinking about what might be done to solve
the sizer issue. Ed and Paul have done a very good job. But they have only
gone halfway. They have made it easier but not easy. Ed and Paul came from
the VFP (visual foxpro) world and realize the ease that VFP programmers setup
frames (windows). Changes can be made in seconds vs hours (at least that's
what happens to me). But VFP forms lack re-sizing - controls have fixed
positions. I want to be able to create GUI's short periods of time and be
able add or subtract easily.

John

···

On Saturday 20 May 2006 20:54, Peter Decker wrote:

On 5/20/06, johnf <jfabiani@yolo.com> wrote:
> I wonder why we need to have sizers? Why can't someone develop a GUI
> editor that automaticly determines what is required to keep the relative
> proportions and positions of widgets on a frame.

Sizers are wonderful, IMO. The goal is to create rich applications,
and this requires developers to make an effort, rather than make users
work harder.

Have looked at Dabo? They have embraced a sizer-centric approach in
their development tools. I resisted it at first, since it seemed too
confusing. But since I've been able to grok sizers, it seems like
these guys really have insight into the way to develop apps that are
cross-platform without having to hack things for each platform.

I love wxPython and all it offers, but once I got hooked on Dabo's ui
module, I can't go back. Yes, there is a learning curve, but isn't
that true of any worthwhile tool? If you haven't seen Dabo, you should
really take a look at it: http://dabodev.com.

Christian1 · May 21, 2006, 4:31am

All of those who write their gui by hand really should have a look at xrc. I
never liked using gui builders which output python code. Xrc on the other hand
is very easy to use and does not interfere with your code. Having changed to a
xrc based gui the amount of time I had to spend on understanding why some parts
of my gui weren't resizing as expected reduced to 20% and of course the code got
much shorter.
Christian

John_Jackson · May 21, 2006, 5:27am

In Robin's book on wxPython there is a diagram (Figure 6.7) that shows the relationship between box sizers, flags and factors and the resize behavior. I've cut out a copy of it and put in on my desk. It keeps me straight, and I've had far fewer problems sorting out sizer issues after looking at that diagram.

</end plug>

But if we really want to "get rid of sizers," the best solution I have ever worked with for GUI building has been Apple's Interface Builder. If you aren't familiar with it but have access to a Mac with the developer tools on it, you should look at it if you are interested in what a polished interface builder can look like.

It uses something akin to layout constraints to do the sizing, and I find them straight forward. You can immediately toggle into a running application mode, and test your layout. All the controls are available on inspectors for addition to your window / panel / menu. There is automatic interface guidelines displayed so that you can line up objects in a consistent fashion. It makes the design of interfaces a pleasure. It's the one thing I miss about not working in Cocoa.

I have thought about how great it would be to have an application as slick as Interface Builder for wxPython.

···

______________
John Jackson

John_Fabiani2 · May 21, 2006, 4:37pm

That's not accurate in my case. I think I understand sizers. My issue has
mostly to do with having to make changes after laying out a large number of
controls. In fact I really try to stay away from grid sizers because it is
easier to control layout with boxers. It could be that I'm not as smart as
others but I find it a pain compared to point and shoot. Yes, I was hand
coding for the most part. When I tried Glade and others I had a harder time
(until ClassDesigner.py in dabo) making changes. I haven't tried wxDesigner
nor have I worked with the Apple development packages. But they sound like
what I think can be done - point and shoot along with re-sizing.

John

···

On Saturday 20 May 2006 16:55, Horst Herb wrote:

People disliking sizers have probably not grokked the concept behind them -
I found that especially people used to statically positioned
point-and-click UI generators simply can't dislodge their minds from the
statical paradigm.

Uwe_C_Schroeder · May 21, 2006, 7:09pm

I use wxDesigner together with XRC. Makes changes very simple to deal with.

UC

···

On Sunday 21 May 2006 09:37, johnf wrote:

On Saturday 20 May 2006 16:55, Horst Herb wrote:
> People disliking sizers have probably not grokked the concept behind them
> - I found that especially people used to statically positioned
> point-and-click UI generators simply can't dislodge their minds from the
> statical paradigm.

That's not accurate in my case. I think I understand sizers. My issue has
mostly to do with having to make changes after laying out a large number of
controls. In fact I really try to stay away from grid sizers because it is
easier to control layout with boxers. It could be that I'm not as smart as
others but I find it a pain compared to point and shoot. Yes, I was hand
coding for the most part. When I tried Glade and others I had a harder
time (until ClassDesigner.py in dabo) making changes. I haven't tried
wxDesigner nor have I worked with the Apple development packages. But they
sound like what I think can be done - point and shoot along with re-sizing.

--
Open Source Solutions 4U, LLC 1618 Kelly St
Phone: +1 707 568 3056 Santa Rosa, CA 95401
Cell: +1 650 302 2405 United States
Fax: +1 707 568 6416

Chris_Barker1 · May 22, 2006, 7:05pm

Horst Herb wrote:

Everyone agrees that sizers are pain in (you know where).

Well, I don't.

Me neither. I love them!

People disliking sizers have probably not grokked the concept behind
them -

I agree, they do take a while to wrap your brain around, but they are
wonderful, and I know spend little time fighting with them.

I do think the syntax could be better, and a better way to visualize
what you're doing also helps.

Also, just like code: start small and modularize your code! I've seen
people post to this list with 20 widgets all layout out and the whole
thing is a mess. If you group them and make sure each grouping works
before you put them together, it'll be much easier to do.

Also create custom classes to group your controls. Chances are you can
come up with a better structure if you have 20 controls all laid out in
one class.

Kevin O: I am curious about your ideas, but I don't see how it could
work, at all! I suppose using the HIG for standard spacing between
widgets could be done, but other than that I don't see how there is
anything at all standard about how widgets are arranged in any GUI: it
totally depends on how they are being used. You have to specify the
layout somehow!

I found that the syntax of Tk sizers is perhaps a bit easier to
understand -

I hated them! "pack" is easy, until you do something complex, and then
you're nesting frames all over the place: worse than sizers!

Michael Hipp wrote:

I just finished the layout of a panel with some 43 controls on it
grouped by 8 static boxes.

How it the world could you imagine making than easier? And this sounds
like exactly what I'm talking about above -- break it down into smaller
pieces!

Yes, I know 43 controls on one panel is excessive. Boy, do I know it.
But I'm trying to give the client what she wants and that's how she wants it. Mine is not to question why.

No, but yours is to write the code cleanly. Just because your client
wants to see all those controls at once doesn't mean you have to put
them all in one Panel. that could be ten Panels: it would look the same.
And I think yours might be to point out usability issues as well!

The sizers seem to have a philosphy of grow, grow, and then just grow
some more for good measure.

I've never had that problem. There is something tricky going on there, that you must have missed. I do think you'd find it easier if you did things in smaller pieces, though.

Eli Golovinsky wrote:

Maybe I'm missing something, but I really don't understand the merit of writing layouts using bare code.

http://www.hacknot.info/hacknot/action/showEntry?eid=76

Primarily, the biggest Issue I have with GUI-builders is that all of the ones I have seen discourage using custom controls. I strongly believe that grouping controls into app-specific custom controls is a very god idea.

-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

Kevin_Ollivier4 · May 22, 2006, 10:11pm

Hi Chris,

[snip]

Kevin O: I am curious about your ideas, but I don't see how it could
work, at all! I suppose using the HIG for standard spacing between
widgets could be done, but other than that I don't see how there is
anything at all standard about how widgets are arranged in any GUI: it
totally depends on how they are being used. You have to specify the
layout somehow!

I think I probably didn't explain myself well. I'm trying to tackle two problems:

1) Creating HIG compliant apps with proper borders/padding is currently a pain (you have to read the HIGs yourself and then code your sizers accordingly), and

2) Using sizers in visual GUI builders is rather awkward, and it may even be true to say the current implementation limits how close to RAD a wxPython GUI builder can get.

I think the reason default sizers solves problem #1 is pretty obvious, and doesn't need further explanation. (And I think for this feature alone it makes sense to have a default sizer for native OS controls.) But how does it address problem #2?

Take a look at Interface Builder (IB). It allows for sizer-like control (although perhaps it's a bit closer to layout constraints...), but in IB the 'sizers' are not something you need to create yourself - by default you can just drag and drop elements into a window. You can't do that with wxPython GUI builders when using sizers, because you need to give that window a sizer first before you can add the control. In other words, for wxPython, creating a sizer to hold controls is always step one in GUI building, not "adding controls", which is step one in other editors.

Some people say that's because those other editors don't use sizers, but they do have layout and alignment tools, so I don't think that's entirely true. I think the reason is that, in other GUI builders, e.g. Interface Builder, Qt Designer, etc. layout and sizing are *properties* of the control, not something totally separate from the control. So when you move the control around, in a way you're adjusting its (and/or its parent's) 'sizer' dynamically. (e.g. adjusting left and top padding) wxPython GUI builders could probably be designed to do this, except for one problem - by default, a control doesn't have a sizer, so obviously it can't be adjusted until it's created.

Therefore, to me it's not a matter of whether or not the default sizer will work in most cases - what I care about is that manipulating sizers within GUI builders becomes easier to do so we can get closer to RAD GUI building. By making controls always have a sizer, we can internalize some sizer code, e.g. adding controls to their parents' sizer, into wx itself meaning that users and GUI builders automatically get this behavior 'for free'. Once that is done, we can remove the need to have sizers as separate entities in the layout hierarchy. Sizers are now simply part of the control, and can be adjusted in the exact same manner as you'd adjust, for example, the control's default text value. So when you're writing your wx app in your GUI builder, and a vertical box sizer doesn't cut it anymore, go into the parent's properties and change it to a grid sizer and watch the new layout appear in front of you. Don't like that? Adjust it's properties, or maybe try a flex grid sizer.

A nice side-benefit for users who code their GUIs by hand is that much of the tedious coding is gone - now you just code changes to the defaults, rather than write code to set the (often largely redundant) flags for, and add, every control to a sizer. All you need to do now is add the control as usual, and change any control sizer properties you want to change.

Hopefully this clarifies things some. Maybe I'm off-base here but it seems to me this is the underlying issue as to why wxPython GUI builders typically have problems working like more RAD-style GUI builders such as Interface Builder.

Thanks,

Kevin

···

On May 22, 2006, at 12:05 PM, Christopher Barker wrote:

Don_Dwiggins · May 22, 2006, 10:51pm

Kevin Ollivier wrote:

Take a look at Interface Builder (IB). It allows for sizer-like control (although perhaps it's a bit closer to layout constraints...), but in IB the 'sizers' are not something you need to create yourself - by default you can just drag and drop elements into a window. You can't do that with wxPython GUI builders when using sizers, because you need to give that window a sizer first before you can add the control.

Well, I've occasionally done it controls first with XRCed: add a bunch of controls, then: add a sizer, cut'n'paste a few controls into it, iterate as needed (XRCed has execellent support for cut'n'paste). I've mostly done that when I'm in "visual brainstorming" mode; if I have a clear idea of how it should look, I'll usually build it top-down. Dunno how that might go in other builders.

Come to think of it, a nice extension to XRCed might be the ability to select a group of controls/containers and say "wrap these in a sizer of this kind".

I think the reason is that, in other GUI builders, e.g. Interface Builder, Qt Designer, etc. layout and sizing are *properties* of the control, not something totally separate from the control.

Seems to me there's a potential problem with that approach: sizing is generally not an operation on an individual control, but on a set of them (possibly the whole frame). It could be awkward to try to specify a multi-control layout when you're restricted to operations on one control at a time. I might be missing something, though.

what I care about is that manipulating sizers within GUI builders becomes easier to do so we can get closer to RAD GUI building.

I think we're probably all in sympathy with this. I think we're still in learning mode as a community on the best way (or ways) to do it.

when you're writing your wx app in your GUI builder, and a vertical box sizer doesn't cut it anymore, go into the parent's properties and change it to a grid sizer and watch the new layout appear in front of you. Don't like that? Adjust it's properties, or maybe try a flex grid sizer.

Hate to sound like a shill for XRCed, but it does that nicely with its Replace operation (which works on controls as well as sizers). I've used it to good effect.

···

--
Don Dwiggins
Advanced Publishing Technology

Chris_Barker1 · May 22, 2006, 11:49pm

Kevin Ollivier wrote:

I think I probably didn't explain myself well.

Much better this time. I know you well enough that I expect your ideas were good ones.

I think you've focused on a good point here: there are three independent hierarchies used when building an UI:

The Python class hierarchy (subclass, superclass)
The wxWindow hierarchy (parent, child)
The Sizer Hierarchy

This does make things confusing -- can we at least get rid of one?

1) Creating HIG compliant apps with proper borders/padding is currently a pain (you have to read the HIGs yourself and then code your sizers accordingly), and

That could be better. I'm not sure we need to do anything really different structurally, just add some more defaults, maybe even smart ones: A Button gets an n pixel border, a TextCtrl gets an m pixel border, etc.

2) Using sizers in visual GUI builders is rather awkward, and it may even be true to say the current implementation limits how close to RAD a wxPython GUI builder can get.

Personally, I'd like layout to be easier to code by hand, then I think the GUI builders would be easier too.

You can't do that with wxPython GUI builders when using sizers, because you need to give that window a sizer first before you can add the control. In other words, for wxPython, creating a sizer to hold controls is always step one in GUI building, not "adding controls", which is step one in other editors.

Couldn't the editor do it for you anyway? though, as I said, I want the code to be easy to write too.

> By making controls always have a sizer, we can internalize

some sizer code, e.g. adding controls to their parents' sizer, into wx itself meaning that users and GUI builders automatically get this behavior 'for free'.

Hmm. I still don;t see how it makes sense for a control to have a sizer, unless it's a container control, like a wxPanel. (Doesn't MindWrapper do something like this? and/or Dabo?) However, controls could have sizing properties, that get used by the sizer. Essentially these would be all the parameters and flags that get passed in to the Sizer.Add() method.

Another thought I had was to simplify the difference between horizontal and vertical sizing, when do you have to know if you use the "option" parameter or a wx.GROW? Why not:

StretchFactorVert = 3

StretchFactorHoriz = 0

Then that would work in either a horizontal or vertical box sizer (and grid sizers)

Another thing I often thought: BoxSizers are just special cases of grid sizers. In fact, I think you could really have only GridBagSizer and everything else is a special case.

The only real trick here that I see at first is that some layouts (quite a few, really) need nested sizers. If there is one sizer per Panel object, how do you do nested sizers? Nested Panels? maybe. It seems like extra Panels, but maybe that's not a big deal.

A nice side-benefit for users who code their GUIs by hand is that much of the tedious coding is gone -

Now that I like!

Now we need someone to prototype this up....

-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