KDE will be moving to git, Qt has moved to git, recently also CMake moved to git.

So, it's time to start using git.

...until now it really looks so complicated, compared to cvs/svn.
In cvs/svn it was easy: local working copy, remote central repository, just one step away.
With git this is about three steps away: local working copy, stash, local repository, remote repository. You always have to be aware of where things are.

Ok, one has to get used to that "git add" is something different from "svn add", and "git commit" is different from "svn commit".
After a "git merge --rebase" (which seems to be the same as "svn up"), git told me that some files "need updates".
So I just tried "git update".
This would have been too easy:
git: 'update' is not a git command. See 'git --help'.

Did you mean this?
update-ref
$

Ah, right, I think "git checkout" is the same as "svn update".

At least "git diff" seemed to do the same as "svn diff" (or cvs diff).
Then I committed. To my local repository this means.
Now, I wanted to have a patch which I can send away.
So, with svn/cvs I did "svn diff", so I tried "git diff".
Nothing.
Of course, because there is no difference anymore between my working copy and my local repository.
But how do I get the difference between my local repository and the repository from which I cloned ?

I mean, I'd like to know that before I push.

So, some browsing and googling follows:
http://marklodato.github.com/visual-git-guide/
http://www.kernel.org/pub/software/scm/git/docs/everyday.html
http://book.git-scm.com/3_comparing_commits_-_git_diff.html

I read things like "committing with a detached HEAD" or "Create a local reference to the remote repository as" and other things which sound quite complicated.
I try "git log '^origin/master' master" and then "git format-patch --stdout 62b095d". This looks quite good, but is only one commit, not two. So I try "git format-patch --stdout 62b095d 57c5d370". This gives me plenty weird stuff. Next try.

And finally I find a web page which seems to contain what I'm looking for, how do I compare my stuff to the central repository:
http://pjps.tumblr.com/post/96756489/git-diff-with-a-remote-repository

Phhh, is it really that complicated, doing like one of the most basic things ?

So, how do I do this ?

Alex

> Read More... | Digg This!

1) Create a folder somewhere eg ~/Desktop/My Favourite Apps
2) Drag and drop the folder onto a panel
3) Choose "Folder View" from the popup that appears
4) Drag apps from the menu, documents from Dolphin and other stuff onto the new panel icon
5) Click it and enjoy your new menu!

> Read More... | Digg This!

Rendering slides is a complicated business. Slides can contain tons of different features just like webpages can. People expect that presentations look the same in different programs. Perhaps not pixel-perfect but very similar nevertheless.

OpenOffice and KOffice (and the Maemo/Meego Office Viewer) both have ODF as their main file format. ODF is an open standard and this means exchanging data between these programs should be simple and lossless. To help the developers of these programs find differences in rendering of slides, I have written a program that loads a presentation and shows it as rendered by KOffice and OpenOffice.

As an added bonus, it also shows how these programs render PowerPoint files. PowerPoint files are converted to ODP first and then loaded into each of the two rendering engines. That gives four types of output:

• Converted by OpenOffice to ODP and rendered by OpenOffice
• Converted by KOffice to ODP and rendered by KOffice
• Converted by KOffice to ODP and rendered by OpenOffice
• Converted by OpenOffice to ODP and rendered by KOffice

You can see an example view in the screenshot and screencast below.

The code will has been announced on the koffice mailing list.

Ogg Theora screencast of SlideCompare
Flash screencast of SlideCompare

> Read More... | Digg This!

I haven't blogged about my development activities for some time now...
So here come some news.

We released KDE SC 4.4.
There were no really big new features in this release buildsystem-wise. Nevertheless it was enough work. PolicyKit support has been added, which was quite some work, and all the new Strigi/Soprano/Nepomuk/Raptor/... stuff, which is still quite confusing for me, and which broke our buildsystem during the 4.4 cycle for a few weeks. But we got that sorted out too

For KDE 4.4.x we still require version CMake 2.6.2 or above, as we do since KDE 4.2.0. This required some effort, to make sure no "code" which requires newer versions gets added somewhere. Right now CMake is at version 2.8.0, and 2.8.1 is in its RC-cycle. Please give it a try, to make sure we get a release which works without problems with the KDE codebase.

In the current 4.5 cycle we may increase the required version of CMake, so we can use the newer features again. I see basically two options: upgrade from 2.6.2 to 2.6.3, which would give us parentheses in if()-expressions, and better finding of FooConfig.cmake files.
Or directly go to the most current release, 2.8.1, or maybe 2.8.2, so we can stay with this again for a few release cycles.

With KDE requiring CMake 2.6.2, and KDE being available not only on Linux, but also other operating systems like FreeBSD, Solaris, OSX and Windows, it becomes important that we can ensure KDE trunk keeps building and running on all these platforms. Luckily, CMake comes together with CTest, which is a tool to drive testing, continuous and nightly builds.
We are currently in the process of setting a CDash dashboard for the KDE modules up at http://my.cdash.org, which provided for free by Kitware. E.g. here you can see the dashboard for kdelibs trunk: http://my.cdash.org/index.php?project=kdelibs&date=2010-02-23

This is not yet finished. I'm still working on making it easier to set such nightly builds up and for a project of the size of KDE we need finegrained notification emails. E.g. the maintainer of kcalc in kdeutils may not be interested in problems in other parts of kdeutils, like e.g. okteta. To help with this there is support for subprojects in CTest and CDash, but I'm still not sure how we can make good use of that in KDE, it seems currently still quite some manual work is required. So we may need some modifications in CMake/CTest/CDash to make it easily usable in KDE. Documentation for using subprojects can be found here, the "The Source" edition from July last year.
If you are interested in helping, come and join us on the kde-buildsystem@kde.org mailing list

In KDE itself, Harald Fernengel started to work on cross-compiling support for KDE. This work is still in its early phase, but we may well have a cross-compilable KDE 4.5 release ...or at least some parts.
CMake supports cross compiling since its 2.6.0 release. When making a software cross-compilable, you have to keep several things in mind:

• you cannot run the executables you build, so avoid configure checks which need to run an executable.
• the same is true for running foo-config executables to query package information. This will in general not work when cross-compiling.
• when writing custom commands or targets, keep in mind that you cannot run the executables you just built. These helper executables may have to be imported from a native build.
• you may have to check not only for one system, but two systems. CMAKE_SYSTEM_NAME gives you the system name of the target platform, CMAKE_HOST_SYSTEM_NAME gives you the system name of the build host.

Implementing this in KDE is quite some work. I think it may be even more work to keep cross compiling working then. I guess for that we will really need good working nightly builds.

In CMake itself, I'm currently working on adding support for the IAR compiler, which is a compiler for embedded systems. For added fun, the IAR compiler for ARM and the IAR compiler for AVR seem to be two completely unrelated toolchains, using different command line options, linkers and file formats (the AVR compiler uses some proprietary r90 object file format, haven't found any documentation on this yet).
That said, the IAR ARM compiler is already working, and I'm working on the AVR compiler now.

Beside that, since a few weeks I own a Symbian mobile phone. So, guess what...

Yes, I'm also working on adding support for Symbian to CMake (... in order to be able to build Qt apps for my mobile phone).
That's actually more work than I expected. The thing is, Symbian comes with its own set of weird build tools (named abld and more scripts), which generate Makefiles finally. Symbian seems to consist of many many small libraries, and I didn't find a good overview documentation yet. Also, the different versions of Symbian also seem to differe slightly in required compiler options and definitions.
Currently I am able to compile and link "Hello world" for Symbian, but in order to be able to install it on the device, I need to create a sis-file from it, using more strange Symbian tools. But I think we'll get this working too

So, that's it for now.
Alex

> Read More... | Digg This!

I have fixed Exmap, my still favourite tool to measure system memory usage, to compile with latest kernels, and also to work on x86_64 (the latter was a bit of guess-work, but I think I got it right). KSysGuard seems to be getting close, and with Exmap unmaintained by its author I don't feel like doing this forever, but for now, it's still possible to get exmap from my home:llunak:kernel repository. And as I don't feel like trying to do cross-distro kernel packages in the buildservice, those not using openSUSE are left with either trying to package it for their other distro, or pick out the patches from the .src.rpm .

While I was at it, I had just a little look at memory usage. Since I had done quite some comparisons of KDE3's memory usage with other desktops in the past, the first thing that came to my mind was doing that quickly again. As these days LXDE appears to be the new lightweight kid on the block, I tried that one, and also Xfce. Finally there's TWM, basically just to show the memory usage without any desktop. All of them are default desktops on openSUSE 11.2 for a new user with a file browser and terminal open, the only exceptions being adding a mixer to the default Xfce setup for a reason that will be obvious later and not using the nvidia driver. LXDE is from the X11:lxde repo, KDE version is 4.3.5 that'll soon end up in an online update. So, here it is (for those who don't want to find out what all those values mean, the most important number here is the 'Effective Resident TOTALS').

Of course, this is not really comparable to my old memory usage test, for a number of reasons, such as this being x86_64 machine, the setup being different, and so on.

It's interesting to note that LXDE actually loses to Xfce. That 'python' there is in fact GMixer. That really shows that you don't get lightweight things unless you check the setup yourself. And it probably also shows that you can get lightweight things only if also your expectations are lightweight.

It also shows that KDE4's memory usage is not as bad some some might think, although it would be nice if somebody would be bored enough to analyse it in more detail. There seem to be enough people bored enough to just complain about KDE4 performance but not do anything else, and this is actually pretty simple. Or do you need an Akademy talk for that or what?

> Read More... | Digg This!

Hi,

Bill from Kitware just announced that the CMake tutorial from the "Mastering CMake" book is now also available online.
If you're interested, have a look.

(Btw. their new blog also contains other interesting reads, e.g. about open science etc.)

Alex

> Read More... | Digg This!

This is just a quick note to tell the world about the newest Strigi release. It has version number 0.7.1 and is the recommended Strigi version for use with KDE 4.4 and Nepomuk.

Go get it.

Join us in #strigi for comments and questions.

> Read More... | Digg This!

Being able to properly read many different file formats is important for KOffice success. By 'read', I mean 'convert to ODF' because the conversion and reading is strictly separated in KOffice. KWord will convert a .doc file to a .odt file before loading it into the internal rendering and editing structure. There is even a nice separate program called 'koconverter' that can convert files on the command-line.

So far, there were no decent tests to avoid regressions in our filters. I have
written a small framework (well, a shell script, but framework sounds better) that makes it simple to write tests. There are a number of tests there now for converting ppt files, but it would be great to have them for other input formats too. And here is where I hope you will help. All you need is a small input file that highlights a feature or problem and a small XSL file. The XSL file contains the test.

Look at this small example. Suppose you have a file, it can be a .doc, .docx or another office format. The file contains only one image and you want to have an automated test to verify that the ODF that is created also has one image. The following XSL file tests this:

If the number of image elements is not exactly one, the XSL transformation will abort with an error message.

So you see that the framework is written in such a way that writing tests is easy and fast.
When reporting a bug in KOffice or koconverter you can help a lot by writing an XSL for our automated
tests. You will see that this will speed up fixing the bug and it will help
avoid regressions.

This way of testing is a bit unconventional: these are not unit tests but overall
tests. Files are converted to ODF and the output file is checked. Not a small
part is tested but the complete conversion is tested. A benefit is that the tests are independent of the programs doing the conversion. We just check the result. So the same method could be used on any programs that write out ODF files.

Here is how our tests in KOffice work. First we convert the input file to ODF with
koconverter. An ODF is a zip file with many files and we usually want to check
the content of the XML files. So after conversion with koconverter, the ODF file
is uncompressed. Then an XSL transformation is run on the file content.xml.

In XSL on can report errors like this:

(You see that XML does not have to be too verbose.) The prefixes x: and s: in
this snippet stand for http://www.w3.org/1999/XSL/Transform and
urn:oasis:names:tc:opendocument:xmlns:style:1.0 respectively.
The test checks if the fill-color for a particular part of the output document
has the correct value. If not an error message is printed and the
transformation stopped.

You can replay this example by checking out the tests:

That was the overview of how the tests work. Now let us look into one more complicated test. It has two files: background.ppt and background.xsl. background.ppt is the input file and background.xsl
is the transformation that verifies the output of the transformation.

The file background.ppt has two frames, one of which must have a light blue
(#bbe0e3) background. At the moment the frame gets a background color, but it
is wrong. So when fixing this bug we first formulate what we want the result to be by
writing an XSL file.

One XSL file can contain multiple tests. This test is called
testSolidBackground:

We assign the second frame in content.xml to a variable:

Now we find the name of the style for this frame:

And find the style with that name:

Now we do a sanity check: do we even have a second frame?

And do we even have a style?

Now we test if the background is 'solid':

And we check the color:

That is all there is to it! Learning XSL if you do not know it yet is some
effort but one that will pay off. Once you have the XSL you can run 'make test'
while fixing the bug. This will call the test for you which has as side-effect
that the conversion is run and the odf file unpacked.

I hope you all will start using this method for reporting and fixing filter bugs. I stop by starting you off with some links to XSL and XPath.

> Read More... | Digg This!

So let's talk about what's going on in the Ark land.

Some time ago, Lydia blogged about raising the number of bug reports marked as junior jobs on Bugzilla. I've done my part, and currently there are 12 Ark bug reports listed as junior jobs.

If you have some (little) experience with C++ and Qt, fixing a junior job is a very good way to become part of the KDE community: junior jobs are usually easy to fix, you delve into the art of reading and understanding other people's code and, of course, you make KDE better with your contributions! What's more, you get the feeling that you're also part of our community.

Despite being about 12 years old, Ark, KDE's file archiver, does not have a huge code base, and it's fairly easy to understand its source. Most of the bugs marked as junior jobs involve writing support for more file formats (such as RPM), improving the error messages displayed to the user or implementing some easy wishlist items. But that's not all: as I write this blog post, there are 67 open Ark bug reports: only one of them is a more serious crash, and I'm sure there are many other report there which are not marked as junior jobs but are fairly easy to fix or implement.

Take a look at our bug reports, choose one or more you'd like to fix. You can then attach the patches to the reports themselves, mail them to the kde-utils-devel mailing list or send them directly to me. And remember that if you ever get in trouble, there's plenty of places you can look for help: TechBase, the API reference, LXR, the kde-devel mailing list or the #kde-devel IRC channel on Freenode.

Happy hacking!

> Read More... | Digg This!

At work, I stumbled across a problem that I want to declare as universal. I got a mail with a title like

christmas party invitation

I deleted this mail without reading because I knew I would not go there. Fine so far. But later I found out this mail contained one sentence that actually was of interest to me:

"due to the preparations of the christmas party, the canteen will be closed starting 12:30"

So, what happened? Someone had created a bad mail title (also known as subject) and as a consequence I could not eat for lunch. This is what I call bad information logistics. Logistics deal with goods being
* at the right time
* in the right quality
* at the right place
Information logistics deals with the same, just "goods" being "pieces of information" (also known as "knowledge"). Structure information wisely. Make good titles and mail subjects. Tell the reader of the subject if he or she should read the mail. Most commercial websites are a mess of "information" but nobody knows what to read. Imagine a company website having only the following items:
* click here if you want to buy online
* click here if you want to apply for a job
* click here for hot-air-powerpoint slides around our products
* click here if you want to complain

Hey, a site-map would not be needed any more. Customers would not be scared any longer by too much information. Just put yourself into the situation of a user/reader.

Now the same stuff happens when you read about regex's. Take the tutorials. It is unbelievable how quickly people get to talk about branches, pieces and atoms and completely fail to understand why you use regex's at all:

Find all lines that (do/do not) (contain/start with/end with) (the string/one of the letters/a character range) XXX, followed or not by [same again]

This is exactly what I aim at with my software krep. It gives you the right things to choose from, just like a folder full of mails with good subjects.

> Read More... | Digg This!

I just have to say it, I'm thoroughly impressed by Burkhard Lück's determination to improve the user-documentation of KDE applications (particularly the kdebase ones). This is much needed, a huge undertaking, and probably also not very rewarding work. This being said, I'm sure he would appreciate some help -- if you can speak English (you can, otherwise you wouldn't be reading this) and want to contribute to the KDE documentation, subscribe to the kde-doc-english mailing-list

> Read More... | Digg This!

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!