At Akademy 2008 in Belgium, Qt developers Simon Hausmann and Andreas Aardal Hanssen announced dramatic improvements in the web browser engine in Qt and the canvas that is used by, for example, the Plasma desktop shell. Video support, animations and transitions, optimisations to speed up painting and animations, and new graphical effects open up nearly endless new possibilities for developers to present their user interfaces with. Read on for more details.

Reflecting a video in QtWebKit

Hausmann demonstrated a WebKit based Konqueror web browser displaying video content through the HTML 5 video tag. With only one line of HTML code, video content in Ogg format can be embedded in webpages. Style elements can then display reflections of this video widget. Naturally, the underlying multimedia engine used in QtWebKit for showing video content is KDE's Phonon multimedia layer. Animations will also be possible. By adding simple CSS properties to your webpage elements, you can animate, rotate and fade those elements. Writing rich and animated webpages and of course embedded web content in applications becomes a breeze with QtWebkit.

After Simon's demo of QtWebkit, Andreas Aardal Hanssen entered the stage to show some of the improvements that will be in Qt 4.5 which will be released later this year or in early 2009. After Qt 4.4 brought the goodness of widgets-on-canvas and lots of optimisations that especially speed up Plasma, more breakthroughs in the development of Qt's graphics canvas are coming up. Speed-ups of up to 40 times faster in some cases go along with a set of really nice additions that are unparalleled in today's toolkits and can only be dreamt of in competing offerings. Improvements that will be available in Qt 4.5 include:

Transition animations in user interfaces

Optimisations in painting operations

They are also looking into extensive support for animations through a new animation API, due for an unspecified future Qt version. Graphical effects like blur, bloom, shadow and opacity for items on the GraphicsView are being looked into as well.

Hausmann's and Hanssen's future plans for those components in Qt have been met enthusiastically by the KDE developers. Soon, these new features and optimisations will be available to KDE users around the Free world.

Comments

That was my first thought as well. The nVidia part, that is. I hope so. I personally have only used KDE4* on Live CDs since KDE4* isn't ready for "me", yet (yes, I like *real* icons on the desktop, and a hideable "kicker"). I was going to jump to 4.1 because, well, I really want to, but the nVidia problems have kept me at bay hoping that by 4.2, nVidia will have gotten their act back together enough.

If these performance boots help make KDE4* on nVidia cards much less painless, then I can work around some of the other limitations of KDE4 until they are implemented.

Why should the KDE or Qt guys fix nvidia bugs ?
nVidia recognizes that it's their fault and will release a drivers fixing these bugs, but it's not a KDE or a Qt problem when the vesa driver is faster than the nvidia proprietary driver.

We hope confidently that the nvidia issues are solved *before* 4.5 ships. Qt 4.5 might make some things on nvidia faster, but it's really general optimizations, not nvidia-specific ones. All users should benefit from those optmizations, since they for example improve clipping on graphicsview.

Should have been here about 10 years ago. I know some SMIL 2.0(HTML+Time 2) and these years waiting for these type of things to go mainstream have made me indifferent. By the way, how old is Adobe's SVG viewer that has 1.0 capabilities? And SVG 1.0 is still not fully available on the 'cool' browser today. The third world war will probably arrive by the time developers get their acts...oh never mind...what's the point.

I can tell you mean well, but your statement comes off as being very trollish.

Trying to explain in a simple way: IE sucks and it's in M$'s best interests NOT to add cool non-proprietary stuff to IE. There isn't as much motivation to work on SVG and friends because mainstream web can't use it. If IE wasn't the mainstream browser web page authors would be free to use those features, and developers would have more reason to work on them.

Ah, how is it a 'troll' when the reality is that the SVG implementation in Firefox is not 100% complete; may I suggest you look at the latest info on it, and you'll find that large chunks of the SVG specification haven't been implemented yet.

All very nice to rave about how great a feature is, but pointless if it isn't implemented properly.

Will the performance-enhancing improvements introduce incompatible API changes? Will it be possible to get some of the performance improvements by building KDE against Qt 4.5, even if it doesn't actually require it?

From reading the blog where the Troll mentioned the 40x improvement it *sounds* like it doesn't require changes to the applications, so I think (at least that change) could be gotten for free just by upgrading your copy of Qt.

Even if it requires a change it probably won't be too big, and if it would have a large impact the distros could ship a patched version of KDE with a 4.5 dependency.

As far as I know Qt has strict API and ABI policies for forward compatibility so any application written with Qt 4.x should be compatible with Qt 4.y where y > x for the whole life cycle of the Qt 4 series.

KDE4.0 could easily be built against 4.1, and get many of the improvements (performance stuff, bugfixes, etc). KDE4.1, if built against Qt4.5, would get the performance and WebKit improvements without any source modifications. Even if KDE4.2 isn't dependent on Qt4.5, you can always compile against it and get the improvements.

Now I'm sure most of you have heard that a port of Mozilla 1.9 (and Firefox 3) to Qt 4 is underway. On one of the developers' blogs (http://blog.vlad1.com/2008/05/06/well-isnt-that-qt/), he notes that while Qt is a well-designed modern toolkit, it has a few quirks:

*He notes that a drawGlyphs method on QPainter  something that would take a QFont and an array of glyphs and positions - is missing;
*QPainter cant do arbitrary path clipping with antialiasing
*Cairo has a few optimizations (e.g. with paths) that QPainter doesn't.

Will these quirks be addressed in upcoming Qt releases? It would be awesome to have a better-integrated Firefox (Konqueror is great too, but just doesn't offer the same array of extensions). Thanks!

Actually, having Firefox do its rendering via Qt has little to do with integration. Integration of the webbrowser is about a bookmark system, shared proxy settings, mimetype settings, certificate integration with KIO, password integration with kwallet and of course things like file dialogs from KDE. Using Qt as rendering engine is just one step.

File dialogs is the killer thing for me. I can't stand the damned GTK file dialogs. And yet I really love Firefox. And I think on openSUSE which I've been using lately, I set proxy settings in KDE, and Firefox recognizes them. There is an option in Firefox (it may be an openSUSE patch) to recognize system proxy settings.

Web browsers often have separate mime settings from the rest of the system, because you either open it as a plugin, save the file, or pass it to an app. It is more than just saying app x is related to that file.

kioslave and kwallet integration would be nice, but frankly Firefox stores passwords well enough on its own, where as I find the kwallet pop-ups to be a little annoying.

There is a hack around that makes a lot of GTK applications use the Qt dialogs instead. Works pretty well, and makes GTK apps play a bit nicer in your Qt environment. Of course, don't expect KIO tricks to works all of a sudden.

I can't imagine a Qt firefox using a Gtk file dialog, could you ;). Actually, I'd expect it to use the standard QFileDialog. While it's not as awful as the GTK one, it isn't KDE either. Of course you can always use KGtk or KQt, respectively.

Always good to hear. I may be hopelessly addicted to KDE's application-specific file dialog bookmarks and I may be doing fairly well with KGTK, but it'll definitely be a step in the right direction to have native support for Qt file dialogs.

I could wait a few more days for the videos to be published (but whats the fun in that? :P), but did the talk cover anything about how the QtWebKit API is going to be extended? The main-snapshot documentation (on doc.trolltech.com) has already been extended to include QNetworkDiskCache but I haven't noticed anything about exposing the DOM (directly via the C++ API) or anything about NS plugin support in a while (I had heard that it was in the svn server upstream a while ago)?

I'm also hoping there'll be more information about the new KJS implementation (Frostbyte, I think it was called?) and some of the other stuff going on in KHTML that I've seen blogs somewhat mentioning in the past.

So far I've really enjoyed developing against QtWebKit (the trolls have done an outstanding job with the API so far!) and loved being a Konqueror+KHTML user for quite a while, both are very nice rendering engines and I hope we get to have both actively developed for a long time to come!

You won't see much information on KJS from aKademy since neither Harri nor myself are there; nor is the KHTML uber-guru Germain. ...And besides, being old-school KDE guys we're not big on PR and flashy demos anyway. The initial frostbyte version (-41.0) is indeed in 4.1.0, and I've tweaked a few things since then, though nothing major. I tend to work in a funny way where I spend a lot of time thinking over a design problem at odd times, then when I am I finally happy I go ahead and try stuff... Except even on small stuff I tend to sit on patches for a while since something is always bothering me.
(e.g. stuff like better for ... in behavior on dense arrays and better handling of large
object literals inspired by one of the posts by vandenoever).

Wrt to KHTML stuff: the biggest thing in 4.1 would be contentEditable, though the command set is currently somewhat limited. For 4.2, an ultra-smart SoC student is working on picking up the SVG code from WebCore, and is trying to do so largely through a compatibility layer to keep things from diverging. Though, it is hard since we have a far more minimalistic design philosophy. Can't really give any big KHTML plans from myself, since I tend to just pick off areas which I think need work... Right now e.g. load events from iframes/objects are a bit wonky, though their behavior overall is a lot better after
the big rework in 4.0...

That tastes a bit odd: showing of a new feature once in a while or posting short blogs about current development has nothing to do with PR or "flashy" demos. It is another way of communcation with the users.

There are several ways to communicate with users: e-mail, blogs, news, irc, bugzilla, surveys, and so on. Every project picks the set they think fits their style best.
You didn't pick "web presence", ok - but putting it like "I'm too cool for company like PR" is just plain wrong, both things have nothing in common.

Speaking of odd, he never said what you imply in your post, he just said he doesn't (often/ever) show up at those big akademy get togethers that KDE has, which is not the same as saying he doesn't talk to "users" at all (heck, he posted here didn't he?). Jeez, lighten up.