On Mon, May 4, 2015 at 6:11 PM, Jasper St. Pierre <jstpierre@xxxxxxxxxxx> wrote:
There are lots of widgets which don't (yet) respect all CSS
properties. That's because when you try, you break themes which do
something like: "* { background: gray; }", and some widgets weren't
expecting to get a gray background.
We're trying to make more widgets respect CSS, but it's a careful
balancing act to play.
I fully understand that and I agree that it's a good solution.
However there is supposed to be a priority level in the CSS for exactly the reason that sometimes you want application colour schemes to override the user/theme settings, and other times you want the user/theme settings to guide the application.
However there is supposed to be a priority level in the CSS for exactly the reason that sometimes you want application colour schemes to override the user/theme settings, and other times you want the user/theme settings to guide the application.
From my testing I believe that this priority level system is broken. Setting to the highest priority should override everything, and yet it doesn't - for example one of the examples I gave: label background colour for spinbuttons. It seems like the theme colours are always used, regardless of the CSS priority level.
--On Mon, May 4, 2015 at 2:05 PM, salsaman <salsaman@xxxxxxxxx> wrote:
> a) CSS styling is broken in gtk. I have tried to use it set various widgets
> and a lot of the time it fails.
>
> b) The only functions which work semi-consistently in gtk+ 3.0 are:
> gtk_widget_override_color() and gtk_widget_override_background_color()
>
> c) The above functions work for most widgets, except for a few cases like
> the background for labels in spinbuttons and the background colour for tabs
> in gtk notebook widgets. There is apparently no way to set these. You can
> try via the above functions or by CSS but the colour cannot be changed
> within an application.
>
> Regards,
> Salsaman
>
>
>
> http://lives.sourceforge.net
> https://www.openhub.net/accounts/salsaman
>
>
>
> On Mon, May 4, 2015 at 10:01 AM, The Devils Jester
> <thedevilsjester@xxxxxxxxx> wrote:
>>
>> That may be an elegant solution to drawing using theme parts, but thats
>> not the question. That is not an elegant solution for getting solid colors
>> that are similar to the overall theme, but not using gradients or textures.
>> The deprecated function gives me a useful, expected value, what ever it does
>> to give a reasonable approximation has worked great for years, where as the
>> other function gives me black for all background colors, all the time, on
>> almost every widget. (Some give white).
>>
>> On May 4, 2015 7:49 AM, "Emmanuele Bassi" <ebassi@xxxxxxxxx> wrote:
>>>
>>> Hi;
>>>
>>> On 4 May 2015 at 13:38, The Devils Jester <thedevilsjester@xxxxxxxxx>
>>> wrote:
>>> > I am aware of the dynamics of GTK
>>>
>>> If you say this, followed by:
>>>
>>> > In the same vein, of colors, can someone explain what I am doing wrong
>>> > when:
>>> > gtk_style_context_get_background_color(context, GTK_STATE_FLAG_NORMAL,
>>> > &bg_n); gives me nothing but black for the same widget that
>>> > gtk_widget_get_style gives me the (expected) rgb (214,214,214) ?
>>>
>>> Then it means you're not really aware of the dynamics of GTK.
>>>
>>> The gtk_widget_get_style() function is a deprecated API that we had to
>>> leave in there because the CSS style machinery wasn't finished by the
>>> time we released 3.0, and because applications would have needed much
>>> more porting from 2.x to 3.0 if we downright eliminated that function.
>>> It was not optimal, but the other option would have been to delay GTK
>>> 3.0 by another 6 to 12 months, and that would have had a cascade of
>>> effects on the rest of the ecosystem based on GTK+. Historical reasons
>>> aside, this means that gtk_widget_get_style() returns a best effort
>>> value which may or may not make sense.
>>>
>>> For instance, if you ask gtk_widget_get_style() the for the background
>>> color of a widget using a with a background image in CSS, what color
>>> should you get? What happens if the widget is using a gradient? Right
>>> now, it's completely undefined. That is why you don't query a style
>>> context for a background color: you just ask the style context to draw
>>> a background, according to the state in which the style context is.
>>>
>>> > but the need to render custom widgets to
>>> > use a similar color palette to the current theme is a real one that
>>> > does not
>>> > seem to have an elegant solution.
>>>
>>> The elegant solution is to use the gtk_render_* family of functions.
>>>
>>> Ciao,
>>> Emmanuele.
>>>
>>> --
>>> https://www.bassi.io
>>> [@] ebassi [@gmail.com]
>>
>>
>> _______________________________________________
>> gtk-list mailing list
>> gtk-list@xxxxxxxxx
>> https://mail.gnome.org/mailman/listinfo/gtk-list
>>
>
>
> _______________________________________________
> gtk-list mailing list
> gtk-list@xxxxxxxxx
> https://mail.gnome.org/mailman/listinfo/gtk-list
>
Jasper
_______________________________________________ gtk-list mailing list gtk-list@xxxxxxxxx https://mail.gnome.org/mailman/listinfo/gtk-list
