GNOME Bugzilla – Bug 492206
Selection changes upon focusing
Last modified: 2018-02-10 04:38:52 UTC
When the focus goes for the first time to a GtkTreeView in GTK_SELECTION_BROWSE or GTK_SELECTION_SINGLE mode, the first element is automatically selected in addition to obtaining the focus. See e.g. the shortcut pane of the file selector. While this is desirable in the general case, there needs to be a way to deactivate this behavior, because in some cases changing the selection triggers an event, and you don't want it to happen just by obtaining the focus.
Created attachment 98303 [details] [review] Don't select the initial focus in GTK_SELECTION_SINGLE mode On second thought, this makes sense for GTK_SELECTION_BROWSE but I don't see the point of doing it for GTK_SELECTION_SINGLE. The point of the latter is to be able to have nothing selected, so there is no need to enforce having something selected.
Hmmmm, we had a big bug about focus behavior in the treeview; does anyone remember what it was?
This specific behavior hasn't changed for a long time; it was introduced in r4673 with the GTK_SELECTION_* macros.
*shrug* The behavior has been like this since the very beginning, I don't really fancy changing it at this point ...
This behavior is now causing an issue in the file chooser; now that the shortcuts pane is single-click, keyboard navigation is broken because of the GTK_SELECTION_SINGLE behavior. As soon as the shortcuts pane gets the focus, selection is forced to be non-empty and the current directory changes.
This is a very annoying "feature", and not only because it just cost me several hours of debugging. Essentially it means that GTK_SELECTION_SINGLE does not allow for the selection to be empty, in spite of claims to the contrary. It's hard to even think of a decent workaround. This is, by the way, an ancient issue, as Kristian probably could have explained. It is identical to bug #94837, which was resolved as Fixed, for no obvious reason (based on reading the comments there). Regarding comment #2, there was another related but different problem, described in bug #143270, which caused more serious difficulties but has been fixed.
Debian folks patched this away and made me spend few funny debugging hours, I didn't have a Debian and so I couldn't reproduce a bug (and the bug was in the end "preferences dialog doesn't work"). Perhaps I confused SINGLE with BROWSE back in 2004. But is it okay to break my application in gtk-2.14? Are there docs which I could have read to learn I had a bug waiting to pop up? Regarding FileChooser issue, pleeeease, it has those all the time, last time we had (and still have) that discard-on-focus-out issue in cell renderers.
Looks like the cause of bug 603040.
Note that the LSB h
Oops, wrong button. Note that the LSB folks have a bug open about this issue: http://bugs.linuxbase.org/show_bug.cgi?id=2170 Since the bug is fixed in Debian/Ubuntu and not in other distributions, they consider it a divergence that needs to be solved somehow.
Well, the divergence is on your side...
(In reply to comment #11) > Well, the divergence is on your side... And the bug is on yours…
Can somebody, please, apply the damn patch already?
Comment #4 contains all that needs to be said about this. Your cursing made it clear that keeping this bug open is not beneficial.
Sorry but the behavior is not even consistent with the documentation, so if you don’t want to fix the bug for a reason as strange as “it was always buggy”, you need at least to fix it.
I'm working on this, as part of bug #613728 ("Rationalize GtkTreeView focus"). I'll reopen the bug and assign it to myself.
Created attachment 194166 [details] [review] bgo#492206 - Don't change a treeview's selection when focusing it. The rationale is that you don't expect data to change simply by changing the focus. A toggle button doesn't get toggled when you focus it; you don't expect things to change when you use FocusFollowsMouse and you move the mouse around. This also means that it is now "safe" to focus a treeview, without side effects. Signed-off-by: Federico Mena Quintero <federico@gnome.org>
Please consult with Kris before making any behaviour changes in the treeview
The patch above is the first in a series related to bug #613728 ("Rationalize GtkTreeView focus"). Making the treeview not change the selection upon focusing works very well, of course. However, this uncovered another bug which I'm working on. If you: 1. create a treeview, pack it 2. populate it with rows 3. grab_focus to it, or let it get focus by virtue of being the first widget in the focus chain then everything works properly; the first row becomes the cursor row (i.e. it gets a focus rectangle drawn around it), but nothing gets selected. However, if you omit (2) and populate the tree *after* it has the focus, then you get no focus indicator drawn at all (i.e. cursor_row == NULL). Populating the treeview should make a cursor row appear, but not change the selection. That is, GTK_SELECTION_SINGLE should mean "zero or one items" as usual; GTK_SELECTION_BROWSE should mean "uninitialized or one and only one" depending solely on the user's selection; and GTK_SELECTION_MULTIPLE should be as always, "zero or more". But GTK+ should *never* change the selection without the user taking explicit action to do so.
I agree with this for single and multiple mode. We can patch tree view to simply enable the cursor as soon as the first rows come in and no cursor is set. My problem is with browse mode, which should either be "uninitialized or one and only one" or "one and only one". From the documentation you would say it should be the latter, from your patch in comment 17 there are arguments that you want the former behavior when using focus follows mouse. If you use the former behavior and are only using the keyboard, then in browse mode the selection never gets toggled unless the user selects a row at some point. IMHO that feels to go against the idea of browse mode, which is to have a row selected at all times. For browse mode there is another related bug on what to do when the selected row is deleted -- do you select a new row to adhere to the criteria or do you leave the selected uninitialized? Another question is whether browse mode serves a purpose at all? Perhaps it should simply be re-defined or deprecated?
I agree that the semantics of GTK_SELECTION_BROWSE are unclear. If merely focusing the widget changes the result (by initializing the selection), there’s a problem somewhere. You can always get a better behavior in a given application with using GTK_SELECTION_SINGLE and handling this somewhere else in the UI (e.g. by making a validation button insensitive until something is selected).
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.