GNOME Bugzilla – Bug 644430
Should use GtkTreeSelection instead of its own API
Last modified: 2018-02-10 03:35:27 UTC
Right now GtkIconView uses a GtkTreeModel for its data source (good), but doesn't use the GtkTreeSelection API (bad); it reinvents its own little API for dealing with selections. GtkTreeSelection's code deals directly with GtkRBTree, which the icon view doesn't use. However, this is only for "find me a node" and "is this node selected?" actions, nothing more sophisticated. Tristan suggested adding some internal callbacks to GtkTreeSelection so that it could be used by both treeview and iconview. All the GtkRBTree code would then move to GtkTreeView, as it should. As a different (but more complicated) idea, I thought of adding a GtkTreeSelectableIface which is implemented by both GtkTreeView and GtkIconView, and potentially third-party widgets. Then all of them would be able to reuse the logic in GtkTreeSelection for what to select/unselect depending on the single/browse/multiple modes. Or is this overkill? Third-party widgets for list-like things are not likely to want to deal in iters and such... (Context for this: I'm reviewing Simo Kivimäki's patch from bug #141154 to add an icon view to the file chooser, and it has to write its own functions for "get selection from the treeview" vs. "get selection from the iconview" - and that's cumbersome.)
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.