Resizing bugs in wxAuiManager

[seand]

Hi,

I'm developing an application that uses your wxAui library, and I'd like to say that it's great to have in wxWidgets; thank you for it. I've noticed a few problems with resizing in wxAuiManager, so I searched around to see how to fix them. I found the following thread:

viewtopic.php?f=16&t=582

which was created by Rick. This patch helped a couple problems, but it didn't address some of the crucial resizing bugs in wxAui, such as obeying minimum and maximum pane sizes. So, for the past couple of days, I've been adding onto and tweaking his patch in hopes that I can submit it and get it applied. I'm doing this mostly because the problems are also in wxAuiNotebook (which I'm also using), because of its underlying wxAuiManager, which is harder for me to fix by just creating a derived wxAuiNotebook class and fixing them myself. I've found the best solution for everyone is to try to get it patched up in wxAuiManager so both that and the notebook are fixed.

Before I can finish what I've started, though, I have to get a better idea of how the developers want wxAui's core GUI principles to be. So far, I've been basing everything off the idea that all minimum and maximum sizes should be completely respected in every case (resizing docks, resizing the managed window, etc.), and I think this is the best way to go if we consider some of the interesting problems that could arise.

One example is if you have two panes that are docked in the same layer and row but at positions 0 and 1 (let's say the dock's direction is wxAUI_DOCK_BOTTOM). If both of their minimum widths are 100, and the total width of the managed frame is 200, that's all fine and dandy (let's ignore border and sash sizes for this example). If one of them is undocked, though, and the frame's width is moved to be smaller than 200, and then that pane redocked to the bottom, then we have a problem. I think the frame should automatically be resized to 200 at this point, but someone explained to me that basic GUI principles state you shouldn't programmatically resize a top-level window after it has been shown. This makes sense, but I more strongly believe that if you have maximum and minimum sizes for something they should be obeyed in all cases, not just some. Staying with this example, in the current wxAui implementation, if we do this then the managed frame isn't resized when the pane is redocked. However, when you click the sash in between the panes once it resizes based on each pane's minimum size, and some unexpected behavior results. I think it's best if restrictions are maintained in all cases and not just some, so that problems don't arise in rare situations.

However, this decision is obviously not up to me, and since I'm trying to create a patch, I thought it best I get thoughts from the developers. So, I'd like to know what you think about all this and how minimum and maximum sizes should be handled. This not only includes resizing the managed frame but also resizing a dock that is perpendicular to the target pane(s). For example, if we are manipulating the sash of a dock on the bottom, we have to be sure to obey the minimum sizes of all the panes in the center docks as well as the panes in the docks on the left and right.

- seand

[seand]

Never mind about all that; I really don't have time to fix more than what I've already done, so I'll just be posting the patch in the other board along with what it fixes and what still needs to be fixed (as far as resizing docks and panes goes).

[GlennStpierre]

Hey Seand have you completed and posted the patch yet. If so where can we access it? I'm a newb here so if you've already posted it could you point me in the right direction. Cheers.

[Ken]

I think this may be what you're looking for:

viewtopic.php?f=16&t=610&p=1671

[jojosoto]

Did this patch ever get approved or modified by Kirix? It is awesome to see the work of the past live on in the way this patch has been able to.

[fredmad]

i has already made use of this patch. not certain abbout approval or modification by Kirix. believe, not..