trailheads

The pre-4.0 development of KDE was helped along by everyone knowing what we were striving towards: we had the Pillars, these new big chunks of technology we were busy slotting into place so that we could build ever better applications on top of; we had a renewed focus on clean, usable interfaces; we were also aiming for beauty and greater platform independence.

The individual projects around the KDE universe all swirled around these shared goals. Each headed in their own direction that reflected their own interpretation of these goals as weighted by their development team in terms of importance. Not remarkably, while there was variance in execution, there was a remarkable harmony in the overall approach and results.

That didn't happen by accident: it happened because we were communicating with each other about our goals and in-the-moment situations. I was part of only a fraction of these conversations, but I remember the huge number of informal meet ups both online and in person (part of my "coffee shop meetings around the world" tour, or at least that's sometimes how it felt ;). It was inspiring and helpful and marked a high water point in KDE community togetherness for me.

We're into 2009 now and it's time to stoke those fires again. We're at a point where the big rough edges are worked out and we're into the heavy lifting of making things smooth and improved .. but where are those things happening? Where are we headed in this moment?

Work is going on in so many areas: really powerful image manipulation, new artwork for games (the new Egyptian themes are hot), power management improvements, bluetooth and IR support, Policy- and Package-Kit, remote Plasma components, hot media experience improvements, etc, etc, etc... If we don't share these things with each other, it'll end up slowly decaying back to where we were in the no-direction-days of yore.

We need to know where each other is headed and where we've just been. This will help us coordinate without having to elect a coordinator, as we can alter our orbits as we choose to match up with trends that resonate with us. That implies we are aware of those trends in the first place. It's also a key point to helping people representing KDE in the public to be able to talk with accuracy and potency.

I don't want to just say "we should!", though. So I've allocated time over the next month to meet with as many "people in the know" as possible amongst the various KDE sub-projects to document the 1-3 things that highlight the last year of work and the 1-3 three things that define their forward momentum. This is different than a feature plan because it's about direction rather than implementation and scheduling issues (e.g. feature freezes) are irrelevant.

If you are one of those people "in the know" (which doesn't mean you're a "team leader" necessarily, just that you are a contributor and have a good idea of what's going on) and we don't already have a meeting time lined up, please find me either on IRC or by email and we'll work out a time to talk. If you can send me what days/times are good for you, your timezone and whether your prefer IRC, skype or phone that'd be great.

I'll post all of the results on Techbase in the Projects area for everyone to reference, and if this proves to be valuable I'll do it every release cycle around this time.

I knew I'd find something to do with the time freed up after the summer when I'm no longer on the KDE e.V. board. ;)

Read More

KPluginInfo categories and i18n

This afternoon I was informed that X-KDE-PluginInfo-* isn't translated in .desktop files. For most stuff that's alright because the fields are things like author names, license types (GPL, LPGL), version numbers .. generally things that don't get translated.

There is one odd duckling in there though: X-KDE-PluginInfo-Category. Given that it's not a proper noun I figured, naively it turns out, that it would get translated. No such luck. When we went looking for fields that are translated, the only viable candidate we found was the Keywords entry.

So Plasma now uses that for its categorization of applets. As an added bonus, not only does it get translated but it allows for any one component to be in multiple categories. Neat.

The turn around time on this was ~10 hours from it being reported to it being fixed. As a monolingual English speaker, I don't notice things that aren't translated until someone speaks up. When they do, I make sure it gets fixed in a timely manner. I put this on my TODO for the day, which happened to finish at nearly midnight tonight, but I still got it done as planned.

i18n is not a second class citizen in KDE, despite some premature protestations to that effect, but like any non-trivial thing it does have bugs here and there. We do take care of them as quickly as possible, and given that we have things like multiple calendar systems, broad localization for numeric and measurement systems, 80+ languages in KDE3 (and catching up in KDE4 :), etc... I think that speaks for itself.

Read More

cubetest in a browser? pffft!

Plasma devel is motoring along at its usual hectic pace. We held meetings with our SoC students last week on IRC and/or Skype and SoK students have begun lining up as well, we have 10 plugins of various types (Plasmoids, DataEngines, Wallpapers..) in kdereview that are waiting for final triaging into the 4.3 release (and a few more that I'm not sure are quite ready yet.. but we'll see :), the bugsquad laid waste to the Plasma bug reports over the weekend and the Plasma team has been up to its usual hyjinks.

Marco added borders around the window previews, which were really needed now that we can show multiple window thumbnails per preview (and we'll be working on making it possible to mouse over those tooltips and select windows from there too :), Rob has been tidying up the extenders and jobs/notifications in the system tray, Sebastian's been working on Akonadi and OpenSocial glue, a number of nice little additions have been made to various widgets (including the often requested "Show applications by name in Kickoff" option), to name a few things off the top of my head.

The new system tray hotness we've been working on is now in extragear/libs/ for 4.3 and we'll be rolling a tarball for libknotificationitem-1.so.1 for 4.3 and committing our changes to various KDE apps to use the new protocol. So if you come across a check for libknotificationitem, you know where to look now. ;) I'm very excited about that.

It was when I visited planetkde.org, however, that I found my "fun thing to do today": Jos' blog on writing applications with SVG.

"SVG!" I murmured to myself, "I know SVG stuff! Plasma knows SVG stuff! Screw showing it in a web browser, let's try it on Plasma!" Now, Plasma::Svg is not designed for things like Jos' app-in-an-SVG; it is an image painter that uses SVG data to create the pixmaps. That's very, very useful (more so than you might think until you start trying to use SVG to paint interface elements :) but also very, very different from what Jos is doing.

However, Plasma has Plasma::WebView which is a nice little QGraphicsView wrapper around QtWebKit, and QtWebKit comes with an SVG engine that is quite capable of handling Jos' file. Just to check, I threw down a Web Browser plasmoid and loaded the SVG file from disk in it:

(It's a little blocky because I was also playing with the zoom level.)

That wasn't very exciting though: I knew it would work because Aurora Arora uses QtWebKit and Jos had already said it worked in Aurora Arora. So how about a Plasmoid just for Cube Test? In fact, why not do it in Javascript? It turned out to be almost too easy:

Here's the code, all four lines of it:

layout = new LinearLayout(plasmoid);
view = new WebView();
layout.addItem(view);
view.url = Url(plasmoid.file("images", "cubetest.svg"));

All the magic, of course, is in WebView and the cubetest.svg file. The Plasmoid is fully resizable (yes, the contents scale to match the size of the Plasmoid smoothly) and the SVG is fully interactive. As I started spinning cubes around P. came up and said, "Ooh, what's that? Is it a new game? How do you play it?" :)

You may notice in the above code that the SVG file is fetched from the Plasmoid. It's actually using the Plasma::Package associated with the Plasmoid and finding the cubetest.svg file in the images location. That makes the Plasmoid 100% self-contained: it's the application (cubetest.svg) and the "player" (QtWebKit via Plasma) all in one.

If you have KDE from svn (or, soon enough, 4.3) you can download the Cube Test Plasmoid here, all 4.7k of it, and try it out today!

p.s. I totally missed posting this when I was first sent the link, but one of my presentations from the Student Summit on Sustainability on the social implications of F/OSS is up on blip.tv. Thanks, Pascal, for passing this on and everyone on the organization team that made S3 such a terrific event!

Read More

getting a crash in this week's unstable build?

If you're tracking KDE 4.3 development and using packages from the last week or two, you may be experiencing Plasma crashing where the backtrace contains "Solid::Predicate::~Predicate()".

The cause of this is a small bug in some string parsing code in Solid that was tripped up by hotplug action .desktop files installed with some packages of Kaffeine. The kaffeine_play_videocd.desktop file, found in `kde4-config --prefix`/share/apps/solid/actions/, apparently ended up getting shipped with mismatched []s in it. (I'm not sure how that happened exactly as the files look proper in Kaffeine's svn? Oh well ..)

I fixed the crash in Solid the other day but a lot of people seem to be running into it while the fix percolates out. The solution is to get a version of kdelibs (or even just Solid) from this week and/or fix the incorrect .desktop files (e.g. by adding the missing [s).

It's cool that so many people are using and testing the latest and greatest 4.3, though. Figured I'd blog the answer so people can find it more easily.

Enjoy.

Read More

plasmoidviewer

If you're writing Plasmoids, testing them is made a lot easier with plasmoidviewer. With scripted Plasmoids you can even skip the compile stage and go straight to ... damn ... plasmapkg -u <path/to/package>. Having to run that command every time and wait for the call to ksycoca is a major buzz kill. It's like racing on the autobahn with the wind in your hair only to hit a playground zone.

A small voice whispered in my ear, "Use the source, Luke!" and I was like, "Dude, for the millionth time, my name's not Luke!" Having ghostly voices whisper mystic wisdom in your ear is bad enough, but at least he could get my name right. ;P

So I added Applet::loadPlasmoid to libplasma and added a couple lines to plasmoidviewer so that you can have it load Plasmoids right from their location on disk without installing them. This means if your package is in ~/src/MyAwesomePlasmoid you can just do: `plasmoidviewer ~/src/MyAwesomePlasmoid`. Even better, if you are in ~/src/MyAwesomePlasmoid you can just do `plasmoidviewer .` Having accomplished that I realized that even that was one character too much and so with a very minor tweak (involving deleting a couple of lines, actually) you can now sit in the root of your Plasmoid structure and run `plasmoidviewer` and up comes your work.

Plasmate will make this even easier, but until it's ready and for those of us who are console addicted this is quite nice. Speaking of Plasmate, it also required this new Applet::loadPlasmoid method. We had an irc meeting today about Plasmate with a couple of SoC/SoK students. Artur led it and Richard Moore helped steer the discussion. I was asleep for most of it (dang timezones!), but they did a great job without me (no big surprise there :) and it seems we'll be off to a running start in no time on getting Plasmate in working order.

Read More

plasma and memory usage

A long time bane of my Plasma life has been dealing with it ballooning in memory usage depending on the configuration.

Some of the leaks turned out to be related to certain graphics drivers, but that wasn't the majority.

Some were bona fide leaks in the Plasma code base, such as one I found and fixed the other day that, when the job tracking was turned on in the system tray, would result in a small allocation for each and every job (e.g. file transfer) started. This one wasn't easy to find because the allocations weren't huge and they were all parented QObjects meaning valgrind wasn't being very helpful. We've found and fixed a number of leaks of various sizes and things are feeling pretty good ... but there was still problems.

There was a bug report about memory usage jumping when the digital clock was set to update every second. This is a great example of a report that describes both the problem as well as a very well defined way to reproduce it. Now, I don't personally use a clock that updates every second, and Plasma tries its best not to update too much .. but when I ran `plasmoidviewer digital-clock` with it set to show seconds I watched the memory usage skyrocket with great sadness. :)

After hunting around in the clock code, in libplasma and in libplasmaclock for a number of hours I finally thought, "Maybe this isn't my bug after all." So I whipped up a small Qt only test app and was able to trigger the same problem in just a handful of lines of code. It turns out it's a problem with the caching in QGraphicsScene: it inserts pixmaps but never removes them from QPixmapCache. That shouldn't be a problem, however, since the cache should delete pixmaps when it gets too big and delete pixmaps when inserting using the same key. Unfortunately, for some reason, that isn't happening. By inserting a QPixmapCache::remove before both of the calls to QPixmapCache::insert in QGraphicsScene, the pixmap leaking stopped immediately.

I'm not sure that's the right fix, however, but at least I have an idea now of where we need to be looking. That it isn't in Plasma is nice (yay! not my fault!) but also a bit frustrating since it's slightly easier for me to fix things in Plasma. ;)

In any case, with all these patches applied on my system, a full on Plasma session is currently taking up 17,832k in resident memory and using 302 pixmaps that total 5904k in size on the X server. That's a total of 23736k of app and pixmap memory for my desktop, panel, widgets and wallpapers running using a full debug build.

Earlier tonight my Plasma had well in excess of 1000 pixmaps after running for not a very long time at all. Glancing at xrestop Plasma now has 292 pixmaps, or 10 less than when I wrote that last paragraph, so it certainly seems to not be leaking now. ;)

Yes, definitely headed in the right direction ...

282 pixmaps.... whee.

Update: Alexis just replied to the bug saying he'll be working on fixing this issue first thing on Monday. I just love working with the Trolls from Qt .. :)

Read More

more on keyboard status

Michael Leupold has been working on a class for kdelibs that can report on keyboard modifier (and mouse button) states, the same thing that the keyboard status widget does internally. The class should appear in KDE 4.3, and this is quite nice since it gives us a platform-neutral way to do things like show when the caps lock is on in dialogs with passwords without reimplementing the code to do that over and over.

When Michael told me he was working on this in response to my last blog on the keyboard state widget I sat back and thought, "Why the heck am I dragging myself over the coals and modifying the 986 line of code literal-port-from-kicker thing in kdreview?! I should write a small DataEngine around Michael's class and then do the widget in JavaScript: it's just a collection of buttons, after all!"

So today while the P-man was off at a friend's place I scurried off to a coffee shop and sat down to work on the DataEngine part. Other than half an hour or so spent on some phone calls from friends and answering Plasma bug days questions, I was able to just sit and hack on it while sipping cappuccinos for two hours. The end result is a complete DataEngine plus Services in 198 lines of C++ that is (thanks to plamaengineexplorer) fully tested and working flawlessly.

Now any Plasma component in any language can easily interact with keyboard and mouse button states. You can even latch and lock modifier keys ...

... which means I'm now ready to play with some JavaScript. Using the service architecture I expect a dozen lines of code or so for the buttons to lock/unlock/latch/unlatch the corresponding keys and another dozen or three lines at most to create the buttons, hook them up to the engine and get the layout orientation right (e.g. vertical for Vertical constrained containments). When done this will be the first JavaScript plasmoid to ship by default in kdebase. I can't wait to see what limitations and bugs I run into in the process. ;)

I think I'll also take the opportunity to write a Techbase article on writing Plasmoids in JavaScript as I go, documenting what I do step by step.

With Michael's code, the whole thing should be less than 650 lines code, which is a 35% savings over the old keyboard kicker applet and done in a way that any KDE app or Plasmoid can take advantage of.

Huzzah.

Read More

kaizen and kakushin

I read Mark Shuttleworth's blog entry about meta-cycles this evening and was taken back in my mind to an entry I wrote in September of 2007 about Toyota.

My issue with the "6 month cycle" has always been three-fold:

1. the number 6 is a project specific detail and should not be pushed on every project because it won't fit every project (Mark notes he works on projects with 1, 3 and 6 month cycles; other cycle are also possible, of course); what we're really talking about it timed releases made with a relatively high level of consistency


2. The discussion is often coupled with the idea of coordinating different projects to the same cycle, which is really a different sort of conversation altogether with "length of the resulting release cycle" being an implementation detail within it


3. it's only one half of the equation, with the missing half being the non-high-level-of-consistency-time-interval releases; too often it was an either/or discussion where if you were doing one you couldn't have been doing the other

Both halves together make up the kaizen (continual incremental improvement) and the kakushin (continual leaps in innovation), and Mark notes that both are needed and can work together well. In fact, it seems that as the discussion continues, Mark and I see things increasingly similarly in general.

(Odd/intersting side point: I recently came across the concept of a "kaizen blitz" which happens to be exactly what our "developer sprints" are. Neat.)

Mark asks some questions, and since he asked I thought I'd share my personal answers to some of them:

'Is it true that the “first release of the major cycle” (KDE 4.0, Python 3.0) is best done as a short cycle that does not get long term attention?'

It's not he only way of doing it, but if the starting of the major cycle represents the end of a period of major innovation, it's only sensible to expect there to be a period of cooling off, dust settling and refinement. The point of making such a release is to draw a line in the sand saying "from here, be engage in the process of kaizen with earnest".

One can also do first major releases that don't bear these hallmarks very strongly at all (KDE 3.0 leaps to mind as an example of that), but then it isn't a kakushin release.

Being able to discern the difference between a release that is the result of kaizen versus one that more embodies kakushin is the key to whether that initial release should be "sat on" for a while or immediately pushed to production. The people to ask are the people doing the work.

Wait, though .. what does that mean, "people doing the work"?

In a FOSS project it's a combination of the people laying down the code / documentation / translations / art / etc and the people who rely on those technologies in their own projects. So KDE 4, as a concrete example, wasn't "ready" until application developers were confident with the platform, proven by basing releases of their own apps on it, and until production environment needs were met. So depending on who you are, 4.1 or 4.2 marked that point of "readiness".

With KDE 3, 3.0 was "ready" for all intents and purposes. 3.5 was miles better, but that's the point of kaizen and should not be confused for previous releases not being "ready".

This all implies that there is communication which is heard, listened to and delivered without unreasonable expectation. With 4.0, our communication was too often ignored, which erodes trust in both directions, and communication we received in return was often pejorative. The pejorative nature of it was mostly due to the lack of realization that 4.0 was the start of another period of kaizen (something we did for 6 years with KDE3) and the mid-cycle of a kakushin period.

There needs to be a way to allow releases like this to happen without it become a hail storm for all involved, and I personally believe that means generating an understanding of these two different but complimentary cycles and trusting people when they say "let's get busy with this, but it's going to be shaky in the short term" without freaking out about it.

We also need to not leave our users and developers high and dry: that's why we announced a year of KDE 3 releases at the KDE 4.0 release event right in the keynote. Back to Mark's questions:

'How do short term (3 month, 6 month) cycles fit into a broader meta-cycle?'

I think that really depends on the goals of the meta-cycle and the resources you can bring to bear to it. In general, however, there should be a lot more kaizen than kakushin type releases. Software needs revision to approach greatness, and in FOSS we do our revision in the open rather than behind closed doors. How many short term releases are "needed" and how they fit into a broader cycle is a bit like asking "how many licks to the center of a tootsie-pop". Well it really depends on how hard you lick it and how patient you are. :) This varies from project to project, and even within a project over time.

Compare the position of "GNOME is decadent" to "GNOME is all about 6 month cycles forever!"; they were both "right" for the project given its context when those positions were taken. It will shift, and to deny that is to deny the nature of existence itself.

This isn't a nice easy answer, I know. It means we can't draw cute little boxes on paper from here to eternity and have it all "figured out"; it means we need to do continual assessment. This is harder and requires more trust (or, to put it another way, is a more anxiety inspiring aproach ;), but it fits reality, one that is based on "continuousness of process".

Some people will need to plan long into the future, though. Distributions are one such group, needing to say things like "here's when our next long term, enterprise release will be" well in advance (this is implied by giving a life span to the current enterprise release, in fact).

So how do we balance those two needs? Personally, I think it can be solved by communicating with an appropriately long horizon. What does that mean?

Well, let's take the made up example of Frubagge. It's a hot new piece of technology that solves a really important gap in the Linux stack: the ability to read Dr. Seuss books with proper cooperative support from the kernel. Now, maybe we can already read books, but Dr. Seuss books with their anapestic tetrameter are a bit odd and we can do better. Frubbage just might be the key to unlocking it all. It also might not be. Distros need to know.

So maybe one or even a number of distros could say something like, "We're going to make Frubbage the default Dr. Seuss reader in one year's time in our main line releases. We're adding it as an experimental, will-eat-your-babies-and-steal-your-shoes, option." Then they would need to keep to that distinction and not get over enthused and confuse people by implying that the the experimental configuration is the main line stable release. Clarity and consistency, like good parenting.

Then all the book reader app devs out there need to pay heed and should start poking Frubbage and adding support in their apps. Maybe one group does a release with Frubbage support in 3 months time, and another will take 9 months to do the same. With a year's horizon, it's all details and none of it matters.

More importantly, those app developers now have a responsibility to speak up about Frubbage if it's somehow broken and then those distros need to pay heed to that. If the brokenness can be addressed and then is addressed, things go ahead as planned. If they don't, then the Frubbage horizon is either extended or dropped altogether.

This way the Frubbage project gets to "force" those persnickety app devs to kick its tires, the distros get what ends up looking like a coordinated release and the user doesn't get Frubbage unless it's "ready". Nobody loses, except maybe our proprietary competition as we start hitting on all cylinders and stop screwing up our platform on a regular basis. ;)

Most interesting, this doesn't require coordinating release cycles or punishing kakushin just because someone else is looking for kaizen that week.

My approach, as outlined above, is certainly not the only one and I admit it's probably a bit more Sun Tzu Planning than Gantt Chart Heaven, but I think it would work and work a lot better than what we have now.

Back to Mark:

'If it’s 2 years or 3 years, which is better for you?'

My answer: yes.

Honestly, from this high in the stack I don't care, just pick one and communicate it and then let us communicate back as to which release should hit that. Give me access to your spreadsheet so I can pencil in the KDE release version for you with reasoning and rational. If you want two years, awesome. If you want three years, awesome. KDE will be doing more kaizen than kakushin in that time period anyways, as we gracefully coast down the backide of our current kakushin cycles.

(To clarify: when I refer to the "backside process" means taking full advantage of the big initial arcs of the Pillars such as Nepomuk. Finally getting network transparency fully completed for Plasma components is another backside-of-the-initial-kakushin; not to be confused with the kaizen of making panel popups animate, for instance.)

As long as I know which it is, I can offer guidance. If our releases don't line up perfectly, that's OK, nobody's going to die. If your release concept is compelling, I might try and make my line up for that event. Cooperation as friendly negotiation.

Back to Mark:

'Does it make sense to have low-level, hardware-related things on a different cycle to high-level, user visible things? Or does it make more sense to have a rhythm of life that’s shared from the top to the bottom of the stack?

Would it make more sense to stagger long term releases based on how they depend on one another[?]'

I don't see how I can take advantage of new hardware features in my application until I can get my hands on them, nor can I see how KDE application developers could port to KDE 4 until they could get their hands on it.

There is some reality stuff that gets in the way here:

• there's too much going on for me to build everything from source all the time, so I do rely on binary packages for a lot of stuff which means waiting on actual releases that can then be packaged for me.


• I don't have the time to bleed on everyone's project's cutting edge, so except for very critical things to me I wait until there's at least a pack of bandages that comes with the release. I don't need stability, I just need the first aide kit to come included. ;)


• I don't want to wait for everyone to "be ready", because if the hardware guy can't release until I support it in my software that's going to suck for him: he needs to get on with his life too without me holding up his show because of coordinated releases; and the "show" is all about getting releases out in the wild

So if we had a constantly safe-enough, built from sources on demand base system and we were happy not doing quick releases of our stuff except to each other within our own little circle of happy coder friends, I don't see a non-staggered system working.

A non-staggered system could work, but we'd likely see Microsoft-esque releases: few and far between, and still half-baked when they first come out anyways.

'Is there any established theory or practice for this?'

There's lots said in business management and the social sciences about these kinds of processes. It's why I try and go to at least a few non-software events per year and read as much as I can afford to in these areas: they are solving similar problems and typically have a lot more experience (in both the good and bad directions) than we do. Software is a young industry, and modern FOSS is the baby brother in the family. The good news is we can learn from older siblings and don't have to reinvent it all.

We'll still screw up, I'm sure: we're learning, together, after all; but we can look at what others do. The ideas of kaizen and kakushin and how to combine them were not born from the software industry, let alone, FOSS, for example.

So, executive summary of my personal opinion on it all:

• We do need regular releases of continuous improvement


• We also need regular releases of major innovation, which will likely cause bruising that will be healed in time with the regular releases of continuous improvement


• We can blunt the impact of major innovation bruising on the user and vastly limit platform risk through processes of check/balance coordination (the Frubbage example)


• Staggered releases: realistic; lock-step releases: not realistic


• We can 'fake' lock-step releases by coordinating sufficiently openly, cooperatively and in advance as to what we (as a whole production line, top to bottom) are going to deliver as final products to market

It's mignight now .. so I'm going to take my tired butt to bed and dream of our next kaizen laden KDE release, 4.3.

Cheers...

Read More

must be monday

One of the cats went on a crazy streak at around 5am, waking me up with all sorts of crashing and banging noises. I stumbled out to find him knocking over everything he could on a shelf in the bathroom, at which point he darted out as fast as he could between my legs leading to a (in retrospect, anyways) fairly funny chase around my (small) house. I think he thought it was fun; my own tired brain was just annoyed. Once I finally did catch up to him and get him calmed down, I really didn't know what to do with him other than pet him until he calmed down a bit.

Then P. was up at 7am to get ready for school, and he hit the floor running. He was chatty and happy and moving all around .. and I was still groggy from getting woken up four hours into my own sleep (nothing worse than having sleep interupted; it's often worse than not sleeping I find). I made breakfast and drove him to school in a mild mind-fog, while he talked the entire 20 minute drive in to school without pause or stop, until I finally got my hands on some coffee and begun to woke up a bit more with the rising sun.

Back home I went and looked quickly at a used car I'm considering purchasing to go along with the move to the new city. When I came back some guy snatched a bag off of a parcel company delivery woman, but did so right in front of a half dozen guys along the block I live on who then all gave chase. I was not so foolish and simply decided to let the police handle it; didn't feel like getting shot or stabbed today, thank you very much. They caught him, and held him until the police arrived. I swear, in Canada even the criminals are nicer; I've lived places where chasing a guy who just robbed someone was a great way to cut your own life short.

In between all that, I worked up an email for kde-core-devel and the freedesktop.org xdg@ mailing lists about the new system tray .. uhm .. system. :) I also fixed up a handful of bugs in our implementations and now kmix is working pretty well identically to how it has in the past, only with less suckage.

Between the hard work of Marco, my tinkerings and Davide helping port various apps as test cases we have the whole thing working rather flawlessly at the moment. The Plasma bits are all in kdebase for 4.3 already, and we hope to have a good number of apps ported using a small separate library so that we don't have to commit to binary compatibility in the protocol or the API until 4.4 while still allowing us to get developer and user feedback during the 4.3 series.

Now we wait for the feedback, and hopefully action, from other developers both in the KDE community as well as in others such as Enlightenment, GNOME, XFCE, LXDE and other projects engaged with freedesktop.org.

Read More

Plasma's KDE SoC

Well, the results are in and the Plasma team is looking forward to working with a couple of familiar faces and a few more new ones. Our students this year will be:

• Alessandro Diaferia: Plasma Media Center Components


• Ana Cecilia Martins: New Widget Explorer


• Chani Armitage: containment-mouse interaction


• Diego Casella: PlasMate Editor - An editor for Plasmoids, DataEngines and Themes


• Rob Scheepmaker: Network transparency in Plasma

We received 48 proposals for Plasma work and that made the ranking decisions very, very hard on the Plasma mentors. We ranked based on thoroughness of the report, usefulness of the results, expectation of completion and how likely that work was to get done outside of a paid opportunity like SoC.

Even then we still had a dozen or so very high quality proposals which we had to then further cut back to just five. We tried to choose wisely, but we know that some proposals that were probably as deserving hit the cutting room floor. There was no winning when we had so many quality proposals.

Over the next couple days, we'll be in touch with the rest of the students just to let them know that we did indeed read and appreciate their proposal. If you are one of those people, please know that you can still work on your ideas and we'd be happy to help you do so.

For those whose projects did make it through, both for Plasma and all the other projects under the KDE umbrella: congrats and get ready to work hard and have fun; and if you are North America, start planning to attend the free (as in beer!) developer sprint for KDE SoC students!

Read More

fewer magical appearances

When desktop effects are enabled, extenders "roll up" and "roll back out" instead of just suddenly appearing and disappearing. This goes along with the idea of "organic interfaces" where things shouldn't exhibit magical behaviors: if you saw someone disappear into thin air in front of you .. well .. they'd either be an illusionist playing games with you or else Bilbo Baggins mucking about with his magic ring. It certainly wouldn't feel "normal" though, because that's not how thing behave according to our accumulated sensory experiences.

It doesn't work with QWidget based popups yet, though there's no reason it couldn't; Plasma::Dialog just doesn't have the logic for it yet. That means that things like kickoff or the device notifier still behave a bit magically.

I'm pretty sure that when we do extend it to all "things that come out of an edge docked panel" that we'll need to make it configurable (though it turns off automatically when animations are cut in plasma as a whole or when there is no compositer around) since some people will likely absolutely hate it for reasons of personal taste. I think it's jolly good (to use a quaint Britishism), but I can just tell it's the sort of thing someone, somewhere will take umbrage with.

It also occurs to me that this would be so much better as a compositing plugin. However, at least to my knowledge (and please correct me if I'm wrong, window manager people), there's very little interaction possibility between individual windows and the compositing effects. While usually this is perfect (you don't want random windows doing random things because their app developers feel they really ought to have spinning-breaking-apart-windows), in this case it makes me put code in a place it really doesn't belong (the application).

It would be terrific if a window could say "Ok, now slide me out into that other window over there on these positions." We actually already do this for the minimize effects by publishing the location that a window should minimize to/from. I actually tried using that but the results weren't exactly what I wanted because it meant positioning, minimizing then restoring the window and even then it didn't exactly work right (perhaps because the window is set to skip taskbar?).

There are a few such things that would be just awesome to be able to do with more comprehensive application<->window manager interaction possibilities. Which led me to think what now seems like the bleedingly obvious:

It would be beyond awesome to have a window manager developer sprint that focuses on application <-> window manager interaction issues

Such a thing would be attended by people writing high-energy window managers (KWin and Compiz would be two "must haves" there IMHO .. who else? E17, XFCE, Metacity?) and people writing applications or frameworks that could take advantage of such things (e.g. Plasma for the obvious reasons; Qt and KDE lib for thing like document modal dialog (aka "sheets" on MacOS) .. there must be others out there too :).

The goal should be to walk away with a set of agreed upon capabilities, interaction patterns, trigger mechanisms and even some initial implementations in the apps and window managers. It would be great to see things like the "slide 'n hide" window effect we now have in Plasma, sheets, the ability to ask for specific groups of windows to be shown in the currently active window switching style (e.g. present windows or cover flow or whatever the user has selected) for use by things like grouping task bars ... so many possibilities.

I really don't have time for such a thing before the summer is out, but maybe I'll try and hook something up after then. Or maybe one of you could hook it up. The world neither revolves nor depends on me, after all. :)

p.s. Apologies for the lack of screencasts lately, a lot of the stuff I have going on looks best with compositing and my compositing screencasting set up is in pieces atm.

p.p.s. Rob's been doing some rather nice work on improving the feedback when jobs and notifications are hosted in the systemtray; can't wait for that to settle in and for him to screencast that stuff. :)

Read More

hard things simple

Solid gives us the ability to easily react to hardware events. With the large number of DataEngines that use the network, this made an almost-too-obvious target. Since I'm still tickled fluffy bunny pink by the weather wallpapers, I figured I'd hit that first.

So I tucked into the weather DataEngine and even though it's one of the more internally complex engines out there, it was only ~10 lines of code:

0. Query the state of the network when it starts out.


1. Connect to the statusChanged signal from Solid::Network::notifier()


2. When the network is not available: create entries on request with empty data, return "it's coming" (aka false) from updateSourceEvents


3. When the network comes up, set m_networkAvailable to true and call updateAllSources

What's neat about the way the async support built into DataEngine is implemented is that visualizations that are set to update every N minutes, if they don't get data right away they go into a queued state. Whenever data does finally appear (say, when the network comes up) they will instantly update. Of course, if the network goes down and then back up within their update interval, they won't needlessly update. (I do have a patch to allow that to be overridden at the discretion of the DataEngine ... but I'm still contemplating the implications of that API-wise.)

As for the network "fluttering" the minimum update interval in the engine will keep the engine from hitting the network constantly just because the connection comes and goes every 30 seconds (or whatever). I may have to eventually introduce some additional event compression safety, but so far it looks OK.

I'd like to put this into Plasma::DataEngine itself so any of the network using DataEngines can get this magic "for free". Well, with one line of code to turn it on, anyways.

The dilemma is, as usual in libplasma, one of API: just turning it on or off doesn't strike me as quite good enough. If a DataEngine plain doesn't work without networking, we probably want to queue updates as is now done for weather and let release the flood gates (excuse the pun) when the network is available again. But for DataEngines which only use the network when it's there but don't really require it (geolocation on a device with both GPS and wifi/3G as an example) they may want to get a kick in the pants when there is suddenly network but they still want to process requests normally even when the network isn't there.

There's also the issue of bandwidth availability, cost, etc.. I'm not sure how much we care about those things as first level concerns in laptop and desktop land, but I can think of use cases and devices where this will matter.

So I'm trying to consider what an appropriate API would be in DataEngine without going over the top with too much detail but also not hitting too low and making it harder when we do hit these more fine-tuning-desirable situations. As usually, the thread is on plasma-devel at kde.org.

In the meantime, I can log in and even if plasma-desktop starts faster than NetworkManager can connect I still get a pretty wallpaper (and a weather plasmoid that isn't spinning it's busy wheel) as soon as the network is there.

Thank you Solid, thank you NetworkManager / HAL / etc, thank you India, thank you terror, thank you disillus... omg. I can't believe I just broke out into an Alanis Morissette song mid-blog. How embarrassing.

;-P

Aside #1: there's now a small library the various weather Plasmites are putting together to share things like configuration, location switching, etc. It already uses the geolocation DataEngine too, though there is a granularity disparity between the resolution of the geolocation results (fine grained) and the weather services we currently have which don't have a lot of small towns in them. Something to figure some sort of solution to.)

Aside #2: A fellow came online yesterday to say he had gotten permission from wetter.com to start using their data, so our coverage of Germany and various other locations in Europe should see a sharp uptick when he's done with that weather plugin (Ion).

Aside #3: There have been a couple of really interesting geolocation based ideas floated by new (to Plasma) developers on the mailing list. I think this whole "finding where you are with whatever happens to be at hand and then make awesome things happen in the applications" is going to take off nicely for us this year. :)

Aside #4: Am I the only one who's disappointed with this season's netbooks? They've settled in at $400 a pop and are now quite happy being the smaller, slower, uglier siblings of "real" laptops. Holy missing the boat or what? Now we have a $350-400 entry point (netbooks) and a $6-700 entry point (low end notebooks) but the $200-300 range is still empty and the "OMG poniez!" interfaces that might make me actually want to buy one of those $400 playmobile versions of a real laptop are nowhere to be seen on the store shelves. *sigh*

Aside #5: As a commenter pointed out in my previous blog, the log out process is not very pretty, fast or .. well .. "KDE4". It does indeed need work, and I think we ought to replay the splash screen in reverse instead of showing all those windows blinking out of existence, which is really ugly; though we need to handle the "uh-oh .. this app wants to know if you want to save that document" situation gracefully too. Tricky.

Aside #6: Speaking of splash screens, the splash screen started centering itself properly on my laptop recently which was really nice. I think it needs a little spinny wheel on it though. As at least one bug reported has noted, there are moments when nothing is moving and you wonder if it's frozen up or something.

Aside #7: I think asides have taken over this entry. *sigh*

Read More

KApplication tricks

When plasma-desktop quits, it's possible to have KIO jobs in the queue waiting to be started. This happens when a job is requested, e.g. a KIO::file_move, but then QApplication::quit() is called before the event loop is entered. This means that the job is never started and so never completes. This is not what we want at all, as it prevents things like the wallpaper cache from working on exit.

I asked our resident kdelibs guru, David Faure, about this and he pointed me at KGlobal::ref() and KGlobal::deref(). What this does is hold a reference count for how many objects are wanting the event loop, and each job will increment the count on creation and decrement it on completion (successful or not, of course).

If your app is using KMainWindow, you already get this nice feature for free as KMainWindow uses it internally so that your app never misses a job-on-exit. Clever.

But what if your app doesn't use KMainWindow? Then you may well need to Roll Your Own(tm). Thankfully, as with most Qt/KDE API tricks, it's pretty easy. First, tell KGlobal you are going to be using the reference system for quitting:

KGlobal::setAllowQuit(true);

If you have windows that will be shown, you also need to tell the application to not automatically quit when the last window is closed:

qApp->setQuitOnLastWindowClosed(false);

This can go into your main() even. Then in one of your long-lived objects, e.g. that pesky non-KMainWindow widget/dialog/window, grab a ref:

KGlobal::ref();

Make sure this will only get called once otherwise the reference counting will get screwed up. The constructor or a run-only-from-the-constructor init() method are good choices.

Now in a method of that same class that will be called when application termination should be triggered (let's call it quit()), and which must be called only after all possible jobs may be started (so do your cleanup here as well, perhaps), drop the reference. Here's an example from plasmawallpaperviewer:

void WallpaperWidget::quit()
{
    if (m_wallpaper) {
        KConfigGroup config = configGroup();
        m_wallpaper->save(config);
        delete m_wallpaper;
    }

    KGlobal::deref();
}

So it cleans up (saves and deletes the wallpaper) and then deref()s. The wallpaper plugin in this case might just decide to save something to the cache and remove the old cache contents. Plasma::Wallpaper in libplasma will use a KIO::file_delete to remove the cache contents, and we don't want that to block regularly, so it isn't exec()d but rather allowed to run asynchronously.

When WallpaperWidget::quit() gets called now (it's connected to the KStandardAction for quitting), if there is a pending job the reference count will not drop to zero quite yet. The application will not exit immediately, the job will start its thing, return as soon as it can, drop its reference ... and then we're at a zero ref count and the application exits.

Of course, if there are no pending jobs the reference count will immediately be zero at this point and the application exits.

This is all well and good, but what if you don't have a widget that spans the lifetime of the application? What if you have a KApplication subclass that is the lifetime definer for your application? What if someone calls kquitapp myapp? Uh-oh!

(This happens to be the case with apps like plasma-desktop. *sigh*)

Good news is that QCoreApplication::quit() is a slot ... which means that unless it's called directly like qApp->quit() it's essentially virtual. Anything connecting to it via a signal or using QMetaObject::invokeMethod or some other introspection-based method of calling it will call quit() in your subclass. Neat. Unfortunately this doesn't get around the DBus usage scenario (e.g. kquitapp myapp or a direct qdbus org.kde.myapp /MainApplication quit).

The best way to accomplish this that I've found so far is to declare a public Q_SLOT: Q_SCRIPTABLE void quit(); in a KApplication subclass used in the application. The DBus interface is generated from scriptable signals, scriptable slots and declared interfaces at runtime so if your quit() slot is Q_SCRIPTABLE that is what will get exported, not KApplication::quit()!

This means you can do the set up and initial ref() in your KApplication sublass' constructor, do all your cleanup in its quit() method and finish off with a KGlobal::deref():

void PlasmaApp::quit()
{
    cleanup();
    KGlobal::deref();
}

Voila! It all works as expected and no jobs are left unstarted just because we're ready to quit.

For probably 99.9% of KDE applications out there, you don't have to worry about this. They probably use KMainWindow and/or have no code paths that can lead to straggler jobs. If you're working on one of those odd 0.1% of apps, though, there is a solution and it's only a handful of lines of code.

Huzzah!

Read More

improving freedesktop.org specs

One of the difficulties people have with the specifications hosted on freedesktop.org is figuring out just what the status of them is. I guess I just don't find this page all that enlightening. freedesktop.org does have a git repository, but the specifications are apparently still in cvs somewhere and there's very little in the way useful structure to it.

Another issue is the inertia in fromt of putting a draft spec on freedesktop.org and keeping the authoring process transparent. The visual notifications spec the Galago project originally did up, and which uses the org.freedesktop namespace on the bus (urps!), isn't hosted on freedesktop.org at all. To find it, you have to know it exists in the first place and then do some googelfu to pull it up. As another example, at one point, a fellow working on some clipboard related stuff was blocked for nearly six months waiting for a website update to show progress on the relevant spec. Oi vey!

I figured this should get fixed and with all my copious free time I figured I could do it, maybe. :P So I posted an idea to fd.o and there was feedback given such as Vincent Untz suggest to put the metadata in a file rather than plop the name of the project in the spec file name. Fair enough :)

While there was a good amount of initial interest .. none of us did anything. Oops.

I last wrote a blog entry on this nearly a year ago. In testimony to the lack of sexiness related to the topic, there were exactly zero comments on that entry. For comparison: the posting a few days before had 30 comments and one a few days after had 15.

So I started a git repo and put a couple of the specs into it to experiment with things. I don't have a git account on fd.o and nor do I particularly feel like jumping through hoops to get one just to play around with this, so I went the "get things done, let's worry about detail later" route. I started on a XML metadata file format, some parts of which are inspired by the docbook stuff already in the specs, and started on a repository structure.

(Btw, I know that github is proprietary software; but gitorious was broken and not behaving nicely when I went to do my work. :/ )

The idea is that you should be able to check out the repository and have all the documentation transparent and easily accessible to you. You shouldn't need to know revision numbers or rcs commands to get at specific releases. You should be able to see what spec is use by whom and since when.

However, I haven't done anything more on it in the last two weeks. Fail!

I mentioned I'd started this on the xdg list on freedesktop.org and nobody commented (or if they did, I missed it.. :/), which also sort of sucks. But oh well ... I'm going to do my best over the next few weeks to dump the remaining specs into the git repo and write up a small utility or two that will rip through the xml metadata files and answer queries like "which specs are implemented in both KDE and XFCE?" or "list the versions of GNOME that support the menu spec" as well as be able to dump out feature support matrixes and tables of index in html.

If you'd like to help out with this wonderfully entertaining (*cough*) task, please find me on irc or by email or just fork the git report and start sending pull requests.

Read More

system trays

Marco's been doing some great work with getting the new D-Bus based system tray into place. Today I dove in and (locally) ported KMix over to the new classes. I picked KMix because it's a bit of an odd duck in a few ways (e.g. the "parent" window actually behaves like a popup), so I figured it would be a nice stress test, but is also a fairly straightforward app so wouldn't be too annoying to dig into.

So far the total diff is +47 -42 lines: a sum total of five new lines of code. For those lines of code we get a couple new features, including being able to tell the system tray that we are a hardware related item and that we're currently active.

The first neat thing I noticed when it appeared in the system tray was that it behaved like all the other icons: it glowed when it was hovered over, it grew smaller when it was pressed. It suddenly felt a lot more like it belonged with the rest of the things on the panel down there. It wasn't some odd alien anymore.

(Which reminds me: in 4.3 when you press on Plasma::IconWidgets the "get smaller" as if you are "pressing them into the canvas and therefore receding away". It's the same kind of effect I put into kicker back in .. oh .. 3.3? 3.4? Something like that .. anyways, it gives some nice "tactile" feedback for those icon buttons. Anyways, back to the system tray stuff .... )

The coolest thing, however, was when I started a second system tray using plasmoidviewer: now I had two trays in two different processes ... and the KMix icon showed up in both. None of the other icons did, of course. One more step towards closing a feature wish I first came upon years and years ago for Kicker: to have multiple trays for multiscreen systems. :)

The DBus protocol behind all this had all the wiring in place for stuff like wheel event notification, but not all of it wasn't plugged together in the actual system tray code. So I went off and did that bit of ankle-bone's-connected-to-the-mouse-wheel-bone work and there was wheeling goodness again in the KMix icon. Great!

There are still a few small things to take care of, like making the DBus calls on the system tray plasmoid side non-blocking so we don't end up freezing the whole of plasma-desktop due to a misbehaving app on the other side (the wheel event call is already non-blocking since I just put that one in there, but the others are synchronous), figuring out what kind of geometry information we want to pass back for main window activation (kmix likes to position it's slider popup using this information) and couple other minor points.

A current assessment of KNotificationAreaIcon is that it's a really long name but it works right out of the box, including with xembed-only system tray environments, with only a few minor (though quite fixable) caveats at the moment. It needs some tweaking and polishing, but it should be in great order before 4.3.0 given it's current state.

Support for this on the Plasma side is already in svn for 4.3, but we're planning and plotting how to go about the application side. Our current strategy is this:

0. Port a couple of KDE applications to the new application side API, KNotificationAreaItem, to prove and stress the current system and APIs, fixing bugs and implementing needed features as they crop up. I've already done KMix, but we're looking for a couple more to join the game. Come find us in #plasma on irc if you'd like to try it out in your application, or just take a look in playground/base/plasma/libknotificationareaitem and figure it out on your own. :)


1. Write up a detailed spec and put that on Techbase as documentation for the DBus interaction bits.


2. Take it all to kde-core-devel for comment and hopefully approval for kdelibs. My personal goal is to have it in KDE 4.4's libs. I'm not sure we can (or should) make it in for 4.3: we can port select apps using a small helper lib for 4.3 that doesn't have the BC guarantees that kdelibs caries. We could perhaps install it as a static lib even that apps just "suck in" to avoid any BC issues of any sort. If there's both comfort and demand for this, we can put it into 4.3's kdelibs .. but we've lived with the current situation for years and years, another 6 months limping along with a static lib won't kill us. ;) In return we'll get good usage info and be able to modify the API or DBus service as needed.


3. Assuming it goes well on kde-core-devel, then we will take it to freedesktop.org.


4. Have some icecream, watch the lilies grow in the field


5. Fast forward a few years to a time when we no longer have any of this xembed crap to deal with in the tray anymore.

Happy days are here again.

Read More

birthdays

P.'s birthday was yesterday .. no, make that day before yesterday. It's past midnight now, making it officially Tuesday here. ;)

We had it at the Calgary Science Centre (note the Canadian spelling!) and it was a blast. Cake and pizza and presents and a movie and big huge bugs (tarantulas, scorpions and millipedes!) and physics demonstrations and dozens of interactive stations ..! Much fun was had by all, though the number of "all" was a bit smaller than I'd figured on. When I book it some 5-6 weeks ago I forgot the check the calendar and so failed to realize it was Easter weekend. Several of P.'s friend's were out of town, but those who were able to show up had a lot of fun and most importantly P. had a blast to start off his 10th year of life.

A number of parents at P's school, upon receiving the invite, said things like, "You're a brave man." In my experience that's often translated to, "Holy crap, there's no way I'd do that. Way too much [negative by-product]. You are a crazy person." I suppose the braveness was related to having invited a whole gaggle of 8 and 9 year olds for six hours of science center celebrations where I'd be the responsible adult. I dunno ... I love getting to "be a kid" again one in a while like that and the kids generally take care of themselves in a place like the science center. I ran around with them, threw balls with them, tried the various activities with them, participated in the live demos (where I got to showcase my expertise in "blowing a ping pong ball with my mouth out of one glass and into another one placed ten centimeters away"; seriously, I never thought I'd actually have a chance to show that one off. In fact, I had written the time spent practicing it all those years ago right off. ;P )

In the end, there was no real bravery involved at all. Just lots and lots and lots of fun, and the joy that watching one young man's face light up with smile after smile brings.

Ok, so I did go to bed a bit early that night. Then again, so did P. Having fun, it turns out, is pretty exhausting no matter your age.

Read More

easily amused

Let it never be said that I'm not easily amused: the Weather wallpaper shows the weather outside on your desktop. Tonight it was a bit cloudy, so it showed an evening landscape with clouds. A little while later the clouds blew away outside and the wallpaper morphed (there's a nice 1 second fade :) into a nightscape with a clear starry sky. How cool is that?!

I also couldn't stand that the tab bar, that totally looked like it had a button like a scroll in it, wouldn't let me grab and drag it. So I implemented that. So not only are tab bars in Plasma animated (thank Marco for that) but you can now grab the tab selection and drag it to another tab. As a bonus: it's all animated. Click on it, throw it a bit and it moves over.

Which leads me to wonder: if we got rid of the visual representation of tabs as .. well .. tabs and instead had something that looked like a bar with labels where one of them was selected, which was the original Oxygen style concept (and when the artists were harassed into not doing that I was very upset) and is the current Plasma approach, what else would we come up with? The only downside I can see right now is that click-drag-reorder isn't as easy, but click-drag-different-tab is just so ... natural!

Other than that, I spent the last day or two working out little regressions that were pissing me off, like how the popup for the tasks widget weren't perfect or how the line edit in the application launcher didn't get focuse when opened ... little things that just rub me the wrong way.

I'm also increasingly excited about the netbook stuff as we move forward with it because it's allowing us to put into practice the promised and inherent flexibility of the Plasma framework in a way that has real, practical purpose. It helps remind me that this isn't just a "make a desktop" project, something the world really doesn't need in my opinion, but a "make a way to make user interfaces we need" project.

Oh, and wallpapers that adapt to the world outside. It's like my computer is a living thing observing the world ... and sharing the same DataEngine as all the other weather stuff.

Did I mention we also have a geolocation DataEngine now? ;)

Read More

Linux Link Tech Show, COSSFEST

I'll be on the Linux Link Tech Show tonight. It starts at 20:30 EST (or 00:30 UTC). If that's a bit late for you, you can always download it from their website after the show.

I'll also be presenting at the Calgary Open Source Software Conference (COSSFEST) on the 17th and 18th of the month.

I look forward to seeing you either in the LTTS irc channel tonight and/or at COSSFEST! :)

Read More

on copyright assignment

Dave Neary writes about the potential ills of copyright assignments. I agree with Dave that if you require a copyright assignment as a pre-condition to contribution that you will inevitably limit the amount of participation you have. It becomes just one more barrier to entry that one has to jump over.

The answer, however, is not to have no copyright assignment program in place. Having no such program can actually be quite detrimental for the reasons succinctly outlined by the FSF: you can't defend rights or make decisions on licensing on behalf of others. Limiting the number and types of individuals involved in defense and maintenance of licensing is a good reason to have copyright assignment, as it allows both more agile response and to put risk in response to things like licensing disagreements off of the individual hacker in the middle of some hamlet in the pastoral Canadian countryside (or whatever pastoral countryside they may live in).

Having some sort of copyright assignment option in place also prevents problems that can arise whenever someone disappears from the project. It's hardly fair for the future community of your project to forever be tied to licensing decisions taken by predecessors who can no longer be reached.

So how does a project avoid getting stuck in this "rock and a hard place" type decision between "keeping your community open" and "protecting the technology and rights of others"? Simple: have an optional copyright program that your contributors can engage in. This isn't "perfect" from a purists point of view, but it can make things a lot simpler down the line if it's something the bulk of the community gets on board with.

In KDE we have the Fiduciary License Agreement (FLA) which does a neat little bit of legal polka in which the signatories (the contributor and KDE e.V. in this case) swap about rights to the copyrights. After signing, both now have the ability to continue to make decisions on the copyrights and KDE e.V. can defend the code in our shared repository and make licensing decisions if needed.

"Oh no!" some will say, including apparently Dave, "But what happens if KDE e.V. goes evil?! Now they can do bad things!" Well, all I can say is that if you've signed your rights away with no understanding in place as to what the other party can do with those rights then, yes, you made a silly move and deserve everything you get.

With KDE's FLA, we have another document that goes with it: the FRP, which is pronounced "eff are pee" if you are a lawyerish type or "frap!" with a good amount of emphasis on the 'ap' if you are a bit more light hearted. The frap, er... FRP lays down specific guidelines as to what KDE e.V. can do today and in the future. It's a separate document to keep that part out of the courts should we ever need to defend your rights, since it's only really useful between the signatories and could give a GPL violating defendant enough rope to play out a case for a long time playing "let's define this other term first" with the court. The important part is that it protects the rights of the individual without requiring us to enter into some mistrustful standoff based on "I own my property, and I'm not going to share any rights with you so you can't screw me later! Bwuahaha!"

So the FLA is a socially responsible relationship that displays respect for both the individuals and the community simultaneously. It lives in balance between a proper level of trust between parties (e.g. not too much) and respect for the current and future legal health of the project.

When it comes to corporate entities holding all the rights, something Dave also notes can be dangerous, my recommendation is the same: get an agreement with them first before signing over anything. We did this with the Free Qt foundation and it helped preserve the future of Qt quite nicely even though there was a single copyright holder. This made the decision to relicense Qt under the LGPL very easy while preventing the proprietization of Qt.

In my experience when people talk about the danger of assigning copyrights to a company, the reaction to the suggestion that they get something signed first that lays out the rules by which the agreement should be maintained and dealt with the in the future is usually met with "That's a good idea ..." and a bunch of silence. Then usually a few days/weeks/months later they'll repeat the same argument as if there was no good answer.

Oh, and if you're reading this, Dave: Trolltech is now Qt Software, the commercial version of Qt is only different in licensing terms from the open one, Qt was never "community code [they] forked commercial versions off of" (when they did use community code such as Phonon or Webkit, they stuck with LGPL and multiple-copyright holder licensing) and since then Qt Software has announced that they are opening their repositories for public involvement (something I wish was already completed, but these things take time to arrange organizationally and legally). :)

Finally, to everyone who has contributed copyrightable materials to KDE in any meaningful manner (source code, artwork, documentation, etc), please consider signing an FLA. I have. Why? Because I feel it's the most responsible way of handling my relationship with the KDE community in terms of sharing governance of my contributions at no cost or risk to me.

KDE e.V. is currently having some legally sound boilerplate language for signers to pick from for the "what contributions this covers" created for us (for my personal KDE FLA I used a broad "all copyrightable works produced by me in the kde.org repositories now or in the future" phrase, but we want to get a gradient of legally accurate phrases you can pick from to paste in there). We will also be hosting a FLA signing area at this year's Akademy so you can do this in person. It takes all of 5 minutes. You might even get a cookie or a hug or both from Adriaan for doing so. We're still working out those details. ;)

Also, depending on regional law and employee agreements in place, companies that contribute to KDE can also sign an FLA on behalf of their company's contributions rather than have each of your employees do so. It's a great way to show your support for the community you are helping to make better and getting so much from in return.

p.s. This is yet another one of those topics where I see a lot of either/or argumentation ("assign copyrights for the good of the project!" vs "assigning copyrights is bad") when the reality is a lot less black and white. There are balanced, middle-path answers to be had if sought out. The opt-in FLA/FRA is one such answer. It's interesting how often the best of intentions (in this case "protecting our creations") can so easily devolve into either/or thinking that produces no truly good results in any direction.

Read More

PackageStructures

Today I tackled two things which I wasn't really looking forward to doing: fixing up the keyboard state applet (which probably should be renamed the input device state widget :) and getting rid of the custom Plasma::Package in the Image wallpaper.

The input device state widget (IDSW?) is an accessibility tool that shows what keyboard modifiers are pressed, what mouse buttons are doing what and lets you set those states directly by clicking/selecting the different buttons. This was originally written for KDE3's kicker and then was ported to be a Plasma widget.

Sort of.

It was done in the most minimal way possible, really. It still uses QPushButtons wrapped in proxy widgets for the canvas, PNGs for the images and generally reminds me of Athena widgets style wise. :) It's been sitting in kdereview for months even since it was ported; I haven't moved it out of kdereview because of its horrific shape, and nobody has stepped up to fix it. That means it has fallen to me, and once I started working on it I began to understand why nobody had touched it. Oi vey.

Currently the patch is -367 +366 lines, so the change isn't that much and I have a bunch more work left to do on it. Probably another half day of hacking, actually. Currently it uses Plasma::Svg, Plasma::IconWidget and no proxied widgets. It could still be a lot better, but once I've got it working 100% properly again it should be a lot easier to get it there. I'll probably also break out the handful of classes into their own files while I'm at it ... working on a file that's nearly 1000 lines long with half a dozen classes in it is more annoying than it really needs to be. :)

While I'm still working on the IDSW, I did manage to finish up the Wallpaper PackageStructure thing. Now all the Wallpaper plugins can share the one packaging system. While doing this work I noticed that the role of PackageStructure isn't obvious to people and that PackageStructure had a couple of small annoyances itself. So I fixed the annoyances in libplasma and then implemented everything that was in the custom Package classes as a PackageStructure.

What the heck does that all mean?

Well, a Plasma::Package just represents a way to get at a file structure on disk in a generic way: you can ask for file paths, entry lists, etc. by semantic name. So with wallpapers you can ask for the "preferred" entry, and that will get you the path to the "best" wallpaper image for the screen resolution, or you can ask for all the "images" and it will return all the known image files in that package .. wherever they might be.

A Plasma::PackageStructure is the "driver" and tells a Plasma::Package exactly what "preferred" or "images" means. The structure can alter the contents when the path changes, allowing for dynamic package layouts as well as provide user readable text for use in user interfaces for packaging purposes.

Plasma::PackageStructure is designed to be subclassed, and it's been used for all sorts of things in Plasma already: wallpapers, Plasmoids written in various languages, MacOS dashboard widgets, SuperKaramba widgets, Google Gadgets .... Plasma::Package on the other hand is not designed to be subclassed; instead it is designed to take a Plasma::PackageStructure and use that to figure out what's going on. So if you ever feel the need to subclass Plasma::Package, you're probably doing something wrong and you should come find me on #plasma or plasma-devel at kde.org for some pointers. :)

In the case of the Wallpapers, the package picks the wallpaper file to use based on whether it's a wallpaper package (bundle of papers at different resolutions) or a single file and what the Wallpaper plugin is doing at that moment.

To get a usable Package, a Wallpaper just does: Plasma::Package(pathToWallpaper, Plasma::Wallpaper::packageStructure(wallpaper));

At that point you can then ask for "preferred" and get your answer. It's pretty cool how the PackageStructure concept has made it possible to use the simple Package API all over the place (so you just need to learn one API) even though they map to such wildly different things on disk. Yes, boys and girls, writing code can be lots of fun. :)

Anyways, that was my exciting day. I can tell that feature freezes are upon us when my days fill up with such "fun" tasks. ;)

Read More

KMyMoney, Kraft, Akademy .. you know, stuff with 'k' in them

I noticed the other day that the Linux Today editor blog picked KMyMoney as the best F/OSS personal finance package. Congrats to the KMyMoney people! Now we just need to educate the LT editors about Kraft. :)

(p.s. to Klaas: ever considered defaulting the website to English for a more international feel?)

I've also been looking at my schedule for the next few months and wondering just how much I want to travel right now. It's complicated by the fact that it seems I'm moving to Vancouver. For real, this time! ;) Why now? Well .. besides P's mom being there and it being the home of my soul, I'm currently scheduled to move in with S. Perhaps my bachelor days are actually numbered. Shock! Horror!

That 675 kilometer move to the left .. er .. west needs to happen during the school break in between P's 3rd and 4th year classes, which means July/August. That means I'll be looking for a place out there in July to move out in August. I realized today as I was making my travel plans that this is really cranky timing for me with Akademy, which is also in July. It doesn't help that I absolutely dread the process of moving in the first place, that packing up the house is going to be an exercise in pain and annoyance (isn't it always?) and that I'll have a bunch of extra expenses to cover in the summer now.

I'm contemplating now whether I can afford, mostly time-wise, to make it to this year's Akademy. It would be the first one I've missed, and the one with the best location thus far. I'm just very concerned about doing Akademy, house hunting, moving and P. back to school all within the same 8 weeks and how I'll feel at the end of that.

There's a reason I tend not to move house much: it usually messes up my schedule, and I rarely have a very open schedule to begin with. :/ Something I'm going to have to decide on here this week, in any case. Meh.

Read More

Akademy 2009 presentation proposals

There are five days left until the deadline for Akademy 2009 presentations. I'm working on mine today and tomorrow so I can submit it either Monday evening or Tuesday, and if you're thinking of attending but haven't put in a proposal, you really out to think about doing so.

So far we don't have many talks submitted, and while I expect the usual late rush of proposals (including mine ;) we're making the organizers understandably nervous. Don't miss the deadline, and get your proposals in sooner rather than later.

On the call for participation page it notes that we are to "submit abstracts of under 500 words for 30 minute presentations to akademy-talks@kde.org. Include your name, title of your presentation, a short abstract of your presentation, intent to submit a technical paper, a short bio, and a photo suitable for the web." The bio and picture parts are probably slightly less critical than the abstract. ;)

Most of the presentation slots are only 30 minutes long, and there are even some five minute lightening talk slots. Knowing the KDE people, anyone can do a 30 minutes presentation. I've sat over beer listening to you talk about your pet project for hours on end. It's really the same thing, just with more slides, less beer and a little more structure. ;)

Key topics they are looking for are functionality (holy topical broadness! Just about anything fits there!), portability and beauty, but anything interesting can get the nod as well.

If you feel you "can't" give a presentation, or just haven't done so before and are feeling a bit unsure about the concept, come find me on irc or by email and I can give you a hand and a pep talk. :)

See you in the Canaries!

Read More

Plasma SoC

This year we were inundated with proposals for the Google Summer of Code; Plasma received 48 proposals. Many of them were very good, but sadly we know we are not going to get even half that number approved. So a bunch of the Plasma SoC mentors hunkered down on IRC today along with Lydia, who is doing an awesome job of overseeing the KDE SoC process along with Jeff, and went through all the proposals together.

We divided them into four categories: must-haves, would-be-nice-to-haves, neutral and probably-nots. This was not the easiest of tasks, but we were all in general agreement on things so it went as quickly as it could. The spreadsheet with our proposals on it quickly came into order as we color coded and ordered the entries, then we went and reflected the results with our votes on the SoC page itself.

We have seven "must-haves" and hopefully Google will bless us with spots for all of them. I still feel bad for the inevitable raft of proposals that, despite being good, won't get approved. Hopefully several of these students can actually take on their projects anyways, just as we have done in past years.

I'm excited about the proposals at the top of our list, however. It's going to be a great summer, methinks. :)

Read More

plasma on netbooks

At last year's Akademy, we did some work on a layout for a Plasma interface for netbooks on the whiteboard and started putting together some code for it. It then went quiet and pretty much died: we focused 4.2 development on the idea of "traditional desktop usage parity", there were no SoC projects around the concept to help push it forward and nobody else in KDE really seemed to care enough about the concept of "things that aren't large screened, mouse driven devices" to give the effort any support.

A few weeks back we ended up talking about the state of this interface and I note that, with all honesty, I really don't have the resources to push it forward while keeping libplasma, plasma-desktop, the Plasma plugins, my other responsibilities in the KDE codebase and KDE e.V. all moving as well. Bille suggested I appoint a lieutenant or two to take it on and be the obsessive-compulsive maintainers of it. Knowing a great idea when I hear one, Artur and Marco were quickly deputized.

The topic came up again last week when a rather concerned developer accidentally woke me up in the middle of the night (I'm not very good at ignoring concern :) to discuss why having a netbook interface is so darn important. They wondered if it would be possible to get something out for the KDE 4.3 release ... I didn't think so.

So yesterday a few of us got together on IRC and put together a roadmap and did another revision of our netbook design ideas. I'm really happy with the results, and we're targeting KDE 4.4 for the inclusion of a netbook interface. It will be usable on a regular laptop or desktop as well, and I expect some will do just that.

Now, I'm not going to spill to many of the beans here as to what our plans are, I'll leave that up to Artur, Marco and whoever else joins them to blog screenshots/screencasts as progress is actually made, but here is what I think the important points are:

• We aren't making an interface for a "smaller laptop" or a "larger handheld"; the interface is for a netbook, which has a unique set of use cases and should have a unique, if familiar, user interface. To our knowledge, nobody is really doing this yet. We feel that just as Apple made popular an interface style on handhelds that is for handhelds with their iPhone/iPod touch interface, netbooks deserve a similar treatment.


• Being based on libplasma, we don't have to start from scratch. In fact, the bulk of the work is already done. This will give us a nice showcase for the concept of a "primary user interface framework" and how it can be used to reapply existing work to new physical form factors with minimal investments.


• Being based on libplasma, it will automagically work with other Plasma tools. This will make working with a Plasma netbook and a Plasma laptop together easy and coherent, especially when the SoC projects on things like network transparency in libplasma come to fruition in KDE 4.4.


• Being part of the Plasma project, it will share the visual identity of the Plasma desktop shell: you will be able to put your netbook next to your laptop/desktop and they will look like they belong together. Only Apple manages to do this with their products right now.


• Because it's not some esoteric software stack all welded together with a kernel and various "made for mobile only" toolkit work, it will be easy for people to get involved and work with it.


• The emphasis in the design is on full screen usage, speed to information, integration with appplications and visual beauty.

As this shapes up, I'm going to be actively looking for market opportunities for this new bit of software. If you'd like to get involved, find Artur (aka Morpheuz) and Marco (aka notmart) on irc in #plasma. Bring your text and/or SVG editor with you. :)

Read More

wallpapers and other bobbles for 4.3

We have a number of new Plasma components lining up to make it into 4.3. Not least among them is a geolocation DataEngine, making it absolutely trivial for anything Plasma to get at the information either via a GPS device or by looking up the location of your network address if you are online. Along with a handful of new widgets, some I've already written about recently, we also have no less than six new wallpaper plugins that may make it into 4.3!

They range from the trivial-but-was-in-KDE3 pattern based wallpaper plugin to Jonathan's weather wallpaper which automatically changes the wallpaper to reflect the weather. It of course uses the weather DataEngine, allowing Jonathan to concentrate on the business of making a neat wallpaper concept come to life.

To support his efforts, I added DataEngine support to the Wallpaper class so that using DataEngines is as easy from a Wallpaper as it is from a Plasmoid. Feeling I was on a Wallpaper role, I made a few other additions to the Wallpaper support:

• Wallpapers can now get their configuration sync'd to disk just like Plasmoids and Containments can, so even if the application crashes or some other disaster befalls the system you don't lose your new wallpaper settings.


• Wallpapers can mark themselves as needing to be configured, much how Plasmoids can.


• Plasma::Wallpaper now includes multi-threaded wallpaper rendering built in; this used to be part of the Image wallpaper plugin and people writing plugins were starting to copy this code wholesale. So into libplasma it goes.


• There is on-disk caching of rendered Wallpapers if the plugin indicates it would be a good idea to do so (it makes no sense, however, if the wallpaper is going to change a lot). This means the next start-up is a lot faster: it just loads a perfectly rendered paper instead of loading an image from disk and then scaling it or whatever first.


• The slide show wallpaper now pops up a progress dialog while scanning the contents of a directory so that things don't just "freeze up"; this caused an annoying bug that Thiago hit upon, but he sleuthed it down and I fixed it with a one-liner. Rejoicing was to be had.


• I added a small tool, plasmawallpaperviewer, that lets you load and configure wallpaper plugins. This is much more convenient for development than restarting plasma-desktop every time you want to see how your plugin is coming along. plasmawallpaperviewer joins plasmaengineexplorer and plasmoidviewer as part the handy group of developer tools that come with the Plasma workspace.

Which reminds me of a topic I've been meaning to blog about for a while: if you are writing an application that has plugin support and those plugins are non-trivial, work with the rest of the application (making regressions in the framework hard to pin down without further examination) and/or you want people to write lots and lots of them, be absolutely sure that you include a small driver application that exists only to load and interact with those plugins.

Not only is it much faster to start a small application like that than a full feature killer application, it also serves to isolate the plugin at runtime. You know that anything that's going wrong is either a problem in the testing app (though given how small these apps tend to be, bugs tend to be found and killed quickly and easily), in the framework code or in the plugin itself. Plugin writers will be able to trust that any problems they see are likely behaviours of their plugin and not some odd interaction in the context of a larger sea of plugins.

Speed and ease are what help people make good plugins and lots of them. In Plasma we have a tool for people writing Plasmoids, another for DataEngines and now one for Wallpapers. KRunner is already a good tool for testing AbstractRunner plugins, so we don't need a separate tool for that species.

Adding the ability to write plugins in dynamic languages is also a pretty good plan, and with Plasmate we will be stepping it up with an ultra-simple Plasmoid and DataEngine creator. Plasmate won't be released with 4.3, but it should make it into 4.4, especially if some of the SoC proposals for it get accepted.

Anyways ... wallpapers. The other four wallpapers that might be seen in 4.3 are an interactive mandelbrot generator, a world map (and yes, it uses Marble! :), "virus" which simulates your wallpaper being eaten up by small colonies of breeding pixel munchers and finally a plugin that loads and displays E17 Edje content (so you don't have to be jealous of their pretty wallpapers anymore ;).

While wallpapers aren't exactly critical features, they can be a lot of fun. Sure, it's not "big picture" stuff, but that's ok ... sometimes fun and cool is enough. We have lots of seriousness elsewhere to make up for it. ;)

I'm sure someone will ask about per-desktop wallpapers and drop-an-image-and-it-gives-you-the-option-to-make-that-wallpaper in the comments; I doubt it'll be in 4.3. Both are features that get asked about here and there, but it's not up there in importance enough for anyone to have stepped up and written a patch for either one. Hint, hint. :)

Read More

a bagful of dates

As you probably know, KDE 4.2.2 was released today. It has a whole bunch of bug fixes and translation updates and is quite a worthwhile upgrade if you haven't done so already.

On IRC last night, people started popping into #kde as the 4.2.2 packages hit their distribution's repositories. The big themes were how many bugs had gone missing and how much better the performance was.

Always nice when there's a really great release on the rails. :)

Of course, we aren't stopping there: I assume there'll be a 4.2.3 (more Plasma and KRunner fixes were backported after 4.2.2 was tagged) and the "soft" feature freeze for 4.3 hits us in just 5 days! That means that any features that aren't on the official TODO list can't go in. This is the first step towards a hard feature freeze a few weeks after that. Then it'll be bug crunching time to get 4.3 looking and working great.

Speaking of bug crunching, the KDE Bugsquad is turning 1 year old and they are having a KMail crush-a-bug-a-thon this weekend. Join in the fun to help 4.3 be even better!

The Google Summer of Code deadline is also upon us tomorrow, so students really need to get their proposals in ASAP if they haven't already. We have a lot of Plasma proposals which is both good and bad: it means we'll have lots of great stuff to pick from, but it also means we'll end up turning some good proposals away as well. (Unless Google ends up feeling extra helpful this year ;)

Having noticed that there were a few rather good proposals for a dock-style panel, I got to thinking about what would be needed to support such a project. Plasma's design can handle it quite nicely with a PanelContainment; I personally think it's really silly that people have to pick a whole different application just to get a dock due to design limitations and/or annoyances in other desktop shells. Sort of like how I feel sad watching people post multi-page blogs about how to set up this or that system monitor on their desktop when it's a couple of clicks to get something that looks even better in a fraction of the time with Plasma. Anyways ... thinking about the Dock I remembered something a bit "funny":

While the framework supports the idea of different types of Containments for Panels that can behave as differently as they want to ... the "Add Panel" menu entry could only add the default Panel containment. Which would make the dock thing all a bit an academic exercise: sure, you can write it, but then it would be off to the config file with a text editor to try it out. ;)

So today I changed that and now we query the system to see what panel Containments are available. If there is only one, it just shows a single "Add Panel" menu entry. That one panel Containment doesn't have to be the default one, though. It could be swapped out for something completely different by changing just one .desktop file around.

If there are multiple panel Containments, you now get a menu listing the options which you can then pick from. Voila, problem solved.

There's some code duplication going on in there, but if Chani's menu plugin SoC project gets the nod then that too will go away.

Not all was happy in the land of Plasma, though. Artur discovered that if you dragged an extender into a Firefox window it would just ... disappear! While it was a funny way to get rid of the calendar in one of the clocks, this was rather surprising to say the least. It turns out that Firefox quite stupidly accepts anything dragged over it, regardless of mimetype. I'm pretty sure that Firefox doesn't know what to do with a plasma/extenderitem mimetype, after all. ;) However, they one-up'd their own sillyness by also accepting the drop and then marking the drag object as having been moved (ergo the extender just disappearing) ... even if Firefox actually ends up ignoring it. What?! It was a simple one-liner work around in Plasma, but I was pretty shocked by the behavior of Firefox. It was the only app we could find that did this. *sigh*

Speaking of extenders, in 4.3 the dragging is really, really smooth and nice, they can be grouped and then expanded or collapsed (so no more mile-high stacks of Kopete announcements :) .. I'm really happy with how they have matured since their arrival in 4.2.

Read More