https://bugs.kde.org/show_bug.cgi?id=422096

            Bug ID: 422096
           Summary: Right-click often performs the first action in the
                    context menu on high-DPI displays
           Product: krita
           Version: 4.2.9
          Platform: MS Windows
                OS: Microsoft Windows
            Status: REPORTED
          Severity: normal
          Priority: NOR
         Component: Usability
          Assignee: krita-bugs-n...@kde.org
          Reporter: m...@chrismorgan.info
  Target Milestone: ---

STEPS TO REPRODUCE
1. Open the timeline panel (as a good example of this problem).
2. Move the mouse cursor over a layer, and press the right mouse button down.
3. Observe the context menu opens (which is wrong by Windows platform
standards—it should instead open on mouse up, which would incidentally fix the
bug).
4. Also observe that a fair fraction of the time it opens *with the first
context menu item (New Layer) selected* (which is hopefully wrong everywhere).
5. Release the right mouse button.

OBSERVED RESULT
The action (New Layer) is performed, if the first item in the context menu is
focused. (If that didn’t happen, move the mouse somewhere else and try right
clicking again.)

EXPECTED RESULT
The context menu should have opened and stayed open, as I hadn’t moved the
mouse at all, but just right clicked.

SOFTWARE/OS VERSIONS
Krita 4.2.9 (x64)
Windows 10
Qt 5.12.7
Hardware: Surface Book, scaling factor of 200%

ADDITIONAL INFORMATION
I suspect that the focusing of the first item in the menu occurs on high-DPI
devices only, something to do with rounding of pixel positions so that in some
positions it opens the menu less than one logical pixel above and to the left
of the cursor, so that the when the menu opens the cursor is already hovering
on the first menu item, when it should have been at least one physical pixel
above and to the left of it.

This is extremely irritating because it makes right clicking unreliable.
However, it can normally be worked around: most laptop touchpads will either
have a physical button that you can right-click-and-hold (and then move the
cursor before releasing), or have pressing in the bottom right corner of the
touchpad act as the right mouse button. But I suspect there are devices out
there incapable of right-click-and-hold, which would make this very bad.

On an earlier point: I know Windows conventions: all actions resulting from
mouse events (e.g. click button, right click context menu, do something with
dragged file, &c.) take place on mouse up, and NEVER on mouse down (I hereby
deem beginning dragging something not an action; 😛). I have no idea about other
platform standards, least of all KDE. I have kdenlive installed, and it opens
some context menus on mouseup (e.g. timeline) and some on mousedown (e.g.
project bin). Eww, such inconsistency!

-- 
You are receiving this mail because:
You are watching all bug changes.

Reply via email to