Sharing CSS code between Gtk and the Shell

2013-02-06 Thread Giovanni Campagna
Hello Gtk and hello Shell developers,

In https://bugzilla.gnome.org/show_bug.cgi?id=687881 I promised I'd
try to address one of the big performance problems in the current
gnome-shell, which is the St theming system.
Currently St does an awful lot of string matching again and again, as
neither the style classes and element names, nor the property names
are interned or preprocessed. We rely on libcroco to do basic
tokenization, but that's it, everything else happens every time a
StThemeNode (~ GtkStyleContext) is computed. We introduced some
caching at the beginning of the 3.7 cycle, but to me that's just
papering over a bad implementation.
So I started to rewrite it. I streamlined selector matching, added
quarking to classes, tried to normalize css values at parsing time and
finally built a map of known CSS properties to StThemeNode fields. But
I don't have a selector tree, I don't have GtkBitmask optimizations, I
had to reimplement GtkCssValue, etc.
The patch is not complete (it's missing background properties), but
I'm thinking: why should I write this again? Someone else did this in
Gtk, can't we just use that?

And this prompted me to this mail: is there a way for gnome-shell to
reuse Gtk CSS implementation?
Ideally, we would just use GtkStyleContext outside GtkWidget, and
parts of Gtk's docs claim it is supported. But I'm curious on what
assumptions are made from GtkWidgetPath, and if those assumptions can
be worked around or lifted. Additionally, there are a number of
accessors that are not exposed by GtkStyleContext or GtkThemingEngine,
but are available only to Gtk internals.
Consider that we can't use gtk_render_*, since we use Cogl for
painting, not cairo.
The next issue with that straightforward approach is that St's theming
is slightly more powerul than Gtk's. Looking at the gtk docs, I see
Gtk has no support for box-shadow, icon-shadow (st extension),
background-position, background-size, outline, text-decoration,
text-align, as well as width, min-width and max-width. If we were to
use Gtk directly, we would need to move our implementation into Gtk,
or work around that limitation.
Also, I saw that Gtk has recently deprecated extension CSS properties.
We use a number of those in gnome-shell, and it's not always possible
to replace them with standard CSS2, although I guess it'd be possible
to use gtk_style_context_save() / add_class() / restore() like Gtk
themes do.

The second option is to share just code, in some form, either as a
private shared library that would be provided by Gtk
(libgtk-internal?) and developed by both teams, or just as a copy-lib,
with a massive s/Gtk/St/. I'm not sure what would be the cost of this
last possibility, but I'm still convinced it would be lower than
rewriting from scratch, and maintaining two different CSS
implementations in GNOME.

Looking forward to your comments,

Giovanni
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list


Re: Sharing CSS code between Gtk and the Shell

2013-02-06 Thread Jasper St. Pierre
I looked into this a while ago, and one big issue with this is that we
can't e.g. implement custom properties that we just fetch from JS. So we
couldn't implement any of our -st- properties or any others that we just
make up on the spot. I don't know if it would be possible or feasible to
add this to Gtk. In our current St implementation, the tokens that come out
of libcroco are especially hard to parse correctly, and we can't access
this from JS, so it might be possible to add some very simple custom
property system for colors and lengths, and that's it.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list


Re: Sharing CSS code between Gtk and the Shell

2012-12-17 Thread Alexander Larsson
On ons, 2012-12-12 at 19:01 +0100, Giovanni Campagna wrote:
 The second option is to share just code, in some form, either as a
 private shared library that would be provided by Gtk
 (libgtk-internal?) and developed by both teams, or just as a copy-lib,
 with a massive s/Gtk/St/. I'm not sure what would be the cost of this
 last possibility, but I'm still convinced it would be lower than
 rewriting from scratch, and maintaining two different CSS
 implementations in GNOME.

I think this seems like the more doable approach. The gtk css machinery
is very much not a public API/ABI and it changes a lot internally and
needs to continue doing so. However, just splitting out the code doesn't
really work well as it will conflict with symbol names and GType names
if both are pulled into the same binary. So, we would need some kind of
setup where cpp defines modify the exact prefix on symbols and GType
names. That way we can use two different out-of-sync versions of the
code in the same process.

Of course, just splitting this out will be quite some work, as there are
a number of interdependencies with the gtk+ code...


___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list