kpart container eats away keypresses

Tobias Anton TA at ESC-Electronics.de
Thu Sep 23 12:58:32 BST 2004


On Dienstag, 19. August 2003 13:24, Leo Savernik wrote:
> Hello,
>
> For caret navigation, I detect in KHTMLView::keyPressEvent whether a
> keypress is directed towards an editable element and divert from there if
> it is. However, this does not catch keyboard accels that are managed by the
> container -- they are handled somewhere *before* the event handler.
>
> This is especially nagging for Ctrl+Home which is a shortcut to
> file:///$HOME, but shouldn't take effect while navigating (like in html
> textareas).
>
> So where should i install an event filter? On kapp? On the part object? On
> the parts main window? Or is there a better solution?

Not sure, but would it help if you filtered out Accel events in the view's 
eventFilter? I think the Accel*-events are generated before the according 
keypress/keyrelease events.


Cheers
-- Tobias

---------------------------------------------
 bool KHTMLView::eventFilter(QObject *o, QEvent *e)
 {
-    if ( e->type() == QEvent::AccelOverride ) {
+    if ( e->type() == QEvent::AccelOverride || e->type() == QEvent::Accel) {
        QKeyEvent* ke = (QKeyEvent*) e;
 //kdDebug(6200) << "QEvent::AccelOverride" << endl;
        if (m_part->isEditable() || m_part->isCaretMode()





More information about the kfm-devel mailing list