[OSX] UI quirks with DRC dialog in Pcbnew

Bug #1468274 reported by Johannes Maibaum
18
This bug affects 3 people
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,UTF-8,compiler with C++ ABI 1002,GCC 4.2.1,STL containers,compatible with 2.8)
Platform: Mac OS X (Darwin 14.3.0 x86_64), 64 bit, Little endian, wxMac
Boost version: 1.54.0
         USE_WX_GRAPHICS_CONTEXT=OFF
         USE_WX_OVERLAY=ON
         KICAD_SCRIPTING=OFF
         KICAD_SCRIPTING_MODULES=OFF
         KICAD_SCRIPTING_WXPYTHON=OFF
         USE_FP_LIB_TABLE=HARD_CODED_ON
         BUILD_GITHUB_PLUGIN=ON

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->Fill_All_Zones( aMessages ? aMessages->GetParent() : m_mainWindow,
                                  false );

(https://bazaar.launchpad.net/~kicad-product-committers/kicad/product/view/head:/pcbnew/drc.cpp#L232)

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://bazaar.launchpad.net/~kicad-product-committers/kicad/product/view/head:/pcbnew/drc.cpp#L75). But this is only a very crude hack, since I thought that wxDialog::Show(), overridden in dialog_shim.cpp:94, should already take care of this.

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.

Tags: osx
Revision history for this message
Garth Corral (gcorral) wrote :

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.

Garth Corral (gcorral)
Changed in kicad:
status: New → Confirmed
Revision history for this message
Garth Corral (gcorral) wrote :

I've created a patch that works around the issues which has been committed by JP. I'll file issues for the underlying issues against wxWidgets.

Changed in kicad:
status: Confirmed → Fix Committed
Jon Neal (reportingsjr)
Changed in kicad:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.