[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-promo
Subject:    Re: [kde-promo] Final Article Final Final!!
From:       Jaroslaw Staniek <js () iidea ! pl>
Date:       2007-01-31 8:48:53
Message-ID: 45C057F5.1090106 () iidea ! pl
[Download RAW message or body]

Sharkscott said the following, On 2007-01-31 00:32:

Scott,
Fixes below, once again, please confirm you fixed all this (one minute of work):


> Make me stop messing with it...aahhhhh...:-)
> 
> Here is your advance copy..there are links in the text and at the end
> that are not included because it is not posted yet.
> 
> It will immeadiatly be available in the Features section but it will
> not hit the newswire until tomorrow. Look for it on Digg.com,
> Linux.com, Newsforge and more!
> 
> If you can get people to digg it and it makes the front page then it
> will get a TON of exposure.
> 
> 
> ---------------------------
> 
> 
> With KDE porting their applications to Mac and Windows the potential
> number of people using free software is unlimited. Imagine millions of
> people using Open Source Software for the first time..and getting
> hooked on it.
> 
> I had the opportunity to speak with several KDE developers recently.
> Benjamin Reed and Jaroslaw Staniek are just two 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?
> 
> Benjamin: On Windows many dependencies are not considered as "system"

NO, Jaroslaw

> 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?
> 
> Jaroslaw: For Mac, Nothing all that special other than XCode (Apple's

NO, Benjamin

> 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?
> 
> Benjamin: On Windows there is installer that installs the development

NO, Jaroslaw

> 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?
> 
> Benjamin: The timeline for KDE/Windows target is dependent on KDE4's

NO, Jaroslaw

> 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?
> 
> Benjamin: The current implementation of KDE is designed in a unix

NO, Ralf Habacker

> specific way, which is partially different from the Windows way.
> Examples for this are:
> 
> * Process creating - the Unix way of using Unix way of fork and exec.
> * It isn't available on Windows, this difference requires a redesign
> of the related parts.
> * Its missing Windows api counterparts.
> * KDE uses Unix domain socket for high speed data transfer betwen
> kioslave slaves and its parent process and for the communication
> to/from the dbus deamon. On Windows there are no Unix domain sockets.
> They could be emulated by tcp sockets with the costs of slower
> bandwidth and additional patches to deal with Unix domain socket files
> exchanged between processes.
> 
> 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 Ralf Habacker,
> 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 have, 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 to 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 day 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!
> 


-- 
regards / pozdrawiam, Jaroslaw Staniek
  Sponsored by OpenOffice Polska (http://www.openoffice.com.pl/en) to work on
  Kexi & KOffice: http://www.kexi-project.org, http://www.koffice.org
  KDE3 & KDE4 Libraries for MS Windows: http://kdelibs.com, http://www.kde.org

 
_______________________________________________
This message is from the kde-promo mailing list.

Visit https://mail.kde.org/mailman/listinfo/kde-promo to unsubscribe, set digest on \
or temporarily stop your subscription.


[prev in list] [next in list] [prev in thread] [next in thread]