Fast, faster, solid.

Our last KDE on Windows release is already a month old, but still we have tons of bugfixes that result in updated packages (to be true, this hasn't been the case for all releases).
Today I just finished uploading several new packages again, including a new kdelibs package which contains a new solid backend. This doesn't really sound to interesting in the first place, so why should you care? Solid works completely in the background and gives your applications the system information it needs, whether this is the number of DVD-Drives and its read speeds, or your battery status or ... This also shows the problem: there is a call to solid each and every time you open a file dialog and in case your solid backend is slow and/or crashes sometimes you can easily see how bad the situation can be.

At the bottom left in dolphin you can see the device list (Geräte) directly taken from solid.

Already since quite some time we thought about improving our current solid backend, but only november Patrick von Reth (TheOneRing) actually started to work on a new backend implementation. Work continued for quite a while, I went to the solid sprint in Brno, and now the biggest part of work is done. So I decided to integrate that work already now, even though we haven't even started to bring this upstream. This will follow soon but given that this might count as a new feature, we might need to wait a while ;-). If you are curious, work has been done in the git branch win-solid-next.

But not only that has happened lately.
Andrius Ribas (Xiluembo) is trying to build KDE on Windows with yet another compiler, the Intel one. Of course this is not to easy, each compiler has a specific behaviour, and of course, specific bugs. A new compiler might not be to interesting for everybody, but it helps us understand how our compilers work, and specifically we are interested in producing OpenMP-code (parallel execution code) which the msvc compiler does not support.

But there is more going on, Ananta Palani (notedible) is fixing bugs for the digikam package (and sometimes has to fight the once I introduced) and I am trying to fix smaller bugs in all KDE applications, I even became top bug killer in commit digest once :-D.

tl;dr: Please update your KDE on Windows packages regularly and get tons of bugs fixes :-D

new release

Hi everybody, after over a year of silence, I have something new to announce: I will make a new release available of the KDE SC on Windows tomorrow. There have been several problems in the past year that spoiled new release attempts, beginning with a build server leaving together with Nokia and ending with our web server which hosts the original binary releases. But these problems have been solved and so there we are. I hope this will make it also more obvious that KDE on Windows isn't dead yet ;-).

In the next weeks I also want to blog about several features I worked on in the last year:

• improvements/bug fixes for kate
• improvements in our emerge build scripts, especially for packaging and building collections of software
• making nepomuk (at least partly) available

stay tuned.

Waiting.

The KDE on Windows sprint meeting in Osnabrück just ended 2 hours ago and me and my colleague Andy are still waiting at the train station. The train to Berlin is now more than 2 hours late, so we decided it is a good time to write a summary for the sprint.
First of all we want to thank Andre Heinecke and Intevation for organizing a really nice sprint and giving us a place to hack and discuss.
This time we had 7 participants with a lot of different interests and backgrounds. Andre is maintaining the Kontact builds for Windows, Boudewijn Rempt attended to improve Calligra and Krita, Fabian Aichele showed us his work on integrating windows menus and shell actions with KDE, Andy Holzammer worked on several Qt5 on Windows related tasks, Patrick von Reth set up the new buildserver and worked hard to get mysql building with mingw-w64, Dominik Schmidt worked on cross compiling Windows applications under Linux with the help of OBS and I, I quote "have been slacking" (I worked to get emerge in a better shape).
The meeting started on thursday evening when Patrick & Patrick arrived already in Osnabrück. On Friday the rest arrived and we continued to discuss and hack. In the evening we had a nice dinner in a bavarian styled restaurant sponsored by KDAB, but just after dinner we went back to the office and hacked a bit more.

On Saturday we had a nice Introduction into Qt5 and its development process by Andy, I spoke a bit about KDE frameworks and how this will affect KDE on Windows. In the afternoon we had a google hangout together with Andrius Ribas who is based in Brazil and couldn't attend. Again we had a nice arabian style dinner which was sponsored by KO GmbH. This evening was a bit more of a social event, we had planned to make a release party (even before the KDE 4.9.0 release ;-)) and went to the unikeller just around the corner from the office. Just, as you would expect from hackers, we couldn't resist to go back to the office after that, and so last ones stayed until late in the night.
Today the day started obviously an hour later, but still we had two nice presentations from Fabian (lots of cool features for the KDE start menu and the file open menu in Dolphin) and Dominik showed us how to cross compile Tomahawk on Linux. Since Fabian had one of the longer journeys, he started first, and one by one all the participants had to leave. I hope that even if the journey might not work out as planned (I already heard that Patrick has been delayed in Düsseldorf until tomorrow), everybody will have a safe trip.
We all thank the KDE e.V., KO and KDAB for covering the trip and the hotel costs and of course once again Andre for doing all the organisation work.

Sprint Update

Just a small update before we head out for the KDE release party:
We discussed quite a lot of topics already, came to some conclusions and committed over 130 commits since thursday night. Yay!
We also are working on the next release which will hopefully be ready in about two weeks.
Tomorrow is already the last day, but it is really nice and productive over here so even a short time is worth it...

KDE Release Party Osnabrück and KDE Windows Sprint

Today I arrived in Osnabrück for the 3rd KDE on Windows Developer Sprint. It is hosted in the office of Intevation.
We have quite some things to do:

• What do we want/can we do for KDE frameworks?
• What changes in Qt 5 (in all respects there are)
• Which improvements are needed for our emerge buildsystem
• What improvements are needed for packagers for single app installers?!
• a new buildserver is waiting at intevation too.
• improvements for our own kdewin-installer

Some other nice ideas are floating around as well, we will keep you informed!

For all people near Osnabrück: we plan to do a KDE release party and we want to invite all KDE developers and all Qt developers around to have a nice chat and some drinks in the unikeller.

transqript v0.0.1

Today I want to announce a new Qt application called transqript.
Transqript can be used to bring interviews etc. that have been recorded as an audio file into written text.
Originally I wrote it as a christmas present for my wife since the free-as-in-beer application that was recommended for this task before was only available for Windows (and my wife uses Linux of course). The second point was of course to try out some classes in Qt and have a real life test application for that. Since my wife got a lot of questions regarding transqript I decided to clean the code, add some features and make a real windows installer too. You can download the installer or the sources required to build transqript from the sourceforge page.
Please be aware that transqript is still in a pre-alpha state, that means it looks really ugly and there are bugs in it!.
If you use transqript and you find some bugs, please enter them in the bug tracker. I will try to fix those bugs and I plan to release a new version every 2-3 months.

Have fun with transqript!


Heute möchte ich transqript vorstellen.
Transqript ist gedacht um insbesondere Interviews zu transkribieren die vorher als Audio-Datei vorliegen.
Ursprünglich habe ich es als Weihnachtsgeschenk für meine Frau geschrieben, da die dafür empfohlene Anwendung leider nicht unter Linux verfügbar ist. Da uns viele Fragen nach dieser Anwendung erreicht haben, habe ich sie nun ein bisschen aufgeräumt und stelle sie nun der Allgemeinheit zur Verfügung.
Da transqript noch sehr neu ist, enthält es bestimmt noch einige Fehler die ich aber in kommenden Versionen ausräumen möchte. Falls jemandem Fehler auffallen oder neue Funktionen einfallen, einfach in der Fehlerdatenbank eintragen.

Viel Spaß mit transqript!

finally 4.7.0

Weeks after we started, we finally managed to get out the KDE 4.7.0 release. Only after TheOneRing asked me several times about a new release (either a last 4.6 release or the 4.7.0 one), I finally gave in and told him what I know about the KDE on Windows release process... We needed quite a while to get most packages building again, very likely because our buildserver was stopped already some months ago due to lack of maintainance time. Also the splitting of the kdeedu & kdegraphics packages had not been done when we did our last release (KDE SC 4.5). But now we added new buildscripts and fixed our packaging scripts so now we welcome more packages to be split up (kdesdk or kdegames perhaps?).

Since I couldn't put everything into the release announcement, I want to add some more stuff over here:

• Our release contains the latest version of Digikam (which is 2.0.0)
• Also, there are now both skrooge and kmymoney available.
• besides the kdepim package, we also ship a beta version of zanshin, a todo application based on akonadi.
• a small but still nice scanning application is skanlite, which just works...
• also contained are Amarok 2.4.3, Kile, Quassel, Konversation, KRegExpEditor and KRecipes.

If you want to have other packages available, ask us and we will try to make that possible. Also, if you are maintainer of an application and you would like to see your application available on windows, we can surely make that happen.

Desktop summit midtime summary

Ok, the first 3 days of desktop summit have passed, I met a lot of old friends, met some new people, looked into some issues in several projects, went to the parties....

One of the things that comes to my mind from time to time is software accessibility, so I heart both the talks of Frederik Gladhorn about Qt accessibility and Peter Grasch about simon, a voice recognition software. He already provides a windows installer (based on KDE on Windows), so now I am trying to integrate simon into emerge so that it can be distributed both within the KDE on Windows installer and with a self contained NSIS installer.

The second thing I looked at was skrooge, I fixed some build errors and so I expect that skrooge will be in the next KDE on Windows release. Which actually also brings me to the next point:

The next binary release is near, at the moment we are preparing the release, update the 3rdparty libraries, cleaning up our buildserver etc. (well, it is mostly TheOneRing doing it - a big thank you over here). In a couple of days we will start again the builds, so binaries will be there in some weeks time too. We are not yet sure which software we package, I will probably announce this again, if you have special wishes, please let us know on our mailing list: kde-windows@kde.org or here in the comments.

update

Nearly half a year after my last blog post I just thought I would share some news with you.
First of all I became father of a cute boy in february - which limits my time (especially for KDE) quite a lot. Because of this I thought about stopping my work for KDE on Windows completely but I couldn't really live without it ;-).
This also means that our build server slowly stopped working in the past months. This is partly due to size constraints (one of the buildprocesses filled its quantum again) and due to a bug in jom which will only happen after quite some time.

One of the questions that comes up quite often is when we will have another binary release. The current plan is to release KDE 4.7.0 more or less together as all the Linux distributions and maybe add another release of KDE 4.7.X later this year.

Another big issue for us is the transition of our emerge build scripts to git. This brings multiple things with it that are no easy-to-solve questions:
At the moment we recommend that you install a svn client (e.g. TortoiseSVN is my personal choice) and checkout emerge. One of the ideas that came up were that we could easily distribute our scripts from now on as a tarballed git repository (and maybe bundle it with git & python executables).

At the moment emerge uses different categories for different minor versions of KDE, e.g. kde-4.X/kdelibs etc. With Git, we want to move that (at least in the future) into branches of emerge; This would make it possible to easily build & develop older versions of KDE without interfering with more up to date KDE builds.

Together with PovAddict, I already started some tests for the git transition (he ran the scripts etc, and I tested it ;-)) but we came across a problem that is probably singular to us:
KDE git repositories do not allow crlf files inside the repo so we need to translate all of our files to lf EOLs on the server. In our checkout, we need to have some files as crlf (think of batch files and patches) and some files as lf only (the python stuff). My guess at the moment is that we should turn

core.autocrlf=false

(which we already do) and at the same time add a .gitattributes file which contains

*.cmd eol=crlf

or something like that (if you have more ideas, please let me hear them).

So far for now, more information, especially on our google summer of code project this year (which is about the kdewin-installer). hopefully later.

a new compiler error

While I am currently trying to get KDE on Windows up to a releasable state again (nearly done ;-)), I found an interesting compiler error with the new Visual Studio version (2010):

...
class Andere;

class Klasse {
    public:
        Klasse() : bc(NULL, NULL){
        }
    private:
        std::pair<Andere*, Andere*> bc;
};
...

Why could the above fail? Right, because NULL is not of type class Andere. (That works on the other compilers we have...)

sprint

Ok, long time no blogpost, but now that we speak about it at our KDE Windows sprint in Osnabrück, I'll try to make up a new blogpost.
Lots of discussions are going on here since a lot of time has passed since the last meeting in 2007, I will try to sum them up in a later point in a dot story.
As you can see from the picture below, the very minute we started the sprint, the sun came out.
Finally after bad preparation from my point we still managed to find together:


back: Patrick Spendrin, Ilie Halip, André Heinecke
middle: Patrick von Reth, Ralf Habacker, Romain Pokrzywka
front: Bernhard Reiter, Andreas Holzammer

Well, since Aaron raised one or two issues, I'll take the time to blog again.

Our primary goal for KDE on Windows is easy installability and a complete and stable KDE on the Windows platform. So the question is - where do we start?

Aaron mentions that our installer seems to be way more complicated than installing Linux and that a simple fire and forget installer is far better for a broader audience.

This is probably true and was already part of some discussions. The task of rewriting the packaging format is also not the biggest part. More tricky is the problem of updating the core package, which would then contain quite a lot of smaller libraries which are now handled by the installer. And the second point is: If you want to install more than one package, you might find a package manager far more convenient (on a side note: it is near to impossible to use the .exe installers as packages from inside the kdewin-installer). This part of course gets less important if you want to install just Amarok or just Digikam.

The second point Aaron brings up is how we see ourselves. Aaron says that it could bring a lot more for KDE if we see ourselves as the ones to deliver the libraries for other application developers and at the same time be our own consumers (in our role as the ones who deliver the applications).

The equivalent model would be the java runtime environment vs. java applications. I have been thinking about this model already for quite a while and it never really has vanished. On the other hand I must say that I think the priority is wrong. Until recently an external KDE application was not compilable out of the box on top of our packages (thanks go to Alex Neundorf for fixing it). A whole lot of shiny new KDE technology has no working backends under Windows (think of solid) or is really unstable (phonon). There are really basic bugs like you cannot copy files from one drive to another (recently fixed in kio_file), and last but not least on a lot of corners you don't have any system integration for your applications (this is somewhat similar problem to the missing backends). Personally I consider those issues far more pressing because I benefit from fixing those issues when using KDE applications.

On a more personal level now as it is already getting late:
One of the funny things is the usage of the word 'we' in and around KDE on Windows. This can have multiple different meanings: All the folks working on Windows (which excludes people not working on Windows), the people that distribute their software via the installer (excluding KDAB which uses a single installer for kontact), and not to forget the 'we' Aaron uses where he includes himself. That there is a difference between the first two has been made obvious here but I think those issues have been solved now more or less. The third 'we' is a general KDE one and sometimes also looks from outside: If 'we' have to change our way of thinking, then it is of course not the 'we' including Aaron who has to do something but the other two 'we'.


Enough ranting for now.

KDE Imaging Sprint

I just wanted to say that I returned home from KDE imaging sprint now and want to say thank you again to our host and the organizer of the event Marcel Wiesweg. We got quite a lot of coding done, some errors in Digikam and the kipi plugins have been fixed on Windows, so it was a really positive sprint. Some fixes are still waiting to be committed. I met some people I didn't knew in person before, which was really interesting too.
So all in all, a good sprint and I am looking forward to next years imaging sprint in France ;-).

yokadi on windows

While reading planet KDE a bit I somehow got caught by Aurélien's release announcement for Yokadi, "the command-line driven, geek friendly, sqlite backed TODO list". I was in need of such a tool already for quite some time, and so began to look at it.
First of all Yokadi is written in python using an sqlite database, which is basically the size I was looking for. Also it makes it possible to run also on windows... In the README it says that Mac OS X and Windows should work but haven't been tested and so I started my way through it.

To make it possible for more people to use this application I want to document what I needed to do to get yokadi working on Windows:

1. Install the python setuptools if you haven't done so yet. After the installation you might need to adjust your PATH to include the Scripts folder of your python installation so that the easy_install.exe is included.


2. get pyreadline, sqlobject and dateutils by simply running easy_install[PACKAGENAME]. Make sure you have svn.exe in your path for pyreadline. Except for this requirement, everything went smooth so far.


3. Now get the yokadi sources with git. I needed to add a patch, so make sure this patch is already contained in your yokadi sources. I send this patch to the mailing list and hope it gets committed soon.


4. After you made sure about the patch, run setup.py install from the commandline. This will install yokadi as a python site-package.


5. Set the EDITOR variable if you don't have vi.exe in your path. I installed the commandline version of vim for that: set EDITOR="C:\Program Files\vim\vim72\vim.exe".


6. To not add a HOME variable to my local environment, I made a yokadi.bat which basically sets the environment variable HOME to the directory where I want to store the database (and the history file) and then calls the yokadi python script in the scripts folder.

I haven't tried the yokadid daemon which is supposed to notify you about due dates: both because I don't like such notifications and as well because at least the master version looks suspiciously Unix-only ;-).
So far I am really pleased by yokadi, it matches my way to work (yes I use the windows cmd.exe a lot!) and I hope I can get rid of all those .todo files now :-D.

git web

As you might know I also work on Linux machines from time to time and so I tried to set up a git server on a local machine. After two hours trying to set up gitweb I simply gave up (That costed me a lot of nerdpoints as casper pointed out correctly!). Today I invested another hour into gitweb until I finally came to the conclusion that whoever writes such a bad documentation, doesn't want any users. So I decided to search again for something else:
There are various pages where alternative projects are listed, and after having tried git-php which is either not accessible (probably a self hosted git server) or which doesn't work as well, I finally came across viewgit. ViewGit's claim is 'to be easy to set up and upgrade, light on dependencies, and comfortable to use.'. Which it really is. The point is not only that there exists a rather good documentation in the source code (as you would like to have it), there is a readable README which also tells you what to do and if you try to access it before it redirects you to the README. All in all this is what I wanted & needed - it took me less than 10 minutes to set up. Kudos to the developers.

This is what I expect from open source software. Why is the rest so crappy?

build server web

It is not new anymore that we got a build server which runs windows and regularly builds KDE on Windows. But from now on we have a webinterface for the build server which for now can be found under http://winkde.org/pub/kde/ports/win32/dashboard/ . This means that build results can now be tracked more easily. This goes as far as having the complete logfile for the build available, basically the same you would have if you'd build on your own.

The advent of the web interface also means a second feature I will hopefully set online this weekend: nightly packages which always return the latest state of KDE. And I also have planned some more features: rss feeds for each package & for all packages, a history for each package (so you can check when an error has been introduced, etc.) and of course an improved error searching algorithm (it currently only uses the last 20 lines from the complete log as summary).

And last some pictures: Some of the stuff that doesn't build on the right side is my fault, but of course not everything:

new windows nightly builds and a question about nepomuk on windows

I don't want to make a big announcement out of it, just so you know: I just set up a nightly build server for KDE on Windows in the last days, which is supposed to build all our KDE packages on a regular schedule. Thanks to Qt Development Frameworks for providing the server and especially to Maurice and Danimo.

The server currently comes with a mailing list where broken packages are announced (kde-winbuild) and I hope I can provide a web page soon similar to this one. I hope this will make it easier to see build errors early and will make the life easier here on windows.

One other thing I fell upon is nepomuk and its companions soprano and strigi. Since I was asked about it and I couldn't answer (because I never came accross it!) I decided to take a look at it. The problem I found is that under windows, the indexing part (strigi) is nearly completely disabled - this also makes clear why no errors occur. Which in turn makes also clear that soprano and nepomuk might work, but since there is no index at all, the two do not really seem to make any sense.

So what can we do?

• we could try and fix strigi. This seems like a lot of work, since a lot of the strigi code is written without Qt support - using fork, sockets and some more non-portable stuff.


• we could disable nepomuk and rely on the build-in Windows search - this minimizes the work, which can be spend on other targets (solid, plasma etc.) then.

If by chance the windows developer base increases by a high percentage, we could reenable nepomuk then - or if we have nothing else to do anymore.

Personally I tend to fix strigi, but what do you think?

No more hungry evenings!

Just some minutes ago I got krecipes compiling here under windows - after just a few changes (What else would you expect!). Ok, it crashed because our mysql packages are not the best, I might have to improve those, but with sqlite it worked quite well (though a bit slow).


Just to give a small impression:



To say the truth, I was never really hungry, but perhaps this program makes me cook a bit more often? - Lets see.

Summertime

For those of you who haven't seen it yet, KDE on Windows made another release (only some days after the official release date - it is just me who needed nearly two weeks to blog about it ;-)). We introduced two "new" compilers, first of all Microsoft Visual Studio 9.0 Express Edition and second MinGW gcc 4.4.0. There are still some drawbacks when using MinGW 4, but we hope that we can fix those soon and then we can drop the old gcc 3 series (probably together with KDE 4.4).

Personally I am currently slacking off a bit. Last week I helped my sister to move her flat and at the end of this week I will go back to Iceland for one and a half weeks meeting some friends again. If you're around there, just drop me a note here.

Some days ago I decided to start a long term project of mine and with the help of my mother who is an oracle consultant I installed a small oracle 10g express edition database on my computer. So far we could get it running via both the OCI and the odbc sql-database plugin of Qt and everything seems to be as easy as I can think of. Look forward to some interesting news concerning Marble... ;-).

KDE 4.3rc1

Just some minutes ago I uploaded the first patches for windows packages for the first KDE 4.3 release candidate.
If you start the installer, you might find that the list of packages has grown quite a bit. This is for two reasons: first of all Ralf and I currently try out splitting the kde modules into subpackages, so that you can simply install e.g. Okular, without having to install kolourpaint (nothing against kolourpaint!). This will make it more obvious which applications you install and close a long waiting wish in KDE's bugzilla.
The second reason is that the number of packages has really grown: I added a (rather dirty) patch so that konsole can be build under windows, and this of course leads to some new features: kate, konversation, yakuake and kdevelop use the konsolepart to embed konsole into their applications. This is a long awaited feature I wanted to have, and I am pretty sure both code quality (so that I can commit the changes) and the number of windows specific bugs in it will improve in the next months.
Besides the packaging process, Ralf is also working on some improvements to our 'emerge' build scripts. He has nearly finished restructuring them completely. This will greatly improve the overall quality and will make those scripts more extensible and easier to fix in the future.