Javascript Jam Submission Deadline Today!

All submissions for the Plasma Javascript Jam must be sent in by midnight tonight UTC to javascriptjam at kde dot org!

We've already received a number of submissions over the last week and one lucky developer will be walking away with a shiny new N900 of their own as a result! Submissions will be published on the 2nd, voting by the community (20% of the final score!) will start (hopefully) on the 3rd (I will post details when that happens) and winners will be announced on the 9th. Exciting times! :)

Read More

krunner, QDBusServiceWatcher

Ah, KRunner, lovely time saver, let me count the ways I love thee. :) This blog entry is about KRunner and has something for "everyone": user, artist, developer ...

One of the most immediately obvious changes in truck right now is the streamlining of the look. Perching KRunner at the top of the screen has been very successful, but it did make it very obvious to my eyes just how unnecessarily big the window was when it first appeared. It really doesn't look very much like the original mockups, at least in the details. So I chopped down the margins and replaced the odd CSS-styled buttons (a relic of the 4.2 release, if I recall correctly) and switched it to use the same toolbuttons seen elsewhere in the Plasma Desktop shell. Here's what it looks like when it appears:

... and with mouse hovers and keyboard focus on a button in a rather unnatural pose to illustrate the various button states ...

I'm hoping to get some new artwork for the '?' and 'X' icons and we (Pinheiro and I) are toying with an even more radical concept: making it possible for KRunner to be always visible with "windows can cover" style autohiding known from plasma-desktop's panels. That hasn't been done yet, but I plan to at least put it in as an experiment for the 4.5 betas. Pinheiro has also suggested putting the hardware related entries from the system tray in there as well. We'll see.

The other day someone came into the #plasma channel on IRC and asked how to get the unit conversion runner to "convert" timezones. I said that it sounded more like a good case for a new Runner plugin altogether and that it wouldn't be hard. I was having an annoying day and so decided to see how quickly I could pound something like that together. Answer: ~15 minutes. The KTimeZone classes and the Plasma::AbstractRunner architecture made it painfully simple (112 lines of code, counting the C++ header and all the usual C++ fluff, most of it boilerplate with some snippets borrowed from the time DataEngine) and now you can do things like this:

It also understands things like "date cest". You can mix and match the words "date" and "time" with a city or timezone name and it spits out the results. Activating the answer moves it into the edit area (so you can edit it if you wish) and copies the text to the clipboard. This is true of any informational match in KRunner, actually, something I find really handy when doing simple bits of math.

This also prompted me to improve a little thing with the informational match selection: it now puts the query ("time oslo"), rather than the answer ("17:20"), into the command history. Speaking of the command history, hopefully I'll be able to blog shortly about command history and keyboard navigation improvements as well. ;)

In addition to the date and time Runner, there is also an events runner under review that fetches and adds todos and events from Akonadi. So KRunner will get to continue its "a few more plugins every release" pace. More are always welcome.

Finally, some DBus foo that others using DBus in similar ways may benefit from: Today I discovered QDBusServiceWatcher, a new class in Qt 4.6. Some of the runners use DBus services, and when that service isn't available they will stop processing queries and when the service appears they will start again. Up until now they were using the QDBusConnectionInterface::serviceOwnerChanged signal, but this results in a message every time anything appears or disappears from the bus. Yes, that means every time a KDE app (or other DBus using app) started or quit. Obviously, this isn't great.

My first bit of research uncovered DBus match rules, which among other things can be used to prevent signals from being send from the DBus server that the receiving application already knows it won't care about. In the case of the plasma-desktop-runner (responsible for things like "desktop console" in KRunner), it only cares about serviceOwnerChanged when the service in question is org.kde.plasma-desktop. I figured I could send an appropriate match rule and avoid KRunner being woken up and doing some processing every time an app starts/stops. Turns out QtDBus can already do this for us by defining the signature parameters when connecting to a signal. Even better, this is exactly what QDBusServiceWatcher does specifically for watching for specific services coming and going! With each bit of information I dug up, I discovered I'd have less work to do. Awesomeness! I heart Qt.

One Runner plugin is now using QDBusServiceWatcher and by the end of the day so will all the rest of the code in the Plasmasphere that needs it. There are somewhere over 100 other files in KDE that should similarly be moved to QDBusServiceWatcher.

One more trick came to light yesterday via Alex Merry's exploration into pauses and hiccups related to the audio player Runner. Since queries are processed in threads, Runners are able to keep complexity down by not worrying about blocking. So they tend to make non-async DBus calls. Unfortunately, this leads to pauses elsewhere as synchronous DBus calls far too easily end up blocking each other, defeating the purpose of the threading altogether in those cases. Fortunately there is asyncCall() which returns a QDBusPendingReply. Unfortunately this means writing async code even in the threads where we don't care too much about blocking for a bit here and there, increasing the complexity there .. or does it? QDBusReply has a constructor that takes a QDBusPendingReply, and in that case it blocks waiting for the async reply to come back (or timeout, in the failure case). Which means code like this in a thread:

QDBusReply reply = favicon.asyncCall("iconForUrl", url.url());

will cause the thread to block (preserving the simple, clear synchronous code path) while the DBus call itself is asynchronous. All in one line of code. Beauty! I heart Qt some more.

Read More

Plasma Javascript Jam: Open For Submissions!

It's the 24th of March, which means that the Plasma Javascript Jam Session competition is now open for submissions! You have between now and the end of the month to get your Plasmoids in via email to javascriptjam at kde.org. In fact, the first few entries have already appeared. :)

We're cool with people re-submitting their Plasmoid if they make some improvements or catch some odd bug after sending it in and we will be testing Plasmoids against the latest ScriptEngine in the 4.4 branch, though if your Plasmoid requires (for whatever reason) the ScriptEngine from trunk we can probably accomodate that in the judging.

I can't wait to see what appears in my Javascript Jam inbox over the next week!

Read More

semi-random thoughts for the day

Plasma Netbook Reference Platform

A couple days ago I downloaded a build of the Plasma Netbook Reference Platform (PNRP?), threw it on a USB key and for the first time ran it on an actual netbook. Up till now I'd been running it either on my laptop or on funky "developer devices" hooked up to a normal monitor. Putting it on one of the first-gen EEE PCs was really eye-opening. The whole form of the user interface makes so much more sense on a smaller screen, and it worked right out of the box quite nicely. There were a few issues here and there, and some new issues related to design came to light as I sat there watching P. use it (he loved it, and is now back to using that rather old netbook now because of the new interface on it). This is exactly what we hoped for when getting PNRP up and running: being able to easily see it in the proper context and get working quickly and effectively on improvements. Since my experiment with P and the old netbook, there have been two new builds and I'm about to update his USB stick to today's version.

Some have also been asking how this relates to the Kubuntu Netbook effort. Kubuntu put out a tech preview of Plasma Netbook and continues to ship a netbook version. Why didn't we go with Kubuntu, then? Well, that question is a loaded one. In particular, it implies that only by sticking exclusively with Kubuntu would Kubuntu's efforts be validated. To me, those efforts stand on their own as being great and valuable and it's still something I encourage and support personally.

The openSUSE Build Service gives us two new things, however. One is a new set of tools that makes the "test, feedback, change, test again" and "try, change, publish alternate" workflows easy beyond belief (and the tools work on all major distributions, including *buntu, Fedora, Mandriva, Debian..). Plasma Netbook wins and that means our users win, regardless of the distribution they ultimately use it on.

The other thing using OBS gives us is another distribution joining in and getting involved. Instead of Plasma Netbook being theoretically available everywhere but only available in an "out of the box" configuration specifically for netbooks with one distribution (Kubuntu), it's now available "out of the box" for netbooks on openSUSE as well. I hope that number of out-of-the-box-for-netbook distributions continues to grow, and grow faster.

Testing and growth is precisely the reasoning behind the PNRP. It gives people something to play with and improve upon, but it also gives those who would package up Plasma Netbook a gage by which to measure what a Plasma Netbook release should look like (that's why it's called a ("reference"). This will only help to improve Kubuntu Netbook and will lower the cost of entry and raise the chance of success for any other OSV (or OEM) who wants to engage with Plasma Netbook.

Summary: we're working together with as many groups as we can to float everyone's boats higher. It's not a choice between one or the other, especially not when there is a "Help everyone!" option for us to choose.

Take a moment to take the Plasma Netbook Reference Platform for a spin and discover just how easy it is go get that thing on a USB stick and booting on your netbook. The ease of a live CD, the speed (and persistence between boots) of a hard disk install. Huzzah!

We Do More Than Chase Taillights

The community press is fairly awash with stories about Linux on tablets. Why now? The iPad. This is what we're best at it, isn't it: chasing other people's taillights. Ok, that's a bit dour and we are actually really good at creating new stuff too. But when someone else comes out with something great, we steamroll off with amazing momentum to react. The word "react" is an interesting one: it's the combination of "re", which indicates repetition (it can also mean, funnily enough in this context, "backwards"), and "act". While reacting is important in not letting Free software be end-run by the good ideas of others, we also need to be proactive. The prefix "pro" can mean this: "a prefix of priority in space or time having especially a meaning of advancing or projecting forward or outward".

The good news is that we are often proactive and there is a lot of interesting work being done in Free software. The concept of "activities" are big topic right now for us in Plasma, to pick just one example, and they aren't to be seen outside of Free software. There are many such examples to pick from, but there's something about our proactive work that fails us. After all, why aren't the MacOS or Windows fanboys railing on about the need for activities on their platform? (Ok, besides the fact that they are still a work in progress on our platform; but I predict when we ship them fully formed, that still won't change the answer.)

These companies do something we don't which we ought to be doing: not only are they proactive as well as reactive in creating technologies, they tell people about what they've done.

If the press, driven by our promotional efforts (across Free software, not specifically/only KDE people), spent the same effort publicizing our proactive efforts as they do our reactive ones it would be wonderfully (or painfully, if you are competing with Free software ;) apparent how well F/OSS does on the innovation front.

Defining Ourselves By Successes

We also need to learn how to define ourselves by our successes and see our failures as interesting, expected and required by-products of the road to those successes. There are people in the community who look at our success in countries around the world and discount it all as being "not relevant" because it isn't in the country they live in, and therefore conclude Free software has failed generally. Similarly when we talk about using KDE (or other F/OSS) software in production usage, instead of defining our successes and positioning ourselves in line with them we too often discount all possible usage of that software because of failures that affect only a portion of the market. This leads to us eliminating ourselves from entire market segments that we are perfect for just because we aren't (yet? :) universally perfect.

This would be akin to Apple telling nobody to buy the iPhone just because they don't feel they, as a company, are a great fit for the enterprise or that due to the lack of multitasking the iPhone is a poor choice for a variety of use cases. Those are both statements of truth, but that communication would do a great disservice to those whom the iPhone does work just fine for by preventing them from trying it. Now, if we made the iPhone we'd make double sure people know it wasn't ready for the biggest of enterprise usage and how our lack of multitasking is a "real issue that makes us not ready for production usage". Yes, we would be able to take the iPhone and destroy its potential success in the market. This in spite of many of the people I know who are "guilty" of this behavior thinking the iPhone is a great product, a feeling they have because they have been made aware of the benefits clearly and because it is a product, faults and all, that is clearly defined by its successes.

Note that Apple does not ignore (all) failings: eventually the iPhone OS will do multitasking. Nor do they try and say that it currently does indeed do multitasking. They aren't saints (I'm not a fan of their use of legal pressure and ultra-secrecy), but we can learn from some of the things they do well. I also love their approach to the enterprise by seeing sales to enterprise customers as "collateral successes". They don't perceive themselves to be a failure because they don't do well in the enterprise, they are a success because sometimes they win even in places they do poorly. Imagine if we had that same healthy viewpoint of F/OSS? There is no excuse not to.

So not only do we have to be proactive (as well as reactive) in creation, we have to be able to define ourselves by our successes and speak openly to the people who are well served by those successes.

Speaking Openly About Our Failings

In my opinion, the best place to speak about our low points is with each other, where "each other" is defined by "the people working on those things". This is how we can identify and fix those issues. I'm not advocating actively hiding them from the public, but talking with each other about them is the best way to see improvements be made.

When we decide that our first action will be to broadcast what we see as problems via, say, our blog we are setting up a very nasty situation, especially if we're talking about someone else's work. We may not have the whole story, and spreading half-facts or even incorrect information does not help anyone.

It reminds me of a story about a guy who was spreading rumors about this other fellow called, for ease of story-telling, Bob. Bob and the rumor monger have a discussion about the rumor and it turns out it was largely a misunderstanding. The guy apologizes for the misunderstanding and expects it to be all better between them from that point forward. Bob says it's more complicated than that, and to illustrate he takes the guy out to a bridge and brings along a feather pillow with him. Atop the bridge Bob tore open the pillow and the feathers blew in every direction on the winds that swept the river valley below. Bob pointed out that while he realized ripping the pillow was not the right thing to do, the feathers were still spread out everywhere and were now beyond his ability to get them back.

When we blog, we're ripping open a feather pillow into the Internet.

Just as important, when we discuss things between team mates in the context of the appropriate mailing lists, irc channels, etc. then we give each other the opportunity to respond without pressure and in context. People, being people, respond much better with greater performance with that kind of approach. If your goal is just to piss people off, then don't do such a logic, reasonable thing. If your goal is to see things improved, then discuss it with the people involved first. Then go blog about it and document the warts, but this time with accuracy and all parties aware of what's coming.

Of course, if you get ignored or the responses returned are indicative of being in need of a wake up call (e.g. there's denial at play) then maybe press the issue by taking it to a wider audience at that point. I've personally called various people to task in the past via my blog, but before doing so I try to ensure that I've first attempted (in some cases for months!) to get the issue dealt with either privately or in the appropriate context. There are times when the unfortunate is necessary.

In KDE, this is very rarely the case.

Read More

5 days and counting!

Plasma Javascript Jam: 5 Days and Counting

As is noted on the timeline page, the Plasma Javascript Jam Session is just 5 days away from being open for subsmissions! From the 24th on there is a one week window (ok, plus one day ;) for your submissions to come rolling on in to javascriptjam at kde.org. I can't wait to see the results! :)

Read More

The Plasma Netbook Reference Platform

What It Is

The Plasma Netbook Reference Platform is a Linux-based software distribution that gives you quick access to the KDE Plasma Netbook experience.

It's designed to be easy to get: If you have a 2 GB (or larger) USB memory stick and a device (laptop, netbook, tablet) that can boot from a USB stick, you are one download, two (copy and paste) commands and a few minutes away from having the latest build of Plasma Netbook up and running.

It's designed to be easy to get involved with: We are using an openSUSE Build Service project that you can not only use and monitor but which you can even modify in your very own "playground". You can share your changes with others easily and even request merges from your work back into the main project.

Why?

Testing Plasma Netbook, demonstrating the possibilities of it to others or even just simply using the latest builds has not been easy or reliable enough. The Plasma Netbook Reference Platform gives us the opportunity to build and deliver a quality example of Plasma Netbook that is constantly kept up to date with development. This will hopefully allow us to:

• test Plasma Netbook easily and reliably


• provide system integrators a reference to evaluate Plasma Netbook with, to compare their own Plasma Netbook offerings with and to work with us on improvements that they need/want to deliver to their audiences/markets


• support the growing Plasma Netbook user base in being able to easily get involved with testing, improving and demonstrating interesting, useful and fun modifications both to the upstream Plasma project as well as to other Plasma Netbook users

We were lacking a tool that could do all of this for us ... until now!

How To Get It and Get Involved

Here are all the resources you need to get started immediately:

• The project page on the KDE Community wiki
: this has all the step by step instructions and information you need to get involved as a user, an evaluator and/or a contributor.

• The OBS project page: the work is coordinated and happens here.


• #plasma-netbook on irc.freenode.net: real time communication with the developers


• plasma-devel at kde.org: development discussion via email

How We Will Measure Success

There are three very simple ways we will be measuring the success of the Plasma Netbook Reference Platform

1. Is Plasma Netbook improving in quality?


2. Is it more evident to our user and distributor audiences what Plasma Netbook can look and perform like?


3. Are more people using and contributing interesting improvements to Plasma Netbook?

A Personal Invitation

This is your chance to dive into the deep end of the pool the easy way, to get a bit closer to Plasma Netbook and the KDE workspace projects using an easy and exciting set of tools. Whether your aim is to evaluate, use or contribute I personally invite you to take the Plasma Netbook Reference Platform for a spin today, track where we go tomorrow and share your feedback and ideas of how Plasma Netbook can be tweaked to perfection.

Here's where you start, we're already there and waiting for you. :)

Thank Yous

Thanks to:

• openSUSE and Novell for hosting Tokamak 4 which is where this concept was finally able to come together, for their patient and extensive demonstration of the very cool OBS tools, and for helping us set up the OBS project itself.


• Marco Martin for being an amazing steward to the Plasma Netbook project.


• Qt Development Framework's support of both Marco and my own efforts.


• Every single Plasma Netbook user: you are who we do this for.

Read More

The Plasma Netbook Reference Platform: A Preamble

Whenever I was working on kicker back in the KDE 3 days, I was quite focused on panels and applets in the panels. It was a pain to test at times because panels can be in any number of positions on screen, they can be hiding (in various ways) or not, etc. Ignoring the repetition involved in testing, however, it was pretty straight forward development.

When moving from Kicker to Plasma I bit off a lot more to chew on, though I didn't immediately realize all the nuances of those decisions.(I probably have more to learn about them still, in fact. :) It wasn't until the 4.0 release was a few months away that the following aspect of it really set in: I was no longer creating one tool (kicker) that Someone Else(tm) would pick up and somehow cram together into a desktop environment, I was now working with a group of people to create a complete and coherent desktop shell that would encompass the run command dialog, the desktop layer, the panels, the window manager, system information ... as a coherent product. Yes, each piece still runs very nicely on its own and nothing is welded together at the seams (kwin, plasma-desktop and krunner all happily run without each other, for example), but they do support the user experience across those boundaries when run together as can be seen in how KWin provides more and more of the windowing effects used by plasma-desktop (such as the slide in and out effects on the panel).

Every time I press the volume up/down key on my keyboard and see the Plasma themed OSD I get that "oh yeah!" shiver; it's a very small and perhaps even inconsequential thing in and of itself, but it reminds me of what we're doing in the bigger scheme of things. :)

This hasn't been exclusively about KDE software on the desktop, however: a primary Plasma design goal is to be able to create any number of "primary user interfaces" with it and have them all be equally consistent and harmonious. Plasma Desktop was the first such asset we worked on, and in the process of making it we have brought various improvements to the desktop experience (and continue to add to them), but we have also created new kinds of primary UI shells. Netbook was the first "not a desktop" primary UI we made, and now mobile is coming along nicely. (Plasma Media Center is finding some new wind in its sails, giving me hope that it will see the light of my laptop screen eventually too. :)

This approach of creating multiple shells from a shared technology base, each of which is a "whole product" and unique from each other in terms of interaction concepts, has raised new new challenges for us. In years past I could just run Kicker (for example) on its own and ignore everything else that was going on during development and testing and never miss out on any useful information. Today, working effectively on (or with) Plasma Netbook, which has its own primary UI (plasma-netbook) as well as significant tweaks to the window manager and other tools, means running Plasma Netbook in its entirety. Only then can I really test it, understand it and appreciate it. We expect it to get even more tricky with other Plasma Workspaces that are being worked on such as Plasma Mobile.

This really came to a head for us a serious blocker as we find ourselves needing to be able to demonstrate, in context, what we're doing for:

• ourselves, so we can do more testing and define the development direction more effectively.


• existing and potential KDE distributors, so they can get an idea of what we're aiming for, what the bar for "success" is and whether or not they'd like to use it in new products they are creating.


• the tribe of users who circle the KDE community most closely, so they can quickly and easily try things out, know what's available (and why) and get more deeply involved with testing and feedback if they wish to.

Every challenge is an opportunity, and so it has become apparent to those of us most deeply involved that we could really use an "interactive reference platform" that can be used to show "this is what we mean when we say Plasma $SHELL_TYPE, and here's how you can quickly get your hands dirty with it". The technology preview that the Kubuntu community put together was really helpful in this regard, and we have decided to go even further with this approach and try to produce something even more collaborative, that can keep you even closer to the leading edge of development and which is even easier to get, to try out and to modify.

So it was that at Tokamak 4 the Plasma Netbook Reference Platform was born. With all the explanatory bits out of the way, the next blog entry will focus on what that is and how you can get it (and get involved) right now!

Read More

Plasmate 0.1-alpha2

I just tagged and uploaded a tarball for Plasmate 0.1-alpha2. Plasmate is our Plasma add-on creation tool and we're aiming for a summer release. Improvements since the alpha 1 release last month include not only a large number of bug fixes (thanks to everyone who tried it out and reported issues they came across!) but also some great new features, of which probably the most cool one is the online integration which allows you to grab a Plasmoid via GetHotNewStuff and instantly start working on it as well as upload your own creations using your opendestop.org account.

Download it and give it a whirl!

Read More

javascript, javascript jam updates

We are now just two weeks away from when submissions to the Javascript Jam Session can start to be made via email to javascriptjam at kde dot org. Exciting times! I've already seen some of the early entries and I think it's going to shape up really nicely.

To mark the "two weeks and counting" point, I've uploaded yet another Plasma Javascript ScriptEngine errata tarball. It should be usable with KDE 4.3 and 4.4. Enjoy!

Work continues to go into improving the Javascript Plasmoid API, with more and more of that work set to appear in KDE SC 4.5 as v2 of the API.

Today I committed a change that provides the ability to connect a DataEngine to any Javascript function:

unction myUpdateFunction(source, data) { print("in myUpdate") }

function myClass()
{
   this.count = 1·
}

myClass.prototype.dataUpdated = function(source, data)
{
   print(this.count++)
}

var myObj = new myClass
myObj.oddUpdate = function(source, data)
{
   print("huzzah! no access to the 'this' object, though.")
}

var label = new Label;

var svg = new Svg("tiger")
svg.dataUpdated = function(source, data)
{
   // a cute made-up example
   if (source = 'image') {
      this.imagePath = data['path']
   }
}

dataEngine("svgs").connectSource("image", svg)
dataEngine("time").connectSource("UTC", plasmoid)
dataEngine("time").connectSource("UTC", label)
dataEngine("time").connectSource("UTC", myUpdateFunction)
dataEngine("time").connectSource("UTC", myObj)
dataEngine("time").connectSource("UTC", myObj.oddUpdate)

.. and it all just works as expected. As someone who generally works with C++ this is all a bit magical. ;)

I've also added an interesting, at least to me, GSoC project idea to the KDE projects idea page: Javascript Test Suite. It's not particularly sexy, but it would be a great contribution to the future quality of something that is likely going to be increasingly important to us. I don't know if it would get a spot for sure if someone takes it on, but I'd root for it. :) There are some other interesting Plasma related ideas on that page, including a couple of cross-project ones, such as between Skrooge and Plasma.

Read More

awesome pastebin workflows

Robert Riemann writes about an awesome workflow for pastebin using Klipper. Very cool indeed.

Here's another awesome pastebin workflow: add the Pastebin Plasma widget (which is likely to get renamed to something like "Share It" in 4.5) and drag things to it: text, images, even files! You can also just middle click on it to paste the currently selected text. It then sends it to a pastebin on the Internet and when it's done it offers a nice little notification with the URL in it and can even pop the url into the clipboard for you.

Clicking on the widget opens the last pastebin URL in a web browser window and right clicking gives you a history (in addition to the usual configuration, etc.)

There is some documentation about this very cool Plasma widget on Userbase and someone even uploaded a screencast to Youtube showing it in action.

Huzzah.

Update: since it was a 30 second change, I made it so that when you trigger the pastebin wiget with a keyboard shortcut, it pastes whatever is on the clipboard. Fun.

Read More