...making Linux just a little more fun!
Recently, I had the opportunity to speak with several KDE developers. Benjamin Reed, Jaroslaw Staniek, and Ralf Habacker are three of the many talented developers working on porting KDE to Mac OS/X and Windows.
Can you tell me about the technical design of the Mac and Windows ports?
Jaroslaw: KDE/Windows should really be considered as "KDElibs/Windows and some KDE applications on Windows". Porting applications to KDE/Windows typically just means making KDE libraries and the build system more "portable". The source code of the applications is largely the same. As an example, I can mention that Kexi's source code, which I develop on Windows, is often committed to SVN without prior checking on other platforms. Then, I just update another copy of the same source code from SVN on Linux, and recompile. There are few, if any, and easily fixable problems with this method, usually related to difference between compilers. You get the idea; this is how portable development works.
There is one assumption many of the developers agree on: we re-use as much of the native interface as possible. However, we do not perform any forks that would make ported applications non-standard in terms of file formats or protocols. I personally tend to give up on a given functionality (and look for a replacement) rather than go with using a proprietary technology. A small example of this is my use of the 'mdbtools' project to access the MS Access file format, instead of using native Windows DAO/ADO API. This is not even a matter of licensing (because many APIs are considered "system-level" technology), but more about a strategy. Other examples of re-using lower-level layers are multimedia frameworks. An example of an existing facility that should not be replaced in a typical installation is the explorer.exe desktop shell.
Benjamin: For the OS/X port, right now there is no specific "technical design" beyond what KDE provides in general, and as far as the technical challenges involved, there is not a lot going forward that isn't a general challenge to the KDE codebase. I know that's not much of an answer, so I need to back up a little into the history of it.
Back in the day, Sam Magnuson (a Trolltech employee) did a bunch of work to rip out the X11-related code in the KDE3 codebase and got it to compile against Qt/Mac 3.x. I picked up where he left off, and did a lot of work trying to clean up the patches, make it look a little nicer, etc. Around the same time, the Windows folks had started working on cleaning things up on their side. Time went by, and the Mac port stagnated, mostly because I'm not really much of a C++ coder, and I'd hit the limit of what I was able to do on my own. No one else really had the time to work on it with me (although there was certainly still a lot of interest.) Most of my porting time went into maintaining other Fink packages, and keeping the Fink KDE/X11 port up-to-date and working smoothly. In that time, the Windows folks did a lot of awesome work on committing bits of my and Sam Magnuson's work, along with a ton of their own, cleaning up the code, removing X11-isms, etc.
Fast forward to KDE4, I talked with various folks in #kde-devel, off and on, about wanting to pick up the Mac port again, and about the feasibility of really making a go at it. One of the things that really made the port possible was the move to Qt4, and a real dedication on the part of the KDE core folks to try to use official Qt APIs for things that had been hacked-around at the X11 level in KDE3 (and a commitment from Trolltech to add proper APIs for things that required hacks before.) In addition, there were a lot of awful hacks that needed to be done to the existing autotools-based build system (automake, autoconf, libtool) to make things even build on OS/X against frameworks.
The move to the SCons build system made building on Mac feasible, and the subsequent switch to CMake made it easy: CMake has had a very large role in making it simple (and sane) to make KDE GUI and console applications cross-platform without a lot of work on the developers' part. Mac OS/X has a lot of quirks at the compiler and linker level that make it hard to understand building (especially dynamic-loading) if you come only from a Linux point of view. CMake makes that completely transparent. A lot of the ease of porting now comes from Alexander Neundorf's awesome work getting KDE to build with CMake.
So, to make a long story short, there used to be a lot of technical code hurdles to getting KDE to build on non-X11, but many of those were hashed out late in the 3.5 cycle, and early in the 4.0 cycle, thanks to the work of a lot of talented and dedicated people. At this point, there are only a few small platform-related issues for the Mac port, and the rest is really just a matter of keeping up with KDE4 development and fixing small problems before they snowball into big ones.
What were some of the technical challenges facing the developers?
Jaroslaw: The integration with facilities existing on the target platform and the look and feel.
There is some probability that in special cases platform-dependent looks will be configured. Think about toolbars on Mac and Windows, as well as features related to window management (full screen, etc.) Thanks to our API, KDElibs tend to provide well-defined helpers that behave appropriately for every given environment. Many of these facilities are also delivered by Qt - namely, the accessibility API - so KDE developers can focus on preparing higher-level facilities.
What were some of the technical requirements for building KDE on Windows?
Jaroslaw: On Windows, many dependencies are not considered as "system" libraries, so these are delivered within the so-called KDE development environment. The environment is needed only for developers, not users. The general rule here is that we try to have the environment as self-contained as possible, to make new developers' lives easier. There are two main compilers used on Windows: 'gcc' and MS Visual C++, aka 'msvc'. Since C++ does not define de-facto binary compatibility between compiles from various vendors, when distributing binaries, both targets will be (probably) distributed together.
Jaroslaw: CMake is used as a high-level build system for KDE4, on top of compilers and particular environments. This is a positive change, since for KDE3/Windows Qt's 'qmake' was used, without any chances for using advanced and automated configuration checks. Now, for instance, if you need MySQL support in your application, it is possible to declare this fact once in your CMake build file, and the build system will try to find all the needed facilities for this requirement.
KDE's relationships with Trolltech is well known. In version 4, KDE is even more a place where community and companies meet for mutual benefit. CMake is an advanced buildsystem delivered by Kitware, Inc. and others. In fact, it's not only delivered as-is but there are also CMake releases with many features needed, especially with a large project like KDE.
Were there any special requirements for Mac OS/X?
Benjamin: For Mac OS/X, nothing all that special other than XCode (Apple's GCC compiler set). KDE has a lot of dependencies to get the most out of it, so if you don't want to spend days compiling libpng, dbus, etc., then you probably want to install my Qt4 and "kdesupport" packages on the Web site. I provide pre-made packages, which include headers and dev libraries, so that you can pretty much just jump in compiling KDE SVN if you'd like.
What is the distribution strategy?
Jaroslaw: On Windows, there is an installer that installs the development environment. In the end, there will be a choice between installing just the runtime for users and runtime+development files for developers. You can get more information at KDE Lists.
On Mac OS/X, right now I'm putting together Apple Installer packages, with everything self-contained in '/opt' to avoid getting in the way of other software. Eventually, my goal is to also provide KDE4 through Fink, but I'm not going to bother doing so until we get closer to a beta quality, at the least, but even so I will probably continue creating the installer packages. I have it pretty much automated, and it provides a really easy way to just drop a running KDE4 setup on a system without any external dependencies.
|
Category: Promotion
If "adding" KDE to a Mac or Windows machine gets millions of people who otherwise would not try OSS, then so be it. I am convinced that once a person tries OSS, they will get hooked on it. |
What are the timeline, support options, and future development going forward?
Jaroslaw: The timeline for the KDE/Windows target is dependent on KDE4's plans. In general, porting efforts and updates provided try to follow the mainstream development, i.e., the one for Unix target. There are already people (including me) interested in commercial development using the development facilities of KDE on Windows. There is the KDE ISV subproject in development. There is no doubt the user base is growing, and we now have an active community around this target, which helps the KDE Project in general.
The design covers two steps:
1. KDE on Windows uses current code and similar packaging as on Unix and to have KDE applications as they are, with a minimum of required porting effort. This is to show people how it works and to get Windows in contact with KDE applications. In this step, the basic differences between Unix and Windows must be fixed (fork/exec and Unix domain sockets not available on Windows, no undefined symbols in shared libraries possible, different file path syntax, etc.)
2. When enough developers are available, they could make partial redesigns of KDE internals to use specific Windows features like named pipes for faster IPC, or be able to have standalone applications - for example, Konqueror or Kontact/Kmail - not require many additional background processes running, as is the case now. I can imagine having a redesigned klauncher, kded and kioslaves included into a standalone application; the latter may be using threads or something similar. Jaruslav has gone already this way with Kexi.
Are there more features and ideas in the works?
Ralf Habacker: The current implementation of KDE is designed in a Unix-specific way, which is partially different from the Windows way. Examples for this are:
There are different application interfaces. Windows, for example, has a TCP socket stack similar to the Unix one, but it differs in some areas, which makes porting harder. Windows named pipes have a completely different API, which required a partial redesign of KDE code.
After Qt4/GPL was released, our next step was clear: build a native kdelibs4 on Windows. The main problem is that we're too few people with too much work (starting with a native dbus implementation, and ending with a working KDE app on Windows, to show others that we are really moving forward). Because of this, I'm happy for any publicity to get new developers, which could help because we're all doing this in our spare time.
Some of the developers working on the Windows port are Peter Kümmel, Holger Schröder and Christian Ehrlicher. On the Mac side, there are Derek Ditch, Alexander Neuendorf, Marijn Kruisselbrink and Tanner Lovelace, just to name a few. There are many more who have contributed in the past that were integral in making these projects a success. All the hard work they have done will have the cumulative effect of exponentially increasing the number of people who get exposed to and use Open Source Software.
I believe that KDE porting their Desktop Environment to Mac OS/X and Windows to be a watershed moment for Open Source Software. By and large, people are resistant to change, and in all my interactions with strangers, friends, and family, I have learned creative ways to describe what using Linux is like, or how to run it from a liveCD or how to install it on a PC. I have learned to stay away from the word "change", and use the word "add" instead.
It is much easier to convince someone to try Open Source Software
if you describe it as "adding" something to his/her computer,
rather than "changing" it. Many who read this do not look
at "changing" a computer with apprehension or fear, but we are not
in the majority. If "adding" KDE to a Mac or Windows
machine gets millions of people who otherwise would not try OSS,
then so be it. I am convinced that once a person tries OSS, he/she will
get hooked on it. It is easier than starting smoking. 
From the day I first downloaded Firefox, my addiction and/or love affair with OSS has flourished unabated. It started with Firefox and progressed into using only FOSS within two years. Why? Because I chose to. After using it every day and comparing it to proprietary software, it was a "no-brainer" to switch to Open Source Software entirely. There was no loss in quality of applications, security, and functionality on my machine. There was a significant increase in the quality and choice of applications I could use, and by switching to Linux, my computer became a bank vault compared to whatever it was running Windows. How did all this happen? I started using one program, got hooked, and never looked back.
Soon, everyone who owns a computer will be able to try and use OSS, and all they will have to do is "add" software to their computer. That shouldn't be too hard; people add software to their computers every day, right? So, lets say that 25 to 50 million people who had never tried OSS before, try it because all they have to do is "add" some software to their computers. Those of you who have surfed before will know what I mean when I say this: you're lying on your board and you look out into the ocean and see a bulge in the water and you think to yourself "Is that the next big wave coming in?" The answer is yes - this is indeed the next big wave coming in.
Cheers!
Scott Ruecker
Links:
Talkback: Discuss this article with The Answer Gang
Scott Ruecker lives in Phoenix, Arizona. He works as an IT Manager and plays Drums in an alt-rock band every Saturday night. First exposed to FOSS when he heard about "This Linux Thing" in 2002. Got his start on Fedora, SuSE and Kubuntu. He currently uses Debian, Knoppix and DSL for his really old machines.
