AW: AW: AW: AW: making fallback access keys configurable

David Faure faure at kde.org
Wed Mar 1 16:25:04 GMT 2006


On Wednesday 01 March 2006 16:59, Tobias Anton wrote:
> You could as well be of the opinion that ctrl is just a key as every other
> and should be treated as such. 

Yeah let's redefine the meaning of keyboard keys ;-))))
Sorry, but this makes no sense to me.
Alt, Shift and Ctrl are modifiers, and have always been.

> Unfortunately, too much key handling is 
> hardcoded in QT, making it hard to impossible to change certain behaviours. 
Phew :)

> I think the idea behind the usage pattern "press ctrl once to make shortcuts
> appear, press it again to make them disappear" initially was to use ctrl
> like a modifier, i.e. "show shortcuts as long as ctrl is pressed", but then
> it became obvious that holding down ctrl while reading the accesskeys is
> very inconvenient. To keep that paradigm, yet removing the annoyance, a
> possible solution could thus be:  
... to use another key? ;)

> - show the accesskey tooltips on Ctrl press
> - hide accesskey tooltips on Ctrl release if any other UI event had occurred
> since the corresponding Ctrl press.
> - otherwise, show tooltips until any key or mouse button changes status.
> 
> Unfortunately, this will not work properly if the window manager dispatches
> all UI events between the ctrl-down and the following ctrl-up to another
> application. I think this is exactly what happens in your case, but most
> probably there is a solution for that, too. Particularly, I am thinking of
> something like the X11 window leave events, but I'm not too deep into the
> details of X11 event handling.

I don't think khtml should grab the keyboard when I press Ctrl
(since that would make Ctrl+F2 completely not-effective).

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).




More information about the kfm-devel mailing list