Surprising wxAuiNotebook split behaviour (Issue #26081)
rudolfwalter
rudolfwalter created an issue (wxWidgets/wxWidgets#26081)Description
When dragging the tabs of a wxAuiNotebook into a split state, multiple behaviours are possible:
A. There is only one pane (ie, no split), the new pane will take up half of the total width. The old pane shrinks to take the remaining half.
B. There are multiple panes, the new pane will take up a small amount of width. The rightmost pane shrinks enough to allow this. If the rightmost pane is not large enough, the one to the left of it will also shrink, etc.
C. There are multiple panes, the new pane will take up the same amount of width as the destination pane. Existing panes shrink like (B) above.
The above is mostly okay, but there are unexpected details:
1. If the rightmost pane is not large enough to yield sufficient space, it gets resized to zero. The user might think they lost their tabs. Ideally, there should be some minimum size (perhaps configurable).
1a. If then one starts resizing a pane, suddenly things snap into a new arrangement of widths. Perhaps the widths are calculated differently in multiple places? In some cases the result is reminiscent of behaviour (A), so maybe there is overlap with that too?
2. It is not intuitive to me why some drag destinations allow only behaviour (B), others allow only (C), and still others allow both (B) and (C).
2a. I'm not sure if behaviour (C) can make sense if the destination is larger than 50%. Currently it is allowed regardless.
3. Behaviour (A) seems generally useful: perhaps it should be possible to split a pane halfway even if there are multiple ones already.
Here is a screen capture showing some of the above:
https://github.com/user-attachments/assets/d312ee95-28b6-4a43-a999-a9a6565eac37
Platform and version information
- wxWidgets version: 3.3.0 and 3.3 master
- wxWidgets port: wxMSW
- OS: Windows 11 25H2
- other: 150% DPI
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
vadz left a comment (wxWidgets/wxWidgets#26081)Thanks for reporting this, the problem (1) is indeed pretty bad so I'll fix at least this.
For the rest, I'm not really sure what the correct/best behaviour would be. Do you already know this, by chance, e.g. do we have anything (MSVS, VS Code, ...) to compare with?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
rudolfwalter
rudolfwalter left a comment (wxWidgets/wxWidgets#26081)the problem (1) is indeed pretty bad so I'll fix at least this
Yeah, (1) is what one of my users actually stumbled on. The rest is what I saw while reproducing their report.
do we have anything (MSVS, VS Code, ...) to compare with?
I briefly checked MSVS, VSCode, and IntelliJ. Here is what I saw:
- MSVS:
- Adding or removing a pane maintains the sizes of the unchanged ones relative to each other (they all shrink or grow, proportionally).
- I'm unsure what the formula is for the size of a newly added pane. It seems to depend on the size of the source pane, and either the total available space or the number of splits. It does not depend on the destination location.
- VSCode:
- If you don't manually resize any of the panes, then adding/removing some will always keep their sizes equal.
- If you have some small panes and a large one, then focusing a small one will make it swap sizes with the large one.
- Otherwise it feels somewhat similar to MSVS, but also different. I would need to play with it more to understand better.
- Jetbrains IntelliJ:
- The new pane always takes half of the destination pane's space. Other panes are not affected.
- When removing a pane, either the one to its left or the one to its right takes all of the new space (I'm not sure how left/right is chosen).
So it seems like they all do different things.
I can see advantages and disadvantages in each of them:
- I personally like the proportions-preserving behavior of MSVS. I also like VSCode's default where if all you do is split a few times, the resulting panes all end up with the same size.
- I don't see much usefulness in MSVS's source-pane based sizing. VSCode's rules feel unintuitive, once user-resized panes are involved.
- IntelliJ's rules are very simple and intuitive, but I also feel like they are not the nicest default.
Note also that none of these apps allow the user to choose between two different behaviours for the same operation, like wx does with the modes (B) and (C) that I described originally. Overall, I feel like the extra flexibility allowed by wx is a good thing, but it should be more intuitive and consistent. For example, the two modes could be to either take global space contributed by all panes, or to take half of the destination pane.
Other people might have different opinions.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
vadz left a comment (wxWidgets/wxWidgets#26081)I've spent a lot of time on this but I just don't know how to fix this without major changes in wxAUI :-(
I can improve the code determining the new pane size, e.g. it's simple to do something like IntelliJ and just divide the size by 2 for every new pane — and this definitely works better than the current code in practice, although I suspect there may be some cases when it's not very intuitive because the panes are not arranged into a grid and we could have some weird layouts when the new split is much smaller than you might expect.
But this is not the worst problem. The real problem is that currently in wxAUI:
- We don't have any way to impose a minimum pane size (or, rather, we do, but it isn't applied when new panes are added).
- We don't have any mechanism to resize the existing panes when a new one is added.
Note that both are problems at wxAUI level and are not specific to wxAuiNotebook, they can just be seen much more easily with it as new panes can be created interactively.
So whatever size we use for the new split, sooner or later (and, in practice, pretty soon), you can create enough new panes to make one of them completely invisible. And hence we need to fix these problems, but wxAUI layout relies on using sizers with manually set minimum sizes for the sizers containing docks (not panes) and the code in wxBoxSizer trying to ensure that as many items as possible are visible even when there is not enough space for all of them doesn't work when item min size (and not best size) is explicitly set.
I'm afraid I'm going to have to abandon the idea of fixing this before 3.3.2 because there are several other things to do it before it as well and I still have no idea how to do this, which is a pretty good indicator that it will take me a lot of time to finish it... I'll sleep on this and hope that maybe I have some bright idea tomorrow, but right now I think I'll push just the code improving the new split size calculation, but it will do nothing to fix the problem (1).
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
rudolfwalter
rudolfwalter left a comment (wxWidgets/wxWidgets#26081)Unfortunate that the AUI code is inflexible in this regard, but understandable. No worries.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.