The Open Source Hook: Porting KDE to Mac and Windows
I had the opportunity to speak with several KDE developers recently. Benjamin Reed, Jaroslaw Staniek and Ralf Habacker are several of the many talented developers working on porting KDE to Mac and Windows respectively. They explain in detail what's involved in making KDE and its myriad of applications boot under Mac and Windows. Can you tell me about the technical design of the Mac and Windows ports? Jaroslaw: I'll refer to KDE/Windows as to "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 are 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 it 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, easily fixable problems with this method, usually related to difference between compilers. You get the idea, this is how the 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 which would make ported applications non-standard in terms of file formats or protocols. I personally tend to give up with a given functionality (and look for replacement) rather than go with using a proprietary technology. A small example of this is my use of the mdbtools project to be able to access MS Access file format instead of using native Windows DAO/ADO API. This is not even a matter of license (because many APIs are considered as "system-level" technology) but more about a strategy. Other examples of re-using lower-level layers is multimedia framework. An example of an existing facility that should not be replaced in a a typical installation: explorer.exe desktop shell. Benjamin: For the OSX 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 API's 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 developer's 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 look will be configured. Think about toolbars on mac and windows as well as features related to window management (fullscreen, 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 deliverred 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 only needed for developers, not users. The general rule here is that we try to have the environment as self-contained as possible to make new developer's life easier. There are two main compilers used on Windows gcc and MS Visual C++,a 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 a MySQL support in your application, it is possible to declare this fact once in your CMake's build file and the build system will be trying to find all the needed facilities for this requirement. KDE's relationships with Trolltech are well known. In version 4, KDE is even more a place where community and companies meet for mutual benefit. CMake is an advanced buildsystem delived by Kitware, Inc. and others. In fact it's not only delivered as-is but there are also CMake releases with may features needed especailly so as large project as KDE is. Were there any special requirements for Mac? Benjamin: For Mac, 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 installer that installs the development environment. In the end there will be a choice between runtime for users and runtime+development files for developers. You can get more info at KDE Lists On Mac, 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. What is the Timeline, support options and future developments going forward? Jaroslaw: The timeline for 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 active community around this target, which helps 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) 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 contact/kmail not to be required to run as many additional background processes as now. I can image to have a redesigned klauncher, kded and kioslaves included into a standalone application, the latter may be using threads or 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 ends with a working kde app on windows to show others that we 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 and 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 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 their computer rather than "changing" it. Many who read this do not look at 'changing' their 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, to try OSS then so be it. I am convinced that once a person tries OSS they 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 too. 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, Your laying 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 the next big wave coming in. Cheers! Links: |
| Subject | Topic Starter | Replies | Views | Last Post |
|---|---|---|---|---|
| KDE-Win :P | jimf | 22 | 4,340 | Feb 1, 2007 2:43 PM |
You cannot post until you login.
|