wxAui problem on the Mac (floating panes appear on top of frame windows that do not own them).

121 views
Skip to first unread message

Tony Kennedy

unread,
Apr 4, 2021, 1:57:11 AMApr 4
to wx-users
Hello all,

I'm posting here after trying the forum (and someone said it might be better here).

I've got an application where each workspace window has a number of floating panes (all managed by a wxAuiManager).

The problem is that if I have two windows open on the Mac, each with a floating pane, the floating panes appear on top of all other windows. It's as if the floating panes have the wxSTAY_ON_TOP style, but they should only stay on top of their parent window (not other wxFrame windows).

All works fine on Windows, a pane floats on top of it's own parent only.

I've tried setting the Layer during the creation of the panes, but that didn't make any difference. Also cannot see anything in the documentation that is helping me.

Any ideas?

Thanks in advance,

Tony.

PS.

Some more info if it helps.

If I create a wxMiniFrame, that also floats on top of all other wxFrame windows (not just it's parent).

If I create a modeless dialog, that behaves correctly, it only floats on it's parent.

Floating panes can still only dock into their parent, but they can dock on a parent window hidden by a different frame (it's as if the top level window is invisible to the docking code).
AuiBugDemo.zip

Tony Kennedy

unread,
Apr 4, 2021, 1:59:12 AMApr 4
to wx-users
To demonstrate, run the attached project. It creates two wxFrame windows, each has a floating Aui pane and a dialog.

If you move the two parent frames and child floating panes, no matter which parent frame you click, the child floating panes appear on top of both wxFrame windows.

I hope this makes sense.

Vadim Zeitlin

unread,
Apr 4, 2021, 7:26:04 AMApr 4
to wx-u...@googlegroups.com
On Sat, 3 Apr 2021 22:57:11 -0700 (PDT) Tony Kennedy wrote:

TK> The problem is that if I have two windows open on the Mac, each with a
TK> floating pane, the floating panes appear on top of all other windows.

Do you see this problem in the aui wxWidgets sample too? If you don't, can
you please try modify the sample in the smallest possible way to reproduce
the problem there?

In any case, please mention your wxWidgets and macOS versions.

Thanks,
VZ

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

Tony Kennedy

unread,
Apr 4, 2021, 8:20:15 AMApr 4
to wx-users
Whoops, I should have mentioned, I'm on MacOS 11.2.3 (Big Sur), and it's an Apple Silicon machine. Running wxWidgets 3.1.4.

I'll see if I can find the Aui demo. That code I uploaded, I found that in a bug report and just used it (my own app shows the same behaviour).

Vadim Zeitlin

unread,
Apr 4, 2021, 8:23:39 AMApr 4
to wx-u...@googlegroups.com
On Sun, 4 Apr 2021 05:20:15 -0700 (PDT) Tony Kennedy wrote:

TK> Whoops, I should have mentioned, I'm on MacOS 11.2.3 (Big Sur), and it's an
TK> Apple Silicon machine. Running wxWidgets 3.1.4.

The sample is under samples/aui of wxWidgets sources. If you built
wxWidgets yourself, you can build it by just doing "make -C samples/aui" in
the same directory where you built wxWidgets. If not, you need to use
"make -C samples/aui -f makefile.unx" from the source directory itself.

Regards,

Tony Kennedy

unread,
Apr 4, 2021, 8:37:31 AMApr 4
to wx-users
Found it, I do see the same behaviour.

I've got a modified auidemo.cpp, will that be enough or shall I upload my Xcode project? All I've done is modify it so that two "MyFrame" windows are created, and the tree control starts floated instead of docked. The two tree controls always appear on top of everything. And if you make Frame1 the active frame, you can take tree control 2 (from frame 2) and still dock it into frame2 through frame 1.

I hope this is making sense. If Frame2 is made active, it (and it's floating panes) should appear on top of any floating panes from Frame1.

Thanks in advance,

Tony.
auidemo.cpp

Vadim Zeitlin

unread,
Apr 4, 2021, 8:42:15 AMApr 4
to wx-u...@googlegroups.com
On Sun, 4 Apr 2021 05:37:31 -0700 (PDT) Tony Kennedy wrote:

TK> Found it, I do see the same behaviour.
TK>
TK> I've got a modified auidemo.cpp, will that be enough or shall I upload my
TK> Xcode project?

No, thanks, no need for the Xcode project.

TK> All I've done is modify it so that two "MyFrame" windows are
TK> created, and the tree control starts floated instead of docked. The two
TK> tree controls always appear on top of everything.

Are both changes required to reproduce the bug? Or is just starting in the
floating state enough?

TK> And if you make Frame1 the active frame, you can take tree control 2
TK> (from frame 2) and still dock it into frame2 through frame 1.

Could you please show a patch (how to do it is explained in details at
https://trac.wxwidgets.org/wiki/HowToSubmitPatches but if you use Git, just
running "git diff sampes/auidemo" is all you need to do) with your changes?

In fact, the best would probably be to open a new ticket on Trac and
attach the patch there, as I'm not sure at all if I can actually fix this
(Z-order/layers/whatever under Mac is not really something I understand
well), but at least we'll keep a record of the problem and will be able to
get back to it later.

Thanks,

Tony Kennedy

unread,
Apr 4, 2021, 8:48:48 AMApr 4
to wx-users
>> Are both changes required to reproduce the bug? Or is just starting in the
>> floating state enough?
The only real change is to create two MyFrame windows. You can undock the tree pane from both windows and see the behaviour. I made the additional changes in an attempt to save others time when running the code.

>> Could you please show a patch (how to do it is explained in details at
>> https://trac.wxwidgets.org/wiki/HowToSubmitPatches but if you use Git, just
>> running "git diff sampes/auidemo" is all you need to do) with your changes?
>> In fact, the best would probably be to open a new ticket on Trac and
>> attach the patch there, as I'm not sure at all if I can actually fix this
>> (Z-order/layers/whatever under Mac is not really something I understand
>> well), but at least we'll keep a record of the problem and will be able to
>> get back to it later.

I'll try. I've had limited success creating patches in the past :).

All the best,

Tony.


Tony Kennedy

unread,
Apr 4, 2021, 9:05:15 AMApr 4
to wx-users
Done (I hope). Ticket  19129

Vadim Zeitlin

unread,
Apr 4, 2021, 9:38:19 AMApr 4
to wx-u...@googlegroups.com
On Sun, 4 Apr 2021 06:05:15 -0700 (PDT) Tony Kennedy wrote:

TK> Done (I hope). Ticket 19129
TK>
TK> https://trac.wxwidgets.org/ticket/19129

Thanks, the ticket is useful and I do see the behaviour you mention, but,
as I wrote there, it's not going to be simple to change it and, in fact,
I'm not even 100% sure if we want to do it.

As you're using Xcode, I wonder how do its floating windows behave? I.e.
don't they also stay on top of all the other normal windows and not just on
top of their parent?

Regards,

Tony Kennedy

unread,
Apr 4, 2021, 10:56:15 AMApr 4
to wx-users
>> Thanks, the ticket is useful and I do see the behaviour you mention, but,
>> as I wrote there, it's not going to be simple to change it and, in fact,
>> I'm not even 100% sure if we want to do it.
I think the correct behaviour would be to use the style from a modeless dialog in any floating AUi windows. Or at least have the option of changing the wxMiniFrame window so it's level is the same as a modeless dialog (I'd give it a go if I knew how).

>> As you're using Xcode, I wonder how do its floating windows behave? I.e.
>> don't they also stay on top of all the other normal windows and not just on
>> top of their parent?
I only use Xcode as I don't know any alternatives (I hate using it). Xcode does not really have any floating panes that I'm aware of.

I've found an example though on OSX, Microsoft Excel. If you have two spreadsheets open and insert a formula in one, you get a docked formula editor. If you undock this and click on the other spreadsheet, the formula box stays with it's parent. Another difference here is that the undocked window does not look like a wxMiniFrame, it looks like a dialog (it has the three buttons top left of the window to close, minimise and maximise). Maybe wxMiniFrame on OSX should also look like this?

Igor Korot

unread,
Apr 4, 2021, 11:37:46 AMApr 4
to wx-u...@googlegroups.com
Hi,



On Sun, Apr 4, 2021, 9:56 AM Tony Kennedy <kenned...@gmail.com> wrote:
>> Thanks, the ticket is useful and I do see the behaviour you mention, but,
>> as I wrote there, it's not going to be simple to change it and, in fact,
>> I'm not even 100% sure if we want to do it.
I think the correct behaviour would be to use the style from a modeless dialog in any floating AUi windows. Or at least have the option of changing the wxMiniFrame window so it's level is the same as a modeless dialog (I'd give it a go if I knew how).

>> As you're using Xcode, I wonder how do its floating windows behave? I.e.
>> don't they also stay on top of all the other normal windows and not just on
>> top of their parent?
I only use Xcode as I don't know any alternatives (I hate using it). Xcode does not really have any floating panes that I'm aware of.

I've found an example though on OSX, Microsoft Excel. If you have two spreadsheets open and insert a formula in one, you get a docked formula editor. If you undock this and click on the other spreadsheet, the formula box stays with it's parent. Another difference here is that the undocked window does not look like a wxMiniFrame, it looks like a dialog (it has the three buttons top left of the window to close, minimise and maximise). Maybe wxMiniFrame on OSX should also look like this?

This is not particularly useful as its a MS application and not a Mac one

Thank you.


On Sunday, 4 April 2021 at 14:38:19 UTC+1 Vadim Zeitlin wrote:
On Sun, 4 Apr 2021 06:05:15 -0700 (PDT) Tony Kennedy wrote:

TK> Done (I hope). Ticket 19129
TK>
TK> https://trac.wxwidgets.org/ticket/19129

Thanks, the ticket is useful and I do see the behaviour you mention, but,
as I wrote there, it's not going to be simple to change it and, in fact,
I'm not even 100% sure if we want to do it.

As you're using Xcode, I wonder how do its floating windows behave? I.e.
don't they also stay on top of all the other normal windows and not just on
top of their parent?

Regards,
VZ

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

--
Please read http://www.wxwidgets.org/support/mlhowto.htm before posting.
 
To unsubscribe, send email to wx-users+u...@googlegroups.com
or visit http://groups.google.com/group/wx-users
---
You received this message because you are subscribed to the Google Groups "wx-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wx-users+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/wx-users/b1bcf91f-7b5e-47ef-8e7c-2df634b756efn%40googlegroups.com.

Vadim Zeitlin

unread,
Apr 4, 2021, 11:42:38 AMApr 4
to wx-u...@googlegroups.com
On Sun, 4 Apr 2021 07:56:14 -0700 (PDT) Tony Kennedy wrote:

TK> I think the correct behaviour would be to use the style from a modeless
TK> dialog in any floating AUi windows. Or at least have the option of changing
TK> the wxMiniFrame window so it's level is the same as a modeless dialog

Yes, I'm starting to think that this could well be the case.

TK> I only use Xcode as I don't know any alternatives (I hate using it).

Oh, I thought I was the only one. FWIW I just use command line tools
instead.

TK> Xcode does not really have any floating panes that I'm aware of.

I thought you could undock some of its panes, but perhaps this was in some
old version, sorry.

TK> I've found an example though on OSX, Microsoft Excel. If you have two
TK> spreadsheets open and insert a formula in one, you get a docked formula
TK> editor. If you undock this and click on the other spreadsheet, the formula
TK> box stays with it's parent.

This doesn't seem to be quite the same UI, i.e. I don't think we want
wxMiniFrames or floating AUI panes to be moved with the parent.

TK> Another difference here is that the undocked
TK> window does not look like a wxMiniFrame, it looks like a dialog (it has the
TK> three buttons top left of the window to close, minimise and maximise).
TK> Maybe wxMiniFrame on OSX should also look like this?

No, wxMiniFrame should really look like a "panel", not like a dialog, this
is the whole point in having it -- otherwise you could just use wxFrame.

Tony Kennedy

unread,
Apr 4, 2021, 12:18:55 PMApr 4
to wx-users
>> This is not particularly useful as its a MS application and not a Mac one
I'd still expect Microsoft to folloow the Apple guidelines as closely as possible.

Tony Kennedy

unread,
Apr 4, 2021, 12:24:19 PMApr 4
to wx-users
>> No, wxMiniFrame should really look like a "panel", not like a dialog, this
>> is the whole point in having it -- otherwise you could just use wxFrame.
My mistake, I thought the mini frames on OSX had the same little x in the top right corner (I see they are identical to small windows on OSX like find/replace in TextEdit). Just getting confused (again).


Tony Kennedy

unread,
Apr 5, 2021, 3:39:22 PMApr 5
to wx-users
Some more info on this as I've been experimenting.

If I make the following two changes, I get pretty much what I need (the floating panes become dialogs instead). I know this doesn't fix the problem, but it makes my app work in a similar way to the Windows version and stops any user confusion.

1. Edit framemanager.h, and change the wxAuiPaneInfo.frame variable from a wxFrame to wxWindow.

2. Edit floatpane.h, change
    #define wxAuiFloatingFrameBaseClass wxMiniFrame
to
    #define wxAuiFloatingFrameBaseClass wxDialog

Tony Kennedy

unread,
Apr 6, 2021, 4:00:45 AMApr 6
to wx-users
Some more follow up.

The modification here does not quite work as intended. When dragging the parent window with a child that is undocked, the child docks by itself.


Reply all
Reply to author
Forward
0 new messages