-
-
Notifications
You must be signed in to change notification settings - Fork 818
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
gui: improve mouse text selection #1805
Conversation
* implement mouse press capture between the terminal and UI, so when you start selecting text from the terminal the tabs won't activate and vice-versa * selecting from the top and bottom lines won't scroll the viewport anymore, it will only scroll if the mouse is moved out of line bounds * change cell selection so that it behaves like text selection usually does in other popular software refs: wez#1199 refs: wez#1386 refs: wez#354
@wez What do you think of this approach for testing? |
@@ -36,8 +36,8 @@ pub struct MouseEvent { | |||
pub kind: MouseEventKind, | |||
pub x: usize, | |||
pub y: VisibleRowIndex, | |||
pub x_pixel_offset: usize, | |||
pub y_pixel_offset: usize, | |||
pub x_pixel_offset: isize, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't have time for a full review right now, but this caught my eye: why is the type changing? I'm pretty sure that this can never legitimately be negative. @AutumnMeowMeow: can you confirm?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The idea is for them to be able to have negative values, to encode information about the mouse leaving the area. For instance, y = 0 means that the cell is the top one, and y pixel offset = -10 means the mouse is 10 pixels above that cell. They'll only have negative values when x/y are = 0.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(Sorry if incoherent, watching Matrix 4 while drunk... 🍷🔫🔫🔫👭🔫🔫🔫🔫🔫🔫🔫🔫🔫👭🔫🔫🔫🔫🔫🔫🔫🔫🔫💞💞)
The terminal should not be reporting negative values (they are required to be positive in CSI sequences), but at one point xterm itself was reporting negative when the mouse was captured (button down) and dragged above the top-left corner of the text area -- when using SGR-Pixel mode. I didn't report that as a bug, someone else might have. Let's see if I can find that thread.... here: contour-terminal/contour#574 (comment) Of course j4james is the real expert. :-)
Within wezterm, the offset values could work the same whether positive or negative values.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note that the negative offset is only used internally/where it makes sense, in other places I've clipped it to positive only values, like here:
wezterm/term/src/terminalstate/mouse.rs
Line 72 in be567fb
(event.x * (self.pixel_width / width)) + event.x_pixel_offset.max(0) as usize + 1, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On the topic of those offsets, they have an unexpected (to me) behavior, so I'm not sure if it's a bug or could have weird side effects. These are the values reported:
The blue cells are what is reported in the x
property, because of the rounding here:
wezterm/wezterm-gui/src/termwindow/mouseevent.rs
Lines 85 to 87 in be567fb
// Round the x coordinate so that we're a bit more forgiving of | |
// the horizontal position when selecting cells | |
x.round() |
x_pixel_offset
is calculated based on the real cell, so the reported cell, offset
are not in sync.
I'm thinking maybe it would be better to always report the real cell and offset, and let the code that's using them do the relevant processing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@AutumnMeowMeow: what do you think about these positioning offsets; are they actually what you want to see in the report sent to your app?
I think it looks good! Just the right amount of trait use IMO. There are some selection bits in the |
Anyway, I'll create another PR for the tests and some other related changes, so this one is ready for merging (as soon as all discussions are resolved). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this looks good! Thanks!
Thanks! |
start selecting text from the terminal the tabs won't activate and
vice-versa
anymore, it will only scroll if the mouse is moved out of line bounds
does in other popular software
refs: #1199
refs: #1386
refs: #354
possibly: #1589