Hi Hagen, On Mon, Oct 6, 2008 at 5:45 PM, Hagen Schink <[EMAIL PROTECTED]> wrote:
[...] > Engine API: > - ----------- > > At the moment the designer can only modify as much details of a theme as the > engine provides. That is why I propose a more data driven approach based on > SVG. It is standardized and there are a lot of sophisticated tools to create > and modify SVG files. It also offers the possibility for the modification via > CSS [2]. Even animation would be possible [3]. > > With librsvg a powerful library exists but it has to become more powerful if > it should be usable for theming. I've spoken with the developer, he said he > lacks time so it would be on others to provide patches. As I told you on IRC, what you are proposing here is very well possible on top of the current engine API. However, it is important not to confuse the issues at hand, just because the SVG standard mentions animations that does not mean it's easily possible with librsvg and/or fitting the way how gtk deals with widgets. Also, just starting to write an engine you will have to do a considerable amount of footwork to get where all the other engines are already. What about a more ambitious "reseach project" approach? You could for example try to render an entire GtkWindow with all its children using generated SVG in webkit or gecko. That would give you the ability to actually do animations and you could apply all kinds SVG filters across widget bounds to achieve effects. Start with implementing proxy classes for GtkWindow, GtkHBox and GtkButton that produce the SVG, keep the SVG representation in sync with the gtk widget and propagate events. Once you have left behind the constraints of the gtk drawing model it should be way easier to prototype new theming approaches, like loading SVG images to represent a GtkButton. - Rob _______________________________________________ gnome-themes-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-themes-list
