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 605466 - In GTKTextView selection by double-clicking should be from the other side(from left to right)
In GTKTextView selection by double-clicking should be from the other side(fro...
Status: RESOLVED OBSOLETE
Product: gtk+
Classification: Platform
Component: Widget: GtkTextView
2.8.x
Other All
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2009-12-26 07:33 UTC by iorlas
Modified: 2018-02-10 03:30 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description iorlas 2009-12-26 07:33:27 UTC
History:
I want to use gtksourceview for the one project, but many my friends don't like some small things in this widget, because they use keyboard as main input device.
I started looking for a solution of these problems.
Now, i want to fix problem of selecting by double-click.

Best way to see problem:
1) write "my cool textview" in gtkTextView widget
2) double-click on "cool"
3) press "shift" and press right arrow key

Cursor starts to moving from _start_ to end and further in right side.
This is because selecting on double/tripple-click starts selecting from _end_ of word/line to start. Insert mark at first char, "bounce" marker at end.
I spend some hours for searching problem code, and i found it in gtktextview.c gtk_text_view_start_selection_drag():

...
orig_start = ins; //this is insert mark
orig_end = bound; // this is "bound" mark
...
gtk_text_buffer_select_range (buffer, &ins, &bound);
...

My solution - swap ins and bound in function call and variables assignment. But, it is a good solution? Or i missed something?
Comment 1 Christian Dywan 2010-01-04 06:08:43 UTC
The problem here is that if you use Shift + Left arrow it does extend the selection, just like you want. So your "solution" will as much fix as it will break the behaviour.

A proper solution would be to a) always extend the selection, without relying on the direction of the selection b) provide a keyboard shortcut to do the opposite.
Comment 2 iorlas 2010-01-04 16:38:54 UTC
>The problem here is that if you use Shift + Left arrow it does extend the
selection, just like you want.
No! I want to use Shift + Right arrow to select my text from this widget, like in other gtk widgets!
Why GTV need to be "special"?

>So your "solution" will as much fix as it will break the behaviour.
I really want to change this behaviour.

>a) always extend the selection, without relying on the direction of the selection
But in which side? Left(like now) or right(like other gtk widgets)?

>b) provide a keyboard shortcut to do the opposite.
How i can change side of selection? Give me link to functions in reference, plz. So i cant find it.
Comment 3 Christian Dywan 2010-04-01 23:20:09 UTC
In fact it was when the question of selection behaviour came up in WebKitGTK+ that I realized that GtkEntry and GtkTextView behave in opposite ways. So now I do think, even if the direction is arbitrary, it should be consistent on the platform.
Apparently Qt always behaves like GtkEntry, and like iorlas proposes GtkTextView should behave. So I think we should indeed change GtkTextView accordingly.
Comment 4 Matthias Clasen 2018-02-10 03:30:51 UTC
We're moving to gitlab! As part of this move, we are closing bugs that haven't seen activity in more than 5 years. If this issue is still imporant to you and
still relevant with GTK+ 3.22 or master, please consider creating a gitlab issue
for it.