GNOME Bugzilla – Bug 333117
Need API to set GtkTreeView item focus (without selection)
Last modified: 2018-02-10 03:33:48 UTC
I've searched everywhere, but there does not seem to exist a simple API to set focus to some item inside GtkTreeView WITHOUT setting its selection state as well. I've tried using gtk_tree_view_set_cursor API, but it seems to always set item selected too. My current solution is to: 1. read selection state of an item 2. call gtk_tree_view_set_cursor to set both focus and selected state 3. restore selection state to be the same as before the step 2. Problem is this causes a big flicker, making it unusable in real life programming.
Perhaps you could fake it like this: tree_view->priv->ctrl_pressed = TRUE; gtk_tree_view_set_cursor (tree_view, ... tree_view->priv->ctrl_pressed = FALSE; I haven't tried it, and of course it is really dirty, but it might work...
You'll need the private header as well "gtktreeprivate.h" . Wow, what a bad idea! Forget I even suggested it!
See bug #613728 for a compilation of focus issues in GtkTreeView. Why do you need to set the cursor without changing the selection? I *think* I have needed to do this before, but maybe it was due to one of the focus problems mentioned in that bug.
Basically, I wanted to implement standard browsing behavior as in Total Commander. When you use Arrow keys to move within the File List panel, only focus rectangle is moving, no item selection is generated. Since the focus state is obviously a separate state from the selection, it makes sense to set them separately. For example Windows API (macro) ListView_SetItemState (http://msdn.microsoft.com/en-us/library/bb775102%28VS.85%29.aspx) allows to set item states, either separately or in batch (LVIS_FOCUSED and LVIS_SELECTED being separate states). Qt for example also has an API to set the focus (depending on selection mode, it can also select the item too): QTreeWidget::setCurrentItem
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.