Hi there. In order to keep the tradition, an introduction in this first post. I'm Raphael Kubo da Costa, a 20-year-old Computer Science student at State University of Campinas, Brazil, and also part-time employee at ProFUSION Embedded Systems (a very nice place for any free software developer, I'd say).

My first contact with KDE as a developer was in 2006 when I sent two small patches for Konversation. Curiously and frustratingly enough, when I started university in 2007 I found myself with much less time to dedicate to my own free software interests than before -- even though I did to go to the International Free Software Forum that year and happened to be one of those "new and interested developers" to whom aseigo showed off the soon-to-be KDE4.0 desktop on the exhibition floor.

Since the beginning of this year I've been contributing to KDE in a few different fronts: I do some occasional bug triaging and commits to kdelibs, but most of my KDE time is spent maintaining Ark, our old and beloved file archiver, with Harald and helping the KDE-FreeBSD team (I'm not a full-time FreeBSD user, although I'm writing this post directly from FreeBSD 8.0-RC3). So expect me to write more about these activities in the future.

Now let's try to make this post a little less "hello planet-ish" and talk about Ark, KDE's file archiver which lives in kdeutils. I believe it's one of the longest-living programs in KDE (the first commit shown by svn log is revision 12097, which was actually a CVS commit and dates back to the end of 1998). It has survived our four major releases and has had quite a few different maintainers (curiously enough again, most of them were Brazilian).

So what's the state of Ark today? As I write this post, Ark's bug count in Bugzilla is at 72, which I consider a small number to be honest. However, we have been mostly in bug fixing mode for at least a few months, and some bugs need pretty big changes in code to be properly fixed. Being a university student, working (even when it involves using Qt) and also having a life means I don't have that much time for big changes at the moment, and neither does Harald, who's also losing his hair to graduate from university.

I don't want to end this post in a negative mood, though. So my dear reader, you have been watching the KDE "scene" for some time, you would like to contribute and you don't know where to start. Well, Ark needs you! Despite its age, Ark has a small code base, and both Harald and I are (presumably) nice guys and we are more than willing to help you. And you, my dear reader who already contributes to KDE, how about doing something completely different?

> Read More... | Digg This!

Oh, yes, just in case you haven't noticed, it's out. However, since I maintain this image of seriousness, purposefulness and so on (which I only occassionally spoil by something like doing strange things to my hair, eating way too much icecream or doing silly things at SUSE outdoor events), I would like here to reference the KDE release notes for openSUSE 11.2. We recalled at least the Pulse Audio thing a bit too late, so maybe right now the actual release notes do not mention it yet.

Default Web Browser - yes, we default to Firefox with KDE integration, see the notes for switching back. Nothing more to say here, if you still don't know about this, you apparently don't know about KDE and openSUSE (in which case you're kindly asked to fix that ).

KDE3 - boy, I'm getting really tired of this topic . It's really simple: Apparently there is nobody caring about KDE3 enough to do something about it. So, if you are in the minority that still doesn't find KDE4.3 good enough as a replacement, either just stick with an older release, or try to use the unsupported KDE:KDE3 repository, which right now looks like it still builds, but may not anymore tomorrow if anything changes, since, as I said, everybody feels like having more important things to do than spent time on it (really, we tried to find people who'd be interested in it, but apparently all people capable of doing so already work on KDE4 or are too busy complaining on mailing lists). So, just get over it. KDE3 is dead. It is no more. It has ceased to be. It has expired. It is an ex-KDE3. (Thinking of it, I will skip that is has gone on to meet its maker, just in case).

Strigi/Nepomuk - they are disabled by default. With Beagle not enabled by default being asked a lot for, and generally considering the situation, we decided this would be a better option (and upstream wasn't really against). Those who want them enabled can easily do so in systemsettings. Well, almost - unfortunately a problem slipped in that prevents starting Strigi in default installations. See comment #6 in the #548007 bugreport for an easy fix.

PulseAudio - since KDE not only does not have a hard dependency on PA but also there is basically no integration of PA, having PA with KDE doesn't buy anything to most users, so we decided to disable it by default in KDE installs. This is not the broken PA that was in 11.1, but still, why force it unnecessarily. Those that have a use for PA need to enable it in the YaST Sound module (note that this includes everything running on a system that has KDE as the default desktop).

Now, onto the goodies!

> Read More... | Digg This!

Now that the mention of the Firefox KDE integration I've done has reached also the dot, I guess it's time for a couple of things that don't quite fit into an article but I should probably say them somewhere anyway.

First of all, this is nothing against Konqueror. I still use Konqueror. In fact when a couple of months back there was a wave of "let's ditch Konqueror" voices on the planet and kde-core-devel, I was one of the people opposing that (and I still think it's not an option, as Konqueror is still the best KDE browser there is - Aurora is Qt-only, Rekonq is at version 0.<somesmallnumber>). For the next openSUSE release we will evaluate the possibilities again and Konqy may end up as the default again if it's considered to be up to the job. Speaking of which, Konqueror has never really been 100% default in openSUSE, as the desktop icon, which is what the common user uses, has always been Firefox, so we can also say the we just fixed the inconsistency (and it's really simple to switch it back). But the real reason was that many people are simply not satisfied with Konqueror, so we decided to try to not ignore the reality for a change. I myself use Konqueror, but if somebody else wants to browse the net on my home machine, they get Firefox. I don't like this, but what the hell, c'est la vie.

So, when we decided to make Firefox the default, we also faced the problem that we switched to something that from KDE user's point of view sucked in pretty much all aspects except for the browsing itself. The idea of Firefox desktop integration on Unix ranges from not bothering with it at all, over using generic not-really-desktop stuff like mailcap, to thinking Unix==GNOME. Normal Firefox in KDE offers to open PDF files with Evince, shows /usr/bin in a filedialog when you decide you'd like to open the PDF in some other application, has inconsistent (not just reversed) button order in dialogs and other yummy things. There have been attempts to solve this e.g. by creating a Qt version of Firefox, but those AFAIK have never led to something usable in practice, and with WebKit now part of Qt I somehow fail to see the motivation for anybody to try once more. And in this situation we had just a short time before openSUSE 11.2 feature freeze.

The trick, of course, was using magic. The Firefox with KDE integration is still the same Gtk Firefox, just with a bunch of hooks calling an external helper. I don't have the ability of some other KDE developers to have clones, and I'm not crazy enough to try to mix Gtk and Qt in one process (which, despite the possibility of a shared event loop, should be nowhere near trivial). So it's nowhere near the extent of the Qt port, and maybe that's why it has worked out (as we all should know, perfect is the enemy of good).

The helper and the patches at available in a Gitorious repository, they are made to match the openSUSE package so they may not possibly apply cleanly to upstream sources, but feel free to play with it. Actually, you are more than welcome to do anything you want with it (wanna be the maintainer of it? no problem). With the problem more or less solved, and with other things to do, I don't have any further big plans for it. I will try to push this upstream if possible (I have no idea what faces will Firefox developers make when they see it), but besides that, there are still many other areas that need some magic. And, after all, the ultimate plan is still that Konqy will one day rule the world .

> Read More... | Digg This!

This weekend I visited my parents in law, because my wifes paternal grandmother celebrated her 90th birthday. I noticed that the laptop they use was still running Kubuntu Feisty with OpenOffice 2.2. On this machine, reading emails, managing photos, surfing the internet and working on office documents are most important. Digikam is used for photos. Kmail and konqueror from KDE 3.5 are installed and a mix of OpenOffice and Microsoft Office 97 on wine is in use for editing office documents. in short, a horribly outdated setup of more than two years old. IT is still moving fast. Feisty was not a long term release and no updates for it anymore.

So in a slightly reckless move I decided to update the machine to the next Kubuntu: karmic koala. This meant going to KDE 4.3. To my relief the install went very well. All important settings for digikam and kmail were migrated automatically. Dolphin is really nice and more intuitive for non-professional users. The kwin effects add a nice touch of class (translucent wobbly windows). Plasmoids on the desktop (photo frames and weather forcast) were very well received.

In short: good karma! Thank you very much, Kubuntu team.

(my last two blogs were written on the Nokia N900 which has a good keyboard)

> Read More... | Digg This!

One important feature for photo management is missing in the FOSS world:an application for creating photo albums that can be sent away for printing at a printing service. There is however a pretty slick closed source application that works on linux. It can be fiound at for example Pixum (also in.nl and .de). It is based on Qt 4.4 and installs using a perl script which downloads the artwork and the required libraries. The application is customized for different printing companies that have these customized downloads available from their website. Not all of them
offer the linux or even the macintosh version. This is a shame and probably done to limit the number of different questions users might have. A standard for these photo album ordering services would be great, but I'm not holding my breath and will recommend Pixum for now.

> Read More... | Digg This!

Amazing Blog This is the amazing idea that came with Amanda from the new local KDE-MG group. Simple, beatifull and the most interesting way to get conference people to enjoy your booth, put his ideas out of the mind and getting everyone close. At this picture, you see Tomaz ( no tap dance included ), and the board, saying ODEIO ( I Hate ) on left and AMO ( I Love ) and everyone can express their feeling about our beloved project where we can improve it or not, writing a note, whatever you want to write. Our small booth is really more interesting:-) Right now, i'm in the talk table to introduce Anne-Marie in her's bugsquad presentation ! Later will talk more about our second Latinoware experience, getting better and better... Ahh, i forgot to say, there's a nice tipical "Minas Gerais" prize waiting for one of the guys writing the note !

> Read More... | Digg This!

You may remember two of my recent blogs. One was about a project to parse powerpoint files and another one was about porting hexdump to the browser.

So how about a combination of those two topics: parsing powerpoint files in the browser. It is quite a feasible task. The powerpoint file format is largely described in an xml schema now. From this scheme one would need to generate a parser like there is for c++ and java already. The parsers for java and c++ are both less then 700 lines of code.

We have not reached that stage yet and I do not have time to implement a powerpoint parser in javascript soon. I have written some requirements for it. To parse the individual data streams in a ppt file, one must parse the OLE2 file format. Currently we use pole for this in c++ and poifs in java. Now I could port either of these libraries to javascript, but there is another nice OLE parser: strigi.

In Strigi, the OLE file format is treated like other container formats such as zip, tar and mime. Porting parts of Strigi to javascript seemed like an interesting challenge. In Strigi, we use low level c++ to ensure speed. Most of the techniques used in the c++ are not available in javascript. So the javascript version is bound to be much slower. Still, I was curious what Strigi would look like in javascript.

And now it is ready. The parts required for reading OLE files have been ported. The result is one html page of 600 lines. It can read ppt files and list the streams in there. When clicking the streams, you see the stream in 'hexdump' style display. The speed is not even that bad. It takes about a second to parse a megabyte of file.

enjoy the demo!
(firefox 3.5 or recent webkit browser required)

> Read More... | Digg This!

A feature that has been floating around in a few places but hasn't been a
significant feature in KDE is web slicing. This is the ability to take a piece
of a web page (commonly a div) and render it as a standalone object. It's
useful for stuff like putting a weather forcast on your desktop, watching new
comments on a forum etc. This weekend I made a start on implementing it as
tool for Project Silk.

The first version I wrote was pretty simple - it lets you specify the element
you want rendered, then presents it to the client application as a
QPixmap. This was fairly easy thanks to the new QWebElement API, the core of
the code is as simple as this:

QPixmap Slicer::renderElement( const QString &selector )
{
    QWebFrame *frame = d->page->mainFrame();
    d->page->setViewportSize( frame->contentsSize() );

    QWebElement element = frame->findFirstElement( selector );
    if ( element.isNull() )
	return QPixmap();

    QRect rect = element.geometry();
    QPixmap result = QPixmap( rect.size() );
    result.fill( Qt::white );

    QPainter painter( &result );
    painter.translate( -rect.x(), -rect.y() );
    frame->render( &painter, QRegion(rect) );

    return result;
}

This is enough to let you specify a CSS selector and render it to a pixmap
thanks to the nice API of QWebElement. Doing the same using the DOM API would
be simple enough, but a lot more verbose (and probably less flexible). The
code above was enough for me to make it trivial to write tools that present a
slice of a web page as part of their UI.

As ever in life, some people are never satisfied so a common response was
to ask if I could make it so the slice is interactive. This is a bit of a can of worms
as everyone has their own definition - eg. simply responding to requests from
the page to repaint could be trivially added to the code above and would offer
the same functionality as that I'm told MacOS offers. Rather than try the
half-way solution, I wrote a prototype that actually gives you a fully
interactive slice - eg. you can type into the form elements. It's not
production quality, but it proves the point. You can see the result below:

Around the point I got this working, Kenneth let me know that a commit had
just landed in QtWebkit that would make the earlier version even simpler -
there's now a render() method on QWebElement that does exactly the same thing
my original code did. This is great news, as that solution is the correct one
for a lot of use-cases.

Of course, by this time, I was quite tired but Sebas was still feeling
lively. The result is that 'live slice' code gained support for being embedded
in QGraphicsView overnight using the new QGraphicsWebView. There's a support
class that makes it available as a widget like before, but the implementation
is using this (new in 4.6) class. All in all this means we can nicely
integrate this functionality into apps using QGraphicsView like plasma or
amarok, and into QWidget based apps too.

All in all, a successful couple of days in the stealthy advance of project
silk.

> Read More... | Digg This!

This morning, I thought: why is XMLHttpReq for xml and text but not for binary files? It turns out you can use it for binary files, but not in each browser and only for remote files. I've written a small implementation of hexdump. It loads a binary file like this:

function load_binary_resource(url) {  
  // this works in firefox, chromium and arora,
  // but binary files are read only partially in konqueror and opera
  var req = new XMLHttpRequest();  
  req.open('GET', url, false);  
  req.overrideMimeType('text/plain; charset=x-user-defined');  
  req.send(null);
  return req.responseText;  
}

Then you can access each byte with code like this:

  var data = load_binary_resource(file);
  var byte5 = data.charCodeAt(5) & 0xff;

As described here.
With these techniques I made hexdump in the browser.

> Read More... | Digg This!

So, after far too long, TagLib 1.6 is out. I finally asked Luká? Lalinský, who's been the largest TagLib contributor other than myself and veteran of the MusicBrainz project, to step in and take over maintainership as I've been off doing the whole interwebs startup thing for the last year and change and time is exceedingly scarce of late.

The real highlights of this release are a whole bunch of new formats supported:

• MP4 [compile time option]
• ASF (WMA) [compile time option]
• WAV
• AIFF

The first two are compile time options so that distributions can easily decide if they thing just dealing with the containers / tags of encumbered formats is murky territory. Tarball has been up for a couple of days. Enjoy, report bugs and give a big round of thanks to Luká?!

> Read More... | Digg This!

This weekend I have been bitten by some singletons. They have annoyed me so much that I am writing this blog about them. I will expose the singleton as a dangerous construct. Tempting, but dangerous.

Singletons, or K_GLOBAL_STATIC as they are called in the KDE world can do a lot of harm because they are sneaky. The are a source of hidden information that makes your function calls behave in unexpected ways.

Singletons are global instances of classes. They contain data that is not obvious in a stack trace. Take for example this function:

int count() {
   static int count = 0;
   return ++count;
}

The above function will return a different value each time you call it. And the reason is that it knows things that you do not know. It has hidden information, unaccessible to you, the caller.

Compare this to a different function:

int count(int& counter) {
   return ++counter;
}

This function is better behaved: if you call it with the same arguments, the result is the same.

This example is about a static int, not a K_GLOBAL_STATIC, but the idea is the same: the caller of the function is not in complete control.
Yes, you are reading that correctly, if you use singletons, your code is no longer in control: the singletons are there before the first line in "main()" is executed. They exist before the command-line arguments have been parsed and they are still around after the main() return statement has wound down the stack. The singletons call the shots.

Now, I could go on about downsides to singletons, but other people have done so convincingly.

Instead, I'll tell a tale about how two singletons that are making command-line scripting of KWord impossible for now. The two protagonists in this tale are KoPluginLoader and Kross::Manager.

KoPluginLoader is a singleton that keeps a registry of the plugins that are loaded in KOffice applications. If you want to put a shape in your KOffice application, you have to ask KoPluginLoader, because KoPluginLoader loads the the code that is the shapes.

So what about Kross::Manager? Kross::Manager can, like the name suggests, be dangerous. If you can avoid it, do not cross a cross manager, especially not when it is in charge of your objects. And that is exactly what it is when your run 'kross' from the command-line. Kross::Manager is a singleton that keeps track of all your script variables. If you run a script in kross, the variables you use are deleted when the K_GLOBAL_STATIC Kross::Manager is deleted, which is after the main() function ends.

And this is where the problem occurs. Here is a simple kross script that demonstrates it:

#!/usr/bin/env kross
import Kross
kword = Kross.module("KWord")
doc = kword.document()

What happens in the script is that a KWDocument is created and when it is created, it falls under the control of Kross::Manager. The document can contain shapes that can only be deleted by the code which is controlled by KoPluginLoader. So KoPluginLoader has to be deleted after Kross::Manager deletes the document. And that is exactly what does not happen. KoPluginLoader is destroyed before Kross::Manager and nothing can be done about it because the order of destruction of K_GLOBAL_STATIC objects is mostly outside of your control.

The question that remains is: "Why are KoPluginLoader and Kross:Manager singletons?". There answer is: there is no reason that they are singletons. Singletons are mostly used as an easy way out when a developer does not want to make a dependency explicit by adding an extra argument to functions or constructors that depend on the singletons.

As an exercise to the reader look up one of the many uses of K_GLOBAL_STATIC in KDE and ask yourself how that singleton influences the repeatability of your unit tests.

> Read More... | Digg This!

Just recently my blog got syndicated by Planet OSGeo. So I'd like to take the opportunity and say "Hello" to all readers and I'd like to thank for the warm welcome!

As a Marble and KDE developer I had been at the Gran Canaria Desktop Summit last month (and that made me miss the State Of The Map unfortunately). I enjoyed this conference a lot and I would like to thank especially the GCDS Team which did a terrific job and made this event a full success.

For all people who have missed my 30-min presentation about Marble: The slides of this presentation are now available. Additionally there is a
Video on YouTube which has the first ten minutes. The full OGV-video can be downloaded here. The video is licensed under the Creative Commons Attribution-Share Alike License 3.0. Credits go to the GCDS team. Enjoy!

As an introduction to Marble I can also recommend this nice review over at Dedoimedo.

> Read More... | Digg This!

I'd like to introduce a little pet project of mine: Kustodian, which some people would call a ripoff of the mac dock or windows 7 taskbar. But I maintain it's a thing of it's own, but it indeed has some similarities.

The idea is that when you click one of the icons it launches a new application. The number next to the icon shows how many instances are already open, and when you hover such an icon a dropdown/popup immediately appears with thumbnails of the windows. When you click one of those thumbnails you bring the window to front/minimize/restore just like you are used to.

Some icons/applications on the Kustodian are marked as favorites and appear even when there is no number next to it. If you launch and application that is not already there it will appear and you should be able to mark it as favorite.

Now you might wonder how much of this already works. Well it's a real screenshot so the icons appear and disappear, and there is a list of hardcoded favorites, which can launch new instances. The popup is however blank at the moment, so I'd like to get some help from a plasma person who thinks this project is worth helping out. It follows that you cant actually manage your windows with this thing yet, although I've managed to use it as a day to day taskbar replacement for several months already

I'll commit what I have to playground soon, but don't hesitate to contact me on irc. My nick is boemann in case you wonder.

> Read More... | Digg This!

The release team made a decision to branch the KDE svn for 4.3 in advance of the actual release. From the point of view of kdebindings I am finding it a highly error prone messy pain in the arse.

I don't blame the release team, but it really shows how unsuitable subversion has become for a project on the scale of KDE. Various parts of KDE development have different relationships with the release cycle. With kdebindings we move into high gear rather late, when everyone else has frozen their apis and headers for the release. So with the early branching it means that I am unavoidably developing some things in trunk and other things in the 4.3 branch. And being human it is very hard not to screw up, and not accidentally copy the wrong stuff from the branch to the trunk and vice versa. Well it's Sunday, and I now have a 'subversion headache' and am retiring for the day..

> Read More... | Digg This!

I'm back from the awesome Gran Canaria Desktop Summit. It feels good to be back in Berlin and with my family, but I'm very scared of the backlog that now awaits me. Before I tackle it (and potentially blog more about the event) I need to get something off my chest, lest it is forgotten. I'd like to publicly thank Klaas Freitag, who's term as a member of the KDE e.V. board of directors just ended with our general assembly a few days ago, for his contribution to our project. He stepped up to help out with the more mundane and every-day tasks that are required of the board, thus freeing up people like our beloved bouncing ball and poster boy Aaron (who's term also ended, but who'll get plenty credit anyway to do what they do best. I really admire the effective, quiet and ego-less way in which Klaas has carried himself and represented us. He's done a lot of work behind the scenes that benefits KDE greatly and helped get e.V. and its operational side up to a sustainable level. So thank you very much, Klaas, and enjoy the extra time you can hopefully now spend with your family again.

> Read More... | Digg This!