On Fri, 2008-10-03 at 10:31 +0200, Robert Staudinger wrote: > Hello, > > it has been brought to my attention that CSS support for clutter > applications might be of interest to you. As part of my gtk css > theming effort I'm writing a standalone CSS drawing library; the > clutter/cairo integration makes bridging the gap between clutter and > CSS fairly straight forward. I've recently written two simple examples > to get things moving: > > http://www.gnome.org/~robsta/tmp/cccss-0.png > http://www.gnome.org/~robsta/tmp/cccss-1.png > > Standalone libccss ("the cairo css library") is blocking on fd.o [1], > but can be built from the CSS engine's [2] source tree (pass > --enable-libccss). The examples are in libccss/cccss/ (c^3 for clutter > cairo css, looks like i need to find a better name). > > Let me know if this is of interest, so we can think about turning this > into something useful. Oh, and don't be misled by the homegrown > screenshots above, things can look more appealing if you get design fu > involved: > > http://www.gnome.org/~robsta/gtk-css-engine/0.2/Gilouche-CSS-0.2.png > > [1] http://bugs.freedesktop.org/show_bug.cgi?id=17480 > [2] svn.gnome.org/svn/gtk-css-engine/trunk/
Hi Rob, We've also been thinking about how CSS theming for a Clutter based toolkit could work, and would be keen to know what you think of some of our ideas: Initially I believe we just need a thin CSS API that can take abstract widgets and let you query the CSS properties for those widget. The library would just deal with the selecting and cascading but *not* any drawing. Essentially the reason I say it shouldn't cope with drawing is because abstracting between widely different graphics APIs (i.e. cairo vs COGL/OpenGL) sounds very awkward, it's not an explored problem as far as I know so I don't imagine we'd get this right initially, and at least on the COGL side we probably don't even have all the graphics APIs yet for some things CSS can describe so I think we need an approach that lets a specific toolkit incrementally implement the rendering code without impacting/holding back other toolkits. To clarify what I mean by abstract widget; I mean the API should work in terms of a NativeWidget typedef instead of taking GtkWidgets or TidyActors etc. The toolkits can then each implement a backend interface that handles querying the class names and info of specific widgets. I have a strong suspicion that you already have a foundation that covers some of this stuff so it would be interesting to know what you think of this approach? So e.g. here is a vague outline of the API as I imagine it: First you need to be able to create a context and let the toolkit specify the backend which handles actually reading a widgets class name etc: css = css_context_new(); css_set_toolkit_backend (css, tidy_backend); Then there would be API for letting the CSS API know how the widget heirachy changes since this affects the selecting/cascading of CSS data: css_register_top_level_widget (css, CSS_NATIVE_WIDGET (stage)); css_reparent_widget (css, CSS_NATIVE_WIDGET (widget), CSS_NATIVE_WIDGET (parent)); ... Finally there would be API for querying the CSS data for specific widgets, used by the code that renders the widgets and deals with layout. I imagine having at least some kind of raw property accessor something like: css_widget_get_property (css, CSS_NATIVE_WIDGET (widget), "foobar", &foobar); But then there could be nice convenience APIs that lets you query things in ways that are especially helpful to toolkit paint/expose/layout mechanisms. Toolkit abstraction interface: This would be an interface that GTK+/Tidy/OtherToolkit would implement. Since were proposing the CSS library could work internally with opaque NativeWidgets it needs a way to access all the widget details used for calculating the cascading/selections. get_widget_canonical_class_name - Returns a string like "Button" (It would be really nice to be able to write CSS that can be applied to multiple toolkits, so as Owen suggested on the gnome-themes list it would be nice to define a pallet of widget names that we know all toolkits will implement one way or another) get_widget_class_name - Returns a string like "GtkButton" (In reality there will be corner cases where the pallet of widgets defined wont be specific enough so it should still be possible to select based on the real class named) get_widget_parent - gtk_widget_get_parent get_widget_siblings - gtk_container_get_children get_widget_name - needed for #name selectors compare_widget_property - needed for [property=blah] selectors - This would be a wrapper around g_object_get_property that would need to stringify the value for comparison with the users CSS value (or de-stringify the users value depending on what's most appropriate) get_widget_css_private_state The idea here is to let the toolkit define the most efficient way of associating per widget private data with widget instances. So I think you already have code that deals with cascading a selecting to some extent, and wonder what you'd think of exposing that code via an interface similar to above? I think it should then be possible to sit your existing cairo specific code on top of that in a GTK+ theme engine and start working on Tidy code that can draw using Cogl. Anyhow, thanks for the interest Rob, it would be cool to see some progress on CSS theming for a Clutter based toolkit, I hope you can help. kind regards, - Robert -- Robert Bragg, Intel Open Source Technology Center -- To unsubscribe send a mail to [EMAIL PROTECTED]
