Friday, March 14, 2008

friday

Ah, Friday: such a perfect title for a blog entry: accurate (it is Friday, after all) but utterly useless (it says nothing about that which I may or may not write about). It's also a song title, as Ice Cube might be inclined to say: "You know it ain't no stoppin all tha doggs I'm droppin". Yeah.

Since I get asked from time to time what the aim for Plasma at our next grand stop on the release roadway (4.1 in July-ish) is, I decided to see what Google might say. Turns out Google's slipping: it's the second link for the query "Plasma 4.1 roadmap" that would take you where you want to go.

The content on that page is particular verbose, but that's just how we roll sometime. Some people are trying to help with that foible of mine by collecting content from plasma developer's blogs and the email list to erect a skeleton for The Tao of Plasma which we'll then flesh out with full sentences, capital letters and all that jazz. ;)

Back to the roadmap stuff, among other things this week I've gotten closer to closing out two of my 4.1 items: a QtWebKit based canvas widget and containment configuration issues.

The webkit widget is neat because it means without any indirect widget rendering (e.g. via QGraphicsProxyWidget) Plasma can display web content right on the canvas. This is a faster, lower overhead path to complex web content on the desktop. For handhelds it's even more appealing: why ship a whole web browser when you can just slop html right on the canvas? Ok, granted web content is more than just a web widget, but QtWebKit gets us a long ways to that end. I have the Plasma and MacOS web based widgets already working with this new webkit-driven QGraphicsViewItem, so life seems peachy. I have a little more events propagation work to do before checking it into trunk/.

The containment configuration stuff has really been a whole lot of seemingly unrelated things working up to the big bang: new canvas placement strategies for both panels and non-panels (e.g. desktop containments), more containment subclass flexibility with things such as layout choices, screen vs canvas abstraction improvements, runtime adding and removing of views as containments appear and disappear, etc.

Both Binner and Chani have also be helping out with this particular set of changes with various patches, some of which have served as target points. A good example was Binner's add/remove panels patch which should have worked as he wrote it if one assumed the libplasma API worked as expecte. Of course, it didn't: some things had only been stubbed in, some things were marked with FIXME:'s in the code and other things hadn't been updated to reflect new understandings. Once his patch worked, then I knew my work on that part was done. ;)

That's one of my favourite ways of working, actually: start with code that uses the API that should work but doesn't, get things to the point where they are working. The game is to do it without hacks, without API ugglification and with as few new lines of code as possible.

The last bits left on the containment front are making menus sharable (to increase code re-use and consistency), the ability to swap containments on the fly and the ability to create new ones that isn't a hack. Then we're done and not only will multiple panel heaven be back, but we'll be able to play with multiple desktop containments. Neat.

Panel hiding and greater content control (DependsOn: panel toolbox) are then left and I can start to ignore panels altogether ;)

Once WoC is behind us, then I can start working on the two new plasmoids I want to bring to KDE 4.1: the welcome plasmoid and the timeline.

I'm also really looking forward to the Plasma sprint in April in Milan. It's going to rock. Unfortunately, it's also during P's birthday. The bugfix? Bring him with me. We're going a few days earlier to Toulouse to hang out and enjoy life with Kevin "ervin" Ottens before heading to Milan (and finally Frankfurt for a KDE e.V. board meeting). It'll be P's first trip out of North America and he's really excited. The first 5 days or so will be pure enjoyment for us, the next four will be his introduction to what his dad does when he goes away (hang out with other crazy hackers, see interesting cities, eat out a lot) and the final two will be a nice exercise in patience. ;)

9 comments:

MarcG said...

Hey Aaron, Friday is also the name of Robinson Crusoe's compagnion :)

annma said...

Hope I can meet you and Peyton when you come to the "Pink Town" as we call it. It's great Peyton can visit Europe, next time I see him on IRC I'll test his French ;-)

Grósz said...

Will KDE 4.1 and onwards (at least until 5.0) depend on 2 HTML rendering engines: KHTML and QtWebKit? It is OK to provide WebKit as an optional rendering engine for poorly written web pages that suck in KHTML and for Mac OS X dashboard widgets. But why use it for plasmoids and applications written specifically for KDE while the default HTML viewer remains KHTML? What is the point in wasting memory and disk space by depending on 2 HTML rendering engines in a default KDE installation?

shamaz said...

@Grosz: QtWebkit *is* included in Qt4.4, and kde 4.1 depends on QT4.4. So there is no disk space wasted, or extra dependencies... I suppose the choice of qtwebkit was guided by the fact that it is better integrated with Qt API (since it is part of it). Anyway, the one who code, decide ;p.

@aseigo: nearly 10 days without blogging :o. Now I understand why I thought the planet was quite quiet. Thank you for your work, and enjoy your trip in France ! (ok, and the rest of europe too ;) )

blauzahl said...

@shamaz: Yes, but you're still loading two rendering engines into memory.

I'd like to know what the technical justification is, as it sounds like quite the performance hit. So was this based on marketing or reason?

Anyway, the one who code, decide ;p

Yes, and hopefully they make good choices because users and future developers have to live with it.

Aaron J. Seigo said...

the technical reasons are:

* it can paint directly to the canvas (we aren't held to a QWidget)

* it is what some of the widgets (e.g. MacOS Dashboard widgets) we support are tested against

* it has a bigger development community and receives more real world testing

it's a hard set of realities, and i don't see a reason to fight them when really it's the progeny of khtml anyways.

as for being a big performance hit, the only different is having one more library loaded in memory. the run time memory usage is much more significant than that and would be similar even if the same html library were used.

Anonymous said...

Thanks for your great work on KDE! Enjoy the trip to Europe!

piivi said...

Hi Aroon, a off-topic question: i've just compiled kde4 from svn, and i've found it more and more stable than the last time i did it; anyway, what about the "argb visual" bug?The system tray still looks ugly with some themes and the icons are not well rendered; is there something in the air about solving this problem? thanx, bye! :)

Anonymous said...

hey aaron, is the kde project moving over to git?