Slashdot Mirror
WebKit For Metacity/Mutter CSS Theming?
An anonymous reader writes "As Metacity (the GNOME window manager) evolves into Mutter, the question of CSS themes and how to implement them has come up. One of the proposals was WebKit, which the author asked more specifically about on his blog. It seems that WebKit, being a very fast rendering engine, would allow Mutter to have unprecedented power, not to mention being nearly future-proofed. As a major bonus, going this way could allow GNOME to share themes with KDE, which is apparently already headed towards a dependency on WebKit. Many people will reflexively recoil at the idea of a browser being mixed with a window manager. But it's important to remember that WebKit is not a browser — it's just a rendering engine, and it's not where all the security issues come from. So, what are the real technical issues at stake here? What are the pros and cons of using WebKit underneath GNOME rendering?"
It's too bad, what with Metacity being one of the few window managers available.
Nerd rage is the funniest rage.
One of the pros: GNOME gets a "tested" engine to do most of the work required...
And the con: GNOMErs will squabble about what to drop and in the end, they will create more duplication. Not good...not good at all.
Indeed.
Now webkit isnt a porous mass of malware-friendly hooks like you have on windows, it's true. At least not yet. Nonetheless, sometimes it's best just to accept that the fact you *can* do something stupid like make your window manager depend on an unrelated application, that doesnt mean it's actually a good idea.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Friends don't let friends enable ecmascript.
"Lets see, some person makes a "theme" that exploits a flaw in WebKit"
Could you explain to me why this would be a greater security risk than some person making a "theme" that exploits a flaw in Metacity?
As long as it keeps my desktop active, like some sort of active desktop, then it's all good.
Yes, yes it is. And a lot of vocal people whinge about how removing IE doesn't remove Trident, which shouldn't be part of the OS, because god dammit, people MUST BE ABLE TO CHOOSE, and now you're not letting me choose not to have WebKit, because my 2 user fork of Gecko is better because it lets me do X, Y and Z.
Sounds like a double standard to me. Either integrating the HTML engine with the window manager is bad (Trident/Windows) or it's good (WebKit/Mutter). It's not both at the same time because you want to be an individual and hate Microsoft, just like everyone else does.
Indeed, nothing says UNIX like a binary format.
CSS barely functions on the platform for which it was intended, and now you want to bring it to a platform that has well-established, functional, themeable rendering engines already in existence?
CSS was intended to let designers seperate from function from form - how is that lacking in current themeing environments? The linked blog contains a laundry list of features that are in CSS that are not applicable to desktop themes and features that are not in CSS that are necessary for desktop themes. What I don't see is a list of features that CSS brings to desktop themes that are impractical in existing systems.
Let's see: a system that barely works on its intended platform that contains functionality not applicable to the new, suggested platform and is missing functionality necessary on the new, suggested platform. Gee, sounds like the right technology for the job!
Unless you were frozen in th 50s, that comment can only be explained as a joke... if there is something of which there is plenty, that's window managers...
But let the rendering engine strip or blobify the skin/theme files. Who cares what the underlying descriptive language is, let it be something people are already familiar with. Imagine if every time a new software project was started we first created a new language, that's what we generally ask of our theme/skin designers. I guess someone's thinking outside that box! :P
Quack, quack.
But, your window manager doesn't run as root. And themes have to be installed by the end user. This is no less secure that just using a browser.
The overhead could be ridiculous, sure, but this just isn't a security problem.
Browser rendering engines? In my application UI? It's more likely than you think, especially if you use Firefox, or any other application built around a XUL runtime. How many CSS-only exploits you heard of for them?
Wait, how does this make it easier? Metacity's code is open already.
There are going to be a ton more crackers wanting to find ways to exploit Safari and Chrome than there will ever be wanting to find flaws in a WM.
And a ton more hackers working to fix those flaws.
Basically, without WebKit GNOME is just another DE, interesting, but not worth the work to exploit. On the other hand, with a ready-made script, it wouldn't take too long for someone with no skills to exploit it.
So you're basically arguing in favor of security through obscurity, and against code reuse?
Also, I fail to see how it's more dangerous for the average user to have their WM compromised than their browser. It's a lot easier to trick people into visiting a website, just once, than it is to convince them to install your theme.
Don't thank God, thank a doctor!
I have no idea why you're modded insightful. I'm tempted to mod you down, but I'll reply, instead:
I know its fashionable these days to do everything over HTTP and inside a browser but it's just a fad.
Yeah, the Web is "just a fad". OK, I'll get off your lawn.
Oh, and what does HTTP have to do with this? Or a browser? This is just a rendering engine, nor is it the first app to do this -- Firefox itself does its UI in XUL, as does Thunderbird, Songbird, and several other apps.
Everybody knows it sucks from a design / efficiency point of view
Design, you may have a point. I'd be interested to hear it.
Efficiency is actually getting quite good, especially for what this is.
I'm not going to waste my time writing a detailed rant about why you shouldn't use a freaking browser rendering engine to draw your GUI for you because thanks to the openness of Linux I will just be able to load one of 10's of other, infinitely faster window managers.
Good. But if you'd written a longer rant, there might actually be more to discuss.
But let's go back to your original point:
Would it not be better to use a compiled, binary version of CSS for this sort of thing to reduce the overhead.
So... Why would we want to use a "compiled, binary" version of anything we don't have to? Your startup scripts are in Bash. If you're on Ubuntu, a fair amount of your upgrade scripts are in Python.
For efficiency's sake, you say. Ok, but why would you want it stored that way? Web browsers are proof that it really doesn't take that long to parse CSS, HTML, and Javascript. There's no reason the runtime can't store them in some binary/bytecode format, but why would you complicate the on-disk format?
For space? Those things compress well. And again, browsers are proof that compression is fast enough for people to not notice or care.
For boot time? Again, browsers prove that's kind of a non-issue -- most websites I view are massively more complex than some borders around a window. Turn on Flashblock, and tell me you wouldn't love for a computer to boot as fast as a typical website loads.
Now, I understand where you're coming from. I used Fluxbox for a long time. Then I realized that KDE4 loads in about two seconds on my machine, and zero seconds vs two seconds to load a GUI isn't enough of a difference for me to care, considering the functionality I get out of it. (Actually, I realized this with KDE3...)
And as for the functionality, I don't know the first thing about skinning a window manager. I do, however, know how to build HTML and CSS. So, me suddenly knowing how to build themes, easily, I call that a useful feature.
Don't thank God, thank a doctor!
unless you are an expensive coffee drinking,
You.
iPhone toting
In.
meeja student
Sensitive.
with messy hair
Clod!
who lives in a big city
Oh, nevermind.
Paul Grosfield - the quicker picker upper.
and a pre-made rootkit to gain access.
you keep using that phrase, I don't think it means what you think it means.
1) your WM runs at user level, an exploit would therefore at best gain the ability to run code at user level.
2) you WM can be locked down pretty tough by apparmore/selinux/etc, so whatever code it can execute is limited to the functions of a WM anyway (no net access, no disk writes, etc)
3) if your downloading random themes from untrusted users, it's easier to attack you by giving you a widget/screenlet or random script to run.
4) if there is a security flaw in the webkit rendering engine, surely you can just exploit peoples browsers when they go to download your theme.
In summary please never talk about security ever again.
IranAir Flight 655 never forget!
I'm not sure I understand how you start by saying that CSS barely works for the target environment - BILLIONS of web pages are served every day in a (relatively) cross-platform fashion.
Many of these are rather good looking, too.
So I'd have to argue that CSS doesn't work. The areas where CSS is weak consist primarily of CSS specs that have NOT been implemented (*ahem* IE) or implemented in a bone-headed way (*ahem* IE) not in areas of weakness within the CSS spec itself.
Perhaps the most amazing thing about CSS is how trouble-free its implementation has been, and just how smooth the transition actually has been.
Old stuff still basically works, new stuff just basically works better.
But while we're at it, we should also pay homage to KDE, Konqueror, and its many progeny. KDE begat Konqueror. Konqueror begat Webkit, which has begat (among too many other web-like to mention) Chrome/Chromium and Safari. And just about everybody who has worked on or with Webkit has raved about its clean design and crisp implementation.
So, we must give kudos to the excellent KDE team who has produced a product that is just now starting to give Mozilla / IE a run for their money, without all the funding by AOL for all those years.
Good job, KDE team!
I have no problem with your religion until you decide it's reason to deprive others of the truth.
Are you... FUKING MAD?
I'm sane enough to know how to spell 'fucking'.
A whole desktop using a HTML engine to render the entire desktop?
I don't know that I suggested that. Doesn't have to be pure HTML, nor did anyone suggest that it be the entire desktop. Oh, and the original proposal was apparently for CSS and XML -- so more like XUL.
Are you using Firefox? Its entire UI is done in XUL, and rendered by Gecko.
You know the nigthmare to create and respond to events using html and javascript?
It's actually like some beautiful dream...
Ok, yes, could be better. Has also been beaten into submission by frameworks. I can create and respond to an event nearly with a one-liner -- and I'm doing it not just with callbacks, but with callbacks that are also closures. Javascript is actually a good language -- I am not insane, I'm not being sarcastic, and if you really disagree, I suspect you don't know it very well.
And the ridiculous performance against a normal window manager like KDE or the actual GNOME?
KDE4 already uses Ecmascript (Javascript) for a few things. I wouldn't be surprised to find HTML and Webkit in there somewhere.
And for what it's worth, browser speeds are actually to the point where they occasionally double between releases. The fact that you think this would be slow mostly means you've dealt with slow, unoptimized implementations.
Or, in other words: Have you seen Chrome?
You maybe like to use a US$2000 machine to simply get the GUI usable
Actually, the machine cost more, but it does hell of a lot more than "simply get the GUI usable". KDE4 also runs on a five year old machine -- not particularly fast, but works fine, and better than the XP that was there.
Don't thank God, thank a doctor!
So... Webkit renders html as far as I know. So the proposal seems to be to render the entire Gnome gui by feeding html at it. I hope I'm wrong, because if that is correct then it would be a really goofy way of going about things.
You're wrong, don't worry.
A window manager pretty much manages the window decorations (title bar, borders, et cetera) and window actions (close, maximize, resize, move, roll-up, sticky, always on top, always on bottom, et cetera).
Metacity is a window manager and nothing else. It doesn't handle what is in the windows themselves.
Oh, and their only proposing to use CSS. No HTML.
Active Desktop was part of or released with IE4, probably in mid-97. Too bad it sucked system resources so hard and was so unstable
Pain is merely failure leaving the body
Just a random thought off the top of my head, but would using css potentially help with technologies such as screen readers for the blind? Also, as you could have named areas, does it open up areas which can be set as preferences, for instance deciding that you prefer to have menus always at the top of the screen.
Just my 1p
Unless you were frozen in th 50s, that comment can only be explained as a joke... if there is something of which there is plenty, that's window managers...
* -- joke
OO
OOOOO -- the cloud
OO
o
\|/
| -- you
/ \