Summary: | KActions should be triggered only once when holding keys despite keyboard repetition | ||
---|---|---|---|
Product: | [Frameworks and Libraries] kdelibs | Reporter: | Sean Lynch <techniq35> |
Component: | general | Assignee: | Unassigned bugs mailing-list <unassigned-bugs> |
Status: | RESOLVED FIXED | ||
Severity: | wishlist | CC: | gj |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | unspecified | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Attachments: |
patch for QAccel to ignore autorepeat key events
Patch that gets rid of KAccelEventHandler::x11Event |
Description
Sean Lynch
2003-07-02 13:21:17 UTC
*** Bug 61227 has been marked as a duplicate of this bug. *** Still happends in 3.2.2 Created attachment 7643 [details]
patch for QAccel to ignore autorepeat key events
In addition to the above patch, KAccel needs to be patched as well. Unfortunately it generates its own QKeyEvents in KAccelEventHandler::x11Event and those events do not have keyboard repeat information set. KAccelEventHandler::x11Event has been added in kaccel.cpp r1.136 to solve http://bugs.kde.org/show_bug.cgi?id=38285 See also kapplication.cpp r1.538 Removing KAccelEventHandler::x11Event doesn't reintroduce BR38285 as a whole, but it causes that the key-event is being send to the focus widget after, and despite, it being successfully handled in KAccelPrivate::eventFilter already. That actually seems to me a trivial bug in Qt that's easily fixed: @@ -323,7 +323,7 @@ bool QAccelManager::tryAccelEvent( QWidg e->ignore(); QApplication::sendSpontaneousEvent( w, e ); if ( e->isAccepted() ) - return FALSE; + return TRUE; } e->t = QEvent::Accel; e->ignore(); Forget the part about the trivial Qt bug. AccelOverride is send as an opportunity to prevent an Accel being send. If the widget accepts the AccelOverride, the Accel will not be send, and a KeyPress event will directly follow instead. kaccel abuses AccelOverride somewhat to ensure that it (as an event filter on the toplevel widget) will get the key event first (in the form of AccelOverride) before any of the intermediate widgets are able to process it. The problem with this is that accepting and acting on AccelOverride does not stop the AccelOverride/Accel/KeyPress sequence of event handling to be stopped. (Only the Accel phase will be skipped) Created attachment 7646 [details]
Patch that gets rid of KAccelEventHandler::x11Event
With this new understanding, attached patch gets rid of
KAccelEventHandler::x11Event without any bad side effects such as BR38285
Status update: Some code very much likes to have KAccels that auto-repeat, so the idea is to disable auto-repeat only if the KAccel belongs to a KAction that is plugged into a menu or toolbar. The QAccel part of http://bugs.kde.org/attachment.cgi?id=7643&action=view should be removed, it's not needed since we can handle things in KAccel sufficiently as long as the remainder of the patch is in. http://bugs.kde.org/attachment.cgi?id=7646&action=view is in CVS already. Ok, getting rid of KAccelEventHandler::x11Event was a bad idea because we need it very much for handling the Win key. See bug 91176. Reverted again. That means we will need to do keyboard repeat detection ourselves in KAccelEventHandler::x11Event SVN commit 877421 by jordipolo: set autorepeat to false for the "close tab" key shortcut (no more innocent tab killing) BUG:60625 M +1 -0 konqmainwindow.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=877421 |