krunner doing just one thing

So here's a feature of KRunner than probably very few of you know about: KRunner can be made to query a single specific plugin for one search. You can even quite easily create shortcuts, both launchers and global keyboard shortcuts, to trigger this behavior. This feature was added some time ago by Jacopo, but it's rather well hidden unless you know it is there or stumble over it accidentally.

If you've played with KRunner, you probably have found the configuration where you can turn plugins on or off by pressing the left-most button with the icon of a wrench/spanner tool on it. This is something different, however.

Here is KRunner searching only for Applications on my machine:

Here it is looking only at command line operations:

You can do that with any of the following plugins (by plugin ID) in 4.7: recentdocuments, org.kde.windowedwidgets, locations, kabccontacts, bookmarks, org.kde.activities, solid, webshortcuts, shell, services, PowerDevil, wikipedia, nepomuksearch, desktopsessions, windows. This is accomplished by having a Runner plugin which either can match whole search terms or which registers a default syntax using AbstractRunner::setDefaultSyntax(const RunnerSyntax &). As long as the Runner plugin matches one of those criteria, then this line in the .desktop file for the plugin makes the magic happen: X-Plasma-AdvertiseSingleRunnerQueryMode=true. Unfortunately, in previous releases only a handful of plugins were marked this way. I've fixed this for 4.7.0 however. :)

To trigger the "single plugin" behaviour, you can create a launcher on a panel or desktop that calls to KRunner via D-Bus like this: "qdbus org.kde.krunner /App displaySingleRunner nepomuksearch". To get a list of possible values for that last entry, try this from a konsole: "qdbus org.kde.krunner /App singleModeAdvertisedRunnerIds".

The other way, and perhaps even more convenient, is to open the global keyboard shortcuts panel (type "global key" in KRunner :) and go to the Run Command Interface selection in the drop down box at the top of the window:

Then you can assign a keyboard shortcut to your favorite plugin. This means that you can, for instance, turn Nepomuk searches off in the main KRunner config and only when you want to search the files on your disk press the key combo for that runner. The rest of the time, the Nepomuk (or whatever other plugin you turn off in the KRunner config) won't be queried for normal searches done via Alt+F2 or "Run Command" from a launcher.

Pretty sweet, huh? :)

Read More

Platform 11

Tomorrow I will be getting up at around 7 AM, along with Marco who has been at the house here for a couple of days, and going out to the airport. However, I won't be taking an airplane. I will be meeting people coming in from all over the place (well, Europe and the Americas, anyways), handing them train tickets to a little town called Randa and making sure they get on the train successfully.

It's not particularly glamorous work and to be honest, I'm not particularly looking forward to hanging out at the airport for an entire day. There is some upside, though: I'll get to see friends, new and old, as they arrive to join one of the four sprints happening in parallel over the next week in the Swiss Alps. It's nice to be able to lend a helping hand in making these events go smoothly and be able to spend time with them.

I'll be leaving with the last group of people in the evening towards Randa to participate in Platform 11.

If you want to read about what we'll be doing at Platform 11, check out Sebastian's blog on Platform 11 from earlier today. He does a great job of explaining it all.

I have no firm predictions as to what the results will be. That's the whole reason for the meeting in fact: we have a good idea of what the questions are, but to make progress towards the answers we need to huddle together with some 60 other people in a secluded village in the mountains and work it through. I have complete faith, given the people who will be there and the results of past events, that the results will be worth every minute and every penny spent. We'll keep everyone informed with daily blogs on planet.kde.org, "live" blogging on identi.ca using the #randa hashtag and with a wrap up summary on

Read More

Posted in | No comments

libplasma2

I've spent a fair amount of time this month working on shaping the libplasma code into what will eventually become libplasma2. The goals are straight-forward:

• Drop cruft


• Smooth out API issues that have cropped up


• Separate QGraphicsView code out into a separate library, clearing the way for QML-only Plasma interfaces to not have to carry that weight


• Make parts of libplasma more QML-friendly than they are currently

The motivation for these changes is based on the history of the library, which grew over the last couple of years in response to changes in Qt (the biggest being the arrival of QGraphicsProxyWidget which was first used in the KDE Platform 4.2 release) and the needs of the increasingly sophisticated applications using libplasma.

One example: As activities shaped up and have become integrated with Nepomuk, KWin and other apps, the classes in libplasma meant to help track activities in relation to Containments simply stopped making sense.

Another example: the rise of QML has made QGraphicsView things optional rather than required. We don't want to do any massive porting or rewriting, so we'll be creating a new library with all those pieces in it. Components that use QGraphicsView things will need to link to that library, but otherwise little changes.

This will be our first big break in libplasma since the KDE Platform 4.2 release, but we're trying to keep it relatively tame. So far all deprecated methods have been removed, needlessly reimplemented methods (usually because the need for the reimplementation was lost over time) are all gone, unused classes have been removed, slots that were being used as a "poor man's" virtual method have been switched to actually being virtuals and some API blemishes have been cleared. The ability to verify signed packages using GPG has also been added.

Next up is a merge of Package, PackageStructure and PackageMetadata into one class, with most of PackageMetadata actually being discarded. Then the QGraphicsView separation will get underway.

Further on, there's hope that some refactoring of DataEngine will also happen to make them easier to use from QML as well as to make them safer to use from C++ (e.g. no pointers). More of the enumerations used in libplasma will probably move into a QObject, so that while little or nothing will change from C++ we can more easily import them into QML and Javascript.

Changes to the public API are being documented here as they happen. There are still several months of work to be done on this, and we're trying to keep the impact low with the mantra of "source compatible if at all possible" constantly on our lips. We don't wish to break plugins or have to touch code that is finally becoming mature in plasma-desktop, plasma-netbook, etc.

The development is happening in the libplasma2 branch in the kdelibs git repository with discussion happening on plasma-devel at kde.org and in #plasma-devel on irc as usual.

Read More

Plasma Active: Marble To Go!

(Note: This post is about Plasma Active, a community collaboration to bring KDE software to consumer devices. To learn more about Plasma Active, read this blog post.)

What is an Active App? It's a project built with Qt and/or KDE libraries that fits into the spirit and use cases of Plasma Active. That means it needs to be touch friendly, preferably present the user interface with QtQuick, have a nice separation between data and visualization where appropriate and integrate well with the platform.

In the Plasma Active meta-project, which includes things like Contour and live OS images, we're building up a small army of such apps in the hopes that those projects can learn from each other and us from them. It will also help ensure that when someone goes to use a Plasma Active device, they don't just have the Contour user experience but also a host of useful stand-alone applications as well.

I announced our first Active App a couple weeks back: Calligra. Today, we add another to the books: Marble!

Marble has already had a mobile version for some time, and since mapping is very important functionality for devices you carry around with you it was only natural for Plasma Active to meet Marble.

There is a project going on right now to provide a QtQuick interface to Marble, and we will be including this effort in the live images as it matures.

Read More

Plasma Active: Quick Catch-Up!

(Note: This post is about Plasma Active, a community collaboration to bring KDE software to consumer devices. To learn more about Plasma Active, read this blog post.)

We've been a bit quiet lately around the Plasma Active farm. This is mostly due to us being rather busy, both with technical as well as organizational tasks. On the technology front, things continue to plow forward at a very brisk pace with Contour shaping up with every passing day and libplasma2 (a big part of the Plasma Quick track) zipping ahead nicely.

Organizationally, we're learning new lessons every day as to how to best coordinate efforts between companies currently involved and reaching out to ones that should be involved. Basyskom sent a bunch of people to the recent MeeGo conf, and the response was fantastic, including some bloggers writing about the demo that was on offer.

There's also been some learning-as-we-grow happening that has hampered outbound communication somewhat. For some of the people involved, this is their very first open source experience. For others, this is their first foray into the interesting world of devices. While it is terrific to expand our merry band of freedom makers, it also has meant some learning curves.

Amongst all that, code is getting written, the user experience design continues to mature and new operating system images are being spun. All is good in the land of technical progress. Marco is hanging out at my place for a couple days prior to the upcoming Platform 11 meeting (which starts Wednesday) and we're getting some work done at a nice pace. Today we're working on Share-Like-Connect and building integration points in Contour for it.

I am, however, behind on posting news about new Active Apps as well, which I'm going to remedy in a moment.

Read More

relax :)

After my last blog about a possible future KDE Platform 5 due to Qt 5, it was interesting to watch the number of "Oh no, not another big release that will break the interface we know!" type comments. Let me put all of that to rest:

The Plasma team has no intention, desire or need to start "from scratch" nor engage in a massive redesign of the existing netbook or desktop shells.

One of the goals of Plasma from the start was to design a framework which would enable us to preserve work in the future. I was at the time quite disheartened that the design of kicker was so inflexible that, as good as it was, to make any sort of real changes to it would essentially require a rewrite of the whole thing. Even if it had been done piece by piece, at the end of a long development process there would have been no original code left. I went through the code and marked it up by hand to discover this. Keeping in mind that Kicker and KDesktop themselves were rewrites I was shocked, and so set out to create something that was flexible enough and free of internal assumptions so that we'd not have to "start over" again.

Fast forward to today and we have a robust framework with very few internal assumptions about what a primary user interface looks like. That's why we can use it for a desktop, for a netbook, for a tablet, for application dashboards and all the other projects people are building around it. Even as Qt has jostled about we've managed to keep Plasma bits coherent and avoided rewrites. Code that hasn't been touched in a couple of years in plugins and the shells themselves still works just as it did, and more importantly when we wish to add to that code it isn't difficult or time intensive.

Also keep in mind that Qt5 is set to be a "non-disruptive" release. It is mostly about cleaning up performance issues, focusing on QtQuick and improving the modularity of Qt. This will end up affecting binary compatibility, but source compatibility will remain largely in tact, especially for modules considered 'done' like QWidget based things. That means we are not compelled out of necessity to rewrite fundamental bits of our apps as we were with Qt4.

I expect there to be work to be done in the build system to reflect however Qt ends up being broken up into modules as well as a lot of work in managing the new QML2 and QScript work, something we've already started preparing for in Plasma. Otherwise, things shouldn't be too disruptive and I'm really looking forward to some of the performance improvements that will result from the Qt hackers really going "full steam ahead" on making Qt even more lean and mean than it is now.

One more important thing to consider is this:

This isn't going to happen tomorrow, or even this year.

Qt5 isn't scheduled until 2012. No release date has even been set. The release planning is still happening, but they've announced it this early so that we can all get involved. Qt being openly developed isn't just a story, it's a reality and Qt project management is putting their actions where their mouth has been. Bravo!

This means that a KDE Platform 5 can't happen any sooner than that. The earliest date that has been suggested thus far on the mailing list for a first KDE Platform 5 release has been January 2013, and even that may turn out to be "too quick". We'll see, but we have at least 2 more 4.x releases, and I would not be surprise at all if that turned into 3 or even 4 more.

As we cast our eyes out into the future by a couple of years, we are also keeping our minds on today and will continue working the 4.x code base. After all, it is what will become the 5.x code base. :)

I hope that puts some concerns to rest. As you can see, the KDE developers share pretty much all the same anxieties as you do about such a big release and are more than content to "just" deliver a more performant, more reliable, more featureful, more device-friendly version of our existing Platform and Workspaces. We've worked really hard to be able to say that, and will continue to work hard to take the next steps forward toward meeting those goals. :)

Read More

Qt5 .. KDE5?

As most of those who read my blog have already heard, Qt5 is on its way. The target is 2012 and the focus is QtQuick where there is a high degree of separation between display and data and things are rendered using a hardware accelerated (read: OpenGL) scene graph. This is very much in line with where we are heading with Plasma as well. Exciting times!

What does this mean for KDE? Will there be a KDE5 in 2012 as well? What would a KDE5 look like? I know these are the questions on some of your minds, if only because some of you have already started asking myself and others about it. ;)

The short answer is that we don't know yet, but we're working on it. Not a very satisfying answer is it? Well, short answers are rarely much fun. So here's the slightly longer version.

Some of us have known for a while that Qt5 was brewing. The decision to start on libplasma2 that focused on QtQuick and moved away from all things QWidget was influenced by this knowledge. Thankfully, with Plasma's emphasis on Javascript, data/visualization divisions, use of OpenGL and more recently QML, we're in a good position to follow the Qt5 flow as it comes. We're already discussing on the mailing lists how to get involved and what issues will be most important to us. We're quite excited that Qt5 is going to be developed in the open, as this should give us much more influence in and foreknowledge of decisions that get made.

However, Plasma is not KDE, it's just one part of our rather large ecosystem of software projects and products. The biggest impact that a Qt5 will have is on the KDE Platform itself, since the library infrastructure relies on working well together as one cohesive unit. As Lars pointed out in his blog entry, the focus for Qt5 is to not disrupt the application developer by changing the API, but rather making performance oriented changes that result in the binary interface, or ABI, changing. For most applications, that will mean recompiles and possibly some source level tweaks here and there.

For some, however, it will be a little more drastic. Qt3Support will be gone, which means KDE3Support will almost certainly die along with it. If your application still relies on the Qt3- or KDE3Support libraries, this is a wake-up call to address that.

The current plans for Qt5 mean that, unlike Qt4's reinvent the world approach (which was needed, if painful), it will be evolutionary and far less disruptive. This is the good news.

I also see this as an opportunity for KDE's own libraries and runtime that form the KDE Platform. We don't need another big re-engineering of the base technologies as we had in KDE4, but there is a lot of opportunity to improve how the pieces fit together. Since Qt will be breaking ABI, KDE's own libraries will also have a new, binary-incompatible signature when compiled against Qt5. That means we have the opportunity to clean up things that require breaking binary compatibility.

Often this doesn't require affecting source compatibility. For instance, the other day in the libplasma2 branch I removed a data member in a public class that shouldn't have been there in the first place. This is binary incompatible, but doesn't matter one bit from a source compatibility perspective.

Some changes will likely affect source compatibility, however. KDE's UI and KIO libraries both need some hard changes made to them. libkdeui will need to split out platform, QWidget and generic components. KIO needs a similar split between platform bits, QWidget-centric UI and business logic bits. We need to think about how to reform the KDE Platform so that it is not only possible but easy to create builds for devices with less storage or targets where QWidget simply won't exist in the future.

The best news is that in just a few weeks, dozens of KDE developers are coming together in Randa, Switzerland to work on these issues at the Platform 11 meeting. The organization for this meeting actually started towards the end of last year, and the timing really couldn't have been better.

Today we stand with a bright future ahead of us, with Qt growing leaner and more modern and appearing on more computers and more devices every day, but we also stand with a number of open questions. We don't really know the details of what KDE Platform 5's libraries will look like. We do know it will be an evolutionary release, much like the transition from KDE2 to KDE3 was, with significant improvements. We will be grappling with those unknowns in the Alps, well away from distractions and surrounded by natural beauty, and we will start to draft those answers. A couple of months later we'll be in Berlin to come together at the Desktop Summit and push it yet further forward. We should, by then, have some very clear ideas of what the next year of development towards Qt5 and an eventual KDE5 will entail.

Personally, I can't wait. Perhaps because I remember how KDE3 polished the raw materials of KDE2 into a high gloss finish and can see the same patterns emerging here again. :)

Read More

another git wiki: ikiwiki

On my previous blog entry about gitit, a wiki that uses git to store and revision all its data, a fellow named Richard commented:

"Why not ikiwiki? Actively maintained, lots of plugins and works as a blog engine so you don't have to use blogger.com ;)"

My answer was simple: it hadn't shown up in searches I'd done. I probably share some of the blame for that, but it also highlights that as a F/OSS project getting the word out and making sure you are prominent, particularly for common search queries, is important. In this case, I missed ikiwiki, but Richard made sure that didn't last long. ;)

I managed to find some time at the end of a long day yesterday to toy with ikiwiki and since I had spent time writing about how great gitit is (it really is! :), I figured it would be nice and fair to at least try ikiwki and report back.

Here is my verdict in summary: it's an excellent tool, far more capable of gitit, but also comes with a lot more overhead in terms of setup and management. It is a classic trade off between power and ease of use.

ikiwki requires an investment in time to set up. If you are running Debian, there are packages for it, otherwise you'll be installing lots of perl modules (thank goodness for CPAN!) and reading the not-as-coherent-as-it-could-be documentation on getting it set up. I felt a little like I was building Plasma Desktop from scratch at times with all the dependencies. ;)

Once ikiwki is set up, you next need to ensure the webserver is set up properly. Unlike gitit, ikiwiki does not provide it's own web server, which is not a bad thing. It just means it's one more bit of software to configure. Thankfully, other than a missing ExecCGI directive, openSUSE's apache2 install is perfectly set up to host ikiwkis in your home directory.

Then there is the configuration. Richard was right, ikiwiki has tons of plugins. Which means choosing which to enable and which not to, and how to configure the ones you do enable that have configuration options. Thankfully the setup page is available via the web interface itself, though the configurations options are often rather cryptic. I wasn't sure what some of the things did, but with some experimenting I figured it out. (Flashbacks to KDE software from the KDE2 or 3 days. :) One thing to keep in mind when trying out ikiwiki is that it looks horrible by default, but if you just put "actiontabs" in for the theme plugin configuration it looks far more sensible.

For the investment of time you get a wiki with full text searching, caching, templates, tags, link tracking and all sorts of other goodies. It does have it's flaws: the management UI is nothing to write home about, the permission management is primitive and the documentation could use some help. ikiwki stores the pages in markdown, but doesn't seem to provide conversion utilities to other formats (other than HTML, of course), but you can easily use pandoc for that.

However, with ikiwiki you do get a very capable, light-weight wiki suitable for group editing and all backed by git for easy replication and interaction behind the web interface, and that could well be the killer feature for ikiwiki: a git backend with lots of features on top.

So now I have not one but two great tools to choose from: gitit when I need something fast to set up and easy to use, and ikiwki when I need something with more features. Got to love Free software. :)

Read More

gitit

After finding myself rather behind on a few different things I'm working on, I spent some time this weekend thinking about how to better order some of the things I'm doing. It seems this is a theme for 2011 so far, what with Plasma Active moving to iceScrum for project management and other similar events.

One thing that came to mind is that I'd could probably really use a personal wiki .. or three. Of course, I'm a picky sort of person and had all kinds of requirements in mind which I was fairly sure I wouldn't be able to find all in one tool. Essentially, I wanted something:

• similar enough to editing a Mediawiki-based wiki that it didn't feel too alien


• that can be set up in a matter of minutes


• that used git for storing the content so I could easily carry it with me on my laptop, but then sync it to a server somewhere without pain


• could host multiple wikis side-by-side

I search the Internet using variations on the search phrase "git wiki" (e.g. "git backed wiki") which gave me all kinds of results that had nothing to do with what I was looking for but, thankfully, also a small handful of links that were on target.

The first two options I found and tried left me feeling empty: they were featureless and not actively developed. Then I found gitit by John Macfarlane.

At first my heart sank: it was written in Haskell and looked to have some sort of arcane install process. That was just my ignorance speaking though, as I soon found that OpenSuse's warehouse of packages gave me quick access to everything needed to get gitit up and running. The most important bit was a tool called "cabal" that does all of the heavy lifting for you. After doing the "one-click" install of cabal (which ironically took more like a dozen clicks), it was installed and ready to run.

After adding the ~/.cabal/bin directory to my $PATH, I made a directory for the wiki content, ran `gitit --print-default-config > gitit.conf`, edited the config file (setting a title, changing the default port; it's very well documented) and then started the wiki with `gitit -f my-conf +RTS -I0 -RTS`. The latter bit of line-noise is to make Haskell behave nicely and not constantly run the garbage collector and thereby kill my laptop battery; I got this jewel from the gitit documentation which is very nicely written in my opinion. Creating a second wiki was as simple as reproducing those steps.

Best of all, going into the wikidata/ directory and doing things like `git log` gave me exactly what one would expect. It feels like a wiki via the web browser, but it's doing git magic in the back. Just like Plasmate does. Is this a part of the future of content-centric software?

I do miss templates from mediawiki, but other than that all is good: easy editing, page history, discussion pages, file uploads, user accounts, etc. It does lack a lot of features Mediawiki has, but I need none of them (save, perhaps, templates). It uses Markdown by default (though you can use various other markup styles, including something call "literate Haskell"), but can export to a myriad of formats including Mediawiki markup, HTML, LaTeX and what not. This part is all powered by another of John's projects: pandoc.

Performance wise it is instantaneous on the laptop (as one would expect) and does support things like caching pages and sitting behind a proxy web server. I haven't bothered to set up either feature as I don't need them, but how to do so is described clearly in the gitit documentation. The gitit process is currently taking ~8.5MB of resident memory and sharing another 25MB and idling, as one would hope, at 0% CPU usage so I have nothing to complain about there either.

I'm very happy to have found such a tool, all nicely GPL'd and everything, that performs like a champ and has absolutely zero lock-in thanks to the usage of things like git (for data management) and pandoc (for content format management). If you've been on the look-out for a similar tool, I heartily recommend checking gitit out.

Read More

Plasma Active: New OS Image Available

I'll be leaving Tokamak 5 and Nijmegen in just over an hour, but before I head out the door some good news by email arrives: it's time for a new OS image according to the Plasma Active OS track schedule, and so there it is: v 1.0.70.

If you are following Plasma Active, download the image and see what's new. If you aren't following Plasma Active yet, what are you waiting for? Go to the install wiki page and get rocking.

We unfortunately don't have a coordinated change log for this release which includes all the improvements made in Plasma Quick and Contour over the last couple of weeks, and that's something we'll be working to improve as part of the process in the coming iterations.

Feedback and participation, as always, are welcome. Join us in #active on irc.freenode.net or the Active mailing list.

A big thanks goes out to our friends at open-slx for driving Balsam forward and helping hit our next milestone in the OS track!

I'd also like to thank those who have joined in from the openSUSE community, such as Will Stephenson, to work alongside the Plasma team on packaging issues. Growing the community of packagers and operating system enthusiasts around Plasma Active is great to see.

Read More