Provide a way to store AUI layouts in any custom format

[vadz]

Add wxAuiSerializer and wxAuiDeserializer classes and SaveLayout() and LoadLayout() functions in wxAuiManager using them.

Show how these classes can be used to use XML for storing AUI layout in the sample.

See #24225.

---

This still needs to be documented and the example serializer might be moved to the library itself if we think it can be useful. It also should use DIPs as discussed in #24225.

TODO:

• Rebake
• Document
• Use DIPs

[vadz]

@craftyjon @marekr @imciner2 Sorry for mass-tagging but would you have any feedback about this? I'd like to go ahead and finish this, but it would be nice to check that it is fit for purpose, i.e. can be used in KiCad instead of the current serialization system, first. TIA!

[craftyjon]

Looks good to me! Thanks!

[marekr]

LGTM

[vadz]

I've implemented automatic support for saving (and restoring) all coordinates as DIPs as this is the only thing which really makes sense and it seems better to do it, even if this is inconsistent with the rest of wx API, than keep doing the wrong thing for consistency.

Please let me know if anybody has objections to this, but personally I'd rather try to find some way to use DIPs in wxPersistentTLW too in backwards-compatible way.

Any other comments are also welcome, of course!

[utelle]

I've implemented automatic support for saving (and restoring) all coordinates as DIPs as this is the only thing which really makes sense and it seems better to do it, even if this is inconsistent with the rest of wx API, than keep doing the wrong thing for consistency.

It is really great to have this support of saving and restoring AUI layouts in wxWidgets. And IMHO using DIPs is exactly the right thing to do. 👍

Please let me know if anybody has objections to this, but personally I'd rather try to find some way to use DIPs in wxPersistentTLW too in backwards-compatible way.

I'm fully in favor of using DIPs, even if it were not backwards-compatible.

[craftyjon]

Using DIPs sounds good to me.

personally I'd rather try to find some way to use DIPs in wxPersistentTLW too in backwards-compatible way.

Does it need to be backwards-compatible? If a client application is working around the current behavior by doing DPI-scaling themselves, it seems fine to me for the client just gate that on checking the wxWidgets version. In general I would prefer wx made breaking changes (in major versions) where necessary to improve things, rather than try to avoid any breakage and preserve old/potentially-broken behavior.

[vadz]

Using DIPs sounds good to me.

Thanks, I count two votes in favour as sufficient, so let's do it like this.

personally I'd rather try to find some way to use DIPs in wxPersistentTLW too in backwards-compatible way.

Does it need to be backwards-compatible?

It would be nicer if it did because it's going to be hard to find all the places that you need to update because if you just change wxPersistentTLW to assume the coords are in DIPs, all the existing code will keep compiling and running -- but the windows will get restored twice bigger than needed in high DPI.

And I think it should be possible to keep compatibility relatively easily. I just hesitate between:

1. Creating a new key with the meaning "this uses DIPs".
2. Coming up with the new alternative names for x, y, w and h fields that would use DIPs (with fallback on the existing fields if the new ones don't exist).

[vadz]

Funny how testing can be useful. After checking the current behaviour under wxMSW, I've realized that we already use DIPs there even though we don't do anything for this in our code: ::GetWindowPlacement() returns values in DIPs on my system using 200% scaling, so there is actually really nothing to do here.

[vadz]

Also, while testing this, I've realized that saving/restoring layout doesn't actually restore the window sizes.

I think this should be done but it doesn't seem to be trivial to implement it, at least just saving/restoring wxAuiPaneInfo::rect is not enough because this size is overridden by the size computed by the sizers when redoing the layout. I'm going to try to do it, however, as it seems wrong to lose the previously used sizes when restoring a previous layout.

[craftyjon]

Wouldn't it be possible to re-apply the saved size after the initial size is computed? This is what we end up doing as a client application if wx doesn't support save/restore of size internally.

[vadz]

Wouldn't it be possible to re-apply the saved size after the initial size is computed?

I wanted to reapply the saved size even before/instead of computing the new size to avoid wasting time doing it, but I guess we can indeed do it later too, as you're probably not going to restore AUI layouts thousands time per second...

This is what we end up doing as a client application if wx doesn't support save/restore of size internally.

If you agree to relicense this code under wx licence, I could just copy it instead of rewriting it, please let me know if I can do it (and where this code is). TIA!

[craftyjon]

If you agree to relicense this code under wx licence, I could just copy it instead of rewriting it, please let me know if I can do it (and where this code is). TIA!

Sorry I was not clear, I just mean that we would do such a thing in the future if wxWidgets doesn't do it. We have various places that do something like this, but not for wxAUI in particular (well, we have some hacks that do some of it, but I think it's not a good universal solution)

To be honest I'm not sure our code should be copied, there are a number of places where we have added "hacks" that seem to work around differences in behavior between different wx platforms that maybe aren't relevant anymore in 3.2, etc. It all needs a rewrite on our side too.