Plasma in KDE 4.4

Each release of Plasma over the 18 months since its debut release has marked an impressive step forward in its evolution. We are planning on making 4.4, our second anniversary release coming in January 2010, more of the same in that regard.

We recently had our Plasma release cycle planning meeting, and here is our list of goals for central Plasma technologies in 4.4 (in no particular order):

• Improve kiosk based lock down and deployment management: We are communicating with some large deployments in Europe about the process of migrating from KDE 3 to KDE 4 and how we can make KDE 4's desktop shell an even better experience than Kicker and KDesktop provided. We've started a wiki page here that we are working on with these downstream users. Expect a lot more to find its way there over the next few weeks and months as we continue to work out the needs and use cases with them.



• More Cowbell JavaScript: A full JavaScript AppletScriptEngine that provides access to all of Qt and KDE core libs and JavaScript DataEngines.



• Plasma Netbook: A Plasma shell optimized for the netbook use case of a small-ish screen, hardware accelerated video and online usage. It features no taskbar (relying on the "display windows" desktop effect instead), an integrated panel and window title bar, Plasma widgets and a full screen search and launch interface. Hopefully we'll be able to add a media interface as well.



• Media Center Components: A first release of media center components for browsing, collecting and playing media in a full screen Plasma containment. This will not replace Amarok, Dragon, Kaffeine, etc. It's designed for casual full screen usage and will also sport Plasma widget support. Oooh! Full screen widgets! :) Essentially, we believe that a basic media center experience should be easy for the home user to get at, which means it needs to be integrated with the desktop shell and be readily available with it. As a first release, it won't have tons of bells and whistles (something we hope to eventually get by integrating this work with existing media center projects in the future) but it should get us on the right road.



• Remote Plasma: Send your data or your widgets to another computer or device or receive Plasma components on your device. No-configuration local area announcement of services over UPnP, working with all Plasma components without modification, integrated authentication and access control and extensible delivery mechanisms will allow us to share components around a table (e.g. at a meeting), control other systems (e.g. a media center) in the house or even run Plasma services on headless systems on the network. No other widget system out there has this, and even the web hasn't yet achieved this level of relocatability.



• Pluggable Containment Actions: Want to have Control+Alt+MiddleClick open up a list of running windows? Scroll wheel on a panel skip through desktops? This plugin based system for defining contextual actions for containments opens up all those possibilities as well as the more mundane but much wanted consistency between containments. Now Folder View Activities can have all the same options as the default Desktop Activity without any duplication of code. Best of all: you get the final say by selecting the plugins and the activation sequence for them if you wish in the integrated control panel.



• Widget Explorer: A more "Plasma" widget explorer that integrates better with the panel controller, looks hotter and is generally just more usable.



• Improved KWin Integration: We've been working on this in 4.3, and we'll try and take it to new levels with the KWin developers. This includes moving some of the effect inside of Plasma into KWin for greater performance, taking better advantage of some of KWin's effects and seeing more Plasma based theming options for KWin (such as window decorations). A good portion of this work will be done by the KWin developers, but I figure it makes sense on this list as well. :)



• Social Desktop and Geolocation Improvements: Building on our start with the Social Desktop features in Plasma in KDE 4.3, we will be adding more features to the existing widgets, adding new widgets where needed and using geolocation in more of our components. We are also looking at ways to improve the geolocation DataEngine itself, though no concrete for 4.4 plans have been committed to yet.



• Plasmate: The 0.1 release of the Plasmoid and DataEngine creator will follow with the KDE 4.4 release. Transparent revision control, live previews and minimal-clicks-to-get-to-work workflow will lower the bar considerably to making scripted Plasma components.



• KUIServer Resurection: KUIServer has received a facelift and an internal resurrection. Now jobs can talk to KUIServer and it updates Plasma for its job notifications. This means applications like Dolphin can now also consume that data without Plasma getting in they way and if Plasma should crash the jobs will still be there on restart.



• Notification Improvements: Notification summaries, queueing and logging, making the notifications area more robust against applications flooding it and more useful by keeping the latest information at your fingertips. We're also exploring the best way to show only the new stuff when it arrives, while letting you click through to the older stuff, too.



• Kinetic: Plasma in KDE 4.4 will be the first release to start using the new Qt animation and state machine framework.



• Plasma Desktop D-Bus Access: A full D-Bus service exposing the widgets, containments and more in your currently running Plasma desktop session.



• More KRunner: In 4.3 KRunner received a lot of interface, performance and stability love. Now we need to keep the runners coming. I started a Kopete chat runner the other day based on a request received on identi.ca.



• Plasmoid Updates: Working with the KNewStuff developers, we want to provide an easy way to check for updates to the Plasmoids you installed over the network as well as check the installed ones for integrity.



• Notification Item Goes Prime Time: With the new D-Bus based system tray protocol in place and under real-world usage in 4.3, we will be porting as many apps as we can get our hands on to it. A formal specification is being written which will be submitted for consideration at freedesktop.org and we hope to move the KNotificationItem class into libkdeui. Next to the ability to put Plasmoids in the system tray (and possibly elsewhere like the quick launcher), this is the single most exciting thing that's happened to the system tray since I've been following KDE. Finally we have a modern system tray / notification area with the ability to have multiple views on the same entries, have non-graphical representations of them, separate the entries into different groups in different widgets, integrate them with the taskbar, react to the internal state of the entries (e.g. for autohide) and theme them properly for the host desktop shell (icon theming, sizing, etc).



• Improved Documentation: Work on extended JavaScript Plasmoid tutorials is underway, and we're growing the general body of documentation around Plasma.



• New Configuration Dialogs: A revamp of the existing activity and wallpaper configuration as well as Plasma global settings is planned. Beauty and usability are the goals.

That probably seems like a lot, but most of the above items have already had significant work done on them and are currently in active development. We do have more plans, such as improving the Lion Mail Plasmoid and working on improved Akonadi integration, but the above sums up the big changes coming to the core components. The usual incremental improvements in other Plasmoids, performance and stability work can also be expected. (They just make crappy line items in a "OMG! What colour poniez are they making?!" list.)

There's so much more that's possible, too: a dock PanelContainment, improved pager usability, getting kdewebkit to a place that we can replace our use of QWebPage with KWebPage for Plasma::WebContent, a Plasmoid based on the Kickoff internals that shows a menu of just a certain sub-menu in the application menu hierarchy, .... there's lots of cool stuff just waiting for eager hands.

Maybe those hands belong to you? If so, come find us on irc.freenode.net in #plasma or on the plasma-devel at kde dot org mailing list. Either way, enjoy riding KDE 4.3 while we work away on KDE 4.4. :)

an afternoon of small things

I spent the afternoon working with some very small computers that we picked up today from a local shop that specializes in electronic parts for things like hobby robotics:

The white breadboard in the picture is 4.3 centimeters along the wider side. One day in the not-too-distant future a Plasmoid will live on the above device and I will be able to access it using Bluetooth and then control the device from my Plasma desktop.

Rob L. and I put some more work into the wire protocol and looked further into what will be needed to integrate it with Rob Scheepmaker's remote Plasma work. Rob L. wrote some code for the device and we got a couple steps further.

I have no idea if this idea will ever see the light of day in a commercial product, but I also don't really care to be honest. It's a fun hack that I'm spending some of my free time on and it stretches Plasma out to a whole new area. Wheeee for having fun. :)

an rc1 package by any other name

I've spent much of the last week dealing with bug reports for "4.3 rc1" packages that users have downloaded from various distributions. Sadly, these packages are usually not packages of the actual 4.3 rc1 that was announced just yesterday and so I'm spending time weeding out things that are already fixed in the actual rc1 and people are spending time reporting bugs that are get closed immediately as duplicates.

The distros tried to get packages out to testers to make sure the packages worked for launch day; fair enough. KDE also spent nearly eight days between the first tagging of rc1 and the eventually final release of it; that's too long. As far as I know, no users were informed of the situation and so took to testing the rc1 packages in good faith. They have done a great job uncovering bugs we've already fixed in the process. ;)

I'd love to see our betas and rc's have much shorter tag-to-release cycles, even if developers come up with last minute fixes: just release another rc a day or two later. I'd rather have seen us put out rc1, rc2 and even rc3 if needed over those eight days.

I'd also love to see distros inform their users much more clearly what those pre-release packages are so that they test what they should be testing: that the packages install cleanly.

In the meantime, for all of our valued testers out there: if you download a beta or rc release and it hasn't yet been announced on dot.kde.org ... it's not the actual release. It's a pre-release. Hold off on reporting bugs until the announcement is up on dot.kde.org and you've updated your packages one more time to make sure you've got all the updates.

Cheers :)

WebKit

I'm glad to see discussion about web content in KDE, spurred on by Will Stephenson's posting on the matter. A couple years back I attempted to get QtWebkit and KHTML working together and failed utterly and miserably. Shame on me. Today's situation, which Will outlines, is a result of keeping the status quo since then.

Many others have weighed in on the matter since, and it seems there are huge numbers of comments on each of these blog entries. I haven't read the comments as I don't have time to do so today (I have a couple hours to close out some bugs I want to kill and then I have to dash out to the outskirts of the city for a farewell dinner) and I'm not sure I even want to open that Pandora's box, to be honest.

For those who are discussing it, here are some thoughts that rattle about in my head, in point form, that others may find useful in the discussion:

• This has nothing to do with Konqueror beyond "we'd like to use Konqueror, so we need a suitable rendering engine for it". The discussion is really about web rendering stacks.


• That we need to have this discussion says nothing negative about the KHTML developers, their efforts or those who use KHTML. The people working on KHTML enjoy doing so, have their reasons for doing so and do great work. They can and should work on KHTML for as long as they enjoy doing so.


• The discussion should remain centered on what application developers need and what our users require so as to make decisions that serve those ends properly.


• There are two contexts for web content: web browser (e.g. Konqueror) and application usage (we use web content in Plasma, throughout Kontact, in application intro screens, in some control panels, in educational apps, in ... a lot of places). These two contexts may not have the same answers. There is C++ API currently missing in QtWebKit that make it not a great option for some applications (though it seems Qt 4.6 is addressing a lot of this issue), but which is pretty well irrelevant to its use in Konqueror as a web browser. There are vice versa examples as well. So keep in mind that there is not, at least not right now, a "one size fits all" solution availalble to us and the discussion ought to reflect that. We need to pick the right answers given the specific questions.


• The reality is that some applications are already using WebKit, so this isn't particularly revolutionary.


• Equally real is that KHTML will be with us at least until KDE 5 and there will be users of KTHML for quite a while yet no matter what happens.


• QtWebKit is not perfect. It's moving forward nicely in Qt 4.6, but to be perfectly blunt: I am disappointed with its progress to date. I had hoped it would be much farther along than it is now. I see all kinds of cool demos for it, but it's mostly for embedded application and usage. We aren't testing it enough on the desktop and we aren't creating enough pressure to move it forward in those directions. Those responsible for QtWebKit would, imho, be wise to put more human resources on it as well.


• The biggest asset WebKit has going for it is broad usage and broad development by numerous entities. The web has become stupidly complex and is ever evolving; it needs a large developer base to keep up, and this is why WebKit works "better" than KHTML on today's "web 2.0". (As a related aside to the Gtk+ WebKit developers: naming your library libwebkit is not only ballsy it's downright ridiculous, divisive and offensive. It's a shameful decision.)


• Here's the most important point, and thus the one I'll end with: this discussion will not matter one little bit in the least unless people commit to a solution and write code for it. Words are great, but they are just words. It is the effort that turns those words into something that matters. You don't have to ask for permission to work on something, either. Just do it, where "it" in this case is the webkit part in playground/libs/webkitkde.

independence

P. is out in Vancouver now, visiting his mother and going to summer camp where he will play in the coastal waters and rainforests of the lower mainland of British Columbia. I woke up this morning in an unusual silence that wrapped the house. Even when he's sleeping in another room, there is less silence than this, but with P.'s departure a profound silence descends. I am alone, again; independent, again.

While laying there waking up I realized that there would not be a single dirty dish laying out that I did not eat from. Were I to stop eating, the dishes would stop becoming dirty. This is not true when you live with others, particularly your own children. Under such circumstances, even if you stop moving the world is affected in ways your are, at least in part, responsible for. Alone, however, it is only the quiet decay of the universe riding towards in it's love affair with entropy that creates change apart from your own actions.

This is the independence I remember from my single, childless years.

While laying there, now slightly more awake with these thoughts, it also occurred to me that were I to cease (a massive heart attack? an embolism in the brain finally giving way to the interior pressures, stroking my grey matter into ribbons? an unlikely small prince riding an equally unlikely comet crashing into my bed as I lay there, crushing me?) nobody would notice for days. (Ok, the comet scenario might attract some attention, granted.)

Friends who called would assume I was out or just not answering my phone as I sometimes do; perhaps, they might think, I was out of the country and forgot to tell them. My cats would eat the last of their food, drink the last of their water and then venture out to fend for themselves.

As I lay there thinking this, an interview with Mavis Gallant was broadcast on the CBC, wherein she recounted laying on the floor of her Paris apartment for three days until the concierge finally noticed her absence. I don't have a concierge, so even three days would seem very optimistic in my case. (These are the sorts of thoughts that come in the waking moments.) Most likely, my remains would just lie there until I didn't arrive in Vancouver in 10 days time, at which point people expecting me to arrive would begin to get worried.

There is a symmetry there: I don't move and the world doesn't change in response to me, but if I don't move anymore the world doesn't take notice either, at least not immediately.

Today is Canada Day. It is the 142nd anniversary of the founding of my country. We are a relatively young nation, as measured by our time being known as sovereign "Canada". It is an old land, however, populated for thousands of years: the oldest studied human settlement on our soil dates some 5,000 years back, though it is thought people arrived here between 12 and 25 thousand years ago. Not until 142 years ago, however, was it a whole nation from sea to sea independent, at least in theory, within our borders. This is, it struck me, somehow not unlike me waking this morning to find this house suddenly my own.

There is a feeling of liberation in this state of independence: no concern of others over whom we do not have the direct cerebral control we have over our selves. Such liberation causes people to celebrate. Today in Canada people are holding concerts and competitions and taking days off from work to wave little swatches of fabric inked with symbols we say represent our area, our region, our nation, our identity. It is a great feeling to be your own persons, is it not?

If that liberation is the only feeling, however, then existence disregards us in direct proportion to how much we are separated from that which is outside our tidy little borders (personal or national). In moments of independence, which I do enjoy, I am also reminded to consider the strength of sharing life and consideration with others.

Sure, it means I have to wash more dishes, including ones I never ate off of, but happily there is more to it than cleaning up after others from time to time, even if that is an unavoidable part of the pact. There is the opportunity to build and experience things together that do not come with solitude: memories, love, art, architecture and mechanism, families, nations, planets.

So I love waking up alone. I just don't want to do it too often.

let's play a game!

Let's a play a game of "Spot the New Feature"! Here's a screenshot, submitted by our own Helio, that shows a new feature in Plasma that will debut in KDE 4.4:

Can you spot it? If so, leave your answer in the comments! Once someone has guessed it correctly, I'll blog again about this new feature, and other things coming in 4.4, in greater detail.

(Oh, and if you hang out in #plasma on irc or are a member of the Plasma team, please don't give the answer away. :)

This feature is also a neat example of how we work together in Plasma, building on top of what each other does, filling in the blanks when someone else gets stuck and riffing on each other's ideas. This particular feature was built on top of some work done in 4.2 by Jason Stubbs; the feature itself was started by Sebastian Kugler and finished by Marco Martin using some hints from a similar feature I fixed up for 4.3 in the system monitor widget, which in turn was written primarily by Petri Damsten.

(... and yes, I know, 4.3 isn't even out yet and we're already teasing you with new things ;)

saving freedesktop.org together

You know that scene in movies where the doctor comes out of the surgery with a mask dangling around their neck and a solemn look in their eyes to greet the family who has been waiting what seems like forever in the waiting room? This is that scene. I'm that doctor. freedesktop.org is the patient. You are the family.

freedesktop.org is in really bad shape. There, I said it. Most of us knew it, but now it's been said. The good news is that it's rescuable. The even better news is that people want to rescue it, and some are actually doing things to make it happen.

Let me back up a bit, though. What is freedesktop.org supposed to be? Well, it's supposed to be a place for people working on F/OSS desktop projects to come together and collaborate on shared designs and shared software. It's been successful in bringing together drag and drop, window manager hints, application menus, icon themes, bookmarks, D-Bus and much more. This is valuable work and freedesktop.org is, or at least should, be vital to the F/OSS desktop platform.

It has seen better days, however. Currently it suffers from two major illnesses: administritus and anarchiosis. ;)

First, the administritus. freedsktop.org has infrastructure related to it: a website, cvs and git hosting, a bugzilla instance. This infrastructure is overseen by a group of administrators. These people are expected to be around whenever needed to set up accounts, approve projects and specifications for entry and do general sys admin type stuff as well. This means that they not only have to have lots of time and energy, but have to have a good idea of what's going on in the F/OSS world for each and every topic brought to freedesktop.org. They need that knowledge because it is them who gives the final "yes" or "no" to something being hosted on freedesktop.org. This is a completely irrational set of expectations, and the admin team is therefore performing as one would expect: below the par of what we need.

Now, I don't blame them as individuals .. I just think the expectations are insane and we, the projects, haven't given them enough support. We ought to have more KDE, GNOME, XFCE, etc. project people with admin privileges to help out. We don't, and that probably needs fixing.

However, that's just infrastructure. freedesktop.org isn't, however, infrastructure. freedesktop.org has infrastructure. It is the people who come together to work collaboratively who are freedesktop.org. Think of it this way: if KDE's svn server disappeared tomorrow, a new system would get set up in short order as best the community could manage and we'd get on with it. New infrastructure would emerge. If the KDE contributor community disappeared tomorrow, the existing infrastructure would not magically create new community. Therefore KDE is the community, not the infrastructure. freesktop.org, indeed any F/OSS project, is the same.

So while we work on solutions to the administritus, we are already working on the anarchiosis. What is that?

Right now it's very hard to get things on freedesktop.org, and not everyone trusts the freedesktop.org hosting due to past outages. The result is that we have work being done all over the Internet with little transparency to others.

There's also no way to know who has implemented which specification or uses which pieces of software associated with freedesktop.org. That's bad enough for those of us in the related projects that participate in freedesktop.org, but it's a deal killer for third parties on the outside looking in who'd like to implement support for the platform.

The admin team has the final say in what goes in and what doesn't, which means that people are not allowed to just work on what they want and let things bubble up. It's a top down approach that discourages people and prevents the best decisions possible from being made.

Finally, there is little to no leadership or process applied to freedesktop.org. When two people have a problem with each other, it's up to them to duke it out. When someone wants to use org.freedesktop for a D-Bus service name, there's no way to figure out if that's Ok to do and, if it isn't, no way for the rest of the participants to veto that.

The result is an inefficient system that is completely opaque to most would be participants that revolves around politics, bad decisions and arguments. Anarchy, and the bad sort at that. Several specifications are in danger of becoming defunct, forked or simply never see the light of day because of this case of anarchiosis.

So .. what do we do? We damn well fix it.

To bring some stability to the ills of freedesktop.org I gave it a swift kick in the nuts this past week in order to wake up the slumbering souls that populate the xdg list. This came via Plasma's implementation of the galago notification spec in 4.3. At issue were some very poor moves that accompanied the creation and maintenance of that specification, starting five years ago and continue to today. (I won't go into the details, it's been hashed through enough on the list and there's nothing to be gained by airing it even more publicly.)

Simply put: we had had enough of the shenanigans that are a direct result of the structure, or lack thereof, within freedesktop.org and we put our collective foot down. I wanted to make people own up to how broken things are. I think that was accomplished. Awareness alone isn't enough, though.

To bring some transparency to the process of specification writing, I've gone ahead and created an xdg-specs gitorious project that enables anyone who wants to get involved to do so. I started this a while ago, but it seems more critical than ever now and people are actually using it. If and when the freedesktop.org administration issue gets sorted and it's as easy as gitorious makes it to get involved with the specs process, this repository will move there. In the meantime, there's a README file explaining the proposed process in the repository, people are free to clone and work and I'm happy to add any specification author to the xdg-specs team to manage their spec in the main repository.

We can finally put all our work in one shared place, work together and document it in a way that third parties will know what we are up to. Which drafts are specs and which specs are standards can be deduced in future by simply measuring things in that documentation, such as how many, and which, projects implement which versions of that spec. You don't have to ask for permission to get involved, you just do. That's how F/OSS should work.

There are also the social ills, of course. Since nobody seems to have wanted to do much more than deepen the politics or bitch at each other or sit quietly and try to get something done amidst the chaos, I've done the silly brash sort of thing I do ... I've stepped up and have begun playing the role of facilitator on the xdg list. Nobody asked me to and I didn't ask for permission, but that's why it hasn't been done up until now: nobody is going to ask and there is nobody to grant permission. Catch 22? Nope. Sometimes you just have to step up and do it.

I'm not sure I'm the best person for the job, but at least I'm a person who will do the job. I'll stand in between people when needed, get out of the way when I can and generally make sure things work. However, I have no interest in control, title or even administration rights within freedesktop.org. (I make a crappy sys admin anyways. ;) I just want some oil applied to the moving parts so there's less friction and more movement that we can all live with.

I strongly urge the people who are attending GCDS next week to discuss these issues in person. Come up with some commitments between the projects. Get some people putting effort into these things. Stop screwing around and get your hands moving.

Save freedesktop.org, together. Or continue watching it die, day by day. It's our choice.

KDE 4.3 Plasma Overview Screencast

Ho, ho! Finally! The KDE 4.3 Plasma screencast arrives! It's 10:36 in length and covers some of the nice improvements we've in Plasmaland for 4.3, including:

• The new Air theme


• Small panel sizes


• KWin integration


• Stability & performance improvements (over 2300 bugs.kde.org defect reports triaged and closed during the 4.3 alone!)


• New widgets, including social desktop integration, remember the milk and unit converter


• New DataEngines, including Geolocation


• System tray and job notification improvements


• KRunner improvements in looks, speed and usability

The screencast doesn't cover everything new or improved in 4.3 .. that would take at least an hour instead of the ten minutes I spend in that screencast. You can find a more complete changelog here but even that is just the big stuff and doesn't catch the numerous little tweaks and improvements that have ben made.

We're not done, though. Not by a long shot. There are a lot of things the Plasma team still aren't satisfied with and several goals from the original design sketches that we have yet to implement. The good news is that we have plans in place and code underway for the KDE 4.4 release that will address many of these open issues. In my next blog entry on Plasma I'll give an overview of what we're working on, and why, for KDE 4.4.

Until then, you can grab the KDE 4.3 Plasma screencast via BitTorrent.

Update: Please keep seeding the torrent after you've downloaded it if you can. I do have a version of the .ogv on plasma.kde.org and will probably post a link to it eventually via identi.ca, but I'd really like to be kind to the server bandwidth and rely on bittorrent as much as possible.


Update 2: Direct link for those who can't torrent because they have nasty sys admins: plasma_4.3_overview_small.ogv. Over 400 seeders showing up in KTorrent right now for the torrent, though. :)

erf

Sorry for the delay in the Plasma 4.3 show-and-tell session. The last couple of days have been consumed by some (much needed) drama on the xdg freedesktop.org mailing list, cleaning out some more annoyances in Plasma (e.g. dropping the time the device notifier takes to initialize by ~85% as it was contributing to a massive slow down on startup; apps are starting to install hotplug activation entries, and the algorithm in the hotplug dataegine, which hadn't been touched since 4.0 it seems, was not ready for it) and our semi-annual "planning the next release cycle" Plasma meeting (though that's always big brush-stroke stuff; the usual flood of fixes, features and new plugins is something we just take for granted ;).

So instead of having a nice calm second half of the week, I've had a silly-busy one. No rest for the wicked, right? :) Anyways, I will be getting that Plasma show-and-tell out this weekend. It will be a screencast. I have already written out the talking points script for it.

KDE 4.3 branched, trunk is now 4.4

The release team has just done something a bit different from past release cycles to test out some modifications to our usual work flow: with the release of the first release candidate, 4.3 has been immediately branched off of the mainline trunk, and trunk is now 4.4. In the past we've done this only when the new release is actually made, not during the release candidates.

This gives people working on 4.4 features, or fixes that can only go into 4.4 due to things like string changes, a free hand without having to wait out the weeks during the extra hard freeze that comes with release candidates. This is very nice timing for Akademy, which is coming up very soon now.

That means that if you fix a bug in trunk, you now have to backport it to the 4.3 branch. I updated the svnbackport script in kdesdk/scripts/ today to target the 4.3 branch by default. Please keep up with all the great bug fixing for 4.3 so we can make 4.3.0 as solid as possible. Even though 4.3 has been branched, there is still time for yet more fixes.

It does sort of really send home, at least for me, the fact that 4.3 is essentially ready to go and to start thinking about the imminent start on 4.4. Today I bumped the version of libplasma and started a new changelog file for 4.4. The changelog for Plasma in 4.3 has become rather impressive, despite us sticking to our "only significant changes" mantra.

With this moment upon us, I feel compelled to write about some of the more interesting changes in Plasma and the KDE workspace in 4.3, and I will do so tomorrow. It'll either be text with screenshots or less text and a screencast. I'm still deciding, though I have a small list of topics written down.

Later in the week I'll lay out what we already know is going to be happening KDE 4.4 with regards to Plasma.

To those working on other parts of 4.3, I'd be really interested in reading something similar in your blogs. Little "wrap up" pieces are fun, enjoyable and informative. They're like little hugs wrapped in RSS.

Right now, however, I have to clean up and get ready: this evening I'm hosting a small "I'm leaving, huzzah!" evening at a local fine cheese shop for some friends and family. The shop is providing one of their cheese-heads, er, maître fromager to walk us through the 50-something cheeses they have in their display cabinet. Together with good company and a little wine, it should be great fun. I can't wait! :)

Which reminds me how this week is all about flux: not only is 4.3 trundling to the launch gate and 4.4 picking up its first sparks, but P. finished grade 3 this week and will be off to Vancouver in just one more week. That will mark the start of my "pack the house and move" period. So many changes and so much going on ... while it feels like there's never enough time (there isn't), I wouldn't have it any other way.

luv 'n hugs, aseigo.

weather info in plasma

So over the last week two of the major weather information providers we use and rely on, Environment Canada and BBC UK Met, have changed the location of the XML weather information on their servers. This means that weather information has broken for people using Plasma widgets with them. We don't pay for the data, so we can't complain too much, but this is really poor behavior on their part in my opinion. Evidently we can't rely on online services maintaining any sort of day-to-day compatibility.

So how do we deal with this? Right now we have 4.3.0 coming out quite soon and it will have the new URL locations in it, and we'll backport those changes to 4.2 for KDE distributors to pick up. This is a short term solution and certainly not long-term.

Update: After some further digging, it appears that BBC's weather information has changed significantly in how it is delivered (split across two files now and using RSS XML). Backporting to the 4.2 branch will be trickier than just pushing an updated URL. :/

What we will be doing in 4.4 is implementing something that's been on our roadmap for a while now: widget and data autoupdates. We'll likely be using Get Hot New Stuff and DXS for this, and the packages will be cryptographically signed. This means we'll need to finally get that KDE gpg key rocking as well as a place to host these bits of data.

Personally, I'm thinking of hosting it on opendesktop.org as they are stable, reliable, have F/OSS as their focus and already run DXS services. That does mean that your Plasma would contact opendesktop.org every so often for updates, though we'll obviously make it configurable.

The end result will be widgets that don't fall out of date on you (if they are scripted) and things like weather data not suddenly stopping.

I apologize for the inconvenience in 4.2, and I ask for your patience and understanding as we work on complete and long-term solutions.