wxWidgets / Phoenix

wxPython's Project Phoenix. A new implementation of wxPython, better, stronger, faster than he was before.
http://wxpython.org/
2.28k stars 515 forks source link

wxPython, Dialogs, Catalina, Dual Monitors --> disaster #2013

Open DKWoods opened 2 years ago

DKWoods commented 2 years ago

OS: macOS 10.15 Catalina (but not 10.14 Mojave or 11.x Big Sur) wxPython 4.1.1 installed via pip Python 3.7.8 downloaded from python.org This issue requires dual monitors.

Many common dialog boxes simply disappear when moved from their originating monitor to another on macOS Catalina. The dialogs still exist, and if they are modal, they retain control of the program, but they are not visible. In such cases, the only option is often to Force Quit.

To demonstrate this, run the wxPython Demo. Open any of the following:

Under Frames and Dialogs: Dialog Wizard Under Common Dialogs: FindReplaceDialog MultiChoiceDialog ProgressDialog SingleChoiceDialog TextEntryDialog RearrangeDialog RichMessageDialog

Open the dialog in question as appropriate within the demo. Then drag the dialog from the main screen to a secondary monitor. The dialog will disappear. In many cases, pressing ESC closes the dialog and returns control to the Demo parent window, but not always. If you leave the new dialog near the boundary between the two monitors, you can sometimes drag the Demo parent window away from that boundary and the hidden dialog will re-appear when it gets back to the first monitor.

I have discovered that changing the dialog parent to None in my own code often, but not always, causes the popup dialog to work properly and remain visible when dragged to a new monitor.

The list above may be incomplete. In my own code, I sometimes have problems with wx.MessageDialog and sometimes don't. The demo does not have problems with this one.

As I've said above, this problem occurs reliably for me from the demo on macOS Catalina. I cannot recreate it on Windows, macOS Mojave, or macOS Big Sur.

swt2c commented 2 years ago

Can you try seeing if you can recreate this in wxWidgets natively, perhaps with the dialogs sample?

DKWoods commented 2 years ago

I have now been able to recreate the problem in wxWidgets.  As a reminder, this issue deals with disappearing dialog boxes on macOS Catalina with dual monitors.

I apologize for how long this took me, and for my methods here, but I am not fluent in C++.  I have, however, gotten wxWidgets working on my macOS Catalina box and have adapted one of the Demo programs to show one example of the problem I've been talking about.

Go to the "bombs" demo program and alter the BombsFrame::OnAbout() method as follows:

void BombsFrame::OnAbout(wxCommandEvent& WXUNUSED(event)) { // wxMessageBox( // wxT("wxBombs (c) 1996 by P. Foggia\n"), // wxT("About wxBombs") ); wxTextEntryDialog dlg( this, wxT("wxBombs (c) 2021 by P. Foggia\n"), wxT("About wxBombs"), wxT("Text to edit") ); dlg.ShowModal(); dlg.Destroy(); }

Build and run the demo program.  Call up the About Box, which you will see is now a wxTextEntryDialog instead of a wxMessageBox. Drag the wxTextEntryDialog across the boundary from one monitor to the other, dropping it near the boundary between the two monitors.  The wxTextEntryDialog disappears, POOF.  Just like with wxPython.

Now drag the main frame for the bombs app away from the boundary between monitors.  You will see the invisible dialog show up when you've dragged far enough.  This also shows that the parent and child dialogs are somehow connected, in that moving the parent dialog, the main bombs frame, causes the child dialog, the wxTextEntryDialog, to move in parallel.  (They're supposed to be independent.)  The two dialogs cannot be displayed on different monitors from each other.

I listed a number of other wxDialogs that show this same problem in wxPython in my earlier post, and I suspect that someone more comfortable with C++ than I am could pretty quickly confirm that this is not an isolated problem.  Again, the crucial elements for making it occur are macOS Catalina and dual monitors.  I have not tested wxWidgets on Big Sur, but the problem does not occur for wxPython so I'd be surprised if it did for wxWidgets.

David

On 10/6/21 9:59 AM, Scott Talbert wrote:

Can you try seeing if you can recreate this in wxWidgets natively, perhaps with the dialogs sample?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/wxWidgets/Phoenix/issues/2013#issuecomment-936447178, or unsubscribe https://github.com/notifications/unsubscribe-auth/AC7ECDL63YWY6XI623Y7JLLUFRP6FANCNFSM5FKCRUFA. Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

-- David K. Woods Pronouns: he, him, his

swt2c commented 2 years ago

Thanks David for confirming that this is really in wxWidgets as I suspected. The next step would be to file a ticket in Trac: https://trac.wxwidgets.org/. If you attach a patch with the change(s) you had to made to the demo programs, that will be very helpful to the developers.