Bug 48062

*** Bug 34362 has been marked as a duplicate of this bug. ***

Could you explain exactly what you mean with "modifier" buttons?  And please give an explicit 
example of who it would be used to resize more quickly. 

I'm not the reporter, but I'm interested in this, too. 
I could think of moving a window with e.g. the 6th button without using the 
title-bar. 
This is possible ATM when you press Alt and the left mouse-button (or which 
combination you've ever assigned). 
With only pressing a mouse-button it would be easier. 
Some more nice features like assigning one button to maximizing the window, 
another one to roll it up. 
 
Just my 0,02 EUR 

I would like to see konq with the ability to map mouse buttons to actions.  I really miss not 
being able to use my side mouse buttons for back/forward, etc. 

Yep, Exactly...  or maybe use one side button to double-click or other thing like this. X 
is aware of this size button... whty not Qt and KDE ?? 
 
 Just my 0,02 EUR  ;-) 
  
  
  

Buttons 4 and 5 are hardcoded in Qt to the wheel. (The Z axis) 

I also would like to map mouse buttons to actions. 
Especially I would like to switch between pointing and scrolling mode: 
 
Pointing mode is "the usual way" to use the mouse. 
In scrolling mode the mouse cursor looks e.g. like a compass, 
and the mouse movement does not move the cursor but the shown part in the current window. 
So the mouse can be used for simultanious horizontal and vertical scrolling. 
 
In control center pointing mode could get enabled and adjusted: 
Switching between pointing and scrolling mode e.g. could be done by 
3rd mouse button, 4th mouse button or Ctrl+Shift -- selected in control centre. 
 
This kind of scrolling mode is especially usefull with a mouse with more than 2 buttons and 
without a wheel. 

I would like to use the mouse button on the thumb for double clicking.

This would be button 4, I believe.

I'd be very interested in this, too.  Basically what would be needed would be
for kcmkeys to allow actions to be bound to combinations of mouse events and key
events; e.g. "move window to top-left corner when CTRL, SHIFT and
left-mouse-button are pressed".

(BTW, this is a behaviour that was possible in fvwm, E, and sawfish, FWIW.  it's
the main thing I miss from sawfish.)

In Keyboard shortcuts I want MOUSE+KEYBOARD keybinding for ease of use
----------------------------------------------------------------------
There are many things which can be done easier when you have mouse and keyboard combinations (keybindings) working together.

if you allow mouse buttons with keyboard buttons as keybindings there will be many tasks that can be done very easily and efficiently.

Strangely there exist very popular and nice KEYBOARD+MOUSE keybindings but the user is not allowed to configure it:

1. the existing example is the ALT+mouse keybinding for kwin, though not documented and cannot be changed as it should have been. This is most common and everybody likes it.
    a. you can resize the window using ALT+RMB
    b. you can send a window backward with ALT+MMB
    c. you can move a window with ALT+LMB

2. using wheel mouse you can scroll and down, using shift you can increase or decrease font size, and alt+scrolling will move the horizontal scroll bar. esp. web pages, text and pdf documents are very easy to work with.

3. SELECTION: of files and text is done mostly with the help the mouse+keyboard keys. like if you want to select 2 different files/folders you use CTRL+LMB on each file.


I ask why can't we use these 5 mouse buttons with 100+ keyboard keys to create virtually so many possibilities of shortcuts, simplifying user tasks.

I request to allow keybindings with keyboard to do different tasks. like:

1. ctrl+alt+lmb -> copy  file/selection
2. ctrl+alt+mmb -> cut   file/selection
3. ctrl+alt+rmb -> paste file/selection

Required Mouse keys and keyboard keys for bindings:
1. LMB
2. MMB
3. RMB
4. Wheel scrolling UP
5. Whell scrolling down

and using Mouse buttons followed by keyboard keys are great option (make sure the mouse button is not released, before the binded key say 'a' (LMB+A)

Mouse buttons is pressed first then a keyboard key is pressed and bothe are released:

Examples of good working possibilites to use mouse and keyboard:

sn  Mouse+key    comment                     Existing keyboard shortcuts
1.  LMB+B     -> to bold selected text     ->CTRL+B
2.  LMB+I     -> to itilicize selected text->CTRL+I
3.  LMB+C     -> to copy selected text/files->CTRL+C

The lmb+[anykey] combination is just having CTRL+[anykey], so we can have as many as shortcuts for CTRL+ combination.

same with MMB and with RMB. thanks

I made this feature request a LOOOONG time ago, and it still hasn't been done.  All I want is support for mice (like the Intellimouse Explorer) that have extra buttons (in addition to the usual 3+scroll wheel.)  Ideally, we'd be able to map those buttons to whatever we want, but a good default would be to map the two extra thumb buttons to Back and Forward in Konqueror.

Right now, the only way to do this is with imwheel, and that tends to break things.

You can do those vertical scrolling and others by X itself. You can add so many buttons to mouse like if you like to cut file you can press LMB+RMB and when you want paste file then LMB+MMB, when you want copy file then just MMB+RMB.

I have Logitech FX trackball without scroll. i did made it use 4th button to scroll horizontal+vertical ways. And when its trackball it act like i would touch that by hand.

Just add those virtual buttons to mouse and bind them to act like you want...

This is similiar to bug: 72199.  Currently I too have had to use imwheel to map the extra buttons correctly.  When KDE offers you a shortcut input button, the mouse buttons should trigger as well.  This would allow you to use the normal shortcut mechanism to perform actions.

*** Bug 36820 has been marked as a duplicate of this bug. ***

If KHotkeys could handle extra mouse buttons, it would solve most the problems.

What I miss from my MS Windows times is an opportunity to map those extra mouse buttons to modifier keys instead of instant actions. That's less obtrusive when they are hit accidentally, and it decreases the need to leave the mouse for activating shortcuts. imwheel doesn't provide such a functionality.

how did you do this using imwheel?

> ------- Additional Comment #15 From Petri Damstén 2004-08-23 12:30 -------  
> If KHotkeys could handle extra mouse buttons, it would solve most the problems.

I agree with Petri. This sounds like quite a clean way of doing it. The other good solution would be to expand Qt to support more buttons (mappings configurable by user?), so application developers can make these buttons context sensitive, but this might make things more complicated than people are used to.

Is this likely to get solved for kde4, or are we going to have to wait for another major revision of Qt for this?

*** Bug 96431 has been marked as a duplicate of this bug. ***

I want the 'Enter' button on my thumb-mousebutton (button 6?) to confirm dialog-boxes without having to point to them. Used it in Win for many years and can´t quit doing it, even the feature is not there.

The Logitech mousedrivers 1996 supported another feature called Hyperjump. This was a gesture-shortcut to several functions. mouseclick (middle button usually) and move mouse to:
top: minimize window
top-right: close-app
right: jump to scrollbar vertical
bottom: jump to scrollbar horizontal
bottom-right: resize window
bottom-left: jump to start/k menu
left: taskswitch (alt-tab)
top-left: application-menu

When the pointer is beeing jumped, it automatically activates the action and jumps back, when done. so you don´t need to reposition the mouse.
This feature has many fans, even today, when it´s no longer supported.
We definitely need the supported other mousebuttons to add all the features (like cut, copy, paste too!!!!) to them. 

re-adding myself to the CC:.  not sure why we all got cleared in comment #20.

I'd also love to have this feature. It's such a pain that Konqueror can't handle the thumb buttons (6 & 7) for backward/forward actions... not to mention not being able to use the other 2 buttons my mouse has.

==========================================================================
This bugreports has become a complete mess of stuff that's barely related to each other, so let's clean it up.

This bugreport itself, i.e. the initial comment about mouse buttons working as modifiers: For the time being, this is CANTFIX, as there's no support in X11 for this. It is not possible to grab a combination of mouse buttons, so it's not possible to e.g. move windows by pressing LMB/RMB and additional mouse button. X11 also reports state only for 5 first buttons, which are taken by the 3 basic buttons and the wheel, the remaining buttons only report press/release events, which is insufficient for making them work as modifiers.

The other unrelated comments:
- mouse buttons as shortcuts -> bug #96431.
- supporting more buttons in general -> bug #34362
- wanting some special action triggered by additional buttons -> create a new bugreport and consider bug #34362 as a prerequisite for it. This includes the request for window actions, e.g. being able to move windows by pressing one additional button and moving the mouse
==========================================================================

Created attachment 20313 [details]
simulate ALT_L key when Thumb-button is pressed.

I was not able to achieve the goal either, but here is a close work-around.
The program watches the thumb-button and when it is pressed, simulates a ALT_L
key press.
I have encountered some weird behavior from X, so the thing is not completely 
working, but it is better than nothing. ATM it only works for the first
mouse-click after the thumb-down. (so you can resize only once. afterwards you
have to click the thumb-button again).
If you encounter "stuck" keys, just press the real keys (in particular ALT_L).
Compilation instructions: gcc main.c -lXtst

Is there an upstream RFE at x.org? (https://bugs.freedesktop.org)

Not that I'm aware of.

Could someone knowledgeable file the upstream RFE and describe there exactly what is needed? This would be a terrific feature to have implemented. Thanks.

In my opinion what we want is the ability to configure additional mouse buttons grafically e.g. in control centre. (I know, it has got a new name.)

I'm using fedora with kde 4.2 rc1. The mouse buttons for back/for works great in Firefox by defualt, but not in Dolphin/Konqueror.
This should be solve quickly, or is there a work around to solve the problem?

I use easystroke for this. Works realy great

(In reply to comment #23)
I don't know if Lubos remains active on this bug, four years later. But some mis-statments need corrections: 

> ==========================================================================
> This bugreports has become a complete mess of stuff that's barely related to each other, so let's clean it up.
> 

AGREED. STRONGLY!

> This bugreport itself, i.e. the initial comment about mouse buttons working as modifiers: For the time being, this is CANTFIX, as there's no support in X11 for this.

This statement is totally wrong. X11 provides the Button number as an integer, 1-32. And so, even under XI 1.x, with it's brain-damaged mask, you could use those buttons (LEFTBUTTON, MIDBUTTON, RIGHTBUTTON, XBUTTON1, and XBUTTON2) as modifiers for events on any other buttons, including the scroll wheels.

Under XI 1.x, these 5 buttons could be used as modifiers for the others (including the scroll wheels, buttons 4-7.)  

> - mouse buttons as shortcuts -> bug #96431.
> - supporting more buttons in general -> bug #34362

yes, that's the "master bug" for all others. ;)

> - wanting some special action triggered by additional buttons -> create a new bugreport and consider bug #34362.....

No, I think that we should keep THIS bug as the 'master' for Buttons with numbers Higher than "XButton1" (AKA 'Back Button') and "XButton2" (AKA 'Forward Button') as modifiers.

This capability is native in X Input Version 2 (XI-2.x). But Qt4 will never use XI-2, and Qt5 will use Wayland as it's "most-favored" Plugin. Still, I CAN obtain a full-width Mouse Button mask... and I can make it available using a standard 'READ' accessor function, returning a 32-bit set of flags.

So (for example), you want something special to occur in your program when you drag while holding the Button with raw number "13"? Just Initiate a graphics scene, and reimplement it's mouseMoveEvent().

In most programs, it will only run with LEFTBUTTON or RIGHTBUTTON.) to run while "BUTTON13" is being held down. utton13 en utton 13your drag action when BUTTON13 in "Pressed" State. Monitor Mouse Motion, and . Then, at BUTTON13 Release, execute your "special" code.

(Yes, I know what I'm talking about. And my gamer mouse, Logitech G700, does have this button on it.) ;

(In reply to comment #30)
> I use easystroke for this. Works really great.

Yes it does, but KDE can easily start implementing lots of advanced Mouse features _without_ a dependency on that small-scale, independent project. 

EasyStroke has been stuck on Release 0.5.4 for an entire year, it may not have a lot of "momentum" for the accomplishment of future maintenance work. For KDE,  qt/KDE Programmers, and end users, I feel that that a "requirement" for users to install Easystroke to run the program would be a bad thing(tm).

The pre-requisite change in Qt support of "more mouse buttons" (https://bugs.kde.org/show_bug.cgi?id=34362) is resolved in Qt5.

So, I'll mumble (a bit) about where we are NOW, with the basic recognition of the Mouse events Press(), Release(), and DoubleClick() resolved in the upcoming Qt.

Many comments here are asking that we (KDE) implement configuratble short cuts for those buttons. I'm referring to the ones which say, "I'd like to use Qt::BackButton (or one of the new higher-numbered ones) to do XXX function". With the button ALONE. I see those as requests for enhanced shortcut capabilities, unrelated to this bug.

The description of this bug, asks that mouse buttons be used as modifiers. (And, BTW, If we created such a button-as-modifier scheme, it would not be restricted to button+keyboard combinations: You could hold the "modifier" button to alter the behavior of another button. Creating additional, virtual buttons by seeing the modifier in "pressed" state when you click a second button.

In Qt programming, this is already possible in the 4.x series: With X11, Qt::MouseButtons() contains the pressed/unpressed State of buttons 1-5. But 4 and 5, unfortunately, refer to the vertical wheel- which almost INSTANTLY switch to "unpressed" after the "press" which corresponds to a vertical scroll motion. So we _really_ only have Qt::ButtonLeft, Qt::ButtonRight, and Qt::MiddleButton available as modifiers.

Qt::ButtonRight, assuming that you have NOT swapped the Left and Right buttons, will pop up the context menu when it is released. It can be used as a 'modifier button' for another, but when you let go, you get the context menu -- and to make it go away, you will need to click a button again.

I _MIGHT_ have have a place in the Qt5 Qt::MouseButtons() State Mask, where I could use a bit to prevent the pop-up *IF* Qt::RightButton had just been used as a modifier. If RightButton is merely clicked, then push up the context menu. But if RightButton was held WHILE another button was clicked, AND RightButton has designated as a 'modifier' button, then supress the context menu pop-up.

Does that work? I'd like to get agreement on the mouse and keyboard behaviors which we want first, and get into the KDE shortcut management second.

@rickst29:
Your analysis seems spot on. Thanks.

Actually, if you could implement that so that it is global.
E.g. In Windows, the "Meta" key can either open the menu, or act as a modifier, in exactly the way you described.

I think this is a superb proposal :-)

(In reply to comment #35)
> Actually, if you could implement that so that it is global.
> E.g. In Windows, the "Meta" key can either open the menu, or act as a modifier,
> in exactly the way you described.
> 
> I think this is a superb proposal :-)

Nick, you probably didn't bother to note this, because it's obvious -- a solution within KDE can affect only KDE applications, and a solution within Qt can affect only Qt-based applications. (Including KDE Apps.) The KDE Developers would be able to use the current scheme of shortcuts and corresponding configuration files to share 'Global' shortcuts, and override those values with Application-Specific shortcuts, very easily: they'd just have to read the 'rc' files and issue the function cals which map the mouse button(s) to the keyboard 'alt' modifier(s).


The original "Keyboard Modifiers" implementation is pretty easy, within KDE, AFTER the Qt support work is done. It might be a bit hard within Qt. Not because the design SHOULD be hard, but rather because current Qt (currently 4.7) has issues with the processing of higher-indexed "modifier" keys, and no one else has solved the regression yet. There are also a number of keyboards, keyboard maps, and language issues to consider.

At this moment, in US-English, X11 maps my keyboard thus:
x2:~ ((unknown))> xmodmap -pm
xmodmap:  up to 3 keys per modifier, (keycodes in parentheses):

shift       Shift_L (0x32),  Shift_R (0x3e)
lock        Caps_Lock (0x42)
control     Control_L (0x25),  Control_R (0x69)
mod1        Alt_L (0x40),  Alt_R (0x6c),  Meta_L (0xcd)
mod2        Num_Lock (0x4d)
mod3
mod4        Super_L (0x85),  Super_L (0xce),  Hyper_L (0xcf)
mod5        ISO_Level3_Shift (0x5c),  Mode_switch (0xcb)

Since Qt runs at a higher level than the underlying X11 (or Wayland, or whatever, Qt could turn on the presence of these mod bits, within our own events, under certain conditions -- even when the underlying hardware did NOT have any of the defined keys pressed.

Then, within KDE, your shortcuts would still be defined within terms of the modifier "key" -- but you could use a certain button, or multiple buttons, to create a "pressed" State of the Modifier Key bitmask field when the button is being held.

KDE support would only consist of a small GUI to do your mapping of buttons to Modifier Keys. Everything else, including the creation of shortcuts would be run via the code we already have: When it asks you to press the button and "enter the keystrokes for the command", you could hold the mouse button and press just one key: The shortcut manager would genuinely receive your key WITH the 'Alt_L' key, or the Control_R key (or whatever... as you previously chose) auto-magically pressed.

But this would be a one-way trip: That particular button would NOT behave as a mouse button for Applications which used that underlying map, unless you re-did the mapping.
- - - - - - - -
IMO, THIS bug should remain open for the KDE GUI interface and config code hooks, even though the requested functionality would be 100% upstream in this scenario. I'll write that bug against Qt and start Developing.

It could take me quite a while. Like 34362 did. But I did succeed on that one ;)

Ellis has (graciously) allowed me to assign this bug to myself.

I have carefully considered the coding which would be required in Qt, and it is probably NOT acceptable to the Qt Core manager. (For performance reasons, primarily. But it would also be extremely confusing and difficult to maintain, and to migrate into ALL of the platforms which Qt intends to support.)

I have also asked the KDE Core Developers whether they agree with me that "this bug is just not worth it". So far, all of their replies agree with me.

If you were to have a mouse button as a modifier, you're still involving both hands (one on the mouse, the other on the keyboard to press the "Modified" key.) This is, IMO, only a tiny enhancement to the current procedure: Hold down the 'Modifier' with one hand, and if the other key is too far to reach comfortably with the same hand, you bring the other hand to the keyboard to press the key which is being effected by the held-down Modifier.

- - - - -

But before I close THIS bug, I'd like to remind everyone-- the objective which nearly all of these comments have been asking for is support for high-numbered mouse buttons within the shortcut system. (Both in using a a mouse button alone, AND in holding down a mouse button while executing a keyclick.)

Nickolas (in comment 35) emphasized that a 'Global' scheme is desirable, and the shortcut system already provides that feature. The Enhancement which we really need, I think, is https://bugs.kde.org/show_bug.cgi?id=96431.

Not this one.

But, if I have missed something, please comment back- I've made a decision, but I'll change it if I'm mis-understanding this bug and it's comments in an important way. Follow-up questions are welcome, too. (When a bug has a history of nearly 10 years, I'm not closing it without allowing a FULL discussion.)

I'm closing the bug.

If I was going to work on this, then the Resolution would be 'CLOSED- UPSTREAM'. The enhancement would be in Qt. But I see almost no value, a large risk of creating bugs in Qt, and too much work-- So I'm not going to work on it in Qt, or even open a corresponding bug for the Qt library. (I'd only turn right around and close it with "WONTFIX", same as I'm doing here.)

I'm closing this with resolution code WONTFIX. Too much implementation risk, with too little resulting value.

Totally Agree. The real enhancement we want is the one you are pointing out (In reply to comment #38)
> I have carefully considered the coding which would be required in Qt, and it is
> probably NOT acceptable to the Qt Core manager. (For performance reasons,
> primarily. But it would also be extremely confusing and difficult to maintain,
> and to migrate into ALL of the platforms which Qt intends to support.)
> 
> I have also asked the KDE Core Developers whether they agree with me that "this
> bug is just not worth it". So far, all of their replies agree with me.
> 
> If you were to have a mouse button as a modifier, you're still involving both
> hands (one on the mouse, the other on the keyboard to press the "Modified"
> key.) This is, IMO, only a tiny enhancement to the current procedure: Hold down
> the 'Modifier' with one hand, and if the other key is too far to reach
> comfortably with the same hand, you bring the other hand to the keyboard to
> press the key which is being effected by the held-down Modifier.
> 
> - - - - -
> 
> But before I close THIS bug, I'd like to remind everyone-- the objective which
> nearly all of these comments have been asking for is support for high-numbered
> mouse buttons within the shortcut system. (Both in using a a mouse button
> alone, AND in holding down a mouse button while executing a keyclick.)
> 
> Nickolas (in comment 35) emphasized that a 'Global' scheme is desirable, and
> the shortcut system already provides that feature. The Enhancement which we
> really need, I think, is https://bugs.kde.org/show_bug.cgi?id=96431.
> 
> Not this one.
> 
> But, if I have missed something, please comment back- I've made a decision, but
> I'll change it if I'm mis-understanding this bug and it's comments in an
> important way. Follow-up questions are welcome, too. (When a bug has a history
> of nearly 10 years, I'm not closing it without allowing a FULL discussion.)

Let me agree on the easy part -- the report https://bugs.kde.org/show_bug.cgi?id=96431 is more desirable, applicable right now (with keyboard+mouse) and useful directly to more users than this one.

Now, I will catch you on words (Rick Stockton) and make one offensive statement, not to offend you personally but to emphasis the point:
----
"If you were to have a mouse button as a modifier, you're still involving both
hands"

Both hands? Boy you are lucky. How about one hand and a leg? Or how about just one hand?

This is textbook example of closed minded thinking "_I_ have both hands so I am sure everybody else has both hands too".
----

Handicapped people exist I assure you. Sophisticated mouse-like devices exists too.

And for years I am observing this ridiculous endless loop. It would be great to buy and use hardware X, but it would be useless because Linux software does not support it, and it does not support it, because "this bug is just not worth it".

From simple technical perspective the hardcodes values and hardwired stuff (like "alt key open the menu", another one not worthy fixing) is one hand and insult to any intelligent creature, on the other it is just waiting for disaster, when you will need flexibility BADLY, but all you get would be tons of hardwired, not-worthy fixing mess.

From human POV -- nobody can tell anyone here "do this and that", but if you are skillfull, have the knowledge -- why NOT do it? Why wait for somebody else to do it (and why somebody else couldn't refuse as well)? And if you don't believe in "making a world a better place" (you know, it is not that a nuclear bomb is killing us; it is tons of tiny stupid issues hurt us and taking our lifetime, piece by piece), please do it as self-insurance. At some point of life you can start using computer with one hand, and then you would like to see "weird" features which help YOU work more efficiently (of course I wish you healthy life).

So, flexibility matters.

And if you are curious -- "If you were to have a mouse button as a modifier..." then you could press Ctrl mapped pedal with your leg, and hit a key with your hand. Since I wrote this entire post with one hand (nothing extreme so far, the other is "simply" broken) , I can tell for sure it would be a big relief.

(And one note: those not-popular devices are aimed for handicapped people, but they could be useful for all, to boost productivity -- here, speed of input.  In theory, we don't have software).

<<I have also asked the KDE Core Developers whether they agree with me that "this bug is just not worth it">>

It helps to get a new perspective for developers (core, or not) to sit on one hand while replying to such question.

> If you were to have a mouse button as a modifier, you're still involving both
> hands (one on the mouse, the other on the keyboard to press the "Modified"
> key.)

Actually, the OP give the example of moving a window with _only_ the mouse should this wish be implemented. Therefore, _not_ resolving it means that we must use two hands for this common operation instead of one (unless you are able to grab the title bar, which some KDE users don't have (it saves screen space) or cannot do (disability, I happen to know at least two users like this).

That said, I understand the technical reasons for closing the bug. I do not oppose the close.


> Both hands? Boy you are lucky. How about one hand and a leg? Or how about just
> one hand?

Actually, due to manual disability I cannot press two buttons on the keyboard at once. I use the Sticky Keys feature. It is far from perfect (lots of tangential issues crop up that are not fixed to due "not worth it for most users") but it certainly helps.

Maciej, and Dotan: I am not AT ALL offended by the fundamental issue on which you have focused: This is not merely a convenience for one-handed people, it would be a significant enabling technology. Thanks, it IS awfully tough for a one-handed person to press even one modifier key when the regular keystrokje will be out of reach; TWO modifiers (for example, the classic Ctrl-Alt-Del combination) are even worse.

I'll try to imagine a reliable way, and re-open, after bug 96431 is fully resolved. Todd says that it is already done, but I will study whether that finished work covers ALL the capabilities which I desire to see in the KDE-Next Version.

Since I'm the only person who would even consider "stepping up" on this one, and I've got other priorities which will consume at least a few months, I want to designate this as WONTFIX for now. But it's my bug, and I CAN re-open this Bug, when I become able to accomplish coding and testing which leads to the requested feature. But, with limited time and other priorities, that might never happen.

I'm the only person who has even conceived of building an actual implementation for this (in nearly 10 years). If anyone ELSE wants to work on the feature request, I'll be delighted to re-open and hand the bug to that Developer. But right now, the only candidate seems to be me- and I don't have the time. I changed the Status to clearly indicate the choice I have made, rather than leave the bug in a State of "uncertain neglect" for another 10 years.

It's bad news, but it's better to make my decision openly- I think.

(In reply to comment #42)
<< snip >>

> Actually, the OP give the example of moving a window with _only_ the mouse
> should this wish be implemented. Therefore, _not_ resolving it means that we
> must use two hands for this common operation instead of one...

Not exactly. The difference, which I see in this case, is that you want to use a mouse button for a single, well-defined Window Action. That is DEFINITELY going to be shortcut-able, lies in the realm of BugID 96431 (enhancing the selection of Button and Button/Keyboard combinations as shortcuts). Our set of Actions themselves is going to be a target-- turning on "move Window", or turning on the "Send to another Desktop" pop-up, or even closing the Window by button click (instead of dragging all the way up to the Titlebar "X", or the File->Quit MenuItem) should be Action choices!

In contrast, The problem in this bug is that we want the Modifier "Button" to work as a Modifier with _ANY_ group of other keys- including other Modifier
keys! There are many hundreds of combinations in the "general case" which this BugID is about.

<< snip >>
> Actually, due to manual disability I cannot press two buttons on the keyboard
> at once. I use the Sticky Keys feature. It is far from perfect (lots of
> tangential issues crop up that are not fixed to due "not worth it for most
> users") but it certainly helps.

I am sorry to hear of your disability, and I DO anticipate that we can do some
things to make your computer use easier and faster. But my priority, after some additional mouse follow-up in Qt, concerns the capabilities in the shortcut system itself. As you just read, I'm concerned with missing stuff on both sides- the invoking keys/buttons, AND the list of resulting Actions which we can choose from.

> I am sorry to hear of your disability, and I DO anticipate that we can do some
> things to make your computer use easier and faster. But my priority, after some
> additional mouse follow-up in Qt, concerns the capabilities in the shortcut
> system itself. As you just read, I'm concerned with missing stuff on both
> sides- the invoking keys/buttons, AND the list of resulting Actions which we
> can choose from.

Thanks, Rick.  I did not mean to come off as apprehensive, rather, I intended to show support for your decision. There is a difference between enabling handicapped users and making things easier for handicapped users. KDE and Qt have very much enabled handicapped users, the things that are left are just to make things easier, for handicapped users and for the healthy as well. Your hard work and dedication is noticed and appreciated!

(In reply to comment #42)
> 
> Actually, due to manual disability I cannot press two buttons on the keyboard
> at once. I use the Sticky Keys feature. It is far from perfect (lots of
> tangential issues crop up that are not fixed to due "not worth it for most
> users") but it certainly helps.

Dotan, can you explain (with as much detail as possible!) how replacing sticky keys with a mouse button toggle capability would make things better for you?

Here's my scenario: On one of your Plasma panels, you would install the 'sticky mouse' Applet. It would show the current State of your toggle buttons: Whether Ctrl is 'DOWN' or 'UP', whether Shift is 'Down or 'Up', and so on-- with size sufficient to show all of the 'sticky mouse' button choices which you have configured.

When *none* of your 'sticky mouse'

(finishing that comment)

When *none of your 'sticky mouse' settings is active, the Applet minimizes itself -- sort of like Clock/Calendar doing pop-up, pop-down of the full Calendar (versus just the clock) when you click it. But in those case, Pop-up versus minimized State would be automatic.

The need for this "visible feedback" of Mod-Key State comes from two things, I think: #1, I'm guessing that one of the main sources of trouble in your use of sticky keys is the timer- it shuts off too fast for you to hit another "Sticky" mod key, AND another key, with precision?. (Or, conversely it maybe stays on for too long, forcing you to make an unnatural delay in your work?)

With the Sticky-keys mouse Applet, the Mod-key would remain active until you turn it off with a second click, right?
- - - - -
Maciej, I'd like to hear from you too. And anyone else who would like to help define exactly how this would work, AND be MORE beneficial than sticky keys: Please jump in and explain the need- if you convince me, then I will try to convince Qt to accept the changes which we would need to support this within KDE-next.

Thank you for the interest. I stress that this is not a major accessibility issue for me, though it may be for others. My major accessibility issues are elsewhere.


> Dotan, can you explain (with as much detail as possible!) how replacing sticky
> keys with a mouse button toggle capability would make things better for you?
> 

The major useful situation that I envision is the keyboard-and-mouse combinations, such as shift-clicking or ctrl-clicking to select multiple files, or alt-dragging to move a window. Keyboard users rarely need the mouse, but it seems like a lot of mouse-only activities (such as selecting multiple files) do require another paw on the keyboard.
 

> With the Sticky-keys mouse Applet, the Mod-key would remain active until you
> turn it off with a second click, right?
> 

I would suggest that it stay active until an action is performed with it, just like regular sticky keys. The applet need not disappear, either, as the regular sticky keys applet does not disappear.

Again, I stress, although this would be a nice-to-have feature, for me it is not a major issue. It may be a major issue for users such as Maciej though. There certainly are other areas that can be improved. If you would like to discuss that in private mail I'll be happy to offer what advice that I can!

I am closing the prerequisite https://bugs.kde.org/show_bug.cgi?id=96431 , because the scope of work and performance costs are too much.

HOWEVER: I do feel that KDE should create some HIG guidelines for high-numbered mouse buttons, and (possibly) mouse buttons held and clicked in particular combinations:

The example above (selecting multiple files with the mouse ALONE) could certainly be included, with a particular 'high button' number designated for this purpose, and implemented in the standard "file chooser" component from Dolphin.

ALSO NOTE: Mouse Event Handling, unlike Keyboard event handling, enjoys automatic 'escalation' through parent widgets. (I don't know if "nested" QML MouseArea elements have the same capability, but they should.) Thus, if you want to create an "application-wide shortcut", you need only handle the event at the highest Window Frame - the mouse event will be passed, up and back, until it reaches that Event handler.