I read an interesting blog this morning Freedom vs. The Cloud Log where Glyn Moody interviewed Eben Moglen. Eben Moglen was General Council of the FSF for 13 years and helped draft various versions of the GPL. He talks about the implications for software freedom caused by the rise of services in the 'cloud' where your data is owned by the service provider, and the fact that they don't usually release the code of their applications that run on the servers.

With the recent ownCloud initiative, the KDE community is doing something about the problem, by allowing you to have your own data stored in a variety of types of places of your choice, so that it is independent of a particular machine. It gives you a option of putting it on a host providers machine, or on you own network - somewhere where you personally are in control of it.

I had been thinking of getting some sort of home server, that was always connected to the internet, to use as a music server. The Apple Mac Mini running either Mac OS X or Kubuntu (like I run on my small laptop) seemed to be the best bet. Most servers are still really big and ugly with noisy fans, and not really suitable for running in your living room. The Mac Mini is one of the few attractive and quiet options, but it is quite expensive.

When Eben Moglen talked about how we could construct a distributed infrastructure peer to peer style, instead of client/server as used by Facebook and the like, he mentioned a small ARM based server called the 'SheevaPlug'. That got me thinking, and I went off googling for everything I could find about this tiny server the size of a wall wort power supply. It turned out that there is a new model called a GuruPlug which has additional features like WiFi, eSATA interface for cheap fast hard disks, and an SD slot. The more I thought about it, the more fun the idea sounded. There are so many things you can do with one of these little servers.

So I just went ahead and ordered one. The basic server was 91.47 euros, a JTag board for debugging was another 26.82 euros, and shipping by FedEx was a bit pricey at 49.76 euros. The total cost was 168.05 euros, which is actually quite a lot relative to how much a cheap netbook costs these days. I'm sure in a years time you will be able to walk into a computer shop and get them for more like 50 euros or so. I think these things will be subject to Metcalfe's Law where their usefulness will rise according to the square of the numbers of users. If Eben Moglen is right we should be able to undermine the efforts of authoritarian governments, such as China, the UK, Australia, France and so on, by going completely peer to peer with strong encryption and cut off the government snoopers from invading our privacy and stealing our civil liberties. So for reasons like that, I think my 170 euros, plus a bit of my time will be a good investment.

Apparently, with my original posting here, I stepped on several people's toes. I'm sorry for that, and for this reason, I've simply removed this content (and also because - as some of you pointed out - some of the things I mentioned were not Plasma's fault, but workarounds or bugs in other areas, although to me as a user they appeared on Plasma).

On the other hand, my frustration with KDE is growing... I find my self more and more replacing KDE applications with GNOME applications, simply because the KDE application does not fulfill my needs or is buggy, while the GNOME application provides the fundamentals that I need.
When KDE 4.0 came out, I accepted the excuse that some things simply needed the time to be ironed out. However, now at KDE 4.4, my biggest problems are still there:

• Printing in Konqueror is just not working so I have to use Firefox (and yes, I posted messages to bug reports),
• KDE's printer dialog does not seem to remember any settings, and it also messes up CUPS in other applications
• VPN does not work in knetworkmanager so I have to use nm-applet (and knm does not display the list of available networks),
• Booklet printing is missing altogether so I have to use Acroread to print my students' seminar works and other papers,
• printing landscape slides 2-up doesn't work in Okular so I have to use Acroread to print handouts for the students,
• KMail regularly decides to eat my inbox or my calendar,
• My bluetooth headset is working only with gnome-bluetooth and gnome-volume-control-applet
• etc.

(And just for the record, for most of these problems I either filed bug reports or talked to the maintainers on IRC, who told me mostly, that it's not their application to blame, but some underlying framework and I could do nothing about it...)

It is raining massively, outside, again. It does that every day here, in Manaus, what with it being the rainy season and this being the Amazon jungle. The negativity ends there, though, since it takes about 15 minutes, is very refreshing, and everything else here is Awesome (TM). I have really enjoyed the past few days, Bossa Conference has been a great experience. The presentations were generally of high quality, I had many very good conversations over many excellent meals, and by a luxurious pool, met several impressively talented individuals and the equally impressive INdT teams. There is a lot of very nice work being done here in Brazil in Free Software in general and around Qt and KDE in particular. I'm proud to have been invited to come.

The main reason for my being here is to present the current state of our efforts to bring Akonadi to mobile devices, solicit the feedback of the mobile experts here and hopefully convince some of them to help us out with their experience. The presentation was quite well received, I think, judging from the amount of interest afterwards and the very curious and in-depth questions. Let's hope our groove will soon be spiced up with some bossa and samba. My next stop on this trip is Recife, in the south of Brazil, to spread the Akonadi gospel there.

Aaron, Sandro, moofang, Shantanu and Diego have been hacking up a Plasma storm lately on the Javascript bindings for Plasma and the Plasmate builder tool. Since good code is running code, and running code is a lot easier when somebody else builds it and packages it, I've updated the Plasmate packages in KDE:KDE4:Playground to 0.1alpha2 and have updated the javascript bindings in our KDE SC 4.4.1 packages to include Aaron's latest errata - no need to update yourselves.

So it's even easier to take part in the Plasma Javascript Jam Session competition now.

And while you're at it, how about completing the loop by using our kde-obs-generator to package your plasmoids and make them available on kde-look.org, so others can start to download and improve them directly in Plasmate? Free Software virtuous circle FTW!

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

Do you know this one?

Phoronix tested md5sums of ISO images of distributions. The winner was openSUSE, scoring e29311f6f1bf1af907f9ef9f44b8328b, which gave it a noticeable lead before second Slackware (b026324c6904b2a9cb4b88d6d61c81d1), which is quite closely followed by Fedora (9ffbf43126e33be52cd2bf7e01d627f9) and Debian (9ae0ea9e3c9c6e1b9b6252c8395efdc1). The difference between these two distributions, as you can see, is only very small. Ubuntu completely flopped in this test, achieving only 1dcca23355272056f04fe8bf20edfce0, which is surprising, especially considering that its previous release scored a very nice c30f7472766d25af1dc80b3ffc9a58c7. (source).

Ok, that's just a joke, but the sad part is, as somebody pointed out, that it wouldn't be really that surprising if Phoronix actually did something like that. And, probably even more sad, there would be people who'd really take it as if it meant something and started adding comments about how last openSUSE is pretty good, last Ubuntu is so disappointing, and Fedora and Debian are not really that different.

So take this from somebody who has already done a lot of performance work: Benchmarks, on their own, mean almost nothing if you don't understand them. Especially if they are seriously flawed (I mean, testing filesystem performance by doing CPU-intensive tasks? Hallo? Probably even FAT16 could provide the same results in those tests on an SSD.), but even if the results are useful numbers, it is still necessary to understand what the numbers actually say. I think I wouldn't even have a big problem forging a "benchmark" where KDE would get better (and correct) numbers than LXDE by finding a scenario that'd be twisted enough.

And even then, it is still necessary to keep in mind what is compared. Comparing the default setup of Fedora and openSUSE means also comparing GNOME and KDE, which you may or may not want, but if you compare the distributions this way, it is affected by differences between the desktops, and if you compare the desktops, it is affected by the differences between the distributions. And in either case, it may or may not apply to another distribution or another desktop.

Yet one more thing to understand is what is measured and how it affects performance as a whole. Ages ago there was a Dot article that also mentioned performance improvements to be brought by Qt4 in some specific areas, yet even now there are numbers of people seriously disappointed by KDE4's performance only because they thought that since Qt4 improves in some areas, KDE4 will get exactly the same improvement, regardless of how much these improvements matter for the whole of KDE4 or how much of KDE4 was rewritten when porting from KDE3. When I fixed Exmap to work again and did a little benchmark as a part of it, there wasn't really much more to it than to show that Exmap works again and that it is very easy to lose a lot of advantage by a simple mistake, yet people had no problems drawing all kinds of strange conclusions from that. Since making right conclusions is unexpectedly difficult for most people when it gets to benchmarks, I really need to remember not to just post numbers again without also saying what it means.

And, finally, there is still the question of other costs and whether it is worth it. Various KDE components often have resource demands, but then they are also often worth it. I mean, we all could still use TWM, or, heck, Windows 95, but seriously, how many of us really would? This, ultimately, is always about what works the best for you.

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!

I recently realised that much of the code I find interesting is about interoperability. That is, I'm interested in making sure we can get at data in a range of formats. Work on libtiff, poppler, okular generators and openchange are all examples of that. I also like Qt as a very nice cross-platform API. The convergence of those interests is having Qt-style libraries and tools that can get access to data, especially data in widely used proprietary formats (e.g. those produced by Microsoft products).

I've set up a gitorious repository (http://gitorious.org/microsoft-qt-interop/microsoft-qt-interop) for some of that stuff.

At the moment, it mainly has a Compound File Binary Format (aka "OLE") parser, written from the MS-CFB specification.

I plan to add an EMF ("Enhanced Metafile") format parser / renderer (already written and currently used in KOffice) at some point too - just need to find some more time.

There are a lot more things that could go in there (e.g. converting the various things in MS-DTYP into Qt equivalents), but I've only implemented those things I actually need.

Contributions are welcome - I'm pretty flexible on format. If you have some suggestions, please add them to the project wiki on gitorious.

Those that were at either CampKDE or FOSDEM might already know, so for those this is a status update, for the rest: I've been working on a tool that makes it quite easy to create packages in the openSUSE build service, which despite the name can create binary packages also for other distributions than openSUSE. If you've ever gotten a mail asking for a binary package of your application or help with a compile problem, this could make your life easier.

For example, imagine Joe Developer, who has written his KFoo application, uploaded it to http://kde-apps.org and is now watching what happens. But, alas, instead of thanks and praise, what often happens is that the first comment is something like "I get this compile error, can you help?" or "Are there packages for Kubuntu?".

It may be quite easy for Joe to see that the compile error is caused by libbar-devel not being installed, but how is he to know what the package is called in other distributions? The same way, how is he to provide binary packages for distributions he does not use? And that's far from all things that can go wrong in such case - Joe may be running KDE workspace 4.4, but somebody may be still on 4.3, where the application would nicely compile and run, if only one #ifdef would be added to the right place. But will Joe really downgrade his installation just in order to fix that, and again each time he does a release of KFoo? And then maybe somebody else will try to compile it on openSUSE Factory, which already uses GCC 4.5, and will get compile errors because the latest compiler is more strict than previous versions and rejects invalid code that however compiles just fine on Joe's computer. And so on and on.

Joe, of course, is a smart guy (after all, he's written this great KFoo app that everybody wants to run if only they could compile it ). He can get the idea to use VirtualBox and install other distros he could care about, and test in all of them. The question is how long he'd be really willing to do that, since it certainly sounds like a lot of fun (and lot of disk space, and work). And that still means that all those potentional users would have to compile KFoo from source.

Maybe distributions would eventually include KFoo, but there's this tricky loop 'nobody uses it' -> 'why should a distro include it' -> 'no distro ships it' -> 'nobody uses it'. Maybe Joe gets lucky, maybe he does not.

Sometimes other people may provide binary packages for the distribution they use, so if somebody likes KFoo enough (and knows how to do it), Joe may find a comment on kde-apps.org pointing to this package and can add it to the list of packages to download. Except this may and also may not work, depending on how well those packagers keep up. Having a binary package of KFoo-0.3 when the latest source tarball is KFoo-1.5 is probably worse than no binary package at all.

So Joe can go back to the VirtualBox installations and try to package KFoo for all those distributions. But Joe is a developer, not a packager, so first of all he'd have to learn how to actually do that (e.g. creating a .deb is quite different from .rpm, and even .rpm packages for different distros are not created exactly the same way). Worse, he is a developer, and, honestly, developers just love packaging, especially for multiple distributions, riiiiiight?

Now here comes the openSUSE build service (OBS), which as already said is not only used for creating the openSUSE distribution, but also provides the ability to create repositories providing additional software, also for non-openSUSE distributions. That almost looks like the solution for all the above problems, doesn't it? No need to install the distributions and do the builds locally, the OBS itself will do the building. New packages would be available very soon after updating the sources in the OBS. And kde-apps.org has even direct OBS support, so packages can have direct download links there.

There's still the problem of actually having to know how to do the packaging, but that is exactly what kde-obs-generator should help with. KDE applications in general happen to be simple to build, and thus quite simple to package (in fact, compared to some other pieces of software, KDE apps happen to be remarkably simple to package ). So a lot of that could be automated. In the best case, creating a KDE package in the OBS can be now a couple of clicks in the web interface, few osc commands (osc is the CLI tool for OBS) and running kde-obs-generator in the directory with the source tarball. I've already tested the tool with some packagers and they even started using it for real, because even for experienced people it saves work.

I still consider the tool to be experimental and work in progress, but it's already pretty usable. Currently it can handle Plasma themes, KDM themes, KPlash themes, wallpapers and generic KDE/Qt CMake-based builds. It tries to automatically figure out all the needed build dependencies (which however means the list of mappings from cmake to package names for all supported distributions needs to be extended as necessary). Also kde-obs-generator itself is packaged using kde-obs-generator. The biggest thing I've built so far is the whole of kdeutils, that's of course not how something like kdeutils should be packaged, but that shows it can handle quite a lot.

So, in case you'd like your application to reach more of its posible users, you'd like to ease your testing, or you're just curious, the documentation is in the openSUSE wiki. I'd especially like to point out the tutorial, which is really step by step and includes also things like how to create an account for the OBS, so maybe even a monkey could now create a package (well, assuming it can read and write and is pretty bright for a monkey - this still cannot be as simple as just hitting Enter repeatedly). If there are any questions or a problem, see the feedback section (mail the opensuse-kde mailing list, or just ping me (llunak) in #opensuse-kde on Freenode).

PS: I'd appreciate if people using other distributions could edit the wiki page on how to actually install the binary packages in some easier way than going to http://download.opensuse.org, navigating to the right .rpm/.deb file and clicking on it. It's pretty easy with openSUSE so I assume there must be something simpler on other distributions too, but I can't find it.

New KDE Four Live CDs with KDE 4.4.1, and much more are up.

They were built with openSUSE Build Service's KDE:Medias project and SUSE Studio and consist of openSUSE 11.2 plus all updates, KDE 4.4.1, upstream branding, Nepomuk enabled and Strigi disabled (because it's a Live CD).

They can be used as Live USB sticks too, see these instructions if you don't know how to dd a file to a device.

You can also install to disk and use it as a normal distribution using the installer on the desktop. Once installed, the first update will pull in all the packages that are normally on an openSUSE KDE install that do not fit on a single CD.

What's new, based on identica notes:

• Thoughts on deploying SQLite turned out to be work in progress. Valuable input from our distro friends. A special wiki page has been created. See the last item of this entry
• KoReport, Kexi's rpt backend has undergone some refactoring to make it more generic.
• Fix number 1, charts working again in the designer.
  
• Working through the huge list of issues krazy has found with the kexi codebase, not glamorous, but necessary!
• Refactored the report renderers, and given better class name, to make the report library suitable for adoption over all of KOffice.
• Do you want well working MSAccess to Kexi converter? It's up to you - request it!
• KOffice now has a suite-wide reporting library! (placed in koffice/libs/koreports/)
• Kexi switched to "system" SQLite again. We want to play with distros well, but will check SQLite features at compilation to maintain high quality standards.

(brought to you by Adam and myself)

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 has been announced on the koffice mailing list.

Ogg Theora screencast of SlideCompare
Flash screencast of SlideCompare

With only a few hours a week to work on Konsole, I often view the logs and other reports for simple issues to investigate. The compile warnings were fixed sometime ago. Most of the simple Krazy and Apidocs issues were also fixed. The remaining Krazy issues would require some heavy duty changes.

Recently I've been trudging through the -Weff++ logs. I coded a simple Ruby script to parse them as Qt generates a ton of warnings. Currently there are around 300 issues. The vast majority of these fall into 2 categories:

1. ... should be initialized in the member initialization list
2. ‘class ...’ has pointer data members
   but does not override ‘Class(const Class&)’
   or ‘operator=(const Class&)’

These 2 can be fix easily enough.
1. Add them to the constructor watching the order of the initialization list
2. Add these to the private section of the .h file:
   // Disallow copy and assign
   Class(const Class &);
   Class & operator=(const Class &);
   If anyone tries to use the Copy or Assign, it will fail at build time.

Thoughts on these 2 issues?

I did manage to get the Apidocs to generate the class hierarchy in graphic form which is very helpful. Although I'm still struggling with using valgrind for memory issues (and unfortunately, valgrind doesn't work on Mac Snow Leopard).

Today I'm leaving Tokamak 4, so I thought I'd write a post about what I've been up to while I've been here.

The first day or so I spent getting my machine sorted out as trunk was causing some issues with my graphics driver leading to a hang in the DRI layer of the kernel. I also had a chance to triage some ksnapshot bug reports and look over some patches.

The next day was largely taken up with talks about the current status of the various parts of plasma, kwin and related technologies. We got a little hacking done but not much as it was more important to make sure we're all coordinating our development.

The remaining days became a bit of a blur, so in no particular order:

• I refactored the plasma javascript scriptengine to make it easier to use it with QScriptEngines that are created externally. This is required before we can integrate things like QML.
• Worked out what is required for QML integration to be implemented in a way that is compatible with our existing javascript bindings etc. This will require some small changes to the API offered by Qt for QML, which may be a problem. If we don't get those changes then QML is likely to be trapped outside the main engine which will reduce what it can do unless we write
  another set of bindings.
• Made some fixes to the webslice applet to improve error handling.
• Started work on an idea I've had in the back of my head for a while, I won't say too much about it here, but I'll include a pretty picture to whet your appetite:
  
  
  

  In addition to this I've taken part in lots of discussions on topics ranging from activities/contexts, scripting of animations, silk and more. I'd like to thank Will and the rest of the openSuSE team for making this such a pleasant and productive sprint.

Looks like Microsoft has released the PST format specification.

I don't normally like to link to MSDN, but I'll do it this once:
http://msdn.microsoft.com/en-us/library/ff385210.aspx

As usual with these documents, I recommend reading the PDF version rather than the HTML. Also, Firefox seems to handle MSDN a bit better than my (KDE 4.3.5) Konqueror.

If you were a mad-keen PIM hacker, and looking for a GSoC project, might be worth a look.

[Thanks to Tom Devey for the heads-up on 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

Last week I went to Washington DC where I was meant to be giving a talk at CALUG. However the whole city was buried in a metre of snow so it got cancelled. In fact the whole government shut down. Good thing the US wasn't doing anything important last week or people would have noticed they had no government and anarchy would have broken loose, it would be like Belgium. The snow was mostly ploughed out the way by the end of the week in time for the KDE 4.4 release party organised by Celeste. The release party started off in true US style in a fast food burger restaurant where I ate Ostrich. Later it moved to a bar with a fine selection of beers of many interesting flavours, gosh it was like Belgium!

On Saturday we'll be hosting the first ever release party in Glasgow. Do come along if you're in the country.

Washington DC KDE SC 4.4 release party, eagerly awaiting beers.

Kubuntu developers visit the White House. Obama was snowed in and couldn't make our meeting so we had to take tourist photos instead.

Remember the last call? After less than 5 months we can see apparent success, and a lot more than a proof of concept.

Click to enjoy the show

Apaprently, Qt Lighthouse was used for porting the QtGUI module.

From the Author:
"You don't have to write your own jni<=>java connections, all the magic is done from java by com.nokia.qt package, take a look to examples/android/QtTest/src/com/nokia/qt"

I can only say, Kudos to BogDan! And of course I still cannot believe how flexible Qt architecture is. I bet we can expect more ports this year.

Dig for more details... and leave what you discovered in the comments below.

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?