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.

Bookmark/Search this post with

Comments

Most developers I've talked to say they ignore dot comments these days because of all the flames.

Incidentally, the khtml group is very active on irc. I guess they need to put out press releases too? That seems to be the way to work these days. Although anything they say will instantly get bogged down in flames. :P
Further reason to hide. ;)

For want of a better place to put this, and so it gets any attention it can, I really need the "hideable panel", and cant really switch back to kde without it, so I'm using gnome for now, but I always used to use kde, and I REALLY like the new 4.1, but kinda-sorta-really-need that (configurable...) "hideable" thing happening...?? - (Great job though, everyone!)

"hidable panel" is the most annoying feature ever, I hope it never gets implemented so I never have to use a PC that uses this lame feature. It's just so annoying to see the panel appear and disappear all the time when I just want to use it.

Some users like it. As long as you can turn it off, it's better to have it than not to. If you have to use a PC with it turned on, just turn it off and turn it on again when you leave (if you don't have your own user account).

I'm sorry to derail this fine thread, but this argumentation is beyond retarded. First of all, no distribution I know turns on hideable panels by default. It's an option strictly for the people who feel that they want to use the panel occasionaly but need the extra screen space otherwise. Nobody "forces" you to use it other than yourself. Plus, can anybody get more self-centered by proclaiming that your special dislike for one feature should be forced onto a whole community of users, especially if it's not even a fringe case?

He's obviously trolling but this is somehow what the "hiding panel complainers" deserve, cause they're doing so much ado for a feature used by a minority of users (and in NO WAY blocker for a KDE release).

a lot of 'features used by a minority of users' where cut and not reintroduced, especially the many things that made KDE3 so lovely for power users (f.e. interface short cuts saving two three clicks/key presses on every file action, compared to windows, packing the panel full of features without sacrificing a pixel to white space)...
Not only that, but the strive to GUI-wise turn KDE4 into a Vista/Leopard hybrid (i.e. hiding 'complexity', removing configurability in favor of 'defaults that please 90% of the users') totally took the fun out of using it for me. And i really tried to like it, having installed from SVN since beta phase and regularily upping. But i do see no progress on winning back the hearts of power users, just bling hype, overstatement and complacency...
(and yes, as soon as i have the time to do it, i will contribute patches.)

I'm not a fan of the panel hiding feature, but one increasingly important use case for having a panel that can be hidden is on UMPCs like the Asus eeePC and the new crop of UMPCs. These machines have screen resolutions around 1024x600 and every pixel is precious. A hideable panel gives more extra vertical space, even if it might be a bit annoying.

Tom-with-the-Acer-One here at akademy yesterday showed me his work-around for this problem. Remove the panel and add the k-menu and taskbar to the desktop itself at the bottom.

"I'm not a fan of the panel hiding feature, but one increasingly important use case for having a panel that can be hidden is on UMPCs like the Asus eeePC and the new crop of UMPCs. These machines have screen resolutions around 1024x600 and every pixel is precious."

True. Another important feautre to have in those machines is the MacOS-type menubar. Instead of wasting space by having each app have a separate menubar, there would be just one universal menubar.

If I were asked, the MacOS-menubar would be enabled by default in KDE: At least that would eliminate most of the "KDE is a copy of Windows!"-whining...

Speaking of hiding menu bars - I have for years and years wanted to "reimplement" the AmigaOS menubar in KDE. Unlike the MacOS menubar that is constantly there, the AmigaOS menubar only pops up when you press the right mousebutton. While you have this mouse button pressed, you can move around in the menues, click entries, set and unset checkmarks with left mousebutton - and once you release the right mousebutton, all actions you have clicked will be executed, in the order you pressed - this is what we old amiga users call "multiselect in menues", and that noone else seem to have implemented - ever, sadly.

I miss this very much in f.ex image processing programs that tend to have long and deep menues. For every action I have to wade through the menues over and over again, instead of just go once. Instead I want to go to menu, click blur, click resize, click save, let go of menu button, see it blur, resize popup coming up, enter new size, press OK, file saved, all done by going through menues only once.

Anyways, a start would be to let KDE be able to hide panels, and assign hotkeys for them to pop up - my hotkey would ofcourse be the right mousebutton.

This also brings me to another thing I miss - complete control over input modifiers, I want to define what happens when I click a file with certain modifier keys pressed, for example if I click a png I want it to open with kview (or other simple viewer), but if I click a png while holding down ALT-key, I want it to open in an editor, like f.ex gimp. To be able to define actions for click, double click and even tripple click would be most welcome - yes "most users" will never need them, I know. I hate "most users", they ruin it for the rest of us :P

Likewice, I want to be able to define what drag&drop does with modifiers, f.ex I might want to drag&drop of image files while holding a key converts all files to pngs in the destination.

I also miss the ability to assign certain commands to certain directories, so that if I f.ex have a directory with images (album), I can set it to open with kview instead of just opening it in the file browser (the default tool tooltype, for those who know amigaos)

While I'm on this wishlist - it would be excellent to have the desktop and the default filebrowser (dolphin) act as one, ideally (IMO), the desktop itself should be dolphin.

First of all, very cool article. As I mentioned in this talk, 4.5 is going to be great. However I feel a minor correction is in place - we're researching animations, transitions, and effects, but these feature are not yet tied to any roadmap nor release target date (in the talk I believe I said "4.5, 4.6, 4.7, we'll see once we know more").