GNOME Bugzilla – Bug 759725
Setting Container:border-width on TextView breaks gesture positions
Last modified: 2017-08-29 17:59:25 UTC
Steps to reproduce: - open a new workbook - insert a rectangle object - double-click on it - go to "content" and insert some text - try to select the whole text with the mouse, from the left to the right => it is impossible to select the first character
It is not impossible, just not that easy. Not sure why, we just use a GtkTextView there, nothing specific to gnumeric.
Hmm, I have no problem at all with selecting it. It is also not difficult at all...
For me, clicking on a character always puts the cursor after the character even if the click occurs on the first pixel. Might be a new Gtk+ feature.
(In reply to Jean Bréfort from comment #3) > For me, clicking on a character always puts the cursor after the character > even if the click occurs on the first pixel. Might be a new Gtk+ feature. I can confirm this on the gnumeric distributed with Debian Jessie; I've not tried unstable yet. However, this is not an innate problem with GtkTextView; I can't reproduce it with basic test cases in GTK+ alone. So we'd need more info about what gnumeric does here.
*** Bug 781987 has been marked as a duplicate of this bug. ***
I'm sure we're not doing anything special. I can select the first character with a right-to-left motion of the mouse (ie., from the back), but not with a left-to-right motion.
Actually, we are doing something mildly special in that we are setting a border width for the view: gtk_container_set_border_width (GTK_CONTAINER (gtv->view), 5); That's a dead kitten, btw.
Created attachment 358601 [details] test case showing Container:border-width breaking text selection It sure is! And it's the culprit here. Attached is a test case with 16 px of Container:border-width, showing that the issue affects all sides. It seems like the border-width causes the dragged coordinate to be shifted both rightwards and downwards before the text is selected (or not, as the case may be).
We can just fix it with: g_object_set (G_OBJECT (gtv->view), "margin", 5, NULL);
Created attachment 358634 [details] [review] TextView: Fix gesture coords with :border-width >0 Container:border-width caused the x/y coords converted to iters to be offset inwards by that width, breaking positioning/selecting by gesture. Fix by subtracting the :border-width in _widget_to_text_window_coords(). -- As noted here, this broke all kinds of gesture positions, not just selecting.
Created attachment 358636 [details] [review] TextView: Fix gesture coords with :border-width >0 Container:border-width caused the x/y coords converted to iters to be offset inwards by that width, breaking positioning/selecting by gesture. So, subtract :border-width in widget_to_text_window_coords(). This fixes gesture positions, & plays fine with :margin & CSS margin/border/padding N.B.: This is not to endorse :border-width. It’s gone in GTK+ 4 & weird on a TextView: it’d be more intuitive to – if you must! – set it on the TV parent. Really, please just use CSS instead. Still, it’s easy to fix.
Attachment 358636 [details] pushed as bd7c87c - TextView: Fix gesture coords with :border-width >0
There might be a follow-up commit required for conversion of coordinates in the opposite direction, window to widget coords, but I need to test that separately.