[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kfm-devel
Subject:    Re: Last step for accesskeys...
From:       Lubos Lunak <l.lunak () suse ! cz>
Date:       2004-07-29 13:08:23
Message-ID: 200407291508.23426.l.lunak () suse ! cz
[Download RAW message or body]

On Wednesday 28 of July 2004 11:54, Lubos Lunak wrote:
> On Wednesday 28 of July 2004 13:35, bj@altern.org wrote:
> > Otherwise, it now works with Numlock or scrolllock,...
> > It now also works if the accesskey is a Caps.
> >
> > I changed the accesskeys popup display to disappear when ctrl is pressed
> > again.
> >
> > Let me know...
>
>  Seems to work fine. Now we need somebody bored enough to make some WWW
> pages actually use it :-/.

 There's one more things I'd like to change. When I initially implemented 
accesskeys using the Ctrl+Alt+? way of triggering, I wrote the key events 
handling so that if the keypress is not handled by accesskey handling, it's 
processed normally. But now that there's a special mode for accesskeys, it'd 
probably make more sense to simply ignore keys that don't have any accesskey 
instead of forwarding them normally to the HTML page. See attached patch. Ok 
to commit?

 The main reason I actually want this is because I have an experimental patch 
that tries to match space, backspace and enter accesskeys to next, previous 
and submit links/buttons/whatever. If there's no matching element, processing 
space or enter normally doesn't seem to be a very good idea.

-- 
Lubos Lunak
KDE developer
---------------------------------------------------------------------
SuSE CR, s.r.o.  e-mail: l.lunak@suse.cz , l.lunak@kde.org
Drahobejlova 27  tel: +420 2 9654 2373
190 00 Praha 9   fax: +420 2 9654 2374
Czech Republic   http://www.suse.cz/

["khtmlview.cpp.patch" (text/x-diff)]

--- khtmlview.cpp.sav	2004-07-29 14:44:29.000000000 +0200
+++ khtmlview.cpp	2004-07-29 14:59:04.534556032 +0200
@@ -1129,8 +1129,10 @@ void KHTMLView::keyPressEvent( QKeyEvent
 
     // accesskey handling needs to be done before dispatching, otherwise e.g. lineedits
     // may eat the event
-    if( handleAccessKey( _ke )) {
+    if (d->accessKeysActivated && _ke->state()==0) {
+        handleAccessKey( _ke );
         _ke->accept();
+        accessKeysTimeout();
         return;
     }
 
@@ -1907,8 +1909,6 @@ m_part->setStatusBarText(QString::null, 
 // Handling of the HTML accesskey attribute.
 bool KHTMLView::handleAccessKey( const QKeyEvent* ev )
 {
-if (!d->accessKeysActivated || ev->state()!=0) return false;
-
 // Qt interprets the keyevent also with the modifiers, and ev->text() matches that,
 // but this code must act as if the modifiers weren't pressed
     QChar c;
@@ -1924,7 +1924,6 @@ if (!d->accessKeysActivated || ev->state
     }
     if( c.isNull())
         return false;
-    accessKeysTimeout();
     return focusNodeWithAccessKey( c );
 }
 


[prev in list] [next in list] [prev in thread] [next in thread]