htop-dev
Right click decrements option value even when mouse cursor is outside the option
This UI issue came up after the merge of PR #1732, and I think it's worth raising it (as a regression), to further discuss the UI/UX aspect of the changes.
Steps to reproduce:
- Start htop
- Go to (F2) Setup -> Display options
- In the list of display options, make sure "Enable the mouse" is checked/enabled.
- Then scroll further down to select a numeric option, for example "Update interval (in seconds)"
- With the "Update interval (in seconds)" highlighted/selected, move the mouse cursor to outside the "Display options" panel, and then right click.
- With the mouse cursor still outside, left click.
Actual result:
The right click in step 5 decrements the "Update interval" value by 0.1, but the left click in step 6 does nothing.
The behavior should at least be consistent. While I personally suggest both left click and right click should do nothing, this can be discussed further. It's that the solution in #1732 was half-baked that I complain.
It only increments / decrements when the line is selected. Just like it did before with F7 / F8 (and increment on mouse click).
@fasterit The point is when the mouse cursor is outside the selected item. The user would expect the right mouse button triggers an event of the item on the mouse cursor and not the selected/highlighted item.
People expect different behavior between the keyboard button and the mouse button, as keyboards and mice are different input devices.
How can they have any expectation of what the right mouse button does?
- htop never knew to use the right mouse button until yesterday
- there is no best-practice / design / UX expectation for ncurses and right mouse buttons
- some DEs will hijack it anyways for context menus
The right click to revert the left click is mostly an accessibility feature for people that have a hard time using a keyboard. As F7 and F8 are often not mapped, we support "+" and "-" already. And we accidentally supported "left mouse button" and now we support that a bit more logical and also "right mouse button". Consider it symmetry.
There are game engines that do it like that and it used to be a pattern when Athena was a top notch UI. Yes, I am that old. We don't have context menus in htop. Once we get these, I'll accept your locality of interaction argument.
- there is no best-practice / design / UX expectation for ncurses and right mouse buttons
- some DEs will hijack it anyways for context menus
The user expectations are actually from GUI, and the "right mouse button opens a context menu" are carried to terminal emulators as well. Because terminal emulator apps in many DEs do take right mouse button for the context menu as you said, it makes a strong reason that applications not to overload the right mouse button for an unrelated action.
The right click to revert the left click is mostly an accessibility feature for people that have a hard time using a keyboard. As F7 and F8 are often not mapped, we support "+" and "-" already. And we accidentally supported "left mouse button" and now we support that a bit more logical and also "right mouse button". Consider it symmetry.
No no no. That "symmetry" only applies to video games. Desktop applications almost never use this "left & right mouse button symmetry" for a few reasons.
- There were single button mice that Apple introduced them as early as in the original Macintosh. Early GUIs were designed to be operable with single mouse button and that principle still applies today.
- Tablet and phone users don't have access to the "right mouse button" at all. What they have is a "tap" and a "hold for context menu". Note that there is no "button symmetry" here.
- Laptop touchpads have access to what's equivalent to the "right mouse button" but they are not designed with "symmetry" either.
You can try operating htop with a touchpad to get what I mean.
There are game engines that do it like that and it used to be a pattern when Athena was a top notch UI. Yes, I am that old.
As I said before, video games are special. Many video game UI conventions don't carry to applications designed for productivity.