GtkTreeView keyboard binding are not intituive

[Damián Nohales]

Most GUIs, like MacOS X, Microsoft Windows and Qt handle the keyboard bindings
for its treeviews in the same way: user can easily expand, collapse and move
into tree nodes using only the arrow keys.

In Gtk+, however, is quite different. User needs to press "plus" and "minus"
key to collapse and expand nodes, leaving Right and Left arrows with
essentially null functionality. Well yeah, that keys allow to move horizontally
into row cells.
Seeing many of the applications written using Gtk+, there are not many cases
where user find useful moving horizontally across the row with the keyboard,
most GtkTreeView that I see are simple and used only to show information.
So I guess the current GtkTreeView behaviour is crazy, not useful in most
cases, goes against intuition and against good User Experience.

I'm really not familiar with Gtk+ programming but, as user, I find this "bug"
extremely annoying in my day to day.

So, I make some changes in Gtk+ to enhance (from my point of view) the behavior
of GtkTreeView with the keyboard.

The attached patch to the 3.4 branch modifies the default GtkTreeView behaviour
with the keyboard, expanding nodes with the right arrow and collapsing it with
left arrow, selecting parent and child nodes when appropriate:
 - When user press Left on a collapsed node, Gtk+ select the parent node.
 - When user press right on an expanded node, Gtk+ select the first child node.
Users that want to navigate into cells horizontally (as I can see, a non
frecuent use case) will need to press Ctrl+<Left|Right>. Users can still move
to the parent node with the Backspace key, without collapsing anything.

I don't know exactly if this behavior change break some expected behavior to
application programmer, I hope not.

A last question, Why Gtk+ programmers implemented the current GtkTreeView behavior
knowing the big difference with other tested GUIs?

Best Regards!

[Damián Nohales (damiannohales)]

Most GUIs, like MacOS X, Microsoft Windows and Qt handle the keyboard bindings for its treeviews in the same way: user can easily expand, collapse and move into tree nodes using only the arrow keys.

In Gtk+, however, is quite different. User needs to press "plus" and "minus" key to collapse and expand nodes, leaving Right and Left arrows with essentially null functionality. Well yeah, that keys allow to move horizontally into row cells.
Seeing many of the applications written using Gtk+, there are not many cases where user find useful moving horizontally across the row with the keyboard, most GtkTreeView that I see are simple and used only to show information.
So I guess the current GtkTreeView behaviour is crazy, not useful in most cases, goes against intuition and against good User Experience.

I'm really not familiar with Gtk+ programming but, as user, I find this "bug" extremely annoying in my day to day.

So, I make some changes in Gtk+ to enhance (from my point of view) the behavior of GtkTreeView with the keyboard.

The attached patch to the 3.4 branch modifies the default GtkTreeView behaviour with the keyboard, expanding nodes with the right arrow and collapsing it with left arrow, selecting parent and child nodes when appropriate:
 - When user press Left on a collapsed node, Gtk+ select the parent node.
 - When user press right on an expanded node, Gtk+ select the first child node.
Users that want to navigate into cells horizontally (as I can see, a non frecuent use case) will need to press Ctrl+<Left|Right>. Users can still move to the parent node with the Backspace key, without collapsing anything.

I don't know exactly if this behavior change break some expected behavior to application programmer, I hope not.

A last question, Why do you implemented the current GtkTreeView behavior knowing the big difference with other tested GUIs?

Best Regards!

[Damián Nohales (damiannohales)]

Created attachment 217896
treeview: change keyboard bindings behaviour

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "0001-treeview:-change-keyboard-bindings-behaviour.patch" of this bug report has been identified as being a patch. The ubuntu-reviewers team has been subscribed to the bug report so that they can review the patch. In the event that this is in fact not a patch you can resolve this situation by removing the tag 'patch' from the bug report and editing the attachment so that it is not flagged as a patch. Additionally, if you are member of the ubuntu-reviewers team please also unsubscribe the team from this bug report.

[This is an automated message performed by a Launchpad user owned by Brian Murray. Please contact him regarding any issues with the action taken in this bug report.]

[Kris-z (kris-z)]

(In reply to comment #0)
> Users that want to navigate into cells horizontally (as I can see, a non
> frecuent use case) will need to press Ctrl+<Left|Right>. Users can still move
> to the parent node with the Backspace key, without collapsing anything.

Just to give a little background, this was tried in 2006, see:

  https://bugzilla.gnome.org/show_bug.cgi?id=105895#c27

And reverted a year later due to complaints:

  https://bugzilla.gnome.org/show_bug.cgi?id=105895#c29

From there on I pretty much gave up. As I mentioned in comment 29 in 105985; a sophisticated plan is likely needed where you "detect" the kind of tree view (list or tree, many editable cells or not, long horizontally stretching rows, etc.) and base the keyboard bindings based on that.

[David Barri (japgolly)]

This is an issue for me too. I don't recall any other framework (at least that I've used) using +/- keys for collapse/expand. It's always left/right arrow keys, which regardless of tradition or incumbency, I feel is the most practical and usable.

I tried to apply Damian's patch to gtk2-2.24.13 today and it wouldn't apply.
I've updated it so that it does work with 2.24.13; new patch: attached.

I've tested it on Arch Linux and it works beautifully. Thanks Damian!

[David Barri (japgolly)]

Here's an unbiased usability test I just did.

I asked my non-techy girlfriend to navigate the tree view (unpatched) using only the keyboard. She tried all the arrow keys then get frustrated, started trying: ctrl+right, shift+right, ctrl+down, shift+down, enter, alt+right, ctrl+shift+down, etc.

I stopped her then asked her to try my desktop (patched) and she got it right away.

When I told her it was the +/- keys, her words were "but it's so far away".

[Damián Nohales (damiannohales)]

Well, errrrr... forget it, Gtk+ is part of GNOME and GNOME has the policy is to destroy UX. But well, luckily I can compile Gtk+ 3 and Gtk+ 2 patched version and have a more usable system.

Thanks for your patch, japgolly, now I can use Eclipse without it hurts :)

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[despairblue (despair-blue)]

I actually had to find this bug report to find out that I am supposed to do this with plus and minus and I use linux and gtk since 2006...It just drove me crazy while working with xml files in eclipse.

I'v also found this: http://superuser.com/questions/289037/how-to-use-arrow-keys-while-navigating-through-file-tree

So one can also use Shift+Left/Right. Ok better than plus/minus (which does not work in eclipse, it tries to search for that character) , but one thing still bugs me: When I'm at a leaf node and want to go all the way up again, in every tree view implementation that would be done by pushing the left arrow key. You would end up one level above the previous node. With the current implementation it simply does nothing, well it makes a sound to tell you that it just will not work the way you expect it to work...

[Wiktor Wandachowicz (siryes)]

I second the effort of fixing GtkTreeView key bindings, 13 years after it has been originally reported, and 10 years after this issue urged me to comment on GNOME Bugzilla.

Please, please, fix it at least on Ubuntu/Debian. Then it will flow to virtually all Linux distro variants I personally use. And world will again be a bit better place :)

[Matthias Clasen (mclasen)]

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.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Micha Lenk (micha)]

The (now separate) GnuCash bug tracker doesn't know anything about bug id 679294.