http://lives.sourceforge.net
https://www.openhub.net/accounts/salsaman
On Mon, May 4, 2015 at 6:11 PM, Jasper St. Pierre <jstpie...@mecheye.net>
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.
>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 <salsa...@gmail.com> 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
> > <thedevilsjes...@gmail.com> 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" <eba...@gmail.com> wrote:
> >>>
> >>> Hi;
> >>>
> >>> On 4 May 2015 at 13:38, The Devils Jester <thedevilsjes...@gmail.com>
> >>> 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@gnome.org
> >> https://mail.gnome.org/mailman/listinfo/gtk-list
> >>
> >
> >
> > _______________________________________________
> > gtk-list mailing list
> > gtk-list@gnome.org
> > https://mail.gnome.org/mailman/listinfo/gtk-list
> >
>
>
>
> --
> Jasper
>
_______________________________________________
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list
