GNOME Bugzilla – Bug 385695
want API to convert screen coordinates to logical (row/col) coordinates
Last modified: 2015-12-26 12:44:29 UTC
sometimes when you right click on a link in the terminal the "show link" item isn't on the context menu. of course, as soon as you go to try again it works fine. this has annoyed me for ages (since it causes me to click "new terminal" instead). i finally figured out where the problem is. approach a url from the bottom. until it just barely becomes underlined. click the right mouse button and notice the lack of "open link". it seems that the bottom couple of pixels that result in the link being underlined do not result in the "open link" item being added to the context menu.
it's actually exactly 1 pixel. sure enough, if you position the mouse above the underlining zone by one pixel the menu item *is* there (when it should not be).
the problem is caused by gnome-terminal naively assuming that it can figure out column/row by taking x/y and dividing by the font width/height. this calculuation doesn't take VTE_PAD_WIDTH into account. of course, gnome-terminal has no way of knowing about VTE_PAD_WIDTH since it's in vte-private.h. this is more or less a vte API bug...
Created attachment 81639 [details] [review] Perform the event translate on behalf of g-t Would this be appropriate?
i was thinking about an API to let g-t give vte the x/y coordinate of the click directly instead of converting it and then making another call into vte. this API is quite fine, though, and will allow g-t to do other things with the information (should it have the need).
Chris, Notes about the API: 1) Why does it have to take doubles? Doesn't make sense to me. 2) If taking int, you possibly can use a single pair as input/output args. But I agree that row+col instead of x+y is more readable (those confusing also because row is y, not x.) 3) I prefer, and I think is more useful, to clamp the mapped position to within the terminal. Similar to pango_layout_xy_to_index().
And I think it can use a better name. transform_position instead of translate_position to start with. xy_to_rowcol maybe! Do we need the other direction too? To get bounding box of a cell?
I chose a pair of doubles because that maps closely with GdkEventButton which passes around the mouse coordinate as a pair of doubles. vte_terminal_xy_to_rowcol(), vte_terminal_rowcol_to_rectangle()? Couldn't immediately see a use for the cell bbox so I didn't include it the first time. Silly example might be if the host application wished to overlay GtkWidgets over a set of cells.
(In reply to comment #7) > I chose a pair of doubles because that maps closely with GdkEventButton which > passes around the mouse coordinate as a pair of doubles. > > vte_terminal_xy_to_rowcol(), vte_terminal_rowcol_to_rectangle()? > > Couldn't immediately see a use for the cell bbox so I didn't include it the > first time. Silly example might be if the host application wished to overlay > GtkWidgets over a set of cells. Well, if we don't want apps to guess the conversion, we need to provide both ways. Should the rowcol_to_rectangle() take double-width chars into account? Not sure. And what type should it return? GdkRectangle()?
Regarding the original issue: the API Ryan was missing is just vte_terminal_get_padding plus a division by 2 ;-)
hah. go figure. for the record: i still think the new API would be nice.
/me too. _xy_to_rowcol is the way to do this cleanly.
*** Bug 481037 has been marked as a duplicate of this bug. ***
The original bug is fixed in g-t svn trunk; retitling.
Is this still interesting?
not worth it i think. you can just take the x/y, subtract the padding and divide by the font size. the fact that this trivial addition has been left for so long with nobody really caring about it is a good indication. :)
Reopening; I'm going to add this on vte-next.
ping?
I think ChPe is kinda away. Feel free to give it a try, Ryan.
This is done on vte-next. Do you need something like it right now on vte-0-32 ?
Nope. Feel free to close as FIXED (or do so when you land the branch).
This is obsolete. We now do the check by passing the GdkEvent to vte, which then translates the coordinates internally taking into account the padding. If another use case for view/grid coord transforms emerge, we can reconsider this, but for now, it's WONTFIX/OBSOLETE.