Hi Thomas,
On Thu, 2010-10-14 at 14:20 +0100, Thomas Wood wrote:
> On Thu, 2010-10-14 at 12:19 +0200, Carlos Garnacho wrote:
> > Hi Benjamin :),
> >
> > On Wed, 2010-10-13 at 18:40 +0200, Benjamin Berg wrote:
> > > Hello,
> > >
> > > So, some notes about the gtk-style-context branch.
> >
> > Thanks for reviewing the branch. FYI, I'm currently in the process of
> > documenting the changes, I was planning to send a mail here once there's
> > some docs that cover the different aspects.
>
> One other aspect I'd like to mention is the theme engine API. Currently
> it's possible for theme engines to hook into the gtkrc parsing and add a
> custom parser. I noticed that there is a function that allows theme
> engines to register new properties, but how would a theme engine like
> the pixbuf engine be able to parse custom syntax?
The custom syntax would be enclosed in the CSS property value, it is
possible to install parsers for these, so doing:
gtk_theming_engine_register_property (engine, "pixbuf",
GDK_TYPE_PIXBUF, NULL,
_engine_pixbuf_parse);
would allow doing in the CSS:
* {
-EngineObjectName-pixbuf: foobar.png 1 2 3;
}
_engine_pixbuf_parse() would be responsible of parsing "foobar.png 1 2 3
" and produce a GdkPixbuf value out of it.
FYI, there is already support for background-image (Although it just
supports gradient patterns ATM) and border-image (also supporting 9slice
for rendering at different sizes), so this is supported by the CSS
parser:
GtkButton {
background-image: -gtk-gradient (linear,
top left,
bottom left,
from (shade (@bg_color,
1.1)),
to (shade (@bg_color, 0.7)));
border-image: url (button-border.png) 4 4 4 4 repeat stretch;
}
>
> Also, some engines (such as the windows engine, see msw_style.c) want to
> set style property values based on platform API calls. Currently this
> has to be done by constructing a string and calling gtk_rc_parse_string.
> Will there be an better way to do this in the style-context branch?
For the windows theme usecase, I think it makes sense to have this piece
of code in GTK+ itself. GtkSettings has already a similar role in that
it has information about symbolic colors and font size, this is hooked
up into the theming machinery by having GtkSettings implement
GtkStyleProvider. So I think it makes sense to put this into
GtkSettings.
If this is badly needed in other places, there is a per-screen list of
GtkStyleProviders, shared amongst all GtkStyleContexts in that screen,
so a theming engine could theoretically add a custom style provider for
its screen. Although this is a hackish solution I wouldn't advise.
>
>
> > >
> > > The gtk-style-context branch mirrors the current drawing functions very
> > > closely. I know that this requires quite some work, but there are some
> > > things that can easily be changed now:
>
> We've talked in the past about moving away from abstract drawing
> functions to more widget focused functions. This would help custom
> widgets that want to mimic existing widgets and it would also make it
> easier for other toolkits to mimic GTK+. What are your thoughts on this?
I think this pertains to a higher layer, if we want to fully mimic both
simple and complex widgets, I think we need full MVC, and the rendering
still has to be splitted piece by piece somewhere.
There is also a problem in user interaction, the simplest of complex
cases I can think of is the spinbutton, it doesn't make sense to render
a spinbutton as GTK+ would if the clickable areas are going to differ.
For simple cases (that construct more complex ones), I'd advise pushing
for a standard set of class names, so for example:
.entry { ... }
.button { ... }
would respectively style all widgets using the "entry" and "button"
classes, while:
GtkSpinButton.entry { ... }
GtkSpinButton.button { ... }
would style a GtkSpinButton entry and buttons respectively.
>
>
> > > * Make focus just a simple flag (that can also be checked from the CSS)
> >
> > There is GTK_STATE_FLAG_FOCUSED in GtkStateFlags, it can already be used
> > as any other state flag (including transition animations), but you are
> > right in that this isn't hooked to the CSS parser yet, should be matter
> > of adding a new scanner symbol in gtkcssprovider.c, create_scanner().
>
> If there is a flag for focused widgets, would this mean you could remove
> the "render_focus" function? Or would this function just be omitted from
> widgets that support the focus flag?
Good point, I guess it can go away.
>
>
> > >
> > > It may be possible to get rid of the text/base vs. fg/bg color pairs,
> > > and instead just use one set of colors with different values depending
> > > on the widgets (ie. any "input" widget like GtkEntry, GtkTextView,
> > > GtkTreeView would get a white background, while the rest is gray).
> >
> > I've been thinking back and forth about that. As far as I can see,
> > mostly depends on what the plans are for GtkStyle if this branch gets
> > merged in, If we only have GtkStyleContext, we can have per-class and
> > per-region styling, so for example a spinbutton can use different colors
> > when rendering the entry than the buttons and we could do away with just
> > fg/bg.
> >
> > If GtkStyle is to stay for easier compatibility, we still need
> > meaningful data in the GtkStyle struct, or we'll screw up any widget
> > external to GTK+ wanting text/base.
>
> It's quite common for developers to use the wrong combination of colours
> (e.g. using text and bg together), so it would be great if they could be
> consolidated. If GtkStyle needs to stay for compatibility, maybe one of
> the colour pairs could be generated using some heuristics?
Not sure, provided we have a standard "entry" class, I guess we could
set text/base to the fg/bg colors of the style with such class enabled.
Cheers,
Carlos
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
