GNOME Bugzilla – Bug 554229
document order of select function for gtk_tree_selection_set_select_function
Last modified: 2018-02-10 04:39:32 UTC
Documentation Section: Documentation of gtk_tree_selection_set_select_function() Testing behavior of gtk_tree_selection_set_select_function(), select function seems to be called after cell renderer callbacks. It allows simplification of code to block selection change after clicking to some columns. Correct version: It would be nice to: - document this behavior or - document that programmers should not depend on the callback order Other information:
Created attachment 119579 [details] [review] gtk-selection-function-doc.patch Proposed documentation fix.
At the very least, the docs would have to say which cell renderer callbacks are meant. But I am not sure we can or want to guarantee any ordering. Kris ?
(In reply to comment #0) > Documentation > Section: Documentation of gtk_tree_selection_set_select_function() > Testing behavior of gtk_tree_selection_set_select_function(), select function > seems to be called after cell renderer callbacks. Which cell renderer callbacks do you mean? The start_editing and activate callbacks? Or the code setting data from the model on the cell's properties?
I wanted to implement a table with a checkbox column, that is active to check/uncheck, but inactive to change of active line. Imagine an application that needs GUI just like GIMP layers dialog. Clicking to eye icon should trigger only visibility, but not change current active layer. The application in question is viking ( http://viking.sf.net/ ) and its layer visibility column. Current API does not contain feature "Make this column insensitive to active line change", so it needs to be implemented using (a bit ugly) hacks. These hacks heavily depend on exact order of callbacks. That is why documented order of callbacks would be welcome. The order that I need was: callback of GtkTreeSelectionFunc set by gtk_tree_selection_set_select_function() and a "toggled" signal of GtkCellRendererToggle column. The latter seems to come first in the current implementation.
Ah, I see now. So basically you are depending on the order of execution in tree view's button-press handler. It is indeed the case that editable/activatable cells are handled first before selections are being made. We don't have any immediate plans to change that at this point, though I don't think we would really want to make a hard guarantee in the API documentation at this point. What I think that does make sense is to introduce a setting on the tree view that can configure whether an activation of an activatable cell renderer (eg. a toggle on a toggle renderer) should also the move/modify the selection or not. Especially the usage in a layer list/tree that you suggested is a really strong argument in favor of such a setting.
Yes, it makes sense instead of the order guarantee. Few ideas: gtk_tree_view_column_set_activatable to disable activation on a whole columns for features like "layer is visible checkbox" setting activatability per cell for features like "inactivated/locked layer" for the most obscure things, making the activation signal/callback public would make possible to write function that dynamically blocks activation after clicking to some cells
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.