I visited the gtk website yesterday, after working on other things for a while, and I noticed that GtkTreeView is now tagged ‘deprecated: 4.10’. Because the latest stable release is 4.8.3 and the latest unstable release is 4.9.2, I wondered if someone might be making a joke? I was just getting started.
Ok, now straight to the point of the issue at hand:
Not so long ago, I wrote an application that has multiple GtkTreeView widgets in a window. The GtkTreeView widget come in pairs of two, one master GtkTreeView and one slave GtkTreeView that switch roles on focus. I use the gtk_tree_view_get_cursor, gtk_tree_view_set_cursor and various gtk_tree_path methods to set the cursor of the seconds from the first and the other way around. Sorters and everything working very nice too.
Switching roles was not yet fully functional, because of a small fight with GtkWidget::state_flags_changed, but the idea was there.
Looking at all deprecations in the latest documentation, I see no reference to any methods that enable me to manipulate the cursor (or manipulate the GtkTreePath for that matter) at all. Neither in the GtkListView nor in the GtkColumnView documentation is there any mentioning about a cursor. In fact, I think the core of this application will pretty much fall apart in full, when these deprecations will get into effect. I don’t think there is a way to start over, when the GtkTreeView, GtkTreePath and related are being removed.
First of all: deprecation does not imply deletion.
Once a type or a function is deprecated in a major version it can only be removed in the next major version; so if something is deprecated in GTK 4 (regardless of minor version), it will continue to exist for the duration of GTK 4’s life time. The deprecation is mainly a notice that the API will not exist in GTK 5, and that you’ll have to change your code when you port your code base.
There is no direct 1:1 mapping of GtkTreeView-related API to GtkListView/GtkColumnView API.
Trees in the new list view widgets are a feature of the model, not of the view widget; view widgets only display rows of widgets.
Rows have an index, so if you want to keep two views in sync you will have to get the index of the row in the model whenever view A loses focus, and tell view B to scroll to that same item (since the model is the same).
My models are anything but identical, but besides that… gtk_tree_view_scroll_to_cell and gtk_tree_view_get_cursor / gtk_tree_view_set_cursor are totally different functions.
Neither in the GtkListView, GtkColumnView or GListModel documentation I found any reference to a cursor of any sorts.
Does that mean that traversing a tree with an ordinary keyboard will be something of the past? I don’t get it. Is any documentation on GTK 5 made available already?
If your models are not identical, then how can you possibly keep your tree views in sync?
I think I’m missing way too much context on how your application is designed to give you any reasonable answer on how to port it.
Of course not.
There is no cursor API in the list view widgets in GTK4 because they contain widgets, not cell renderers. Regular focus handling rules apply. Most of the API in GtkTreeView exists because it’s based on custom objects that get drawn in different places with different content; the list view widgets use widgets (and they recycle them after a while to scale to millions of rows) bound to objects inside a model.
GTK5 does not exist. The main development branch is still GTK4, and even if we branched by the end of the year, like we’re planning to do, it’d still take years for a GTK 5.0 release.
Well, it keeps track of where my items in my TreeView are after sorting, such that I can find them afterwards, such that I can retrieve an object in the slave TreeView from the master TreeView at all times and the other way around.
There is an upper TreeView with a TreeModel with about 70 columns and a lower TreeView with about 70 TreeModels with an unknown number of columns. Each and every row in the lower TreeModels has a corresponding row in the upper TreeModel. I keep track of all row-row pairs, with these mutexes.
As I told you, it works almost perfectly, apart from small glitch that originates from GtkWidget::state_flags_changed.
As you can see from the code above, I make use of gtk_tree_path_get_depth for example. What do I do without it???
I would really prefer that you help with improving the GtkWidget::state_flags_changed function, over losing losing essential parts of my code because you have troubles reading it. There’s no part of the code that I’m not willing to show, but it’s tightly coupled to my database, that’s what makes it extremely difficult to zoom in onto the specifics. I would have to write you a version that is not coupled to any database at all, and I’m very much willing to do that, as long as you leave the gtk_tree_path and gtk_tree_model function intact. I just put it all together!
Good for me, that only the compiler has to read it
For now, let me take back the above code, and tag it brand new but deprecated.
If you want a demo of these interacting sortable trees in the GTK source tree, I’ll be happy to write it for you. You will get the code above with it.
Since the demo will depend on the GtkTreePath, GtkTreeView, GtkTreeModel and GtkTreeStore objects and methods, I can only hope that they will still be included in future releases of GTK despite of all the current deprecations.
Let me now enjoy my brand new application while it lasts.
