GNU TeXmacs - Bugs: bug #60905, Right-click menu displays the...
You are not allowed to post comments on this tracker with your current authentication level.
bug #60905: Right-click menu displays the options for where the cursor is rather than for where you click
Submitter: | Gennady Uraltsev <guraltsev> | ||
Submitted: | Sat 10 Jul 2021 02:55:34 PM UTC | ||
Category: | User Interface | Priority: | 5 - Normal |
Item Group: | Wishlist | Status: | None |
Privacy: | Public | Assigned to: | None |
Originator Name: | Open/Closed: | Open | |
Release: | None | Release: | 2.1 |
Fixed Release: | None | Fixed Release: | |
Keywords: |
No files currently attached
Depends on the following items: None found
Items that depend on this one: None found
Carbon-Copy List
There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
No changes have been made to this item
When using the mouse to do operations, often the menu is displayed for elements other than what one would expect. It is standard for GUIs to open menus for the object where the click occurs rather then for where the text cursor is. TeXmacs does the latter.
To reproduce:
- Make a 3x3 table and put some data into each slot.
- Position your cursor in the slot (1,1) (upper left).
- Right click on the slot (3,3).
- In the menu, subsection Cell, choose horizontal alignment and change it to some value.
Result:
- The horizontal alignment gets changed for cell (1,1) where the cursor is rather than the slot (3,3) where you clicked.
Expected behavior:
- The horizontal alignment gets changed for cell (3,3) where you clicked. Most GUI programs would NOT move the cursor but a solution that moves the cursor to slot (3,3) would be ok. It would be best to "restore" the position of the cursor to (1,1); this is how most GUI programs actually behave.
Current workaround:
- every time you want to access the menu FIRST left click (moving the cursor) THEN right click (opening menu).
- this workaround does not restore the original pointer location.
Impact:
This is actually a recurrent issue with a mouse-based workflow
Obviously, a keyboard-centric workflow does not suffer from this issue.