Further to my earlier post, there has been some more talk over at the Metacity blog about styling windows with CSS. There seem to be a few possible ways to implement this:
- use libccss or plain libcroco for parsing, render it ourselves in GTK. Not as crazy as it sounds because we’re only interested in a fairly small subset of CSS. We could make this an external library and let other window managers use it as well.
- use libccss for parsing rendering; this doesn’t yet work entirely
- use nbtk for rendering; this doesn’t yet work entirely
- use WebKit for rendering. This would save work with rendering, but I’m a little wary of embedding a browser into the window manager.
I was also concerned that using WebKit would not allow us to restrict the CSS, which is something we need to do a great deal:
- reinterpret all URLs to prevent themes from calling home, and to provide pixmap colourisation
- allow references to theme colours (“GtkForegroundSelected”, etc)
- not allow dangerous properties to be set at all (it should not be possible for a theme to set min-height on the frame, etc)
Now someone from KDE says that this could be a great opportunity for cross-desktop interoperability: Metacity and Kwin could share theme formats. But apparently KWin already pulls in a WebKit dependency for other reasons, and the KDE person is planning to implement using WebKit anyway, and thinks that we should too.
I don’t know WebKit very well (and searching isn’t helping), but I thought some of you probably do. So what I would like to know is:
- Am I being over-cautious about the footprint implications of an optional dependency on WebKit?
- Is it possible to heavily vet the CSS which WebKit reads? I know WebKit allows host applications to modify the document in memory, but how easy is it to modify the styles?
The window manager and theming should be as lightweight and reliable as possible. Web browsers, even WebKIT based are neither. The security worries are unplesant – to think that desktop themes could theoretically be used as an attack vector, that would be much too worrying. WebKIT is a large codebase and assumptions that held true in Web will not hold true on a desktop in all kinds of corner cases.
A small and very fast C library is the only sane way IMHO.
If you’re only “a little wary” of embedding Webkit into your window manager, I suggest taking a few steps back and looking at it from the outside.
Please.
Hey, using WebKit seems like a bit too much for me. You can use WebKitGTK+’s SoupSession to avoid any network I/O, if you really need, but I am still not sure this is a good idea.
Anyway, API docs for the GTK+ port of WebKit can be found here: http://webkitgtk.org/. =)
@Jonas:
Meiosis. I am a lot wary. It’s just that someone turned up and seemed to think it was a good idea, so I wanted to sanity check.
WebKit in the window manager, or anywhere near it, would be insanity IMHO. The window manager should aim to have a small, efficient and reliable codebase. Whenever some feature requires a deviation from one of those criteria it should be very carefully vetted. And while WebKit can make a decent argument to be “small, efficient and reliable” as a web browser it can’t do the same as a window manager library.
sure it sounds insane if you first about embedding a web-browser inside your window-manager.
But from a program design point of view it makes very much sense IMHO.
What you want to do with themes is transform a CSS description in some pixel graphics and this is exactly what webkit is designed for – and you never know whether you would want to place some javascript based animations in your theme, which webkti would give you for free.
So I would say go for it – probably the relevant parts can be split out of webkit as a library later…
I’m not nearly as convinced as other people that WebKit is as unreasonable for this as a lot of other people seem to think, for several reasons:
1. It’s not any more of a risk as an attack vector than any other complex theme format. Even “browser vulnerabilities”, are often something more like “libtiff” vulnerabilities. Any theme format brings in vulnerabilities.
2. WebKit is a large library, but the odds are in a 2.28/2.30 GNOME desktop, something is already going to be using WebKit.
3. Coming up with a “future” proof theming system of any variety, and HTML/JavaScript/CSS, while being overkill for most cases, is well tested, well known, and as flexible as needed.
I think, in addition, allowing this could permit some pretty interesting future flexibility, in that metacity could expose new JavaScript functions to the themes, and people could implement more complex, or reactive themes (some of this will be required to even implement buttons of course).
libccss is what is used in Moblin for the theming and it works well.
I commented on the metacity blog on this, but I think the initial comments given here are a bit reflexive. WebKit the >rendering engine< isn’t an attack vector any more than anything else you’d make for the purpose yourself. The security vulnerabilities come from the browsers that use webkit, and not webkit itself.
Again, the intitial comments are pretty reflexive. Webkit is an incredibly fast rendering engine that will save you a lot of work. Give it a shot, at least test it out. Any other decision will almost certainly be regretted.
Following up my initial post, i sill claim that a html/css/js u definition is the way to go for a standard, future-proof,advanced, WELL KNOW and having lots of authoring tools.
Webview rendering is not that much heavyweight compare to a glade/gtkbuilder ui construction.
Cascading of styles offers a way to define default values like common spacing etc… To avoid those defaults to be overriden, you just have to make them private and not in public spec documentations.
On the technical aspect, the events generated by such a view elements, in this case DOMObjects, must be bound to GObject/native code. Currently this can be implemented in two ways :
– by exposing the underlying GObjects to the javascript engine and implementing the event-bindings in JS. This could be achieved using Seed in the Webview js context.
– by exposing the DOMElements to the native word, then g_signal_connecting.
Webkit Bug #16401 offers a solution but the initial commiter has a strong personality to say the least and insist on putting JSisms in the binding API. Thus the patch is still hanging.
This approach could be used for apps’ main interface to, following the examples of WebOS, ChromeOS, S60 widgets stuff, and the new mozilla extensions mechanism JetPack.
As a sidenote, Webkit also renders SVG, maybe even more adapted to the discused purpose.
I’ve only looked at WebKit fairly briefly, but the API seems to only expose the whole browser engine, rather than just the CSS rendering parts. My guess would be that using WebKit to do anything other than render HTML pages would involve a fair amount of kludging (though I’d be interested to hear people’s experiences of actually trying this).
@thurman : concerning the non-overridable properties, you could enforce a fixed values sheet to be the lqst CSS loaded. This way it would override any value modification from the theme.
Hi,
I would rather that a new Metacity theme format was compatible with client-side-decorations [1] than with KDE.
[1] http://git.gnome.org/cgit/gtk+/log/?h=client-side-decorations
@John:
Can you explain how a window border theme format can be compatible with GTK’s client-side decorations?
@Thomas: Unfortunately not, my experience with the c-s-d branch is limited to compiling it and having a play. AFAICT the extensions to the Gtk+ theme to support the csd features have not been finalized.
Combine this with suggestions of Gtk+3 having CSS themes, and it seems sensible that it might be a good time to talk to the Gtk+ csd devs about how to share theme formats in such a way that csd windows, and non csd windows look identical.
I think all apps should be written in strict html for the gui, C++ for the performance, and python for the glue, so that no gui ever goes unresponsive, although the application code it interfaces with could.
Among other things, that would allow for themes to rearrange windows’ contents on the and provide all kinds of slick animations without any other code actually built into the apps themselves.
I really like the direction this is headed, whether webkit or otherwise. A lot of this is being looked at from a strictly engineering perspective, which is as it should be. My perspective is more from UI design / theming.
Part of the discussion is sharing themes between KDE and Gnome? Seems like something that would really give UI design a huge boost for the Linux desktop, while at the same time making things simpler for the end user.
I’d have to think this would be a very long term goal though, it almost doesn’t seem realistic.
Using conventions (HTML, CSS, javascript) for UI design in Gnome?
I think it’s a great idea, because there are far more designers that know these conventions for producing high quality work than there are that know how to write Gnome themes.
Whatever the case.. it would be so freaking awesome to be able to use something like firebug to write OS themes!
The approaches do need a great deal more examination it seems.. a lot of concern about using WebKit because of security problems, but I’ve only read vague references and not specifics so far. Maybe start a wiki or something where pros/cons can really be outlined..
Trying to reinterpret the css would be foolish, then you might as well write your own parser. The right thing to do is overload the Loader object in webkit so you can control what goes on the network, for example nothing.
I’m not sure why you would try to protect the theme authors against themselves by preventing them from setting certain properties.
Please be sure to test what happens if you have a reasonable set of rules and a hundred windows, just to make sure you’re not using half a gigabyte of memory in the window manager/browser. Browsers tend to use a lot of memory which is not acceptable in a window manager.
I think that using HTML and CSS really isn’t a very good idea for anything apart from web pages, simply because they are really not that good even at that – the very thing they were designed to do… Window borders should be using some kind of vector format instead.
Using a web renderer for theming a window manager looks like overkill to me, but as long as it is an optional dependency (both at compile-time and run-time) I think it’s perfectly okay.
A see an other great advantage to use a web rendering engine like webkit (or gecko): XBL
It could change the way we create widget in GTK. No more need for C code, only XML with some JS code.
I love my new Nokia N96. Nokia FTW. I found your blog on google and read a few of your other posts. I just added you to my Google News Reader. Look forward to reading more from you in the future.