GTK+ No More - It's Just GTK As Developers Prepare For This Year's GTK 4.0

[FastCode]

Presumably "retire GtkTreeview" would mean it becomes deprecated in GTK4 and is removed from GTK5? This would be a real headache for MATE and Cinnamon devs, who would have to choose between stopping at GTK4 (or more likely GTK3), porting the very complex filemanagers to GtkList, or forking the treeview (along possibly with GtkPlug, GtkSocket, GtkStatusIcon) into an extension library.

I would want to bring back the long-missing ability of a treeview to stripe rows like in Gt2 themes if we do that, I suspect it could be done in a list as rows are exposed for theming there. For my UbuntuStudio_Legacy GTK3 theme, I had to resort to a gradient on each row of a treeview, same on every row to stripe them, as no nth-child(odd) or nth-child(even) logic is possible with recent versions of the treeview. If I could, I would make Nemo, Caja, and Nautilus treeviews in that theme look exactly as they did with the original GTK 2 theme back in 2008, whatever the backing widgets in use.

If you're fine with adding style classes and removing them when rendering every cell then you can define your own styles and use values from other places. or just set the background color in cell_data_func like this (Gtk#):

tvc.SetCellDataFunc (crt, (TreeViewColumn col, CellRenderer cell, ITreeModel model, TreeIter iter) => {
var path = model.GetPath (iter);
int [] ind = path.Indices;
byte r = (byte)(225 - (25 * (5 - Math.Min (5, ind.Length))));
byte g = (byte)(225 - (5 * (5 - Math.Min (5, ind.Length))));
byte b = (byte)(225 - (20 * (5 - Math.Min (5, ind.Length))));
cell.CellBackgroundGdk = new Gdk.Color (r, g, b);
});

[re:fi.64]

I just want to point out that removing GtkTreeView is the biggest of all and will require A LOT OF CHANGE and will make life a lot easier for Api users in the long term.
rant:
I hope at least some of the issues with retarded(tm) auto-scrolling after 'realize' event, right to left scroll bar position, right to left drag/drop border width, the infinite width last column, unclickable CellRendererPixbuf, double updating CellRendererText, CellRenderer backgrounds not rendering in small columns, tree lines overlapping, CellRenderer rendering value from last render because there are no defaults to use before calling the cell_data_func callback, CellRenderers not supporting any kind of positioning, CellRenderer editor controls having 2 parent classes, the recent CellRendererPixbuf event change(you know which one), and the fucking plethora of other problems don't get repeated. /rant, sorry

Just right after I rolled my own. They finally agreed that GtkTreeView is a steaming pile of rotten spaghetti. I don't know if I should be mad or thankful.

AFAIK GtkTreeView and the entire GtkCellRenderer system has been negatively viewed for quite a while. However, rendering widgets in GTK3 was exponential (?) time (or maybe something else, I just know it was far above linear), meaning cell renderers were the only way to efficiently render the amount of widgets that would be in a GtkTreeView.

With GTK4, not only has the entire rendering system changed (everything has moved from Cairo painting to the GtkSnapshot hardware-accelerated scene graph), but drawing widget children is now O(n), meaning cell renderers have no place and can be removed .

[dkasak]

I just want to point out that removing GtkTreeView is the biggest of all and will require A LOT OF CHANGE and will make life a lot easier for Api users in the long term.
rant:
I hope at least some of the issues with retarded(tm) auto-scrolling after 'realize' event, right to left scroll bar position, right to left drag/drop border width, the infinite width last column, unclickable CellRendererPixbuf, double updating CellRendererText, CellRenderer backgrounds not rendering in small columns, tree lines overlapping, CellRenderer rendering value from last render because there are no defaults to use before calling the cell_data_func callback, CellRenderers not supporting any kind of positioning, CellRenderer editor controls having 2 parent classes, the recent CellRendererPixbuf event change(you know which one), and the fucking plethora of other problems don't get repeated. /rant, sorry

Just right after I rolled my own. They finally agreed that GtkTreeView is a steaming pile of rotten spaghetti. I don't know if I should be mad or thankful.

I've made very heavy use of GtkTreeView in several projects, and what you declare as 'issues' are in fact your own inability to code. Subtle difference to those who don't know better, but trust me, they're different.

[FastCode]

I've made very heavy use of GtkTreeView in several projects, and what you declare as 'issues' are in fact your own inability to code. Subtle difference to those who don't know better, but trust me, they're different.

How do you fix column/row borders not rendering half the time when scrolling?
How do you make the horizontal scroll not go to middle on its own when showing a treeview in a scrolled window?
How do you colorize your 'expand' column when it's too small?
Tell me how and I'll never again claim to know Gtk.

It has issues, You can't just say it works and make them go away.

[FastCode]

AFAIK GtkTreeView and the entire GtkCellRenderer system has been negatively viewed for quite a while. However, rendering widgets in GTK3 was exponential (?) time (or maybe something else, I just know it was far above linear), meaning cell renderers were the only way to efficiently render the amount of widgets that would be in a GtkTreeView.

With GTK4, not only has the entire rendering system changed (everything has moved from Cairo painting to the GtkSnapshot hardware-accelerated scene graph), but drawing widget children is now O(n), meaning cell renderers have no place and can be removed .

Not only that, IIRC you couldn't add more than ~1k input widgets(entry, input method problem) in windows and adding ~10k widgets in linux would take a significant time. Scrolling, resizing, rendering, typing, ... would get really slow and crashy, In my tests it would even segfault sometimes.

[Guest]

Erm, It’s the GIMP Tool Kit, not Gnome.

No! Now it's Gnome Tool Kit.

[Guest]

Maybe I should write my own...

Nice, Linux needs a good free Gui library, for everyone.

[Guest]

Presumably "retire GtkTreeview" would mean it becomes deprecated in GTK4 and is removed from GTK5? This would be a real headache for MATE and Cinnamon devs, who would have to choose between stopping at GTK4 (or more likely GTK3), porting the very complex filemanagers to GtkList, or forking the treeview (along possibly with GtkPlug, GtkSocket, GtkStatusIcon) into an extension library.

I would want to bring back the long-missing ability of a treeview to stripe rows like in Gt2 themes if we do that, I suspect it could be done in a list as rows are exposed for theming there. For my UbuntuStudio_Legacy GTK3 theme, I had to resort to a gradient on each row of a treeview, same on every row to stripe them, as no nth-child(odd) or nth-child(even) logic is possible with recent versions of the treeview. If I could, I would make Nemo, Caja, and Nautilus treeviews in that theme look exactly as they did with the original GTK 2 theme back in 2008, whatever the backing widgets in use.

I'd like someone fork the Gtk2 libs for creating something better. Linux needs a free, modern Gui libs.

[geearf]

No! Now it's Gnome Tool Kit.

I don't think so, I think now GTK does not stand for anything anymore.

If not you wouldn't have this:

https://github.com/GNOME/gtk

GTK — The GTK toolkit

[Shiba]

It's so funny watching Qt fanboys moc-king...