[Patch] Fixing the Access Key system

bj at altern.org bj at altern.org
Wed Jul 14 13:46:57 BST 2004


On Wednesday 14 July 2004 09.08, Lubos Lunak wrote:
>  I used Ctrl+Alt, because that's how Mozilla does it, and some pages
> advertize it that way (e.g. linuxtoday.com). The conflicts with global
> shortcuts are bad, but I'm afraid we can't require everybody to have
> 4-modifiers keyboards :(.
No, Mozilla and Firefox use the Alt+key system 
(http://www.mozilla.org/projects/ui/accessibility/accesskey.html)
I read many user reports that thought accesskeys didn't exist in Konqueror, 
and I only discovered the shortcut by reading the source code.

>  It'd be probably better if there was a normal shortcut for this rather
> than a single modifier key. For people preferring keyboard (and those are
> more likely to use accesskeys) Ctrl is not that rarely used key, and this
> could interfere. I've already noticed a similar problem with the
> Ctrl-suspends-Alt-arrows-scrolling feature, just e.g. switch virtual
> desktops (or even just intend to and then change your mind) and you have
> Ctrl pressed.

>  With your implementation global shortcuts actually don't work at all,
> because it grabs the keyboard, but that's hardly better (type-ahead find
> has the same problem). Can't you do without the grabs? If there's something
> possibly eating the keypresses before, simply temporarily install a global
> event filter and remove it again when done or on focus-out.
Well in fact I did put the grabkeyboard() because I took example on the 
type-ahead feature, but in fact it works well if I remove the 
grab/releasekeyboard() calls.
As my access key system proposal reacts on key release event, it can easily be 
adapted in such a way that it _only_ reacts if Ctrl was pressed and released 
and no other key was pressed in the meantime. (see new patch attached)
Also, I added a check, so that if the accesskey system is activated and you 
press any modifyer (ctrl, alt,...) it immediatly disables the accesskey 
sytem. 
With these extra checks, I don't think it can interfere anymore with other 
keyboards events.


> > Additionnaly, (and this can be removed from the patch if necessary), If
> > you press "Ctrl" again, small passive popups will appear in front of each
> > element in the page with an accesskey, showing that accesskey. 

>  Great idea. But I don't like the implementation - the passive popups are
> not really part of the html widget. Which means they don't scroll together
> with the page, and they stay on the screen if you change active
> window/desktop. They also don't go away after you actually press the
> accesskey. Would it be possible to e.g. use QLabel, reparent it to the
> khtml widget and keep them as the topmost children?
I agree, it was actually more a proof of concept. I first tried to do it with 
QTooltips, but couldn't find a way of making it work. Perhaps the QLabel way 
could be a better way...

>
> > This new behaviour could be advertised in konqueror's about: page.
> >
> > It would fix #45788 and #83053
>
>  #45788 probably can't be closed yet, as the accesskeys support is not
> complete. E.g. checkboxes still don't really work.

They should now work correctly since we recently committed a patch fixing the 
issue.

Attached is a new patch fixing a few conflicting issues and removing the 
display all access keys feature, since it probably needs a rewrite. At least, 
I think we should today commit a patch that displays a message in the status 
bar when the access key modifier is pressed. Will be back in 5 hours, 
comments welcome

regards
Jean-Baptiste
-------------- next part --------------
A non-text attachment was scrubbed...
Name: accesskey_control.diff
Type: text/x-diff
Size: 4150 bytes
Desc: not available
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20040714/b0aa6a8a/attachment.diff>


More information about the kfm-devel mailing list