Is BugID 48062 worth all this?
Rick Stockton
rickstockton at reno-computerhelp.com
Wed Nov 23 01:54:29 GMT 2011
I need advice- do the masters of KDE consider
https://bugs.kde.org/show_bug.cgi?id=48062 to be important?
It's got a ton of votes, but I'll SWAG that a majority opf those votes
were really votes for https://bugs.kde.org/show_bug.cgi?id=96431 -- get
higher-numbered mouse buttons into the shortcut system. Most of the
comments in 48062 are actually about that subject, as is the attachment
("perform the Alt-L action when a mouse button is pressed.")
This is only about mouse buttons replacing modifier keys, you' still
have to press something ELSE to get a "keypress with modifier" Event.
And, it will be messy to obtain and maintain a "miniaturize" mouse
button State mask structure for this, within Qt; I might have to require
users to re-Press, and then hold, the "modifier button which they are
trying to invoke for the next keystroke (And fail to emulate in the case
of entering the Window with the a "modifier" Button _already_ within
pressed State.
Remember- I only have 5 Mouse Button State bits in the Xi Version 1
Events, anything more I'll after to acquire (or build) on my own. And
since Button 1 is already doing Gestures; and Button 3 is already doing
Context Menu (or other things); and Button4/Button5 don't behave as
actual buttons-- the only lower-numbered button which remains
'more-or-less-free-to-use, without problems' is MiddleButton -- and on a
lot of hardware, MidddleButton is really, REALLY hard to press.
So I think that the feature is useless, unless we support high-numbered
buttons as the modifier keys.
If you guys vote "yes, it's useful" then I'll try to ping the current
bug owner, who hasn't made a 'comment' appearance in quite a while
recently. I'll ask the current assignee if I can take it, and try to get
it done within Qt. (That's the appropriate level of the software stack
for this kind of Event Translation code.) If you guys vote "No, more
confusing than useful, and it looks really difficult to do" then let's
reject it. With the explanation that it's an overly specialized, and
technically difficult, case of shortcuts- with a better approach defined
by bug 96431. Not an exact duplicate, but with the users' needs more
fully met by spending our time with that RFE instead.
I watch the list for votes. Email works, too ;)
More information about the kde-core-devel
mailing list