wxnotebook and sizers

wxPython Users
1

I have an app that uses wxContraints and I want to convert it to use wxSizers because wxConstraints is now depricated according to the docs.
   

If you prefer constraints then you can probably continue to do so without much risk that they will suddenly dissappear. They have been deprecated for a few years now and there still hasn't been any talk of removing them. It's more like saying that sizers are the preferred layout mechanisim, but since constraints don't hurt anything if they are still in the library I think they will probably remain.

OK, that's nice to know.
It seems that Constraints are more flexible. Correct?
i.e. with constraints you can place one object ANYWHERE with respect to another object, but with sizers it seems you can only place things in a grid pattern. Is that correct?
If so, then why are constraints deprecated, or sizers preferred ??? Just curious.
Is the idea to have multiple sizers within sizers within sizers for more complex layouts???
Does that give the same flexibility as constraints???

Should I be using wxNotebookSizer or some other combination of wxNotebook and wxSizer ???
   

If you are using 2.5.2+ then the notebook sizer is redundant and doesn't need to be used at all. This is because the notebook now has a proper DoGetBestSize method which calculates the size needed based on the best size of all the notebook pages and this is used internally by the sizers just like any other control they manage. (The wxNotebookSizer essentially does the same thing and was originally added because the notebook class wasn't consistent across platforms about doing that size calculation for itself.) So to answer your questions, the contents (the page windows) of a notebook will always be resized to fill the client area of the notebook, even if the page is another notebook. If the page window is a panel (or other container) that has it's own sizer then that sizer is used to calculate the page's best size. The notebook will use the best size of all its page windows to calculate its own best size. The sizer that is managing the size/position of the notebook can be told to resize it to be larger than the notebook's best size if that is what you need. Does that answer your questions?

I'm using 2.4 but I did notice that the 2.5 docs do not mention wxNotebookSizer.
So if I have an app that I want to work with 2.4 AND 2.5 how do I do it?
My first thought was to use wxNotebookSizer and that it would basically be a wrapper class in 2.5, but it doesn't look like it even exists in 2.5.
The other way is to just keep on using contstraints :slight_smile:

Thanks,
Brendan Simon.

2

Brendan Simon wrote:

I have an app that uses wxContraints and I want to convert it to use wxSizers because wxConstraints is now depricated according to the docs.

If you prefer constraints then you can probably continue to do so without much risk that they will suddenly dissappear. They have been deprecated for a few years now and there still hasn't been any talk of removing them. It's more like saying that sizers are the preferred layout mechanisim, but since constraints don't hurt anything if they are still in the library I think they will probably remain.

OK, that's nice to know.
It seems that Constraints are more flexible. Correct?

Somewhat, but also much more complex for most people once they "get" sizers.

i.e. with constraints you can place one object ANYWHERE with respect to another object, but with sizers it seems you can only place things in a grid pattern. Is that correct?

Essentially, but with spacers, stretchable items, borders, nested sizers, etc. you can do probably 95% (off the cuff estimate that was made last time this was discussed on wx-dev) of what you could do with constraints.

If so, then why are constraints deprecated, or sizers preferred ??? Just curious.

Mainly because the core developers felt that fully supporting more than one style of layout mechanism is a little silly. Interestingly one of the core devs was very vocal against sizers when they were first checked in to CVS (using the more than one mechanism argument) and was a very heavy user of layout contraints in his own projects. Several months later he was the one that was declaring constraints to be deprecated.

My own point of view is that the heirachical nature of sizers is easier for people to wrap their heads around once they learn to think about the layout in a somewhat inside-out fashion. Also, most of the layout tool developers are supporting sizers over constraints.

Is the idea to have multiple sizers within sizers within sizers for more complex layouts???

Yes.

Does that give the same flexibility as constraints???

Pretty much. IIRC it was estimated that all the remaining 5% or so of the layouts could be slightly tweaked to be doable with sizers without impacting the basic look or functionality of the app.

I'm using 2.4 but I did notice that the 2.5 docs do not mention wxNotebookSizer.
So if I have an app that I want to work with 2.4 AND 2.5 how do I do it?
My first thought was to use wxNotebookSizer and that it would basically be a wrapper class in 2.5, but it doesn't look like it even exists in 2.5.

It's still there in 2.5, but it could dissappear before 2.6 (or more likely in the 2.7 series.) So you could probably still use it for now and then just remove it when you don't need to support 2.4 any more, or you could test the version at runtime and use it only if running on 2.4.

The other way is to just keep on using contstraints :slight_smile:

Yep.

···

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