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