Slow but steady progress

There was not much (visibile) activity in the last few weeks. This is mostly due to the fact that I've a new job since october. Have to learn a lot but can also help my co-workers with my knowledge (mostly about how to fight with msvc ;) ). I'm working with OpenSUSE 10.2 here. It's nice to work on a linux system at work after 3 years with winxp & msvc...

In the meantime Ralf updated his kdewin-installer a bit. It's now much more usable than before - the dependency checking is working now. Also a lot of other small problems are solved. For a complete changelog see here.
Saro was very active too. He found his place in the kde-edu project and tries to make the apps ready for 4.1. We can't release something which could be called stable for 4.0 on windows (it was never our plan) but we hope to get beta quality when kde arrives at 4.1. Saro also works on our emerge buildsystem. Looks like students have too much time ;)

Last weekend I had some time and used kdesvn-build to install kde4 on OpenSUSE 10.3 on my laptop. It was an easy task (used kdesupport from suse repository so I could start at kdelibs) and I hope that our emerge build system can do the same when it's ready. I also managed to start a kde4 session. Apart from some crashes all worked fine. But I wonder why X used > 50% CPU when I opened a plasma widget (e.g. the rss reader). My ati drivers are up-to-date so opengl/whatever should work fine.
The good thing is that I now could try to reproduce problems occurring on windows. For now I can say that most of the crashes/problems I have on windows are also happening on linux. So for all who think kde4/linux does not gain from our work here's the proof :)
I'm also thinking about moving to kde4/linux on my workstation - currently I see more need in a working kde4/linux than fixing some problems on windows. But this will not happen until I got a new workstation - my old duron1300 is simply to slow for a daily kde recompile :)

And if you wonder if I also do something else than working and hacking on kde4, here a picture from my last visit at home:


Due to the high temperatures in the last days Mr and Mrs snowman are already history... :(

KUrlNavigator on windows - or: Never try to fix a bug

While trying to fix a bug in kate I hit a lot of other problems. First it was not compilable (although it was not monday) because kdelibs wanted to have soprano 1.97.2. Then another bug in the cmake scripts hit me. Saro fixed this and I was happy to see if me fix for the bug was correct.

So I started kate, opened a file and... crash! Next start with debugger, kate asked me if I want to overwrite 'Default Session.katesession', I select yes but kate doesn't care and asks me again. After checking if the permissions are correct I decided to start another debugger and see what kio_file is doing. I ended up using an own implementation of FileProtocol::rename() for windows. Also moved out copy(), delete() and some other functions (think we should move all those functions into platform specific sources).

Now kate overwrites the file without asking me more than once and I can go further to see why the first crash happens. But this time it was an easy one. I forgot to install kdebase-runtime (wiped out complete kde4 installation before) and now KIconloader tried to add an empty QPixmap to (Q)KPixmapCache. Looks like nobody else did this before on windows because it simply can't work. Ok, added a hack, wrote a mail to qt-bugs and installed kdebase-runtime.

Started kate again and waited for the next crash. Out of curiosity there was none... opening a file worked like a charm. Ok, at least on the first sight ;)
Changed some things in KUrl and KUrlNavigator to fix problems because it's assumed everywhere that '/' is the one and only root path. Not that big problem and in the end I fixed my first bug from bugs.kde.org :)

While fighting with KUrlNavigator I saw that we can't change the drive - I can just open and save documents on the same drive like kate. Because having kate on every single drive isn't a good option I came to the conclusion that KUrlNavigator needs some tweaks for win32.
Now I wonder how you would like to have KUrlNavigator on windows. Here the screen shot from the native file open dialog:



As you can see there are two pseudo directories above the drives. I would like to add this to KUrlNavigator too - except you've a better idea how to select the drives. But keep in mind that we should use a similar approach like above to not confuse the users.

Next try - kde4 beta4 for windows

This time I made packages for msvc and mingw. This should make those happy who don't like msvc (but nevertheless use windows). Don't know if it's working - you'll see :)
I know for sure that the msvc ones work now without the crappy hack with the debug runtime libs. Simply used the same approach like you do on linux - compiled in release mode with debug informations. CMake already provides a a build type but I did not noticed this earlier...
Kopete does not work - I tried hard to understand how kopete and kwallet/kded/dbus work together but found no hint why it does not. I tried it on linux and everything was fine.
Oh - the dependencies in our kdewin installer do not work correct. So if an app complains about missing dll, try to find out in which package the dll is and install it. Sorry for this, but currently it looks like only two people have time to work on kde4/windows.
And please update your kdewin-installer to 0.8.1. I've added .tar.bz2 support to reduce the package size a little bit. This should reduce my upload time - uploading 1.5GB with 396KBit/s isn't fun...

Update on kde4 for windows

There was a lot of trouble yesterday. I made a mistake and therefore the apps were crashing on startup because of missing msvc debug runtime libs. I've now added a new package 'msvc8-runtime-msvc' to address this issue.
And I've also uploaded a new version of the installer (0.8.0-2) to hopefully fix crashes on startup. There's also a version which is not packed with upx - maybe upx is the problem here...

I've also added some new questions to my last blog entry. If you still have problems, plz ask at #kde-windows or our mailing list. I'm now doing some geocaching so I can fix the installer dep problem this evening :)

kde4 / win32 beta3 binary packages available

They're finally released :)
I uploaded them this morning, but then I realized that the installer does not show them... so we had to fix the installer. Ralf then found another quick fix for the problem on the server side (our parser had problems with spaces in the path) and simply renamed the path.
Ralf did not told it to me and therefore the packages were released and I did not knew about :-D
Nevertheless I also fixed the installer and uploaded a new version (0.8.0-2) which you can grab here.

Here are some questions you might have when you're trying to install the packages:
Q: Why does the packager also downloads a lot of packages I did not select?
A: In contrast to linux there're no 'system' libs like libpng, libjpeg, ... available for windows. But they're needed by kde4 and therefore we packaged them too.

Q: Why does the kdewin-installer installs the 'Microsoft Visual Redistributable Package' every time?
A: Our installer is not complete yet and lacks support for 3rd-party binary installers. Therefore it can't know if this package is already installed or not

Q: I can't start an application because of missing dll's / crashes on startup
A: The problem is that some dll's are in kde\lib instead kde\bin. We already moved a lot to bin but get not ready for beta3. For now simply add kde\lib to your PATH environment variable

Q: Why does pop up a command line window named 'dbus-daemon' every time I start a kde app?
A: DBus is one of our bleeding edges and we had no time to make this app run as a service.

Q: An application is crashing - what should I do?
A: There are a lot of bugs in kdelibs4/win32 which can lead to a crash. Try to reproduce the crash on linux. If it's crashing there too, report the bug to bugs.kde.org. If you can't test on linux, also report to bugs.kde.org :)

Q: Hey your crap is constantly crashing - and this is named 'beta3'???
A: Although it's beta3, the platform specific source for windows is in early alpha stage. We currently plan a release for windows which can be called beta in the timeframe of kde 4.1. This is mostly due to lack of time from our site (we're all not paid for this work and do this in our free time)

Q: I get 'The program can not initialized correctly ...'
A: M$ is stupid. They do not ship the debug runtime with their vcredist package and therefore you can't start an application (you need to have VS 2005 SP1 installed). We're working on a solution.

Q: Why are there no packages for mingw?
A: I did not see a reason for this in this early phase of kde4/win32. The end user doesn't care and a developer should compile kde for themself. If you've problems compiling kde4 on windows, join #kde-windows and ask for help. There're outdated mingw binaries available for download. I don't suggest using them.

Q: My applications are crashing on startup!
A: I only tested the apps on my development system. Therefore some libs were available which you normally does not find on an end-user system. We've uploaded a new package named 'msvc8-runtime-msvc' in kdesupport section. After installing this package, all apps should start. If not let us know (#kde-windows or kde-windows@lists.kde.org)

Q: There are still missing libraries!
A: Our dependency system is not bug-free yet. Therefore sometimes the packager does not select all needed packages. You need at least all packages in win32libs and all packages in kdesupport.

And now start downloading and enjoy! :)

Small delay for kde4/beta3 packages for windows

Yesterday evening I found a bug in kstars which cause a crash on startup. Because I want to have a working kstars application in kdeedu package, I decided to do some investigation on this problem. After some debugging I could fine the problem and added a workaround (although a separated thread would be better there, I'll see if I find some time for this). Later this evening I had not time the rebuild the beta3 package for kdeedu 'cause I wanted to cheer my girlfriend on her table tennis match. Sadly it did not help much... :( We arrived back home one o'clock this morning and I initiated the packaging process hoping all compiles fine.
This morning I learned that I should never hope that something runs smoothly until it really worked - somehow the emerge script fetched an old header... this means that I've to restart with kdeedu this evening and after uploading all the stuff I'll let you know how to get the packages (and what to do to get it running)

Still not released a snapshot of kde4/win32

I'm sorry but I still had no time to release a snapshot of kde4/win32.
There were two big problem I hit before I could even think of trying to compile kdelibs with our emerge-scripts.

The first one was Qt - looks like nobody ever did a 'make install' with Qt on windows. After five mails to qt-bugs I ended up with four public
four public task-tracker entries with no priorty... :(
At least qt now install all things correct with my local patches.

The second one was CLucene. As this dependency is now mandatory for strigi and soprano, I had to find out a way to compile it on win32. Thx to cmake a (more or less) small cmake script helped here. Now it compiled fine with msvc and this normally implies that it's no problem to get it compiling with mingw too. This was a big misapprehension (and a good example how not to write platform independend code). clucene-config.h is needed for mingw...
After adding ~60 configure-checks and a lot of iterations trying to compile strigi/soprano it finally worked.

This means that I can now start compiling kdelibs on windows but I wonder if I should wait for beta3.

Two beer or not two beer - or 'What compiler to use on windows?'

During our KDE-Windows meeting in Berlin we had a big discussion on compiler support for kde4/windows. I for myself only wanted to distribute mingw binaries because we should not forget our roots. On the other side the mingw compiler is not the fastest one and debugging on windows with gdb is a pain. Here msvc has a big advantage with it's superior IDE Debugger which is imo even much better than kdevelop+gdb on linux.

And now yesterday trolltech annonced that they will support msvc8 express (and I hope for nmake too, did not take a look yet) for the opensource version and the discussion about whether to use msvc or mingw reached the public. One advantage of this step is that I've no longer create packages to add support for compiling qt4/windows opensource with msvc.

Another problem is that mingw support on win32 is uncertain because the maintainer of gcc/win32, Danny Smith, left mingw just after the second release candidate of gcc4.2.1. That's really a bad sign... :(

We even face more problems because we can't mix msvc debug and release libs. This will force us to rename the debug libs and add a debug postfix. Currently it's only implemented for the kdesupport libs (and all c++ libs below). Adding this feature to kdelibs would blow up FindKDE4Internals.cmake because we then everytime have to distinguish between every debug and release kde4 lib. Maybe I should take a look into cmake macros... :)

I still don't know how to decide... for now we maybe should ship the libraries for both compilers - what do you think?

Back online again

After two weeks without an internet connection at home I'm online again. My ISP told me that I've to wait until next Friday, but somehow it's already working... :)
Although I still had to clean up my new apartment, I started to update some dependency libs. The problem here is that this work is still not automated (mostly during my lack of python knowledge) and therefore it's not failure-proof and takes some time. But I'm on a good way - libpng package is now automatically created by Holgers emerge scripts. Only twenty packages left ;)

real life is calling and a note regarding kget

Just want to give a sign of life. Real life needs some attention and therefore I've no time for real kde4/win32 development. I'm moving to a new appartment in august and hope I'll get all done until september. The only problem I fear is that my internet provider told me that they need two weeks (in the best case) to switch my dsl to the new home... :(

In my holidays I met the kget developer Manolo Valdes. He lives in cuba and I'm very impressed how he contributes to kget development. Cuba is a socialistic country and a normal person can't have an internet connection at home. You only have a chance to get into the internet when you're working in a big firm which has a 'high'-bandwith internet connection (high means 256KBit/s for the whole firm). Due to some nice fortuities he managed to have a wireless connection from his home to the firm and can therefore go to the internet...
I think this effort should somehow be honored but I'm unsure how to do so. Sending something to cuba isn't a good idea because it mostly doesn't arrive where it should (The other way round it's the same - don't expect to get a postcard from cuba). The only way I see is to make holidays in cuba/varadero. My problem was that I did not know about Manolo two days before the flight and did not bring along anything usefull.
So if someone intends to make holidays in cuba, let me know or directly contact Manolo :)

Funny discussion becomes serious

Thx to aseigo the discussion changed from a dumb rant against windows users (and programmers) into a really serious discussion. I hope this discussion will continue on Akademy (I'm afraid I can't be there) and comes to a conclusion so we don't get the same discussion every year...

Maybe some of you should think about their opinions about windows devs. Just because we're developing on a platform you don't like we're not evil in any way. We respect your work as we hope you respect ours. I'm developing on kde4/windows because it makes fun (there is not much difference between linux and windows development) and I've got a lot of knowledge about windows development because of my work (Yes, open source devs also need to do some paid works sometimes). All work I've done for kde4 was done in my free time...

I'll be away for the next three weeks. Hope that I've the luck to meet the kget developer Manolo Valdes and do a 'cuba akademy' - wouldn't this be a nice place for the next akademy? ;-)

Funny discussion

Although I know it's impossible to win a discussion with aseigo (I even wouldn't win them when I would write in my mother tongue) I try to ask some questions and show my point of view.

For me it looks like the fanatic linux guys (the one from the other side aren't better) are afraid of loosing something when a program is running on both os. But nobody could explain what they think they'll loose. You say when an app is available on windows too, they user never comes to the idea to switch to linux. I say - if the program is not available on windows, the user will never use it at all and also will never know that this program is available on linux.

Like you don't see a plan how the porting to windows can make the free os more attractive, I don't see a plan how you want to convince the windows users to switch to linux. Do you really think that creating nice programs and telling a windows user how good this program works on linux is the best way to make him switch to linux? You may say that he can use a live cd - but I don't think that using a live cd for a few hours is the right way to gain new users...
And you don't have to boggle from us - we don't use the win32 api more than you use the linux-kernel api. ;)

Maybe a sentence why I don't use linux as my primary platform. I really don't know why. I maybe easily could switch to linux. Nearly all programs I use (non of them is a kde app because it's currently not possible to use a kde app on windows...) are available on both platforms or have a (more or less equivalent) counterpart. It's just a matter of taste - and isn't this what foss stands for - having the opportunity to use what you want and don't get stuck to a specific operating system?

One note for Derek Kite: It's just stupid what you say. Either you use a framework and learn to use it (with all it advantages and disadvantages) or let it be. It's totally nonsense to blame a platform independent framework like Qt to not support all platofrm specific goodies.

K3Process porting progress

Just a notice to all our app developers. If you want your program compiling and running fine on windows, you have to make sure that you don't use k3process anymore. Since ossi added the new kprocess class, k3process does no longer work on windows (because of this, kdelibs was broken the whole last week for us). We ported kdelibs, kdepimlibs and kdebase (though there are still some references to k3process - but this code doesn't compile on win32 either).
Here the link to the wiki page with all sources containing k3process: K3ProcessPorting. Please add a note when you successfully ported your code to kprocess.

And no - the screenshots from my last blog are not taken from a mac. It's just a custom windec which I used for testing purposes. But since I like this style - does it mean I should try out a mac?

kdeedu screenshots

Compiling and running kde-edu apps on windows is quite easy. Although they depend on kdelibs, they don't use much functionality from there. The hardest part were the various mathematical functions for kalgebra.

As you can see, all programs start fine and the most functions are working. Now we just need working kioslaves (impatiently waiting for thiago to fix them at akademy) and a nice installer because there's no way to convince a normal windows user to run cmake and nmake some hours only to play khangman ;-)

dbus on windows

Yesterday there was a request on qt-interest about the current state of qdbus/windows. This is now the second request on this topic from a company evaluating the use of dbus on windows :)
The other one already contributed to the windbus code base. They want to use it on windows CE - looks like we can soon compile Qtopia with dbus there. Let's have a look until someone is interested in running kde apps on winCE.

Some people may ask why we still don't have a working windbus implementation in the mainline dbus cvs. I think the main problem here is that our gnome friends don't have a real interest on porting their apps to windows and therefore don't care much. Hope they'll change their mind with the increasing (commercial) interest using dbus on windows...

Patch for Qt 4.3/GPL and msvc is coming soon

I'm currently working on a new patch to make Qt 4.3/GPL compile with msvc. As Trolltech now ships the source code of configure.exe, I can create a modified one which doesn't complain about the wrong QMAKESPEC anymore. This will allow us to enable MMX, 3NOW and SSE support (mingw seems not support this and therefore it is disabled then) which should improve the performance in some places. The modified executable also removes the need to patch qconfig.cpp/qconfig.h after the configure-run :)

Afaics Qt 4.3 will be the last version where I can create a patch for. I'll get a commercial license in the near future and therefore I'm not allowed to create a patch for the GPL-version anymore.

Start

Within this blog I'll enjoy you with my famous knowledge of the english language and also try to tell you about my work on porting kde4 to windows.
The idea behind this is to get some more attention outside the kde-windows mailing list, to show what problems we have and what I want to gain from this efforts.

That must be enough for now :)