After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 73307 - (split-cursor) Non-split (jumping) cursor problems
(split-cursor)
Non-split (jumping) cursor problems
Status: RESOLVED WONTFIX
Product: gtk+
Classification: Platform
Component: Widget: GtkTextView
1.3.x
Other Linux
: High normal
: Medium API
Assigned To: Behdad Esfahbod
gtk-bugs
Depends on: 101380
Blocks:
 
 
Reported: 2002-03-03 19:44 UTC by Owen Taylor
Modified: 2015-08-05 22:25 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Patch partially dealing with virtual cursor problems (4.08 KB, patch)
2002-03-03 19:47 UTC, Owen Taylor
none Details | Review

Description Owen Taylor 2002-03-03 19:44:29 UTC
1) Virtual cursor positioning acts with respect to the strong cursor
   not the visible cursor.

2) Clicking at a position positions the strong cursor there, not the
   visible cursor. (This also affects GtkEntry, GtkLabel.)

Fixing this probably requires GtkTextLayout API extensions and possibly
also Pango API extensions to do the "x => weak cursor at x" mapping,
since we don't export information from the weak log2vis table though
we have code in PangoLayout to compute it.
Comment 1 Owen Taylor 2002-03-03 19:47:30 UTC
Created attachment 6949 [details] [review]
Patch partially dealing with virtual cursor problems
Comment 2 Luis Villa 2002-12-05 22:54:23 UTC
Making all 'high' textview bugs 2.2.0 as per havoc's request.
Comment 3 Federico Mena Quintero 2004-01-13 21:05:57 UTC
Adding PATCH keyword.
Comment 4 Owen Taylor 2004-02-21 17:22:53 UTC
See discussion in bug 101380 of why an important component
of this is probably switching the cursor direction on click
within text.
Comment 5 Behdad Esfahbod 2006-09-18 20:41:59 UTC
CC myself.
Comment 6 Behdad Esfahbod 2006-09-18 20:42:34 UTC
I'm willing to fix this as soon as I figure out what this is all about :-).
Comment 7 Owen Taylor 2006-09-18 21:02:42 UTC
Just turn on jumping cursor mode, try it some, and I think what I'm
saying above will make more sense. When you click-to-select, navigate 
with the arrow keys, etc, the natural assumption is that you are
moving the visible cursor, but that is frequently violated now.


Comment 8 Behdad Esfahbod 2006-09-18 21:12:44 UTC
The problem is, being a native bidi user, I still don't quite understand the strong and weak cursors (ok, I think I now, but they really should follow my keymap direction to make sense.)  And don't know what visual cursor is for sure.  How do I turn jumping cursor mode on?
Comment 9 Owen Taylor 2006-09-18 22:38:56 UTC
History:

After I implemented the current default split cursor support, I played
around with it some and thought:

 "Wow, I'm really confused. Maybe it will make more sense to 
  a native bidi user, but I doubt it."

So, once we got some keyboard group detection code into place I tried 
implementing jumping-cursor mode. The basic idea of jumping-cursor mode
is "show whichever of the strong or weak cursor corresponds to the 
current keyboard direction." You can turn this on by putting 
gtk-split-cursor = 0 in your ~/.gtkrc.

However, once I had that implemented, I discovered that just showing
and hiding the cursor wasn't enough ... it was necessary to modify
navigation as well. The current navigation code always navigates the
strong cursor, but that's really confusing when the strong cursor
is invisible. That was more work than I was prepared to do at that
point, so I filed this bug and moved on.

At some later point, I realized that for click-to-position, the behavior
of positioning the visible cursor at the click position might not
be the natural one. The users choice of where they click actually
is a stronger indication of what they are planning to do than the
current keyboard layout. So instead you might want to switch the
keyboard layout. That's what bug 101380 is about.
Comment 10 Behdad Esfahbod 2006-09-18 22:48:36 UTC
Owen, thanks for the detailed history.  However, putting gtk-split-cursor = 0 in ~/.gtkrc doesn't make any different here.  I remember testing that before to the same conclusion.  Will investigate later.  Thanks again.
Comment 11 Matthias Clasen 2015-08-05 22:25:08 UTC
Investigation never happened. 9 years later, time to close