Category: KDE

Note to self: Just blog, don’t ask Blauzahl if the picture is good enough, you can always fix it up latah!
Thursday night, I arrived in Kingston, Jamaica after a long, trip. Roger had hooked me up with Michael (who had, the night before also Jos had the pleasure to be Michael’s guest). Michael has been a very nice and caring host. He put me to bed after a marathon of something close to 40 hours without a bed (but the occasional 1-hour-naps on the plane). The plane had taken me from Amsterdam to London to Miami (insert bitching about U.S. customs here).
I arrived in Kingston roughly two hours late because there had been some fuel leaking into the engine. Apparently the crew didn’t feel comfortable to fly my last hop without having it checked by two groups of engineers. After an hour or so, we the problem was fixed and we flew over to Jamaica. Michael picked me up from the airport, got me some good food and put me to bed, which was needed after a long trip. Thanks dude for caring for me so well!
Finally, I had made my way to Jamaica.

The next day I slept in a bit and ate a large amount of really good fruit, including melon, sugar cane, grapes, … Then, Grandville, a friendly taxi driver picked me up to go by the University of the West Indies, to pick up Richard and Monika, two students attending CampKDE and some recording gear.

The next 4 – 5 hours, we drove from Kingston to Negril, a good 200km. The trip was mostly fun, we talked about music and Jamaica, I saw a lot of the inner-Jamaican scenery, we had some patties (Jamaican pasty stuffed with beef) and spicy shrimps on the way. When we arrived in Negril, it was already way beyond dusk, and most of the KDE folks that had arrived already were having foods and drinks near the beach. I met Dmitry here, who happens to be one the same racing team as Grandville, our taxi driver (not kidding!).

After the usual (but pleasurable) hugfest that’s inevitable when seeing all the people again, we went for a Plasma BoF in the sea (which was still nice and warm). Points of discussion were mostly the ZUI, its usecases, how it’s related to virtual desktops, and what we think we’d need to do to make it really usable. We also talked a bit about documentation issues, developer documentation for libplasma, documentation for scripting Plasmoids, and user-oriented documentation. Blauzahl told us that one problem of triaging Plasma bugs is that people often don’t really know what’s what and that the BugSquad in turn has a hard time to get useful bugreports. Something that can easily be solved with an annotated screenshots (this is the one that needs a better version).

Over new year, I’ve been playing around with Strigi and Nepomuk, which are
the two technologies around desktop search and “making sense of your data”. Strigi is the underlying library that is used to analyze all sorts of files and index those results. Nepomuk provides a semantic layer on top of this information, and a nice KDE API for easy integration in applications. While Nepomuk is only lately maturing, it shows some nice ways to interact with information on your desktop. Nepomuk uses RDF and ontologies to make sense of your data. It has the concept of types of data (think of a photo being an an image), and how those types relate to each other. It also stores metadata (for the photo example, that’d be size, camera model, and so on.

Nepomuk started catching my attention when I had been looking at a bug in krunner, that cropped up when the desktop search on my machine magically started working. It displayed too many results and kept the KRunner interface very busy, and sometime even made it crash. I’ve tried some tricks limiting it in a sensible way, but wasn’t really familiar with the workings of Nepomuk. Sebastian Trueg has fixed this bug last week, fortunately.

There are some caveats, when setting up Nepomuk. In order to get reasonably fast search and indexing, make sure your Nepomuk is using the Java JNI based Soprano backend (JNI is an interface to some Java functionality for C++). I am compiling KDE from trunk usually. Soprano sits in kdesupport and has two possible backends you can use, Redland and Sesame2. The former is C++ based, but it’s very slow. So in order to get reasonable performance out of Nepomuk, make sure the Sesame2 backend gets installed. For compiling it, I had to install the necessary Java packages — I’ve installed both the JDK and JRE. CMake apparently didn’t find this enough, when configuring Soprano, it still reported that it cound’t find the JNI, so wouldn’t compile the Sesame2 backend. I had to tell it explicitely where to find Java by putting the following into my .zshrc file:

JAVA_HOME=/usr/lib/jvm/java-6-sun

on my Kubuntu machine, and

JAVA_HOME=/usr/lib/jvm/java

on my OpenSuse machine.

After having it installed, you can configure the search in System Settings. The first run took pretty long, but after that, indexing doesn’t get in the way anymore and also doesn’t hurt performance noticably (i.e. having nepomuksearch monitoring). Also, the results I got from Nepomuk and Strigi where quite OK, even when limiting the search to only 5 seconds (which makes the first results display a lot quicker as well). In general, not having Nepomuk do endless searches is a good idea. :-)

Over christmas, I had been thinking how to integrate desktop search into Plasma, and started writing a small applet as interface to the desktop search. I’m not really fond of KRunner’s current interface. It displays too little information about the results, and looks a bit messy to me. We’ve already been thinking about possible improvements on the plasma mailing list, but with all the bug fixing around, we didn’t get to tackle KRunner’s UI in a way that makes it suitable to display results from a desktop search.
So I started writing an applet for Plasma, since nobody seems to have done this yet and called it Crystal, since that’s a cool name. Nepomuk actually made it very easy, with 300 lines of code (C++ even), I had a basic Plasma applet, including configuration to tweak the search, and the whole thing displaying results and opening those files.
I’ve committed the applet yesterday to plasma’s playground so others can have a look at this, too. It’s already quite nifty, but only very basic and totally not polished. Many aspects of the applet might change in the future, but it should be a good starting point to experiment with desktop search on the KDE4 desktop.

The applet can popup on shortcut
(I got this for free with the plasma configuration dialog actually) and pre-fill the clipboard into the lineedit. This way, you just select and copy a word into your clipboard, then hit some shortcut and press enter and dang! it searches for it. When the applet pops up, the text in the query lineedit is selected so you can also just start typing and thus override the pre-filled query (your clipboard or the default from the config dialogue). There’s no keyboard navigation in the list of results yet, and it doesn’t sort the results by relevance. I actually have a small patch that makes the SearchHitView sort by relevance, but it sometimes causes rendering problems, painting resulting items on top of each other. That patch essentially returns a rounded score for the items and makes KCategorizedView to order descending. I’ll have to investigate if that’s the right way to do it. Rafael (ereslibre) has some promising work on KCategorizedView in the pipeline as well. We’ll see where this all goes…

Codewise, actually searching and displaying results with Nepomuk is dead easy. Most of the important functionality is included in KDE 4.2’s kdelibs. There’s the QueryServiceClient which is what you use to fire queries into Nepomuk and retrieve the results (Nepomuk::Search::Result). The client is connected to a SearchHitView, which internally retrieves the hits from Nepomuk and puts them into the model, then updates the view.
The SearchHitView is from playground’s nepomuk-kde. It gives us models and view for search items, and has plugins for different types of files and result types. Here’s how this looks like in an example:

// Create a new client for the search
m_searchclient = new nepomuk::search::queryserviceclient( this );

// Search when the button is clicked
connect( m_buttonsearch, signal( clicked() ),
            this, slot( slotsearch() ) );

// ... also search on Enter in the search field
connect( m_editsearchtext, signal( returnpressed() ),
            this, slot( slotsearch() ) );

// Put new results in the SearchHitView
connect( m_searchclient, signal( newentries( const qlist& ) ),
            m_resultsview, slot( updateresources( const qlist& ) ) );

// Do something when the user clicks on a result
connect( m_resultsview, signal( resourceactivated( const qurl& ) ),
            this, slot( slotresourceactivated( const qurl& ) ) );

You’ll need two functions then, slotresourceactivated(QUrl url), which might be as simple as just KRun(url) in order to open the file (or url), and slotsearch(), which runs the query on the the string from the search lineedit. The plugin system doesn’t quite work for me at the moment, there’s an issue that a factory class always returns the most generic of the visualization plugins, making the results in the view look a bit boring. (The mechanism works fine in knepsearchclient, I dunno what exactly is going on there, deeply in KService …) I hope to get this to work quickly, also to get some more polishing applied to the plugins, and have them — based on their type — display more interesting information so you can quickly see if that file is the one you’re looking for. Also, displaying them at different sizes can reveal or hide some information, which is definitely useful and makes the user interface a lot more flexible. The code isn’t yet stable, and it needs some work.

Earlier on Sunday, richmoore blogged about a small class he has written to interact with MediaWikis. I’ve quickly took his code and put it into Crystal. Within an hour or so, I had Crystal display matches from TechBase along with the Nepomuk matches (albeit not correctly yet since the SearchHitView expects a bit more than a QUrl pointing to a random location (oh noes, our techbase is not random!). After a bit more hacking, Crystal now searches in Wikipedia, TechBase and UserBase for your search term. Display of the results is a bit better, but still not quite there yet. Something to sort out. :)

Some more ideas I have for the Crystal applet are saving of searches, for example to the desktop, a dropdown, or something so you can easily access pre-defined queries. Rich’s MediaWiki code also got me thinking a bit about the difference between searches on the web and on your desktop (other than “I don’t want everything I type submitted to Google“, of course ;-)).
It would be really good if applications started using Nepomuk more, although we see some interesting stuff coming up there as well, Gwenview has nepomuk based tagging and rating in KDE 4.2, for example. What I’d find useful is if applications started tagging files through Nepomuk automatically. It would be really useful to keep track of visited webpages, and have some information about that in the results of the desktop search. And of course Email. Tags for attachments from certain persons would be useful. Also there’s a small problem in the config dialogue for Strigi right now — you can’t enter directories starting with a “.”, and my email is somewhere under ~/.kde4/share/apps/kmail. That should be relatively easy to fix though. Mid-term Akonadi should be accessible in the same way.

And finally, I think we should put a searchbox into our file dialogue. During the redesign that has taken place for KDE 4.2, we left some free space in its top center, arguing that it make be the place to put a desktop search box. Sure enough the desktop search is fast enough (and I’m lazy enough) for me to replace most of the navigation-through-my-filesystem by simply typing the filename and choosing the correct file. The results from Strigi and Nepomuk are usually fast enough and correct. The file dialogue feels as a very natural for file search.

This is one of those “I write it on my blog so I can easily find it
back”
posts, that’s hopefully useful to someone out there.
For KDE development, I’m using git and git-svn to manage the codebase. Earlier today, I’ve merged a branch I had created over new year’s holiday. It consisted of 25 patches, some larger (implementing a new feature), some smaller, cleanups, but also some patches I wanted to keep separate for easier reference and review. I didn’t want to commit it to KDE’s SVN as one huge commit, but also not as 25, with a lot of those smaller ones that were more the “savegame” type of commit you do once in a while to easily get back to a “working state” when you’re about to break things or experiment.
Git’s rebase tool is what I wanted then. I’ve started off with my branch, counted it was 25 commits I want to restructure.

git rebase --interactive HEAD~25

Gives you a list you can pick commits from. Every commit is shown on one line, starting with the keyword “pick”. For commits you want to keep as-is, leave that line alone. Make it “squash” to combine this commit with the one on the previous line. Write “edit” to tweak the commit message. Just remove the commits you don’t want. Git will instruct you to do what’s needed, changing a log message, possibly solving a conflict. You pick up the rebasing process with

git rebase --continue

then. If you’re done, you can merge your branch, for example using “git svn dcommit” (do check with “git log”, “git show” and “git svn dcommit -n” first if everything worked OK).

Networkmanager is a daemon that keeps track of lower level bits on computers that have changing network hardware. It’s designed to do this dynamically, and exchange information about status with a user interface that acts as configuration UI and policy agent. Networkmanager has gone through a large redesign between the 0.6 and 0.7 version, including the necessary API and DBus interface changes. Not without advantages though. I personally didn’t really like networkmanager’s behaviour in the past, found it too random, too much getting in the way. Networkmanager 0.7 is better in that regard, it doesn’t drop my connection all the time for a start, it stays online while you log out and operates mostly within the bounds of what I deem sane.

One of the projects I’ve been working on over the last couple of months is the networkmanager plasmoid for KDE4. Will has put the infrastructural bits and pieces that are needed to work with networkmanager 0.7 into place. There is the networkmanager backend for Solid, KDE’s library for interaction with hardware, but also all the different configuration interfaces for all kinds of network access.
During development of the networkmanager plasmoid, I’ve often used the GNOME nm-applet. It does the job quite well and is a reliable interface to networkmanager. Something I find a bit confusing is that it offers two context menues, one on right click and one on left click. I often find myself looking in both until I’ve found the option I’ve been looking for. This also has to do with a limitation of the whole systray interface, which seems really outdated when looking at how we usually do these things in Plasma. As a matter of fact, nm-applet uses the GNOME keyring, which reminds me that it would be nice at some point to share this functionality (i.e. have it uses kwallet on KDE and keyring on GNOME). Right now when using nm-applet, I’ve two password stores that I need to unlock after login. I’ve also tried some other ‘wifi connection’ UIs. One, I’ve seen in Windows was particularly bad. It would ask the user to type in a WEP key (the long versions, often), didn’t offer any help doing this, but made it made it harder. You had to fill in the long HEX key twice, and both fields for that were password fields, so you can’t even see what you’re typing. It was just plain horrible. Quite a bit better is the interface of the iPod Touch (and presumably the iPhone). It does a good job on the input side (especially given that the user doesn’t use a keyboard but the touchscreen). It does fall flat on its face technically though. First, support for WPA2 is lacking, that rules out access to the network at the university, and supposedly many others. Then, it often reports that it has established a connection when it merely logged on to the access point, but didn’t get an IP yet. Since you can often connect to accesspoints (even encrypted ones) but don’t actually get an IP address, that information is often bogus and it can be quite annoying being told you’re connected, while you’re not. One of my favourite wifi settings UI is the one shipped with Maemo. While it’s nothing fancy, it gets the job done reliable and it doesn’t confuse me.

So one of my personal goals is to not make all those mistakes in the interface for networkmanager in KDE4. We’re not there yet, but progressing OK. Settings for wired and wireless start to work, as in “at least three persons on this Planet have ever been able to connect to a wireless network using it”. It has UI glitches, it’s not nicely streamlined for workflows we have in mind, the configuration interfaces are no beauty yet, and it has bugs, lots of it. It is in no way near release quality yet, more like an early Alpha. We’re trying to have a first working version out within the next couple of months, hopefully in time for the distros that ship in spring. So the applet won’t ship with KDE 4.2 we’re planning to release it individually so you (or your distro) can grab it in the meantime. We’re looking at putting it into KDE 4.3 then.
If you’re interested in hacking on it or just trying it, the current code can be checked out from playground. For this to work, you need to have the libsolid code from kdebase/workspace/solid installed. There are actually two networkmanager plugins, one is for networkmanager 0.6, one for 0.7. The latter one is the one we’re relying on. Yesterday, coolo started committing patches to the networkmanager plasmoid, scratching an itch. That’s pretty cool given that he’s one of KDE’s oldtimers. A true honour to share code with :-)

The beginning of this year in KDE was marked with the tagging and release of
KDE 4.0, followed up by the release event in Mountain View. KDE 4.0 has marked for the KDE community a stable base to build a kick-ass desktop and applications on. Over the past year, we see this effort paying off. Applications such as Dolphin, Gwenview and Okular are mature tools, powerful and userfriendly at the same time, speaking for the KDE4. With KDEnlive and Amarok 2.0 as their first KDE4 version, we see the more complex applications coming up. On the workspace side, new UI technology has matured, KWin’s compositing and Plasma give you a very smooth ride as well.

The development platform is paying off, it proves to be a very extensible and future-proof platform, more and more applications are becoming available on Windows and Mac, KDE on OpenSolaris is getting closer to inclusion in the distribution, and we’ve seen KDE already available on FreeBSD. New applications written in Python have entered KDE, and scripting support for many applications is becoming available as well, in the form of services in Amarok and scripted Plasmoids for example.

The development platform appeals to be very attractive to new developers as well. At the end of 2008, we’ll have welcomed 300 new developers in the project. The current activity in terms of commits to the KDE’s SVN, the ongoing bug frenzy and general polishing of KDE4 desktop and apps is amazing.

On the organisational side, this growth in the KDE community and the increased attention from both users and the wider Free Software community, has been balanced out by the launch of the KDE Forum and UserBase to improve communication across a wider community. The formation of the Community Working Group has worked out very well and has come far in smoothening out how we work together. The wide acceptance of the Code of Conduct is another successful chapter in improving the collaboration.

The opening of the KDE e.V. office in Frankfurt and employment of Claudia has been an important step, and are leading to a smoother functioning organisation in many ways. In 2008, many developer meetings have been supported both financially and organisationally and two larger conferences have been held in Mountain View and Mechelen, which scored the record number of attendees.

So what’s up next year? Personally, I’m hoping, actually being confident that in 2009 we see the rise of new technologies such as Akonadi, Decibel, integrated desktop search and the semantic desktop. I’m looking forward to seeing KOffice2 becoming available and maturing. Higher level concepts such as the Social Desktop will start to be integrated, and a wide variety of new and existing applications will make their way onto everyone’s desktops and mobile devices.
More imminent, there will be the second KDE conference in the Americas on Jamaica in January, and a smashing Akademy during the Gran Canaria Desktop Summit in July.

It’s been a smashing year, and we’re not even done yet.

I’ve been playing around with screencasting software for some time. My idea is, to provide a series of screencasts showing off different aspects of KDE technology. I’ve now mostly sorted out the technicalities and concepts, so I started recording some test screencasts. For the screencasts, I’m using recordmydesktop. I’ve chosen blip.tv a one means of distribution. Their web interface is nice and easy to understand. It offers a flash player, so it makes the content accessible very easily, but you can also view the Ogg Video version of the file, so it’s equally accessible for those preferring a Free format. Blip.tv also seems to have a reasonable understanding of licensing. They’re offering several creative commons licenses to choose from. I’ve chosen a relatively liberal license so the screencasts are easy to redistribute and use in other materials. Well, maybe not this first one, as I’m not yet a super hero in this authoring domain. To make things easier, I’ve not included sound. This pilot is about 10 minutes long. I’m using the fine Plasma notes applet to tell what’s going on, although I’m forgetting to scroll in the beginning, and somewhere towards the end, please bear with me — I guess that’s some sort of digital stage fright.

So this first screencast walks us through a part of Dolphin’s feature set. The different view modes, zooming functionality, tooltips, the cool selection mechanism (no ctrl-key!), shows how Dolphin integrates my USB stick and how you safely remove it, the Capacity indicator, the places, information, folders and terminal panels and how you can use them to make Dolphin fit your working habits. It concludes with a run through the configuration dialog. Enjoy!

So Matthew Garrett
dissects what he thinks powerdevil is doing wrong and gives a couple of point that
in his view, power managemers on the Free Desktop aren’t doing right at the moment.
Let’s have a look at Matthew’s points (I’m paraphrasing here for ease to follow,
hoping I’m not getting his points wrong):

• “Powersave is the wrong governor”. First of all, Matthew assumes that the setting “powersave” will actually use the powersave cpufreq governor. Fair enough, the label offers it as powersaving mode. The CPU governor in use though is not the powersave governor, but the “conservative” governor, which indeed is an “ondemand” governor, meaning it gives you the extra needed CPU power when you ask for it. As its name says, it’s slightly more conservative than the ondemand governor when scaling up. Matthew gets this wrong, but he’s probably misled by the label we present to the user.
  The “powersave” performance profile does more than just switching the cpufreq governor, it can also control your display’s power consumption (and in the future probably even disable animations all over the place so you don’t loose any of these CPU cycles for eye-candy).
• “Thermal management is not the job of a power manager”. True, mostly. Usually, it should be controlled by the BIOS. The default setting though is usually very conservative / safe. In general, we don’t want users to fiddle with the limits (at what temperature should your CPU cooler start spinning?). Powerdevil doesn’t offer such option, so Matthew will be happy about this item. (I don’t see how Matthew gets to think that powerdevil does poke into thermal management settings, so I guess Matthews point was more a general one in the first place.)
• “Presentation mode”. Something the app does indeed. We’ve discussed this on the hardware-devel list and came to the same conclusion. Again, powerdevil doesn’t offer an option for presentation mode to the user because it’s “an application behaviour policy” as Matthew tells us. I do agree. What Matthew is missing here is that PowerDevil manages those policies. It’s in fact the central place to do so in KDE 4.2. Apps will tell powerdevil that a presentation is running, powerdevil will keep track of all apps inhibiting certain PM features (screensaver, dimming, suspend, …), check other policies (e.g. “lock screen on resume?”). There’s no “inhibit suspend” button in Powerdevil though. Downside is that we have to rely on apps actually setting this cookie — which might or might not be more reliable than the user herself. So it might take some time until this feature in powermanagement on the Free Desktop works for everybody. (Until that time, you can switch to a power profile that doesn’t suspend / screensave in the first place. All happy. :)
• “3d takes more energy than 2d”. Might be true. From my measurements, however, facts are: a) KWin with compositing enabled does hardly spend “a significant proportion of the time on the GPU”. (In fact, it sleeps most of the time.) and b) KWin in compositing mode does hardly need any more energy than when compositing is off. (Again, results of my measurements, those might be off. I’d invite Matthew or everybody else to provide additional data points so we can improve our default setting to optimize its behaviour further.) Users can of course easily check this themselves. Run powertop with compositing on, measure your CPU consumption, switch it off (alt+shift+f12), measure again, compare. In my tests, results have been in the 1% – ‘hardly measurable’ range. If that’s different on your machine, configure powerdevil to automatically switch off compositing. If you’re findings vary from mine, let me know and we can further improve powerdevil’s set of policies.

Lesson learned: Check your facts before you publically dissect the inner workings of something that is as complex as powermanagement for a desktop system and that you’re obviously not familiar enough with to judge whether this piece of software gets it right or not. I’m assuming that Matthew does know *his* stuff (his general points are pretty much all sensible). Unfortunately his arguments in the light of powerdevil’s actual implementation are all strawmen. I’d have expected a more thorough analysis from Matthew.

I’d also like to thank Matthew for his input on these matters, and I’m glad it’s not as disheartening or dramatic as he tries to put it. In fact, reading his blog, I’m now even more confident that we have something that is both, in its default setting a very sensible system to manage power consumption while not getting in the way of the user, and also very powerful for all those cases where machines are just a bit different — so we’re also set to deal with a great variety of systems and usecases.

I’m on the train back home from ELCE (Embedded Linux Conference Europe) now. It was an interesting conference, not 100%, but quite free software-ish. Met a couple of nice people again: Adriaan (KDE + NLUUG), not quite surprisingly, Armijn (NLUUG + gplviolations.org), but also Will (KDE + Suse) who I’ve did a bit of networkmanager hacking with in between the talks, Shane (FSFE, FTF hero), Oliver Gravert (Canonical), Valer (NLNet) and others. Feels somewhat like home (which I wouldn’t have expected from a mobile / embedded conference in the first place). I gave a talk this morning, which I found quite interesting myself (that’s at least one person). I’ve talked about how to get KDE on a mobile device, starting with an explanation of the software stack and how those parts related to platform independence, moving to technical challenges when turning a desktop system into a mobile system (covering things like screen resolution and pixel density, input mechanism and the more limited hardware you usually find on mobile and embedded devices). People seemed interested although the room was not exactly packed. Also followed talks myself (Will’s to begin with, giving me a bit more insight into Solid’s networkmanagement stuff, quite useful if you’re hacking on that ;-)). Ow, and fixed two layout glitches in battery and networkmanager applet, not bad.

Tomorrow, I’ll be on the KDE-road again, going to Berlin to attend the KOffice sprint that’s held in the middle of cocktailbars and restaurants (a.k.a. KDAB’s office). But why? What do I have to do at a KOffice sprint? Well, one of the topics there is release promotion of KOffice 2.0, which I understand is due in the next months. I think KOffice is in a very interesting situation right now, and it’s critical to position it nicely now so it’ll have a bright future.
People that know me also might have heard me cursing about OpenOffice. Frankly, I don’t see OpenOffice having a bright future. The codebase seems rather convoluted (about as many lines of code as the whole of KDE — including KOffice) and because of its sheer size OOo is basically unmaintainable. Add to that what looks like a fork by the Novell team decided to publish as Go OOo, and a development model that’s pretty much entirely much based on one vendor (SUN or Novell, depending on who you ask ;-)), so community involvement is apparently down to a minimum. With devices becoming smaller and requirements regarding the user interface becoming more central in the Free Desktop ecosystem, I just don’t see OpenOffice providing a sensible answer to that.
Enter KOffice. It’s free, it’s lightweight, it’s cross-platform, its codebase apparently is rather clean, in short it could very well fit into that mobile “niche” as use cases are more limited on those devices anyway. So what’s needed to get KOffice in shape so that it becomes the serious contender? Frankly, quite some work still, in my opinion. First, it needs to work, a word processor, a spreadsheet application and a presentation program are the least I’d expect. so it makes sense to focus on those apps. Then, support for the most used standards, I know Girish is already working on getting OpenDocument support to work really well (absolutely critical IMO), but at some point, we’ll also have to look at support for proprietary formats.

That said, I think there’s quite the business case for a manufacturer seeking support for office documents in a certain product. So pitching KOffice to manufacturers in that market makes a lot of sense.

Then, there’s of course the platform-indepence thing looming. KOffice, as many other KDE application will be available on Windows and Mac OS as well. How does that impact how KOffice sees and shows itself, and to whom? And how do we do end-user support? We certainly wouldn’t like to burn credits by people that run into simple problems but just aren’t able to find a solution to their problem or support in general (be it community support or commercial support).

Another interesting angle is the “OOo reinvents MS Office so we don’t have to angle”. KOffice’s current user base is pretty small, so in turn, there are very little people who will complain when KOffice goes new ways (like Plasma did in KDE4), so I’d expect much less pushback when actually fixing the “Office UI”, making it a sensible interface that’s is a pleasure to use instead of something that drives me nuts the instant it starts (which is not really an instant in fact ;-)).

Simon, our worshippalicous python bindings hacker came by tonight for a bit of hacking (he lives across
the river from here, about 20 minutes by bike on a well OSM-mapped route. I was keen to get the new Python scriptengine Sime has just landed in SVN running so I can play around with Plasmoids written in Python.
The steps to get Python Plasmoids on running on your desktop are (assuming you have KDE from SVN installed): installing python, sip and pyqt into your development environment; building kdebindings, then you can build the plasma scriptengine located in kdebase. There are building instructions on TechBase.
Developing Plasma applets (which is pretty much the only thing you can do with the scriptengine right now, since there aren’t any applets written yet — except for the obligatory clock) is pretty easy from that point. You need to have a .desktop file containing some metadata and you actual script (which can be how ever long you wanted, it lands in contents/code/main.py and other .py’s). How you include graphics and more is well documented on TechBase, so I won’t repeat that here. To see if the scripting engine works, open the Add Applet… dialogue|Install new widget|…from local file. You should then see the scripting engine listed among the other options. In the future, we can make this part a bit nicer, installing and running and applet could be as easy as dropping it on the Plasma canvas and do the necessary security work. ll the needed information is already contained in the package.

This all is pretty new right now, and there are some rough edges here and there that need to be ironed out, but it basically seems to work at this point and is documented so we Pythonistas can get our hands dirty, with KDE 4.2 hopefully out of the Box.

The really exciting thing in my opionion about this is that with the scripting support, we can deliver full-fledged Plasma applets in Python. As they are scripts, it’s easy to deliver them in a platform independant way through webservices such as the OpenDesktop, KDE-Look and others or share them with your friends in other ways (hi JOLIE!).

As we all know, one can never travel enough. In that light, Kim, the supermodel that shares this life with me announced to me that she’ll be kidnapping me for a couple of days starting on Tuesday. We’ll not be going far, just far enough to get away for a bit and recharge the batteries. (Actually we’re running on solar energy and Port wine, but that doesn’t make for a common metaphor, so there you go.)
But fear not, I’ve taken precautions for this scenario, and the guys over at LinuxNewMedia have kindly helped with that. In the last and the current edition of LinuxUser Magazine, there’s a series about KDE4. It started last month with an article about Plasma that was the first part of a tutorial I’ve written. This month’s edition features a longer article that explains all the easy 129 steps you can follow to get to your own Plasmoid. There’s an example Plasmoids I’ve written for that article, it’s called Dr. Ade, courtesy of Adriaan’s promotion some time ago. (I’m obviously very proud of him — well, maybe it’s also the fact that we had this bet running. We’ve started off with one case of beer that I would give him. For every week I had to wait for his dissertation to be finished, he would give me one beer. Ade, you owe me two crates. No, I won’t forget that.) But I digress. Next month’s edition will conclude the KDE4 mini series of articles with an interview (again, with yours truly) about the future of KDE.
Me being away also means that you won’t hear from me in terms of email, chat, blog or one of the other ways we communicate (did I mention the new KDE Forum?) as for that occasion I won’t be taking my laptop, and I just refuse to write anything longer than a URL on those small devices that are taking over the lives of us geeks.
By now, you should have understood 3 points from this post: a) Don’t expect timely replies to emails sent to me next week, b) If you plan to sneak anything by my eagle eyes that I wouldn’t approve otherwise, concentrate on getting that done before next Saturday (instead of sending me emails), c) Go to your next store, buy Linux User magazine and start learning German (if necessary).