! Please note that this is a snapshot of our old Bugzilla server, which is read only since May 29, 2020. Please go to gitlab.xfce.org for our new server !
Icon view doesn't show keyboard focus
Status:
CLOSED: FIXED

Comments

Description Stefan Stuhr 2006-01-11 17:24:04 CET
This may be a bug in libexo.

When one hold down Ctrl in Thunar while the icon view has focus, and then move
around with the arrow keys, one can't see which icon has the current keyboard
focus. But one can, while still holding down Ctrl, select/unselect the icon
which has the keyboard focus by pressing Space.

One can also, while the icon view has focus, hold down Shift, and select a range
of icons with the arrow keys. But one still can't see which icon has the
keyboard focus.

Nautilus draws a thin (1px wide) dotted border around the label of the icon
which has the keyboard focus, but only if the icon received focus by use of the
arrow keys while holding down Ctrl or Shift.
That is, it doesn't draw the dotted border if one uses the mouse to select
one/more icon(s), or if one uses the arrow keys without holding down Ctrl or Shift.

Reproducible: Always
Steps to Reproduce:




I am running Ubuntu 5.10 with GTK 2.8.6 and X.org 6.8.2.
Comment 1 Benedikt Meurer editbugs 2006-01-11 17:48:40 CET
2006-01-11	Benedikt Meurer <benny@xfce.org>

	* exo/exo-icon-view.c(exo_icon_view_paint_item): Let the cell renderer
	  know whether the current item has the keyboard focus. Part one of fix
	  for bug #1321.

2006-01-11	Benedikt Meurer <benny@xfce.org>

	* thunar/thunar-text-renderer.c(thunar_text_renderer_render): Render
	  focus indicator when following state. Part two of fix for bug #1321.

Comment 2 Stefan Stuhr 2006-01-11 19:53:21 CET
Thanks, it works.

But I don't like that it always draws the dotted border. It's useful when
navigating the icon view with the keyboard, but it doesn't looks as nice as when
the dotted border isn't there. I like it better in Nautilus, where it only, as
already noted, draws the dotted border when the icon received focus by use of the
arrow keys while holding down Ctrl or Shift.

GtkTreeView does something in the middle. It always draws a dotted border when
one navigate the list with the keyboard, but not when one uses the mouse (only
exception seems to be when one holds down Ctrl - not Shift - while pressing
mouse button 1).
Comment 3 Benedikt Meurer editbugs 2006-01-12 10:56:03 CET
Ok, the GtkTreeView behaviour is (more or less) reproducible. I could implement
that for ExoIconView as well, ok?

The nautilus icon view is, ahem, a bit messy, so I'd prefer not to go through
the various parts of the implementation looking for exact conditions when to
display the keyboard focus.
Comment 4 Stefan Stuhr 2006-01-12 16:06:42 CET
(In reply to comment #3)
> Ok, the GtkTreeView behaviour is (more or less) reproducible. I could implement
> that for ExoIconView as well, ok?

That sounds good :)
Comment 5 Benedikt Meurer editbugs 2006-01-14 14:14:28 CET
2006-01-14	Benedikt Meurer <benny@xfce.org>

	* exo/exo-icon-view.c: Draw keyfocus using the same semantics as
	  GtkTreeView. This finally fixes bug #1321.
Comment 6 Stefan Stuhr 2006-01-14 14:25:13 CET
(In reply to comment #5)
> 2006-01-14	Benedikt Meurer <benny@xfce.org>
> 
> 	* exo/exo-icon-view.c: Draw keyfocus using the same semantics as
> 	  GtkTreeView. This finally fixes bug #1321.

Thanks, it works.

If you would want to make it work like it does in Nautilus, you could "simply"
say that when one uses the keyboard to move the focus in the icon view, and (may
be as a result) more than one icon are selected, or the selected icon is
different from the focus icon, then the focus should be drawn.

But it works now :)
Comment 7 Benedikt Meurer editbugs 2006-01-14 14:27:37 CET
The GtkTreeView semantics are easier to understand and implement. When you use
the keyboard, you'll see keyboard focus, when you use the mouse you won't see
keyboard focus.

Bug #1321

Reported by:
Stefan Stuhr
Reported on: 2006-01-11
Last modified on: 2009-10-09

People

Assignee:
Nick Schermer
CC List:
0 users

Version

Version:
unspecified

Attachments

Additional information