[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