Last step for accesskeys...

[bj at altern.org]

>When are those tooltips closed? When the Ctrl-key is released? I hope they
>don't stay on screen until you open another document.
They stay for 5 seconds or less if you press a key inbetween...

>  It can be actually even three times if sticky keys are configured to lock,
> but that seems to work as well. It however ceases to work if you turn
> NumLock on. KApplication::keyboardModifiers() includes the NumLock state
> (David and Michael Matz apparently weren't aware of the certain idiotic
> details of X's modifiers handling).
>
>  Can you explain why exactly is that call needed? The event's state() or
> stateAfter() should give you the same information, without this problem.
Right, I missed the numlock stuff! The KApplication::keyboardModifiers() is 
required for sticky keys, because we only want to activate when the ctrl key 
is released. If you use state(), you can't make the difference between the 
first and the second ctrl key release when sticky keys is on. I didn't try 
stateAfter() since the doc says: 
Warning: This function cannot be trusted.
Attached is a patch fixing this issue (but still using keyboardModifiers()).

>  When I press Ctrl twice it still keeps the accesskeys activated. It'd be
> nice if the second press would turn it off again instead of me having to
> press Esc or wait, if this is supposed to be not very intrusive.

Attached is a new patch that fixes (hopefully) all issues, but it requires to 
include file kkeyserver_x11.h. I don't know if there should be some #ifdef in 
case it is compiled without an X server ?
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...
Jean-Baptiste
-------------- next part --------------
A non-text attachment was scrubbed...
Name: accesskeys_mask.diff
Type: text/x-diff
Size: 4988 bytes
Desc: not available
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20040728/0f8a52a9/attachment.diff>