Change in wxPersistentRegisterAndRestore behaviour with wxAui

[jon bird]

Hi,

There appears to have been a change in behaviour with
wxPersistentRegisterAndRestore with wxAui managed windows between 3.2x
and 3.3x.

Prior to 3.3, wxPersistentRegisterAndRestore preserves the sizes of the
wxAui panes associated with the main window, that is any changes the
user makes to them, will be retained the next time the app is started.

With 3.3, that doesn't appear to be the case, the panes always revert
to a default size.

It's probably not going to be too difficult to introduce some code to
manage this myself however I'm interested to know whether this is by
design or has been inadvertently triggered as a result of another
change.

Rgs,

Jon.

--
--
== jon bird - software engineer
== <reply to address _may_ be invalid, real mail below>
== <reduce rsi, stop using the shift key>
== posted as: news 'at' onasticksoftware 'dot' co 'dot' uk

[Vadim Zeitlin]

On Fri, 7 Nov 2025 10:57:39 +0000 jon bird wrote:

jb> There appears to have been a change in behaviour with
jb> wxPersistentRegisterAndRestore with wxAui managed windows between 3.2x
jb> and 3.3x.

As usual, it would be great to have a minimum patch reproducing the
problem in the aui sample. Could you please make one and attach it to an
issue?

Thanks,
VZ

--
TT-Solutions: wxWidgets consultancy and technical support
https://www.tt-solutions.com/

[jon bird]

On Fri, 7 Nov 2025 14:46:41 +0100
Vadim Zeitlin <va...@wxwidgets.org> wrote:

> On Fri, 7 Nov 2025 10:57:39 +0000 jon bird wrote:
>
> jb> There appears to have been a change in behaviour with
> jb> wxPersistentRegisterAndRestore with wxAui managed windows between

> jb> 3.2x and 3.3x.

>
> As usual, it would be great to have a minimum patch reproducing the
> problem in the aui sample. Could you please make one and attach it to
> an issue?
>
> Thanks,
> VZ
>

At this point, it's more just a query on why the behavior has changed
rather than highlighting a bug or problem. It could well be that the
original behavior was deemed not correct and has been fixed to operate
as expected in 3.3.

Regardless, I've spent about an hour or so fiddling around with the
auidemo sample and not really got anywhere. Even after adding a call to
'wxPersistentRegisterAndRestore' in the initialization procedure (such
that the top level window itself now comes up at the previous position
& size), the aui panels always reset to a default size in both 3.2.7
and 3.3.1.

There's quite a lot going on in that demo & my application is also
quite complex in terms of setting up the top level windows. At which
point it's turns into needle in a haystack scenario because from my
perspective it could be literally any subtle difference in terms of how
the windows and sizers are setup which triggers the change in behavior.
I may spend a little more time fiddling around with some of the
settings in my code (which at least I'm familiar with) however it's not
that big a deal of an issue so I'll either leave with it at it is or
work around it.

[Vadim Zeitlin]

On Fri, 7 Nov 2025 15:13:26 +0000 jon bird wrote:

jb> On Fri, 7 Nov 2025 14:46:41 +0100
jb> Vadim Zeitlin <va...@wxwidgets.org> wrote:
jb>

jb> > On Fri, 7 Nov 2025 10:57:39 +0000 jon bird wrote:
jb> >

jb> > jb> There appears to have been a change in behaviour with
jb> > jb> wxPersistentRegisterAndRestore with wxAui managed windows between
jb> > jb> 3.2x and 3.3x.
jb> >
jb> > As usual, it would be great to have a minimum patch reproducing the
jb> > problem in the aui sample. Could you please make one and attach it to
jb> > an issue?
jb> >
jb> > Thanks,
jb> > VZ
jb> >
jb>
jb> At this point, it's more just a query on why the behavior has changed
jb> rather than highlighting a bug or problem.

Sorry for not saying it explicitly, but there has been no intentional
change to this behaviour.

jb> Regardless, I've spent about an hour or so fiddling around with the
jb> auidemo sample and not really got anywhere.

If it's simpler to reproduce in the minimal sample, this would work too.
But I'd need to have _something_ to work with, i.e. see this change in
behaviour by being able to run some code which works differently now from
how it worked before.

Regards,

[jon bird]

On Fri, 7 Nov 2025 16:35:17 +0100
Vadim Zeitlin <va...@wxwidgets.org> wrote:

> On Fri, 7 Nov 2025 15:13:26 +0000 jon bird wrote:
>
> jb>

> jb> At this point, it's more just a query on why the behavior has

> jb> changed rather than highlighting a bug or problem.

>
> Sorry for not saying it explicitly, but there has been no intentional
> change to this behaviour.
>
> jb> Regardless, I've spent about an hour or so fiddling around with

> jb> the auidemo sample and not really got anywhere.

>
> If it's simpler to reproduce in the minimal sample, this would work
> too. But I'd need to have _something_ to work with, i.e. see this
> change in behaviour by being able to run some code which works
> differently now from how it worked before.
>
> Regards,
> VZ
>

Right, ok please ignore pretty much everything I've said. Transpires
I'd forgotten that I'd actually implemented a wxPersistentObject
instance which handles the preservation of the window (which just
happens to be in an wxAui pane). So it's nothing to do with wxAUI
(apologies for that).

The problem therefore appears to be around why that wxPersistentObject
isn't restoring the window (in this case) width properly. All it's doing
is making a call to:

SetSize(wxDefaultCoord,wxDefaultCoord,Width,wxDefaultCoord);

and is still being triggered correctly however for some reason the size
change is being ignored.

I'll need to dig a bit further into this, in the meantime thanks for
the assistance and apologies again for the confusion.

[jon bird]

Now I've got my head screwed on properly, let me rephrase the question:

Whilst I'm seeing this issue when using the wxPersistentObject
framework, that's all working correctly, it seems more a change in
behavior where setting the initial window size is concerned.

As I mentioned yesterday, all the wxPersistentObject::Restore method is
doing is calling SetSize on the window, if I move this call into the
constructor itself, I see the same behavior.

When the window is initially created, the framework (presumably through
SetSizerAndFit) has figured out an optimum minimum size. If I call
SetSize with a value that is *greater* than this figure, that is honored
correctly in both 3.2x and 3.3.1 - the window size increases.

However if I call SetSize with a figure that is *less* than this minimum
size, this seems to be ignored in 3.3.1 and it always uses it's own
pre-determined size. Whereas in 3.2.x (and earlier), I could reduce the
window size.

Having played around with re-ordering things around SetSizerAndFit,
using some of the other size calls, I've not been able to find any way
of overriding the initial minimum window size (this despite the fact I
can happily manually shrink it with the UI once the app is running).

Rgs,


Jon.

[Vadim Zeitlin]

On Sat, 8 Nov 2025 09:56:36 +0000 jon bird wrote:

jb> However if I call SetSize with a figure that is less than this minimum
jb> size, this seems to be ignored in 3.3.1 and it always uses it's own
jb> pre-determined size. Whereas in 3.2.x (and earlier), I could reduce the
jb> window size.

Which window exactly do you call SetSize() on?

[jon bird]

On Sat, 8 Nov 2025 15:15:04 +0100
Vadim Zeitlin <va...@wxwidgets.org> wrote:

> On Sat, 8 Nov 2025 09:56:36 +0000 jon bird wrote:
>
> jb> However if I call SetSize with a figure that is less than this

> jb> minimum size, this seems to be ignored in 3.3.1 and it always
> jb> uses it's own pre-determined size. Whereas in 3.2.x (and
> jb> earlier), I could reduce the window size.

>
> Which window exactly do you call SetSize() on?
>
> Regards,
> VZ
>

Take a look at this picture:

https://www.onasticksoftware.co.uk/images/playout4_2018-09-07_10-02-09.png

There are 3 aui panels, those 2 strips of buttons on each side &
everything else in the middle one. The width of those button strips can
of course be adjusted by the user, the desired behaviour is that the
width is then preserved between sessions.

Those button strips are pretty simple - literally a wxFrame with a
wxBoxSizer holding the buttons (and a wxGridSizer for the two at the
bottom).

When the app closes, I call GetSize on each of the wxFrames & save the
width. When it starts up, I call SetSize (as described in my previous
mail) on them, specifying the previously saved width.

[Vadim Zeitlin]

On Sat, 8 Nov 2025 16:30:22 +0000 jon bird wrote:

jb> Take a look at this picture:
jb>
jb> https://www.onasticksoftware.co.uk/images/playout4_2018-09-07_10-02-09.png
jb>
jb> There are 3 aui panels, those 2 strips of buttons on each side &
jb> everything else in the middle one. The width of those button strips can
jb> of course be adjusted by the user, the desired behaviour is that the
jb> width is then preserved between sessions.
jb>
jb> Those button strips are pretty simple - literally a wxFrame with a
jb> wxBoxSizer holding the buttons (and a wxGridSizer for the two at the
jb> bottom).

This can't be a wxFrame or I'm completely missing something here.

jb> When the app closes, I call GetSize on each of the wxFrames & save the
jb> width. When it starts up, I call SetSize (as described in my previous
jb> mail) on them, specifying the previously saved width.

FWIW the usual way of restoring AUI layout was to save and then reload a
"perspective", which is just a simple string. In 3.3 there is a new and
much more flexible mechanism using wxAuiSerializer and wxAuiDeserializer.
Nevertheless calling SetSize() should still work. I still don't understand
what do you call it on, however.

[jon bird]

On Sat, 8 Nov 2025 17:51:05 +0100
Vadim Zeitlin <va...@wxwidgets.org> wrote:

> On Sat, 8 Nov 2025 16:30:22 +0000 jon bird wrote:
>
> jb> Take a look at this picture:
> jb>
> jb> https://www.onasticksoftware.co.uk/images/playout4_2018-09-07_10-02-09.png
> jb>
> jb> There are 3 aui panels, those 2 strips of buttons on each side &
> jb> everything else in the middle one. The width of those button

> jb> strips can of course be adjusted by the user, the desired
> jb> behaviour is that the width is then preserved between sessions.

> jb>
> jb> Those button strips are pretty simple - literally a wxFrame with a
> jb> wxBoxSizer holding the buttons (and a wxGridSizer for the two at

> jb> the bottom).

>
> This can't be a wxFrame or I'm completely missing something here.
>

No, it's me, I'm still on something - wxPanel not wxFrame (it's been a
long week).

> jb> When the app closes, I call GetSize on each of the wxFrames &

> jb> save the width. When it starts up, I call SetSize (as described
> jb> in my previous mail) on them, specifying the previously saved
> jb> width.

>
> FWIW the usual way of restoring AUI layout was to save and then
> reload a "perspective", which is just a simple string. In 3.3 there
> is a new and much more flexible mechanism using wxAuiSerializer and
> wxAuiDeserializer. Nevertheless calling SetSize() should still work.
> I still don't understand what do you call it on, however.
>
> Regards,
> VZ
>

I'll take a look at those tomorrow.

Thanks and again, apologies for the confusion.

[Vadim Zeitlin]

On Sat, 8 Nov 2025 19:03:52 +0000 jon bird wrote:

jb> No, it's me, I'm still on something - wxPanel not wxFrame (it's been a
jb> long week).

Calling SetSize() on wxPanel should definitely work. If it seems not to,
it must be due to something else resetting this size later.

[jon bird]

On Sat, 8 Nov 2025 23:13:23 +0100
Vadim Zeitlin <va...@wxwidgets.org> wrote:

> On Sat, 8 Nov 2025 19:03:52 +0000 jon bird wrote:
>
> jb> No, it's me, I'm still on something - wxPanel not wxFrame (it's

> jb> been a long week).

>
> Calling SetSize() on wxPanel should definitely work. If it seems not
> to, it must be due to something else resetting this size later.
>
> Regards,
> VZ
>

Attached is a diff which demonstrates this problem against the auidemo.
All it really does is shrink down the width of the Tree Pane on the
left hand side.

When built against 3.3.1, it makes no difference however with 3.2.7 you
can see the window width has been shrunk (not sure if you can actually
apply the patch directly to the 3.2 sample as there have been quite a
few changes however it's a tiny change so easy enough to do by hand).

I had a peruse of the perspective classes you directed me at yesterday,
including wxAuiSerializer however I couldn't see anything obvious in
the wxAuiPaneLayoutInfo structure which would be used to set the size
of the pane - unless it's the dock_size attribute from
wxAuiDockLayoutInfo.

Rgs,

[Vadim Zeitlin]

On Sun, 9 Nov 2025 08:58:52 +0000 jon bird wrote:

jb> Attached is a diff which demonstrates this problem against the auidemo.

For the record, please use "diff -u" (or git-diff) to make unified diffs
which are generally preferred to the "normal" ones.

jb> All it really does is shrink down the width of the Tree Pane on the
jb> left hand side.

Yes, and I can see the difference in behaviour even without the other
changes, so I'm not sure why they were included.

jb> When built against 3.3.1, it makes no difference however with 3.2.7 you
jb> can see the window width has been shrunk

I didn't build it against 3.3.1, but when building it against trunk I need
to use

tree->SetInitialSize(wxSize(92, -1));

to make this size be taken into account (or almost, see below). I admit
that I'm puzzled by this because I don't remember any changes to this since
3.2, but apparently something did change. Still, SetInitialSize() provides
a simple enough workaround.

Note that the tree still won't be 92px wide in the sample because it won't
be made smaller than its best size which is 140px on my system (which is
roughly the length of the root item label plus the icon size and margins).
This change is desirable because it doesn't look right to truncate the tree
contents.

jb> I had a peruse of the perspective classes you directed me at yesterday,
jb> including wxAuiSerializer however I couldn't see anything obvious in
jb> the wxAuiPaneLayoutInfo structure which would be used to set the size
jb> of the pane - unless it's the dock_size attribute from
jb> wxAuiDockLayoutInfo.

The idea is that you don't set any sizes manually when using
wxAuiSerializer as it preserves the layout (and sizes) chosen by the user.
To specify the initial size, when there is no saved layout to restore, you
can create the windows with their desired minimum size or, if this is
impossible for some reason, use SetInitialSize() to specify the minimum
sizes.

[jon bird]

On Tue, 11 Nov 2025 18:56:49 +0100
Vadim Zeitlin <va...@wxwidgets.org> wrote:

> On Sun, 9 Nov 2025 08:58:52 +0000 jon bird wrote:
>
> jb> Attached is a diff which demonstrates this problem against the

> jb> auidemo.

>
> For the record, please use "diff -u" (or git-diff) to make unified
> diffs which are generally preferred to the "normal" ones.
>

Duly noted, I was in a bit of a rush Sunday morning so it ended up
being something quickly generated on a Windows box.

> jb> All it really does is shrink down the width of the Tree Pane on

> jb> the left hand side.

>
> Yes, and I can see the difference in behaviour even without the other
> changes, so I'm not sure why they were included.
>
> jb> When built against 3.3.1, it makes no difference however with

> jb> 3.2.7 you can see the window width has been shrunk

>
> I didn't build it against 3.3.1, but when building it against trunk
> I need to use
>
> tree->SetInitialSize(wxSize(92, -1));
>
> to make this size be taken into account (or almost, see below). I
> admit that I'm puzzled by this because I don't remember any changes
> to this since 3.2, but apparently something did change. Still,
> SetInitialSize() provides a simple enough workaround.
>
> Note that the tree still won't be 92px wide in the sample because it
> won't be made smaller than its best size which is 140px on my system
> (which is roughly the length of the root item label plus the icon
> size and margins). This change is desirable because it doesn't look
> right to truncate the tree contents.
>

I can see the effect in the demo code and understand the rationale on
why it wouldn't shrink any further. Unfortunately this didn't have the
same effect with my application, the window size always reverts to it's
original size.

Here's the default layout that gets generated.

https://www.oasw.co.uk/public/bwall-original.png

Looking at it, there's plenty of space in the x direction. I would
expect the limits to be either at the point the text on the buttons at
the bottom starts to be truncated OR (possibly) the width of the
longest string in the drop down. However you can see from this:

https://www.oasw.co.uk/public/bwall-resize.png

I can manually shrink it further without hitting those limits. So
something else is imposing an artificial minimum width here.

> jb> I had a peruse of the perspective classes you directed me at

> jb> yesterday, including wxAuiSerializer however I couldn't see
> jb> anything obvious in the wxAuiPaneLayoutInfo structure which would
> jb> be used to set the size of the pane - unless it's the dock_size
> jb> attribute from wxAuiDockLayoutInfo.

>
> The idea is that you don't set any sizes manually when using
> wxAuiSerializer as it preserves the layout (and sizes) chosen by the
> user. To specify the initial size, when there is no saved layout to
> restore, you can create the windows with their desired minimum size
> or, if this is impossible for some reason, use SetInitialSize() to
> specify the minimum sizes.
>

At the moment, the only thing I'm saving is the width of the window.
What isn't clear to me looking at wxAuiSerializer is how I'd replicate
that behavior - as in which component in the structure represents the
panel width? Anything else is really "don't care" it can use the system
default.