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?"
"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.
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!