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?"
But it's important to remember that WebKit it 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?"
Ok, so lets see, ignoring the huge overhead this will have and the slowdowns. How isn't it a security risk? Lets see, some person makes a "theme" that exploits a flaw in WebKit to let them run a rootkit. How doesn't this sound like a bad idea? Its becoming more and more like Windows....
Taxation is legalized theft, no more, no less.
But it's important to remember that WebKit it not a browser, it's just a rendering engine, and it's not where all the security issues come from.
And Trident is "just" the rendering engine for Internet Explorer. Yet it's where ALL of the security issues come from.
Make it happen so that Open-Source OS's can move onto standardizing the more important OS API's without having to worry about having a standardized theming schematic that is powerful and unbiased towards any visual toolkit or desktop environment. Hopefully after everyone adopts this I can make apps from one gnome look good in kde and vice versa already...
Would it not be better to use a compiled, binary version of CSS for this sort of thing to reduce the overhead. I know its fashionable these days to do everything over HTTP and inside a browser but it's just a fad. Everybody knows it sucks from a design / efficiency point of view (unless you are an expensive coffee drinking, iPhone toting meeja student with messy hair who lives in a big city).
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. KDE4 has already become far too bloated and unresponsive for my liking and it looks like GNOME will be next, maybe XFCE after that but other minimalist window managers will be created to fill the niche left behind by those who fell victim to the awful disease that is feature creep.
I have nothing against features that are actually useful, but this is just extra fluff we don't need
As long as it keeps my desktop active, like some sort of active desktop, then it's all good.
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!
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.
With all this pissing and moaning about Webkit vulnerabilities and whatever, you are forgetting that there almost certainly will be an API which goes between webkit and the the WM (and possibly more APIs on top of that!) which not only makes interfacing with the WM and the rendering engine easier but it also should restrict the amount of stupid things that you can do!... or rather the amount of things that malicious code can do.
Ah... I forgot. Everybody on Slashdot codes in binary (and the noobs use assembly) and do not believe in abstraction layers.
Maybe I'm old-fashioned, but I'm not really seeing why we need so much power or future-proofing in a window manager. The window manager is responsible for... what, drawing title bars and window frames? Can someone explain to me what part of that needs future-proofing or would benefit in any way from an HTML rendering engine? It's not that I disagree, I honestly don't see the purpose or logic at all. I mean, if the GNOME guys decided to replace Gtk+ with WebKit... well, I think it'd be a lousy idea, but I could see the reasoning. This just completely baffles me. It's like if I suggested replacing a bookshelf with a refrigerator. OK, I guess you can put books in a refrigerator if you want; it does have shelves. And I suppose if you happened to have some books which needed to be kept cold, well, that'd be a big plus. Maybe putting an old book in the vegetable crisper would keep it in better condition longer.
But seriously, I'm not sure I've ever seen such a shining example of a solution looking for a problem.
Who the hell needs CSS+webkit when you have vim????
(full disclosure: is fluxbox user)
that would be in the comments above you...
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.
There are a whole lot of rendering engines out there, why choose one with an HTML API?
As a hypothetical alternative, OpenGL is also a perfectly good rendering engine, why not use it? It is just as ubiquitous, it supports every conceivable rendering operation one would ever want to perform. Nothing can touch it in the efficiency department. There are OpenGL bindings for many languages. There's even the new javascript OpenGL binding.
If I was going to choose a rendering engine, I would look first at its API. I certainly would not choose to use HTML as a rendering language.
would allow Mutter to have unprecedented power,
Unprecedented? It's not as if Windows didn't integrate the browser/rendering engine into Active Desktop, back in what, 1995? And surely Symphony OS never implemented a gecko-based desktop manager.
Its pretty clear you do not know what you are talking about.
They want to use WebKit as a LAYOUT engine. That is, they want to enable styling and positioning of windows (and other objects) using the CSS and DIV+SPAN box layout model.
PDF/PostScript has none of that. The only thing they have is simple vector and font operations (read: a scanline renderer) - so you are suggesting they should use the Skia renderer in Chrome rather than CSS. But that's not a layout engine!
Explain to me why a window manager needs a web rendering engine?
Kudos to the genius who says this will make metacity "future proof".... How many rewrites has it gone through? Were the last ones future proof? What about when the next big thing comes along and they rewrite Metacity in Javascript?
Seriously, it was already my impression that Linux on the desktop was going backward, not forward... This just makes me wonder what the hell is going through their minds. I miss when these projects did what was necessary and what they claimed, not tried to follow wild geese. I guess that's why I'm still using WindowMaker...
Metacity/Gnome are written in C as is the netsurf browser which also has decent CSS 2.1 support. Is it a good idea integrating a layout engine in C++ that's largely under the control of Apple, Google and Nokia?
No, it isn't; not unless you've completely lost the plot. They've got Vala which is amazingly cool and yet they're seriously considering platform dependencies such as Mono and WebKit (libstdc++). Yuk!
Hey, SanityInAnarchy. I'm not necessarily disagreeing with you, but I do want to point out a few things.
So you're basically arguing in favor of security through obscurity, and against code reuse?
It can also be called homogeneousness with can cause security problems in general. On top of that, with all the features Webkit brings it also brings complexity in code... which inherently leads to more security flaws. As an example, many forums only allow bbcode instead of full-blown html.
In the end I think the features are probably worth it, though. While metacity themeing isn't hard per-say, it would still be much easier and more powerful with css. And as an ex-Firefox theme developer, I think the benefits way outweigh the drawbacks.
Once you start despising the jerks, you become one.
WebKit ships with QT. KDE depends on QT.
It's said that when they gave their first presentation in London, most people present knew nothing about computers and were quite unable to understand why they were looking at pages of slashes. One person asked if they were "the Manchester rain beating on the windows".
Years later, I amused myself doing hex dumps using a teletype. It's quite easy to produce a rainy city-scape in this way. But, indeed, with hand coded hex, zeroes predominated and ones were much more scarce.
From scarped cliff or quarried stone she cries "A thousand types are gone, I care for nothing, no not one."
Adapting CSS to work for UI skinning is a good idea. It leverages very common knowledge and works based on a powerful model.
Implementing this by shoehorning an entire Web rendering engine into a window manager is not a good idea. By definition it means including a huge amount of unrelated and unneeded functionality, any or all of which could contain bugs. Witness the lessons of Display PostScript in NeXTStep, which introduced security problems due in no small part to including far more than was needed for the job (a lesson that Quartz and its descendants have avoided by sticking to the more limited, but also more task-appropriate, PDF model).
Swiping the CSS parser from WebKit is a good idea: it's a mature technology with solid performance. Cramming all of WebKit into the window manager is a bad idea: most of it would, for this specific purpose, be meaningless bloat that stands to do a lot more harm than good.
third