====================================== Gnats 5284 Notes / October 18-20, 2013 ====================================== -------- Original Message -------- Subject: Workaround Fix: 5284: Workspace File->Reopen Model menu selection [dropped]. Date: Fri, 18 Oct 2013 From: Phil Weinstein To: software I checked in a solution. It's a workaround which can easily be removed (just one function) if and when it is no longer required with a future version of Qt. I did NOT end up using the code I had committed today to a temporary "Gnats5248" branch. With those changes, I just wasn't yet able to see anything (else) in our code, or in the Qt QMenu code which suggested something we could do differently to avoid the problem. I refrained from including that "cleaned up" code in this solution I checked into the (soon-to-be) "6.5" trunk. I have NOT merged (or cherry picked) this commit into the new "Release_64" branch which Jessica created today. After some testing by others who have more readily been experiencing the problem (esp. Patrick), I recommend that we do. GIT commit records (two) -- see notes below. https://cadswes2.colorado.edu/internal/cgi-bin/gitweb/gitweb.pl/builds.git/commit/ c2f338f501847336034d9bbe31674ba567b54dbc (primary commit, 10-18-2013) dc8d658bfc693d77507881a9df059a68a2c506d7 (minor revisions, 10-19-2013) - Phil Fix: Reopen File (and Re-Show) Menu selections sometimes dropped. (5284) Bug Number: 5284 Release notes (y/n): Yes For Release Nums: 6.4 Gnats 5284: Workspace File->Reopen Model menu selection [dropped]. This irregular behavior of our "history" QMenus in Qt 4.8.5 (having something to do with QTBUG-20094 related to providing friendly handling of slightly-out- of bounds mouse movements to submenus -- "cutting the corner") has been addressed with a workaround. The mouse release event processing for menus containing the special file-associated menu items (QActions) has been augmented to redundantly trigger the QAction. The processing of these QActions fortunately already filtered out redundant "trigger" occurrences, to address a different issue. In order to provide a mouseReleaseEvent() implementation for the relevant QMenus, a QMenu subclass needed to be defined. The existing QAction subclass for this mechanism was modified to insure that those QActions are deployed only in instances of this new QMenu subclass; its constructor now requires an instance of the new QMenu subclass. (Most of the changes in this commit are for instantiating these new menus). These subclasses are defined in Q3GUI/LoadSaveMgr: class LoadSaveMgr::FileItemMenu : public QMenu class LoadSaveMgr::FileItemAction : public QAction This was tested with a debug output provision in a place where the bug scenario occurrence can be detected. The following method contains extensive notes about this solution: --------------------- (Revised 10-19-2013): --------------------- void LoadSaveMgr::FileItemMenu::mouseReleaseEvent (QMouseEvent* evt) { // ********************************************************** // *** Gnats 5284 Note, 10-2013, RW 6.4, Qt 4.8.5, Phil *** // ********************************************************** // This modified mouse release event processing implementation // addresses the Gnats 5284 menu bug. When releasing the mouse over // a FileItemAction, it turns out to be safe to redundantly trigger // that action (as described below). The normal QMenu processing for // this event is still used to insure proper menu state maintenance // (to the extent that that is working correctly within Qt). // // Note that the incidence of the bug scenario (with the File >> // "Reopen Model" menu) can be made apparent by uncommenting-back-in // debug output in method: Workspace::aboutToShow_ReopenModelMenu(). // This solution was tested using that provision. // The clicked QAction (if a QAction IS under the mouse pointer) // probably IS a FileItemAction, but it may not be. The use of this // mechanism by RplPolicyMenu (for example) includes some normal // QActions in that FileItemMenu subclass. // const QPoint pt = evt->pos(); QAction* act = actionAt (pt); FileItemAction* fileItemAct = (act && act->isEnabled()) ? qobject_cast (act) : NULL; // First allow the base class processing of the mouse release event. // Generally this triggers the FileItemAction. But in the case of // the Gnats 5284 scenario, it doesn't. // // Call base class method QMenu::mouseReleaseEvent (evt); if (fileItemAct) { // If a FileItemAction click is being processed, trigger it now. // This will generally be redundant, but not always (because of // Gnats 5284). FileItemAction processing insures that FileItemAction // 'trigger' functions are performed only once. Aside from the // dependence on that provision here, it was also needed for multiple // levels of cascaded FileItemMenus, for example, within RplPolicyMenu. // // Note that it has been found that the menu (and parent menus) // DO get hidden, i.e. even apparently by triggering this action // after the Gnats 5284 dysfunction [with Qt 4.8.5]. fileItemAct->trigger(); } } ====================================================== SEE ALSO "QTBUG-20094" on qt-project.org: https://bugreports.qt-project.org/browse/QTBUG-20094 ====================================================== With Qt 4.8.5 on Windows 7, I believe we're experiencing a race-condition sort of problem with "QTBUG-20094" QMenu submenu related code. Often, after quickly "cutting the corner" to a submenu, the subsequent mouse click (press and release) on a QAction -- instead of triggering the QAction -- is just re-showing the submenu. Sometimes some flicker is apparent; the submenu remains visible, and a subsequent click does successfully trigger the QAction. This menu reshowing is happening on the mouse press event (see stack excerpt below). On the subsequent mouse release event, the submenu has no "current action", so nothing happens. Mouse press stack excerpt: QtGuid4.dll!QMenu::aboutToShow() Line 160 QtGuid4.dll!QMenu::popup(const QPoint& p, QAction* atAction) Line 1823 QtGuid4.dll!QMenu::internalDelayedPopup() Line 3036 QtGuid4.dll!QMenuPrivate::popupAction(QAction*, int delay, bool activateFirst) Line 502 QtGuid4.dll!QMenuPrivate::setCurrentAction(QAction*, int popup, QMenuPrivate::SelectionReason, bool) Line 595 QtGuid4.dll!QMenuPrivate::setCurrentAction(QAction*, int popup, QMenuPrivate::SelectionReason, bool) Line 566 QtGuid4.dll!QMenu::mousePressEvent(QMouseEvent*) Line 2324 -------- Original Message -------- Subject: Bug 5284 - Workspace reopen menu flicker Date: Thu, 17 Oct 2013 From: David Neumann To: software Phil and all, Here is what I've observed on this issue. All of my testing was done with the 6.4 Release executable. I see the problem there so I didn't try the debug. If I mouse very carefully along the menu, it does not happen. If I "cut the corner" it does happen fairly frequently. It appears that this has something to do with it. I reproduced it on both the File ->Reload menu and the Policy->Ruleset-> ReopenAndLoad The File -> Reload is only one submenu (one corner to cut), the Policy-> Ruleset-> ReopenAndLoad has two submenus (hence two corners to cut) so I could see how patrick could see this frequently when reopening rpl sets. It appears there is a flicker when you cut the corner then sometimes the click works, other times, it does not work. I have not observed any more consistent pattern beyond that. The same behavior is in 6.3.3 and 6.3 The problem is NOT observable in 6.2.9 David ---