Pitivi has been traditionally doing style.get_background_color(Gtk.StateFlags.NORMAL)    (or stateflags ACTIVE) to find the theme's color to apply to the timeline ruler.

The problem is that this doesn't work at all with GTK3. You always get pure black (RGB 0, 0, 0) when you do that, even if you do style.lookup_color("bg_color").

From the discussion below, it seems clear that we have no choice but to define all our timeline colors from scratch instead of trying to derive them from themes. Which is somewhat OK with me now that GNOME standardized on Adwaita (see: "Advaita", "the one and only", etc.).


-------

<ebassi> the fact that it's returning a GdkColor makes me thing that it's an old GtkStyle API
 or some sort of weird back-compatibility function
 unless somebody meant to make GdkRGBA match GdkColor
 and vice versa
<nekohayo> no idea what's the "proper" way to ask gtk for the theme's various colors? :)
<ebassi> nekohayo: that's usually something you don't do
 nekohayo: you ask for the color for that particular widget
 nekohayo: and the theme is either setting that color explictly or it's using a symbolic color
 nekohayo: but you don't just ask a generic color
<nekohayo> ebassi, I'm not sure how to figure out colors for pitivi's clutter timeline widget (or its cairo/goocanvas ruler widget that has not yet been ported to clutter)
 unless I should officially stop bothering about even trying to get the theme colors, and hardcode everything :/
<ebassi> you should stop bothering
 and ship a theme with your app for your custom appearance
<nekohayo> you mean a whole custom gtk theme just for pitivi? that's madness
<ebassi> not a whole custom theme: a theme only for the custom widgets you have
 but in general, that's how CSS works
<nekohayo> hm, you mean "in the app", define a small portion of css just for my own widgets
 ........which pretty much amounts to the same thing as having a couple of constants at the top of the file where I hardcode the colors
<ebassi> nekohayo: yes, but with CSS you don't need to recompile your app
<nekohayo> well, it's python :P
<ebassi> s/recompile/re-install/
<nekohayo> (and it runs in-place)
<ebassi> but yep
<nekohayo> alright
 I guess it will look alien if users don't use Adwaita but it sounds like that "can't be avoided"
<ebassi> in theory, by using CSS, you can ship with different versions of the UI yourself, matching the currently used theme
 so you can check if you're running under Adwaita, or Unico, or the HighContrast theme
 and load the appropriate CSS snippet
 but you can do the same by hardcoding colors as well
<nekohayo> how do you even ask gtk what theme it is running? ;)
<ebassi> nekohayo: GtkSettings:theme-name
<nekohayo> oh
<ebassi> but that's how CSS works: we don't define a bunch of colors for you to peek at. we define the whole appearence of the UI. you either use standard controls, and conform to that; or you create your own appearance for the non-standard controls
CSS is about freedom ;-)
<nekohayo> ebassi, well the idea would be to clone/steal another widget's color palette
<ebassi> nekohayo: that can only work for CSS classes, not for widgets
<ebassi> nekohayo: but if the specificity of the CSS selector is based on the widget class, or on a widget's name, then you need to be that widget
<ebassi> in order to get out the CSS style properties
<nekohayo> no widget impersonation
<ebassi> it's like the web: if you want a blockquote to look like a div, they need to share a class; but if the CSS is in terms of blockquote and div, then there's nothing you can do about it



--------
While we're at it, I'm not sure how useful it is to provide color preferences for the timeline elements again. If someone comes up with a nice patch I'll consider it.