GNOME Bugzilla – Bug 541391
Unfocussable Treeview swallows focus
Last modified: 2008-09-24 08:21:17 UTC
The current behaviour of a treeview that cannot be focussed, ie. !GTK_WIDGET_CAN_FOCUS (treeview), can lead to confusion. Even though the treeview is not focussable it 'swallows' the focus and also responds to mouse buttons.
Created attachment 113920 [details] Test case This test case is a window containing two treeviews, one is focussable, the other one is not. If you use the keyboard to move the focus out of the left treeview you will observe that the focus disappears. If you use a mouse to focus the right treeview you will see that it is not focussed, as expected, but still changes the selection which remains grayed/ deselected all the time.
Created attachment 113921 [details] [review] Drop out of focus and button handler if !CAN_FOCUS This patch changes the behaviour, so that the treeview drops out of the event handlers for focus and button click if it is not focussable. If you apply this patch and test with the above test case, you will see that by using the keyboard you can't focus the unfocussable treeview anymore and the focus doesn't disappear anymore. Also using a mouse to focus the right treeview doesn't change the selection anymore.
Created attachment 113924 [details] [review] Drop out of focus + button if !CAN_FOCUS, prevent selection This is the same patch plus an additional CAN_FOCUS check that prevents the unfocussable treeview from selecting the first row if none was selected before. Without this addition, the first row is always selected.
It works. Although you can't click on the !CAN_FOCUS treeview, you can still set the keyboard focus using set_cursor(). Is that expected? It is not very clear to me what the semantics of the can-focus attribute should be in this case.. For example, on a !CAN_FOCUS GtkButton, you can still click on it so shouldn't you still be able to click on a !CAN_FOCUS GtkTreeView?
I think I originally suggested Christian to also ignore mouse clicks for can-focus == FALSE; but Bjorn made me change my mind now. We probably had a little confusion between insensitive and !can-focus. After looking at some other widgets I have to conclude that focus is really just keyboard focus. !can-focus should just disable the keyboard side of things; mouse clicks and programmatical manipulation should continue work. This should answer your questions: (In reply to comment #4) > It works. Although you can't click on the !CAN_FOCUS treeview, you can still > set the keyboard focus using set_cursor(). Is that expected? It is not very Setting the keyboard focus using _set_cursor() should still work. > clear to me what the semantics of the can-focus attribute should be in this > case.. For example, on a !CAN_FOCUS GtkButton, you can still click on it so > shouldn't you still be able to click on a !CAN_FOCUS GtkTreeView? Yes; we should actually still be able to click and manipulate a !CAN_FOCUS GtkTreeView. With the second chunk ("@@ -2486,8 +2486,8 @@") removed, this patch should be fine to commit to trunk.
Created attachment 117576 [details] [review] Updated patch, concerns addressed
Looks good, please commit (maybe after the final 2.14 release?).