Why can't we get rid of sizers?

[Kevin_Ollivier4]

Hi Don,

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.

Multi-control layouts would be controlled by the parent control in the multi-control layout. e.g. you'd change the parent's layout from BoxSizer to GridSizer, and this would adjust all the child controls automatically.

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.

It's not so much an issue of whether or not it can be done; it's rather an issue of how intuitive is it, and how quickly and easily can people coming from other tools (e.g. Interface Builder, Qt Designer, MS IDE) can get used to it. wxGlade does seem to do a nice job of this, but the issue is, again, that sizers are external elements, and you have to add them yourself for even basic layouts. It's just not intuitive, to me, that you have to add a control, then click "Add slot" on the sizer, then add another control, etc. Much more intuitive, I think, to add a control, have wx internally add it to the sizer, and have it pop up on the screen. I know XRCEd does it that way, but it probably is a bit easier to implement things that way since users don't see the interface until they preview. (That's just a guess, though.)

Basically, my primary goal is removing the separation between sizers and controls, so that some of these special features can be replaced by more standardized ones found in other IDEs in order to reduce the learning curve sizers pose.

Thanks,

Kevin

···

On May 22, 2006, at 3:51 PM, Don Dwiggins wrote:

--
Don Dwiggins
Advanced Publishing Technology

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

[Kevin_Ollivier4]

Hi Chris,

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.

Thanks, though your expectations may be set too high. I'm glad I was more clear this time; sometimes I get too much into how and forget to identify the 'why' in the first place.

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.

You're right, it's not anything radically different. We just need to set the padding and borders according to HIG specs.

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.

Sure, but the less an editor has to do to implement a feature, the more likely it will be implemented.

> 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.\

I'm not stuck on this approach. The reason I thought of doing it this way is because it simplifies the internal wx implementation - e.g. We can always just check for a sizer and add it if one exists. Otherwise, we'd have to do something like:

if (child->GetSizer())
   parentSizer->Add(child->GetSizer());
else
   parentSizer->Add(child, child->GetDefaultSizerFlags());

or something like that. (GetDefaultSizerFlags doesn't exist yet Actually, that being said, I'm starting to like the idea of GetDefaultSizerFlags() so maybe we should implement it anyways, in which case why not just do the above? Robin, any thoughts on this?

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)

Yeah, this one often gets me too. I also think it would be a good idea to do this. How do you propose to add this to the API?

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.

Personally, I think at the API level it's nice to have something that is simple like BoxSizers. Implementation-wise, maybe they could share code, but I think BoxSizers are very beginner-friendly.

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.

If you code by hand, you can always just do myPanel.GetSizer().Add(anotherSizer), but for GUI builders it would probably be easiest for the user to create another Panel object, as you say. I don't think this would happen to such an extent that it would introduce significant overhead, and this seems to me the intuitive way to do things from a GUI builder.

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....

If I can sell Robin on this idea, then I'll take it to wx-dev and try to sell it there. The basic implementation will be pretty simple. A default sizer for container controls, a wxWindow::GetDefaultSizerFlags API, and code in wxWindow::Create to add the child to the parent's sizer. What will take time is implementing the GetDefaultSizerFlags for various native controls, though the nice thing is that we don't have to do it for all controls in one full shot; we can do it one at a time. And IMHO early in the 2.7 cycle would be a good point to introduce this, so we have a little time to make this work.

Thanks,

Kevin

···

On May 22, 2006, at 4:49 PM, Christopher Barker wrote:

-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

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

[Don_Dwiggins]

Kevin Ollivier wrote:

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.

Multi-control layouts would be controlled by the parent control in the multi-control layout. e.g. you'd change the parent's layout from BoxSizer to GridSizer, and this would adjust all the child controls automatically.

So in effect, every container comes with a sizer (in its "layout" attribute), and it can be identified and replaced with a different sizer, automatically acquiring any children of the old one (which might require some interaction, depending on the classes of the sizers).

A basic form of this shouldn't be too hard to implement as an extension of Panel and/or a tweak to a GUI builder. In XRCed, you could have a setting that would hide these "automatic sizers" in the tree, making it a bit easier to read. I guess what I'm saying is, maybe someone who feels strongly about this should cobble up a strawman prototype for the group to play with. Maybe some common Panel subclasses that each come with a standard set of sizers that it manages mostly invisibly to the programmer. (Of course, you'd want good visibility to them when needed.). (I'm thinking along the lines of Word's and OpenOffice's concept of document templates, but recursive.)

Basically, my primary goal is removing the separation between sizers and controls, so that some of these special features can be replaced by more standardized ones found in other IDEs in order to reduce the learning curve sizers pose.

There's a learning curve with any but the simplest controls. It took me a few days to get comfortable with ListCtrl, for example, and I expect to have a similar experience if/when I tackle tree controls. The only special thing here about sizers is that they're ubiquitous. (The special thing about the current wx.Sizers is that getting them to do what you want is untuitive until you've had an epiphany.)

BTW, I still think that tackling aspects of this issue would be a good project for the Summer of Code -- prototypes like mentioned above, demos that make it visibly clear how the different kinds of sizers work, alternatives/complements to sizers, etc.

···

--
Don Dwiggins
Advanced Publishing Technology

[Robin]

Kevin Ollivier wrote:

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.\

I'm not stuck on this approach. The reason I thought of doing it this way is because it simplifies the internal wx implementation - e.g. We can always just check for a sizer and add it if one exists. Otherwise, we'd have to do something like:

if (child->GetSizer())
  parentSizer->Add(child->GetSizer());
else
  parentSizer->Add(child, child->GetDefaultSizerFlags());

or something like that. (GetDefaultSizerFlags doesn't exist yet Actually, that being said, I'm starting to like the idea of GetDefaultSizerFlags() so maybe we should implement it anyways, in which case why not just do the above? Robin, any thoughts on this?

It's probably a good idea, although there should be an easy way to override the flags without needing to derive a new control class.

One potential problem I do see however is in cases where you want the tab order to be different than the order items are added to sizers. Currently it's pretty easy to do, but if items are being added to sizer automatically then you have to create them in sizer order and then deal with the MoveBeforeInTabOrder.

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.

If you code by hand, you can always just do myPanel.GetSizer().Add(anotherSizer),

Don't forget that the items you want to Add to anotherSizer will already have been added to myPanel's sizer.

but for GUI builders it would probably be easiest for the user to create another Panel object, as you say. I don't think this would happen to such an extent that it would introduce significant overhead, and this seems to me the intuitive way to do things from a GUI builder.

Again potential tab order problems come into play here, since you can't change the tab order nested nested controls and non-nested controls.

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....

If I can sell Robin on this idea, then I'll take it to wx-dev and try to sell it there. The basic implementation will be pretty simple. A default sizer for container controls, a wxWindow::GetDefaultSizerFlags API, and code in wxWindow::Create to add the child to the parent's sizer. What will take time is implementing the GetDefaultSizerFlags for various native controls, though the nice thing is that we don't have to do it for all controls in one full shot; we can do it one at a time. And IMHO early in the 2.7 cycle would be a good point to introduce this, so we have a little time to make this work.

Another potential problem is dealing with moving items to another sizer if you want to use one that is not the default for the container. Also, wx.GridBagSizer uses a different wx.SizerItem type than the other sizers.

···

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

[J_Grimmtooth]

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

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.

I’ve programmed on a few other platforms (including Amiga using three different GUI toolkits, some quite similar to wx) and have to say that sizers, while not being the absolute finest of all possible solutions, make the most sense for a dynamic, flexible, professional-looking user interface without much in the way of pain - provided one uses good habits.

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.

Back to this in a moment …

OK, so you’ve got a complex UI you’re putting together. You’re using a object-oriented language to do it with. Does it make even the slightest bit of sense to put everything at the top level (the frame) and try to manage it? No! Absolutely not! Here’s an example of how I’d put together a program with a working area (text input/output) and a series of controls.

FRAME

• TOP PANEL
  • Left-hand (working) panel
  • Right-hand (control) panel

Aside from the frame, each of these elements are consisted of a wx.Panel with its own sizer, in its own class OUTSIDE the frame class. Each distinct component is (in source) presented in its own context.

Want a working example? Have a look at wx.Joystick in the wxPython demo program. That example has a wx.GridBagSizer at the top level, and various components below it. I did a large part of the work on that one (the rewrite when we moved from wx* to wx.*) so it expresses my ‘idiom’ fairly well. It breaks down like this:

• JoystickDemoPanel

  • InfoPanel (info pulled from the joystick driver)

  • JoyPanel (joystick positon display)

  • POVPanel (POV button position display)

  • AxisPanel (various axis position displays)

  • JoyButtons (state of all joystick buttons)

Each is consisted of one or more custom and standard controls (such as the LED or crosshair displays) wrapped by a sizer. We even have a control (Label) that is reused over and over again, again it’s in its own little class rather than mashed into the top level. I could have made it even further nested (I often do) and it would still be coherent and maintainable.

You can even break it up into seperate files - I have, for the more complex ones (such as programs that have multiple notebook pages), which helps keep the code readable and (again) maintainable.

So back to your example:

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.

Cake, relatively speaking, on just about any UI I’ve done in the past 5 or so years, using this ‘idiom’. Using the Joystick demo as an example, the following would all be trivial:

• add an additional control to reset the driver’s data

• Add another 16 button indicators

• Add another POV mode

• Rearrange the entire layout of the top panel

So: I don’t think sizers are the problem here. I think the learning curve is the problem, and time and experience using them. That and the approach you might take in organizing your code. Maybe I’m wrong, but almost every case I’ve seen like this has been because the code was a confusing mess due to everything being smooshed together.

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

No, but if someone can beat sizers (say, with HTML table-like stuff) all I can say is I’d buy one for a dollar.

···

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

–
“Ladies and gentlemen, there’s nothing to worry about … but please keep your heads down.” - The Muppet Show

Best,

Jeff

[Kevin_Ollivier4]

Hi Robin,

Kevin Ollivier wrote:

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.\

I'm not stuck on this approach. The reason I thought of doing it this way is because it simplifies the internal wx implementation - e.g. We can always just check for a sizer and add it if one exists. Otherwise, we'd have to do something like:
if (child->GetSizer())
  parentSizer->Add(child->GetSizer());
else
  parentSizer->Add(child, child->GetDefaultSizerFlags());
or something like that. (GetDefaultSizerFlags doesn't exist yet Actually, that being said, I'm starting to like the idea of GetDefaultSizerFlags() so maybe we should implement it anyways, in which case why not just do the above? Robin, any thoughts on this?

It's probably a good idea, although there should be an easy way to override the flags without needing to derive a new control class.

Sorry, I forgot to mention that I had planned SetDefaultSizerFlags(wxSizerFlags&) for this.

One potential problem I do see however is in cases where you want the tab order to be different than the order items are added to sizers. Currently it's pretty easy to do, but if items are being added to sizer automatically then you have to create them in sizer order and then deal with the MoveBeforeInTabOrder.

Good point, though IMHO there are merits to both approaches. (i.e. if you don't heavily modify tab order, you probably gain more by not having to type all those sizer.Add lines and maintaining sizers separately)

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.

If you code by hand, you can always just do myPanel.GetSizer().Add(anotherSizer),

Don't forget that the items you want to Add to anotherSizer will already have been added to myPanel's sizer.

D'oh! Well, as a potential solution to this, we could have sizer Add methods check to see if the control's already in a sizer, and detach it from that sizer if so. Although I'm not sure if it's worth the work.

but for GUI builders it would probably be easiest for the user to create another Panel object, as you say. I don't think this would happen to such an extent that it would introduce significant overhead, and this seems to me the intuitive way to do things from a GUI builder.

Again potential tab order problems come into play here, since you can't change the tab order nested nested controls and non-nested controls.

Yes, this sucks, but this is a wx limitation that affects more than just this proposal, IMHO. Actually, I did find a suggestion about handling custom tab order on the wxWiki:

http://www.wxwidgets.org/wiki/index.php/WxDialog

If this works cross-platform, and I don't see why it wouldn't (although does SetFocus always set keyboard focus too?), we could derive a CustomTabDialog that uses it and has a Get/SetTabOrder( [ control1, control2, control7, control43, control3, control15... ] ) function. This would be almost trivial to write at the wxPython level.

Or, just add Get/SetTabOrder to wxDialog, and when SetTabDialog is called, the CharHook is registered... That way we don't muck with previous behavior.

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....

If I can sell Robin on this idea, then I'll take it to wx-dev and try to sell it there. The basic implementation will be pretty simple. A default sizer for container controls, a wxWindow::GetDefaultSizerFlags API, and code in wxWindow::Create to add the child to the parent's sizer. What will take time is implementing the GetDefaultSizerFlags for various native controls, though the nice thing is that we don't have to do it for all controls in one full shot; we can do it one at a time. And IMHO early in the 2.7 cycle would be a good point to introduce this, so we have a little time to make this work.

Another potential problem is dealing with moving items to another sizer if you want to use one that is not the default for the container.

My thoughts on this were that it would just involve a call to container.SetSizer, which internally will, for each child control, grab its flags from the old sizer and then add the control to the new sizer. Do you see any problems with this?

Also, wx.GridBagSizer uses a different wx.SizerItem type than the other sizers.

It's true that we lose GB data, but if we're moving either to or from GBSizer, the GB-specific properties aren't of any use to us anyhow. And as long as we use GetItem, we get a wxSizerItem back, so we could use that to grab the other properties.

Thanks,

Kevin

···

On May 22, 2006, at 9:08 PM, Robin Dunn wrote:

--
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

[John_Fabiani2]

I can and do use sizers. They are a pain - period. There is no reason I can
think of that prevents wxPython from moving forward to a new level of GUI
programming. I have programmed in asm, c, c++, a little java, VFP, Object
Pascal, and Python. I moved to c because it was faster and easier to use
than asm. I moved to C++ to get oop. I moved to VFP because it was the
fastest way to get a data project to market and used OOP. I used the free
pascal compiler because it again provided a easier tool to work with on the
Linux platform. I have been using Python for a couple of years now. I'd
like to move on to a easier and faster way to setup a GUI and I think
wxPython could be that vehicle. So why would you be completely baffled at
these sentiments?

Even if I couldn't use sizers - I still believe wxPython can and should
improve the way sizers are used. And sizers are not perfect by a long shot!
Most people let textboxes just expand when resizing forms. If I have seen
one I've seen a hundred screens where the programmer allowed the textbox just
to expand to the right. I heard the argument many times why "change it -
it's not broken". Why move from c to basic - because programmers became more
productive for most applications. Why move to a interpretive language when c
is faster at execution. Why move from text based screens to GUI screens?

BTW my suggest does not mean I think wxWidgets should get rid of sizers. I'm
saying why can't wxPython do a better job of using them. Today we have
computers with dual-core CPU's. Graphic cards with more ram than some of my
computers from just a few years ago. I can think of nothing that can stop
wxPython from creating a better GUI system - accept desire.

John

···

On Monday 22 May 2006 22:13, Jeff Grimmett 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 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

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.

I've programmed on a few other platforms (including Amiga using three
different GUI toolkits, some quite similar to wx) and have to say that
sizers, while not being the absolute finest of all possible solutions, make
the most sense for a dynamic, flexible, professional-looking user interface
without much in the way of pain - provided one uses good habits.

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.

Back to this in a moment ...

OK, so you've got a complex UI you're putting together. You're using a
object-oriented language to do it with. Does it make even the slightest bit
of sense to put everything at the top level (the frame) and try to manage
it? No! Absolutely not! Here's an example of how I'd put together a program
with a working area (text input/output) and a series of controls.

FRAME
  - TOP PANEL
    - Left-hand (working) panel
    - Right-hand (control) panel

Aside from the frame, each of these elements are consisted of a
wx.Panelwith its own sizer, in its own class OUTSIDE the frame class.
Each distinct
component is (in source) presented in its own context.

Want a working example? Have a look at wx.Joystick in the wxPython demo
program. That example has a wx.GridBagSizer at the top level, and various
components below it. I did a large part of the work on that one (the
rewrite when we moved from wx* to wx.*) so it expresses my 'idiom' fairly
well. It breaks down like this:

* JoystickDemoPanel
  * InfoPanel (info pulled from the joystick driver)
  * JoyPanel (joystick positon display)
  * POVPanel (POV button position display)
  * AxisPanel (various axis position displays)
  * JoyButtons (state of all joystick buttons)

Each is consisted of one or more custom and standard controls (such as the
LED or crosshair displays) wrapped by a sizer. We even have a control
(Label) that is reused over and over again, again it's in its own little
class rather than mashed into the top level. I could have made it even
further nested (I often do) and it would still be coherent and
maintainable.

You can even break it up into seperate files - I have, for the more complex
ones (such as programs that have multiple notebook pages), which helps keep
the code readable and (again) maintainable.

So back to your example:

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.

Cake, relatively speaking, on just about any UI I've done in the past 5 or
so years, using this 'idiom'. Using the Joystick demo as an example, the
following would all be trivial:

- add an additional control to reset the driver's data
- Add another 16 button indicators
- Add another POV mode
- Rearrange the entire layout of the top panel

So: I don't think sizers are the problem here. I think the learning curve
is the problem, and time and experience using them. That and the approach
you might take in organizing your code. Maybe I'm wrong, but almost every
case I've seen like this has been because the code was a confusing mess due
to everything being smooshed together.

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

No, but if someone can beat sizers (say, with HTML table-like stuff) all I
can say is I'd buy one for a dollar.

[J_Grimmtooth]

I can and do use sizers. They are a pain - period. There is no reason I can
think of that prevents wxPython from moving forward to a new level of GUI
programming.

WHICH new level? I haven’t seen that clearly explained. I keep hearing how sizers are a pain - which I very much disagree with, having suffered many alternatives - but I’ve heard of nothing better.

So why would you be completely baffled at these sentiments?

Because I don’t share that opinion. Because I don’t see the problem.

Even if I couldn’t use sizers - I still believe wxPython can and should
improve the way sizers are used. And sizers are not perfect by a long shot!

Nothing’s perfect. But let’s discuss said imperfections since they don’t seem to be obvious to me at this point (or maybe I’m blind).

Most people let textboxes just expand when resizing forms. If I have seen
one I’ve seen a hundred screens where the programmer allowed the textbox just
to expand to the right. I heard the argument many times why "change it -

it’s not broken".

And this pertains to the shortcomings of sizers in what way? Use small words, I must be especially thick this morning.

I’m saying why can’t wxPython do a better job of using them.

Like? Did I miss the design spec here?

···

On 5/23/06, johnf jfabiani@yolo.com wrote:

–
“Ladies and gentlemen, there’s nothing to worry about … but please keep your heads down.” - The Muppet Show

Best,

Jeff

[Kevin_Ollivier4]

Hi Robin,

Christopher Barker wrote:

Robin Dunn wrote:

It's probably a good idea, although there should be an easy way to override the flags without needing to derive a new control class.

Why not just have the flags be an attribute you can alter?

In this scheme by the time you have a widget whose attributes you can alter it has already been added to the sizer and the sizer has it's own copy of the flags. So you would have to do it something like this:

parent.GetSizer().FindItem(widget).GetFlags().SetSomeFlagValue(value)

Again potential tab order problems come into play here, since you can't change the tab order nested nested controls and non-nested controls.

Is that changeable? the tab order approach is pretty limited in other ways already. Being able to set tab order arbitratily accross multiple Panels would be very cool!

I don't think it's changeable. Tab order is currently handled on a per-container window basis with some help from the platform, and in most cases with support for tabbing into and out of a container at the beginning and end of the container's tab-order. Having a tab-order that transcends containers and sub-wontainers with an arbitrary order of widgets would probably require a lot of work, lose the platform support and would likely be quite fragile when changes are made.

Sorry, I'm not sure I understand what you mean here. I'm guessing you mean that our current implementation for tab traversal is due to how some of the OS/toolkits work, but so far in googling I haven't been able to find a good explanation as to why the OS would care about container controls WRT handling navigation events. I can tell why wx cares, due to wxContainerControl::HandleOnNavigationKey, but I haven't found any information on why we had to do things that way or why traversing some tab order list (e.g. wxWindowList GetTabOrder()) would be significantly different than traversing GetChildren(). Any light you could shed on what could make the above problems occur or why things are setup this way would be greatly appreciated!

Thanks,

Kevin

···

On May 23, 2006, at 2:44 PM, Robin Dunn wrote:

--
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

[Ed_Leafe]

That's really not the job of sizers. In Dabo, you can use the textbox's DynamicFontSize property to dynamically change the font size. Just create your own algorithm for determining the proper size, and set DynamicFontSize to that method. If you want all your textboxes to behave that way, then just create a subclass with that algorithm, and add instances of the subclass to your form.

-- Ed Leafe
-- http://leafe.com
-- http://dabodev.com

···

On May 23, 2006, at 12:15 PM, johnf wrote:

I believe a textbox control should not grow/expand to fill space. It should
grow proportionly. If the developer believes the size should be 1/2 inch
long when using 10 point font on a 1024x768 resolution - then as the screen
gets bigger or the font changes so should the textbox. But today I doubt
that can happen so I'd just like to see a better way of using sizers.

[Chris_Barker1]

Only if you don't re-do how sizers work. For the sake of prototyping, that's probably what we'd have to do, but my "pie in the sky" idea is that the layout related properties of an individual Window in a sizer would be stored with the Window, like "BestSize" currently is. Then when a Sizer did it's layout thing, it would refer to the Windows it contains to figure out those properties. So:

AWindow.LayoutProperties.Border = 5
Sizer.Layout()

Would just work.

(I'm imagining that we would have a LayoutProperties object that would hold all that stuff, and that every Window (and SizerItem) would have one by default.

IN fact, multiple Windows could share a reference to the same LayoutProperties object, so you could change a bunch of stuff in one place. That would be kind of cool.

-Chris

···

On May 23, 2006, at 5:44 PM, Robin Dunn wrote:

So you would have to do it something like this:

parent.GetSizer().FindItem(widget).GetFlags().SetSomeFlagValue(value)

--
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

[Robin]

Jorgen Bodde wrote:

Hi Kevin,

It used to be called wxSizerProducer is that a better name? It however does not reall cover it. wxTextGUI is also not really THE name as it sounds like the GUI is created by some kind of text windows only like TurboVision

Any other suggestions? A search / replace is done easily.

wxGuiParser might also be a better name. What do you think?

I think it should at least have "Sizer" in the name since that is what it is creating. wxSizerFactory?

···

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