some updates

As you might know, I have been working on digikam a lot lately and today I uploaded the new beta6 packages for the 4.1.X release series; included are of course kipi-plugins beta4. Now Digikam on msvc should not crash anymore and both mingw and msvc builds should be able to add images to albums.

To improve digikam even more, I am trying to lower the start up time needed, and of course I know the marble widget best. So I can now tell you (even though this was a rather easy task) that I cut down the startup time needed by the two marblewidgets by about 19%. This is not the end yet, and until the release, tackat and I hope to get this even further down.

One thing that is rather fresh from my desk is that I succeeded to compile kile (and fixed some builderrors). This means that you can look at this wonderful latex-editor, but of course this doesn't mean anything: As I have no latex environment and neither to much time & space nor to much knowledge of latex itself, I search for somebody interested in these topics and who could try to build kile on windows as well, look how to get all things needed to run kile decently and write some tutorials and file some bugs. Somebody interested?

crashfixing

As I was working on digikam porting recently I made some first packages - and of course those were not even starting up. Well, to be a bit clearer: the packages build with msvc (Microsoft Visual Studio) crashed both in

png_read_info

for png images and in

jpeg_read_header

for libjpeg. This seemed to be rather odd I thought, as there seemed to be a lot of applications using these libraries for image i/o. But as I found out, most don't use our dll but instead a static version of it. That wasn't an option for me though.

To understand the crashes a bit more I found a good explanation here. Basically the problem is that msvc will link to different runtime environments (our libpng/libjpeg dll against msvcrt and our digikam binaries against msvcr80) and each of those runtimes has a different idea of what a FILE pointer is. When trying to actually do something with your FILE pointer, you will get the crash.

The solution to the png problem I found in a french forum, I did what they said and now it works (diff). The solution to the jpeg problem is a bit harder as it requires some rewrite/addition. You might have to replace my QByteArray with whatever you use to store the complete file content but essentially it is everywhere the same (changes): I got it from here.

It is tall! not great...

I am back already since sunday evening from the KOffice meeting; I have to say it was a rather great success. The KOffice folks could get two of my koffice errors fixed, one even in qt-copy (patch 0258), and while looking we even found a crash which got fixed too. So all in all a rather good amount for a weekend.

Yesterday I formulated some bugfixes and features I would like to see in KDE 4.2 release on Windows. The first one I basically fixed myself right away, and today I tried out something new with plasma. As you all might know there is this concept of desktop shells, where plasma seems to fit into really well - and now I can say that it is true and it works on windows too. Still we have tons of stuff to do before it is slightly usable: we have no list of tasks (in progress), we have no system tray, there is no integration of the native windows menu into the plasma menus(planned). Even worse is that if you start explorer.exe while running plasma as shell, the default shell will appear again(to be fixed soon).

As you can see, there is still a lot of work to do, we are open to all new people and if you want to lend a hand, simply drop by on irc or have a look at our mailing list kde-windows[at]kde[dot]org.

KOffice Meeting Day 1

After I missed slangkamp at Berlin Hbf. due to my train being 40 minutes late on a 1 hour trip, I arrived at KDAB Berlin Office and started to look around a bit. After some minutes I got jaham and slangkamp interested into a special KOffice bug which only existed on windows: one of the color choosers simply was showing a black rectangle instead of painting the color gradient it should show. So we started to investigate this, first within KOffice (KoColorSlider) - it was no KOffice bug. Then in KDE (KSelector) and it was no KDE bug as well. But at least we could have worked around it in KSelector. But then again Jaham had the idea to look into the Qt sources - and there we found the bug. It was simple, 3 additional lines in qtgui4 and this was one of the points where you can definitely see why it is pretty important to have open source software: we could really fix the bug instead of working around it and hoping that the implementation will stay the same for future Qt versions...
The downtime was: 3-4 people were looking for this bug for roughly 3 hours - so much work for such a "small" issue.