I got a HP Pavilion g6 for my birthday -- this must be the first time I have a personal laptop, all my previous ones having been bought by KDAB (or by IBM as KDE sponsoring, for the very first one).

Main purpose: Windows music software. But also reading KDE email of course. So I installed linux (openSUSE, to try it out for the first time).

We often need to check for a system function or library availability, like HAVE_XZ_SUPPORT, and we put that into a cmake-generated file like config.h (much better than -DFOO because changing that requires recompiling everything).

That's fine. However a single config.h at the toplevel of kdelibs is not modular; every change requires recompiling everything, and at some point we would like to split up the libraries to make their adoption easier by other people.

So the idea -- which was started long ago, before kde-4.0 -- is to split that up into one (or more) generated file(s) per library. Modularity "FTW", as kids say these days.

As a followup to my previous post: I just added a feature to kdesrc-build which makes it possible to run the tests and upload the result to http://my.cdash.org. Just add the line "run-tests upload" in your module definition for kdelibs, and others if wanted.

For the first time since end of May, 2010, the kdelibs unittests are all green again, in trunk:

100% tests passed, 0 tests failed out of 171

During the Akademy kde-on-mobile discussion, Kévin Ottens suggested that mimetypes be splitted out from the main sycoca database, in order to reduce the overall time kbuildsycoca takes every time it runs, and to make things more modular. Last monday I had a look and decided to go one step further and not use ksycoca at all for mimetypes. This makes the KMimeType subsystem really independent (usable without having run kbuildsycoca4 before, so no dependency on kdeinit+kded etc). Took me the whole week, but there we are.

If print preview doesn't work (no viewer found for PDF files), then most likely okularpart (from kdegraphics) isn't installed. If this is because your kdegraphics can't find poppler (the test for HAVE_POPPLER_0_12_1 fails) even though you have it installed, look into CMakeFiles/CMakeError.log. If you see "undefined reference to qBadAlloc" while linking, then the problem is that /usr/lib/libpoppler-qt4.so was compiled against a Qt with exceptions enabled, and your own Qt (e.g. from kde-qt git) was compiled with -no-exceptions.

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 :)

One big risk with git is forgetting which branch you're working in. Several people solve that by putting the git branch in their shell prompt. But often they do that by calling `git branch` and parsing its output, which is quite slow, especially in big repositories (we strace'd it, and it really opens and reads a lot of files).

At GCDS, together with Aurélien Gateau et Sébastien Renard, we came up with
this light-weight implementation (http://www.davidfaure.fr/scripts/git_branch_in_zsh_prompt).

I learned a number of useful productivity tips during this akademy, so as the self-appointed guy-who-shares-productivity-tips-with-the-rest-of-kde, I thought I would share them here :-)

Read more below for yokadi, ack-grep, autojump, and cgdb.

Hearing that kubuntu jaunty was out, I upgraded two machines today.
My wife's machine, so she can finally use KDE 4.2, and my own desktop machine. On her machine, NVidia card, no problem at all.
On my machine, ATI Radeon X1300, after the upgrade, X would always just show some red dots on the top of the screen, and then the machine would hang (no keyboard, no ssh, nothing except reboot).
I tried every possible driver in xorg.conf, no difference. So this isn't a driver problem, but an Xorg problem.
Other people on #kubuntu (e.g. "chx") reported the same issue.