On Fri, 2008-10-03 at 13:38 +0000, Thomas Wood wrote: > Hi Rob (x2), > > What you proposed sounds interesting, but I wonder whether we're in danger of > over engineering here. Styling an application using css-style syntax rules is > a > fairly simple requirement. Creating a multi level generic css styling system > seems an order of complexity greater than what we really need. The end > requirement is that the end user doesn't need to learn yet another styling > language in order to style their applications. I'm not sure it makes sense to > share the same small bits of code cross toolkit, for the amount of benefit we > gain. > > Anyway, just a thought...
Talking with Robsta a bit on IRC, it looks like the abstractions are already there to some extent anyway. Since he's looking at sharing code originally used for a GTK+ theme engine with Clutter I think it makes sense to tidy up the divide between his "selector engine" and the Cairo specific code. I'm fairly sure we aren't talking about adding complexity (certainly not order of magnitude :-) ) Some of the code *can* be shared across toolkits. I.e. I see this more of a code organisation problem and a few typedef tweaks, it doesn't really affect the code that needs to be written one way or another. (except perhaps the canonical name stuff - but I'm fairly sure that can be a later consideration anyway) (To be clear about the canonical name stuff though, a.t.m that's more of a would-be-nice feature, to keep in mind, but I see no reason that it couldn't be implemented later.) At the end of the day, we need code to parse CSS data; code to handle cascading and using selectors be able look up the right data for a particular toolkit widget. We also need code that does rendering, via Cairo for GTK+, and via Cogl for Clutter. In a Clutter toolkit we would also be affecting layout based on padding properties, I'm not sure if the GTK+ code supports that a.t.m. As far as I understand it Rob has achieved the toolkit independence by representing the hierarchy of widgets in a "document tree" of "nodes" which is different from my idea of having an opaque NativeWidget type. I can't see any real advantage of one approach over the other, so sticking with the document tree makes sense to me. I think Rob also has a simlar concept to my backend interface, which uses a vtable of functions to access widget data: robsta: rib: basically, there is no toolkit-specific code in place now, the consumer has to submit a vtable when querying the stylesheet robsta: rib: the vtable consists of one-liners like "clutter_actor_get_name()" for the implementation of the "get_id()" hook kind regards, - Robert -- Robert Bragg, Intel Open Source Technology Center -- To unsubscribe send a mail to [EMAIL PROTECTED]
