GNOME Bugzilla – Bug 738894
GtkPaned/GtkTextView: mouse cannot position text cursor before 1st column of text
Last modified: 2020-11-24 09:59:56 UTC
Gedit 3.14.1-2 Adwaita Theme Window/GTK+/Cursor & Gnome Icons Open text file with Gedit - with mouse cannot position cursor to LHS of text line - only to after first character. The "move vertical" between LHS frame showing files and the text shows the move cursor from around 1 pixel to the left of the line to around 4 pixels into the text area.
Actually 3.14.0-2 - pity I can't find a "Help - About"
hi, you can find help/about in the app menu ( on the gnome shell topbar ) Can you attach a screenshot please ?
I have moved this to GTK+ as I think the issue is with GtkPaned The problem seems to be that the range for the separator "picking up" the cursor position has a minimum which is too large for thin separators. It was reported under gedit because that was the program it first appeared in - as the cursor approached the separator "left-wise" from within the right pane it is picked up by the spearator before it has reached the position before the first character on the line - therefore it is impossible to position the cursor before the first character on a line by using the mouse - that makes it a "major" issue in my book whislt in other apps such as nemo, thunderbird, uGet etc it is just an annoyance so far. I haven't attached a screenshot because they do not appear to show the cursor. I gave discovered the gedit help-about - it was on the other monitor!
*** Bug 739848 has been marked as a duplicate of this bug. ***
The workaround in gedit is to show the line numbers. The bug occurs only when the text is collapsed to the GtkPaned separation. I think it's a regression of bug #735009.
I think the best way forward here is to just add some margin to the text to avoid it running into the splitter. That has the advantage that it looks better, too
(In reply to Matthias Clasen from comment #6) > I think the best way forward here is to just add some margin to the text to > avoid it running into the splitter. That has the advantage that it looks > better, too Just a +1 to fixing this, I have this issue in my application as well (https://github.com/gnunn1/terminix/issues/127), unfortunately I'm using the VTE widget which AFAIK does not support internally padding the text. While I can add margin to the VTE widget, visually it doesn't work well since I'm supporting transparency in the VTE. Adding margin results in a strip of solid grey in the margin area from the underlying Box. I looked at working around this issue in my app by setting the VTE transparent and applying the background color to the underlying Box but it makes the code unnecessarily complicated to cover some of the more complex scenarios I have and gets in the way of delivering other future features I have planned. This can be worked around by using a wide handle in GtkPaned but visually it is not very appealing.
there is no fix in gtk for this; I would recommend moving this bug back to gedit
Isn't this a GTK bug though in that the GtkPaned has an overly large mouse grab area when not using the wide handle? If it is fixed in GTK it fixes for all applications that have this issue, including mine, and not just gedit.
the area is intentionally large enough that you can hit it
Mass-closing of all gedit bugzilla tickets. Special "code" to find again all those gedit bugzilla tickets that were open before the mass-closing: 2bfe1b0590a78457e1f1a6a90fb975f5878cb60064ccfe1d7db76ca0da52f0f3 By searching the above sha256sum in bugzilla, the gedit contributors can find again the tickets. We may be interested to do so when we work on a specific area of the code, to at least know the known problems and possible enhancements. We do this mass-closing because bugzilla.gnome.org is being replaced by gitlab.gnome.org.