GNOME Bugzilla – Bug 322387
setting the background color of an entire row in a GtkTreeView
Last modified: 2018-02-10 03:21:25 UTC
To enchance one of my products, I was wanting to set the background colour of rows in a treeview. The end result is something similar to the rules-hint but with the shade for each row defined programtically. Setting the GtkCellRenderer::cell-background property doesn't work for this because it doesn't cover the entire row. There are white spaces left around cells, and invisible cells are completely white. As an alternative, I've added a new function "gtk_tree_view_set_row_background_func" (similar to gtk_tree_view_set_row_separator_func) that lets programmers provide a callback function to customise the row background colours. I'll attach the patch for this function. Does anyone else think this a good idea and something that could be added to GTK, either in the current form or with modifications?
Created attachment 55208 [details] [review] Patch against gtk+-2.6.10 to add the new feature Sorry about this being against an old version.
I am going to try to get this in 2.10, because it is nice/useful for implementing grouping. I am still contemplating about the API though. I thinking of: * renaming the function to just "GtkTreeViewRowBackgroundFunc", * drawing the background differently. Right now, when a custom background color is set that color is used without question, all other attributes are ignored. The only attribute passed to the background function is the "Selected" attribute. I see two options, we could pass more attributes to the function (also "detail" for example, though then the function will have to handle the "row-ending-details" style property ...). Another option might be to request a color from the function (while just passing the treeview and an iter/path), modify the style and pass that to gtk_paint_flat_box() so the theme engine will have a chance of customizing it (it'll take the state, detail (and row-ending-details) into account). But that might not be wished of course ... I'll update the patch once I've made up my mind on what to do.
Thank you for taking an interest in this. The way I ended up using this in our application was just colour alternating groups of rows in the same shades as odd/even rows. Discovering what the even/odd row colours are turns out to be non-trivial because the style properties default to unset rather than to the default colours. I ended up having to copy the colour manipulation logic out of the depths of the treeview rendering code; something I would prefer to avoid. If this case is common, it would be nice to make it easy to implement while still supporting the more complex case via a more complex api. From the application programmers point of view I think the ideal method would be to provide (via a callback or a model column) a "group-id" atom for each row. Adjacent rows with the same group-id become a group, and alternating groups would be drawn with alternating "even" and "odd" background colours in the same way as the current rules-hint rendering. I'm not sure how you would quickly determine the odd-group/even-group state for a row, especially in a tree as nodes get expanded and collapsed. The simplest to implement would be a callback or model column that redefines the odd/even state of each row. This forces the application programmer to keep track of this information as rows are added and removed, and wouldn't work well with trees except in the simplest cases.
Sounds like you are describing #318163 (see the bottom for the rules-interval property). For the effect I was trying to achieve this is maybe better solved as a duplicate of #309474.
*** This bug has been marked as a duplicate of 309474 ***
Oops, I didn't actually mean to submit that, sorry for the spam.
Having actually read both those bugs, rather than confusing myself my clicking the wrong button, I don't think either of them addresses my problem. The concept of categories is similar to bug #309474, and the idea of alternating the colour on groups of rows is similar to the rules-interval in bug #318163, but neither is exactly right.
Created attachment 81565 [details] [review] Revised patch against gtk+-2.10.9 This new patch: - Changes the names to GtkTreeViewBackgoundFunc and gtk_tree_view_set_background_func. - Passes the tree view rather than the model as the first argument to the row background func, so attributes like selection and default colours can be found easier. - Doesn't pass 'selected' to the row background func. The rendering method is unchanged as I haven't spent the time to work out a better way to do it.
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.