[OSX] UI quirks with DRC dialog in Pcbnew
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
KiCad |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
On OSX, when running the DRC, the dialog window loses focus to the main window after the checks are finished. Since the main window is usually bigger than the DRC dialog window this results in the dialog suddenly vanishing from the screen. An unexperienced user might think that the checks failed and might try to click the DRC button again. But this does not bring the dialog window back in front.
There are two issues here:
1. DRC dialog window should keep focus after checks are finished.
2. If the dialog has somehow lost focus (perhaps the user deliberately gave focus back to the
main window, leaving the dialog open), the next click on the DRC button/icon should bring the
dialog back to focus.
I performed some checks yesterday and dug a little into the code, but I was not able to locate a precise source for this glitch. So I thought it was better to file this bug report.
Here is some of the "evidence", I came up with yesterday:
For reference, this is the Version information of the build used during my tests (Adams OSX nightly):
Application: kicad
Version: (2015-06-22 BZR 5801)-product release build
wxWidgets: Version 3.0.2 (debug,
Platform: Mac OS X (Darwin 14.3.0 x86_64), 64 bit, Little endian, wxMac
Boost version: 1.54.0
I tested all dialog windows that are launchable through toolbar icons/buttons. This confirmed that the observed behavior with the DRC dialog is indeed a bug, since *all other dialogs* (in both Eeschema and Pcbnew) come back to the front of the screen when hiding them with the main window and then clicking the respective icon again. Only the DRC dialog does not.
I then did some code changes to find the source of the glitches:
1. When commenting out the zone refilling part of the DRC checks, the dialog stays on the screen, so the culprit seems to be inside this call, probably related to some wxWidgets internals on OSX:
m_mainWindow-
(https:/
2. I found a workaround that made the DRC icon/button work again (it brings back the dialog window to front again), at least on my machine. Adding
m_ui->Raise();
at the very end of DRC::ShowDialog() (https:/
Finally, all the above does not happen on Linux. I built the exact same revision on Arch and there, everything works as expected. I could not check on Windows.
Changed in kicad: | |
status: | New → Confirmed |
Changed in kicad: | |
status: | Fix Committed → Fix Released |
These are two in a long list of issues that are the result of OS X specific wxWindows bugs.
The first appears to be an issue with z-order management on OS X, deep in the bowels of wxWindows. The wxWindows bug tracker is littered with variants of this issue, some were ostensibly fixed, while others have languished for years. I have a minimal repro so I will add to the pile, but I wouldn't expect a fix in wxWidgets any time soon.
We can hack around the issue in kicad, though it will be a bit janky. If we can suffer the mildly crappy user experience I think we should just do that. I have a patch against wxWidgets that is mildly less lame, but it still just a worksaround for the real issue, so probably isn't worth it to do it there at this point.
The second issue may be related to the first. Basically when the dialog is ordered back, m_isShown is not updated so it still thinks it is visible, and when Show() is called it does nothing. Since this likely affects all such dialogs on OS X, it should probably be worked around in DIALOG_SHIM.