Windows development just got tolerable....

There has always been this inane call to port KDevelop to windows so we can entice windows developers to Qt. Personally I think this call is bullsh*t, and think it makes about as much sense as saying "More people will use Macs if they port Adobe Photoshop to Windows." None the less, I still have to do windows development for some customers...

So I did what any sane person would do, and used KDevelop.
Yes, I use KDevelop for Windows development. No, I don't use Linux to develop and then recompile on windows. In fact I do not have Windows installed at all. No, I did not port KDevelop to Windows. Instead I patched QMake to better deal with cross compiling, and then made a makespec file to use mingw32 as a cross compiler, and wine as a tester/debugger. The resulting binaries work perfectly on windows with no ill effects. In my opinion philosophicly and economicly this is the best way to go. Why pay Microsoft to develop apps for Qt? With this setup, I can use Commercial Qt to develop my windows apps without paying the Microsoft tax, and I can use an ANSI compliant compiler without penalty.

This is the future people, we don't need to port more Linux apps to Windows, we need to make Linux a viable platform for ALL software development. Ideally the Trolls will get the message and promote this behavior more too...



Considering your compilation is performed to build commercial offering - just build an .exe is not only thing you have to do, right? Other things are:
-testing on more than single PC box
-testing an app for clean MSWindows installation (2k, XP, different Service Packs, and depending on target user base: also for 9x, Me); testing on _typical_ dirty installation, eg. if your app doesn't interfere with other components
-build installer, testing it (there are free installer creations apps, but not portable) on MSWindows

What I've mentioned above is not so important if you're delivering MSWindows PC boxes with your software, but this is not the case, I suppose?

Maybe you've diferent, specific needs, but all this is a part of my and my coworkers task (for Kexi and other apps), and, in my experience, something what customers are paying for. Really, Qt doesn't protects us for all differences between 9x and NT.

Jaroslaw Staniek / OpenOffice Polska
Kexi project: http://koffice.org/kexi/ http://www.kexi-project.org/
Qt-KDE Wrapper project: http://iidea.pl/~js/qkw/

By Jarosław Staniek at Sat, 06/12/2004 - 07:36

Since we don't rely on the random method of clicking around an interface to test if it works the need to do your form of "testing" is not needed. As for packaging Cabwiz works perfectly under wine, so there are no issues there, we can build an MSI installer just as easy as under Windows. (in fact somewhat easier, cause we can automate it into our make process) I am shocked you have not even bothered to research this.

In fact, Qt insulates us from any quirks on various platforms, and unit tests ensure that there are never any code mistakes. Yes if you do software development with the way Kexi and OOo do, you must resort to randomly checking random architectures for random behaviors... then again thats the difference between our quality and OOo and Kexi, I can bet we have less bugs in our 10kloc or 100kloc of source than 1kloc of Kexi code. ;) (Actually anything divided by zero is infinity, so I guess thats not fair)

Zero defects is very nice place to be, you should try it sometime. Users have no time to wait for the dinosaurs of technology to catch up. A different methodology makes it possible for us to do things quickly, inexpensively, and right.

By Ian Reinhart Geiser at Sat, 06/12/2004 - 19:32

Mmm, I agree. If it doesn't just work with the minimum of testing then being able to do cross-platform development is rather pointless really. The extra effort in testing doesn't warrant it, and that is why toolkits like Qt exist in the first place. I can't speak for Kexi because I haven't looked at how the code or how it works (functionally it looks like a nice application), but what's wrong with it?

On the other hand, I've had a good look at the Open Office code and the Ximian hacking docs, and it is truly HORRIBLE. Everything lumped statically into the code, and stuff such as:

This is due to some very serious crack smoking going on in stlport. Essentially, there is some nasty header overriding, and they want to be able to fallback to the previous header (with the same name) - thus they have to hard-code the paths. To save doing that in lots of places, they use a #define, the #define has macro expansion done on it. Thus if your gcc prefix contains an element which is a macro - you're stuffed

Sorry, but that's no way to maintain any software, particularly free software where time and effort are at a premium. I was pretty shocked by reading through it all, and Kendy has my sympathies on working with such an abomination. No wonder people think that C++ is terrible.

Functionally Open Office is good, which is why I think everyone goes for it, but over time I think it is just unmaintainable. Seriously, people should just get behind KOffice and some interested parties should fund some decent filters.

By segedunum at Mon, 06/14/2004 - 19:12

why not use the OO filters? then at least koffice is on this field on par with OO, and one important reason not to use Koffice is gone... I mean, for writing letters it is perfect, the only problem I have are the ms word docs. I still use Koffice, but it can be a pain in the arse ;-)

By superstoned at Wed, 06/16/2004 - 14:10

Did I just not mention that OO code is absolutely terrible? That includes the filters as well.

Integrating these into KOffice is nigh on impossible because the code would have to be deciphered, and then retro-fitted from Open Office to KOffice. It just isn't doable. Open source software isn't everything.

By segedunum at Thu, 06/17/2004 - 19:22

I use kdevelop for embedded apps (avr development). It suits that niche very nicely; I just wish I could have it at work under windows...

By mvdw at Mon, 07/18/2005 - 22:59