GNOME Bugzilla – Bug 766773
Publicize GtkCSSNode API
Last modified: 2016-11-25 14:45:27 UTC
Created attachment 328346 [details] comparative screenshot Smoke-tested Evolution 3.20.2 with GNOME 3.20.x in a virtual machine and found a number of regressions regarding the visual UI polish, mostly related to spacing and borders. Besides bug #737330 coming back from the dead, there is: - Insufficient spacing between the mail list treeview's left edge and the contents of the first column; since the mail read/unread icon is rectangular, it feels pretty cramped against the edge and is harder to distinguish visually, it tends to meld into the edge line. - The sidebar scrollview/treeview now has a border on the right, which creates a "double" border that looks broken against the border line that extends above it (separating the search bar from the header of the sidebar) - Treeview column headers have lost all their styling and look completely flat, you can't distinguish them from toolbar elements or even some mail treeview rows. They do not have the appearance of interactive widgets either. Annotated comparison screenshot attached.
I asked gtk+ folks for a help and they pointed me to https://wiki.gnome.org/Projects/GTK%2B/StyleClasses and the end of the discussion is basically: <mcrha> Company, if I got it right, then I should spread around the code calls to gtk_widget_class_set_css_name() to have the giant css work again? <mcrha> and for the example of "EAttachmentPaned" it means to set the css name to "EAttachmentPaned" for the EAttachmentPaned widget? <mclasen> I think that would work <mcrha> that way, with conditional compile, I will still be backward compatible with 3.10? <mclasen> there's a chance <Company> mcrha: not in the cases where you use element names like "GtkScrolledWindow" <Company> mcrha: https://wiki.gnome.org/Projects/GTK%2B/StyleClasses says it's now called "scrolledwindow" <mclasen> you can also load different css depending on whether you use 3.10 or 3.20 <mcrha> Company, okay, then also extend the custom CSS to name both variants <Company> that would work where the referenced "giant css" is located at e-shell-window.c, but more places should be checked, specifically those with gtk_style_context_add_provider() calls. Note the gtk_widget_class_set_css_name() is available since gtk+ 3.20, but evolution can be built with gtk+ 3.10.0 and later.
Nah, I'm not going to waste my time with something I'm not able to fix by any means. I begun with the header bar of the message list, as it's one of the most visible things. That made several issues raised: a) gtk_widget_class_set_css_name() is really on the Class, not on the Object, thus if I want to reuse one object (ECanvas in this case) on several places and it is supposed to be drawn differently in each of the places, then I should define that many subclasses of the ECanvas just to provide "correct" CSS name for the Class. That's a very bad idea. Anyway, I tried it and faced: b) set the parent widget a "treeview" CSS name, then the ECanvas made "button" CSS name and it made the drawing as a button, not as a button in the header bar, thus useless. One observation: c) GtkWidgetPath doesn't do what it used to do. I was able to do this window:dir-ltr.background box:dir-ltr.vertical paned:dir-ltr[3/4].horizontal box:dir-ltr.vertical notebook:dir-ltr[1/1] widget:dir-ltr box:dir-ltr.horizontal paned:dir-ltr[1/1].vertical scrolledwindow:dir-ltr treeview:dir-ltr button:dir-ltr.table-header before calling gtk_render_background(), gtk_render_frame(), but it didn't change the drawing (unnoticed) unless the b) was done. d) GtkCSSNode is currently inaccessible in the public API of the gtk+ (3.20.x), but without that I'd be never able to achieve my tree view header look like gtk+ tree view header, because it adds its own "header" CSS node into the nodes, between the "treeview" and "button". Thus I'm waiting on gtk+ API to be added and maybe the above things fixed, at least some of them. Expect odd evolution look & feel until gtk+ is enhanced and/or fixed.
Created attachment 328636 [details] css.c A little test program to make it easier to get to the state when the custom widgets will draw as expected again. The first line of the file contains a command line to build and run it. The goal is to have the CustomDraw look like the treeview's header regardless where it stays. Please see the current way of adding CSS styles into the game by subclassing the GtkBox only for that single reason. I think the CSS nodes would make things much easier than this, but as I said, there is no direct API to manipulate them from the outside of the gtk+ sources (or I didn't find it). Note that in case of the custom evolution drawing there is no such widget hierarchy, the drawing object is not a widget at all (it is contained in a widget, but otherwise it's a GnomeCanvasItem). Also, adding phantom widgets somewhere to be able to influence CSS nodes is a no go for the evolution, it would make the code too complicated.
(In reply to Milan Crha from comment #2) > Nah, I'm not going to waste my time with something I'm not able to fix by > any means. Please do not misread this, I'm willing to fix it, but as the current gtk+ API doesn't let me, then it makes more sense to wait for the API to be added, than to try to workaround the missing API in some awkward way. If you read whole comment #2, then it'll make more sense, I hope.
*** Bug 767282 has been marked as a duplicate of this bug. ***
As requested in bug #767282, the button drawing is required in the Add Column dialog (accessible in the context menu of the table header in the Mail view) and when dragging the column name, then the column "button" should be drawn as well.
Once the GtkCSSNode API will be made public, and one will be able to push CSS nodes before/after the current widget, then these things will be (semi-)easily solvable.
I thought I'll make some initial changes which could be done without the part on the gtk+ side for the next release of the evolution, at commit_47d1947 [1], but it caused even uglier evolution, at least in the composer, thus I reverted it (I wouldn't commit it at the first place, but I accidentally run incorrect version of the evolution when "testing" the changes). [1] https://git.gnome.org/browse/evolution/commit/?id=47d1947
GtkCssNode is not going to become public api
(In reply to Matthias Clasen from comment #9) > GtkCssNode is not going to become public api Then this bug should be reopened for Evolution.
Evolution (along software such as libreoffice) is one of the main selling points of the Linux desktop at this moment. Visual fixes under GTK 3.20+ would be nice.
(In reply to Christian Stadelmann from comment #10) > (In reply to Matthias Clasen from comment #9) > > GtkCssNode is not going to become public api > > Then this bug should be reopened for Evolution. Well, because gtk+ does things which others cannot do, like the styling of the table header is done without interleaving GtkWidget-s [1], then anything what the Evolution or other code would do might be very ugly, softly said. [1] https://git.gnome.org/browse/gtk+/tree/gtk/gtktreeview.c?h=gtk-3-20#n1847
(In reply to Matthias Clasen from comment #9) > GtkCssNode is not going to become public api It would be great if a GTK+ developer could look into this issue and recommend a solution for Milan. If there's really no way to style it, that indicates a deficiency in the API.
(That said, it's clear there are no plans for GtkCSSNode to become public API.)
I think for this kind of stuff we can rely on a bunch of standard styleclasses in the theme, but please provider me testcases (possibly in GTK+ directly, better if in the widget factory) reflecting the use cases.
(In reply to Lapo Calamandrei from comment #15) > I think for this kind of stuff we can rely on a bunch of standard > styleclasses in the theme, but please provider me testcases (possibly in > GTK+ directly, better if in the widget factory) reflecting the use cases. I'm sorry, I do not follow. This is about custom widgets, which want to look like stock gtk+ widgets. One of them being a custom widget for tree view, where its header bar cannot look the same as the one in the GtkTreeView, because comment #12. There might be more cases, I do not know, I just got stuck on this one.