At least, please note that KDE on cygwin is a very complex application suite and
it helps us very much, if you can give good hints. (The more detailed and qualified information you can
give, the more is the change that you will get qualified answers).
You can use the content list of your archives to delete the unpacked files .
$ cd /
$ tar -tjf <your_archive>.tar.bz2 | xargs rm (for bzip2 archives)
$ tar -tzf <your_archive>.tar.gz | xargs rm (for gzip archives)
where <your_archive> should replaced by the name of one of your archives.
Repeat this step for all archives, you are going to delete.
If you have all your archives in on directory, you can try this:
$ for i in `ls *.tar.bz2`; do tar -tjf $i | xargs rm ; done
$ for i in `ls *.tar.gz`; do tar -tzf $i | xargs rm ; done
Note1: This commands may give you some messages about directories, which couldn't be deleted, you can ignore this message.
To remove your personal kde configuration, enter you home directory and delete the .kde2 directory.
$ rm -r .kde2
Each entry in this FAQ has to be added manually, and
that is not done every day. If you cannot find an answer here, look in the forums or the kde-cygwin mailing list. You are welcome to contribute.
For unix/linux newbies we have collected some documentation unde the following links:
Introduction about UNIX
Basic Unix Commands
Addtional you may take a look at the Google unix newbie search results.
Take a look on Amazon for a list of unix/linux relating books. Search for "Linux" or "UNIX".
If you see output like the sample below when you run
Could not init font path element /user/X11R6/lib/X11/fonts/Speedo/, removing from list!
Could not init font path element /user/X11R6/lib/X11/fonts/Type1/, removing from list!
_XSERVTransSocketUNIXAccept: accept() failed
X10: fatal IO error 104 (connection reset by peer) on X server ":0.0"
after 0 requests (0 known processed) with 0 events remaining.
then the version of Cygwin you are using is too old to
run KDE properly.
This error is caused by a bug in the standard Cygwin
1.3.2 release. You need to install the patched Cygwin
1.3.2-1p1 release, which you can find in the download
area or upgrade to a Cygwin release > 1.3.2.
The X server wasn't started. To verify that your XFree
installation is correct read the XFree installation
manual at http://xfree.cygwin.com.
Also check that if a .
xserverrc is in your
home directory, that it runs xserver. A sample
.xserverrc file is contained in the
The -whitepixel 255 and -blackpixel
0 options have been removed starting with version
4.1.0 of the XFree server. The corresponding arguments
should be removed from your .xserverrc file.
This is due to a conflict between Cygwin's DLLs and
QT's DLLs. Make sure you are using the most recent
release of the QT files from the download area.
Another possibility is to use the DLL rebase utility
kde-cygwin download area to avoid such collisions.
See below for examples:
View the address and size of a DLL:
$ rebase -l /opt/kde2/bin/cygkdeui-3.dll
ImageBase: 74410000 ImageSize: 001ee000
Rebase a DLL:
$ rebase -b 0x74410000
base = 74410000, new size = 1f0000
KDE requires QT. KDE is licensed under the GPL and
can't be linked to non-GPL libraries (some files from
early versions of KDE have specific exemptions for QT,
since the original QT was licensed using the QPL, not
GPL). The upshot of all this is that KDE can only be
linked against the GPL'ed release of QT X11, and not any
other version of QT, including the non-commercial Windows
native version of QT. Besides, even if the license issues
were resolved, the Windows native versions of QT are
built with MSVC++ and cannot be linked against objects
built with GNU C++. For the present then, we are stuck
using X11 until someone implements the missing Windows
native parts of QT and licenses them under the GPL. Even
then KDE itself uses some features of X in, for example,
DCOP (KDE's IPC mechanism).
At present he XFree86 server for Cygwin cannot be run
in 'rootless' mode (it can under, e.g. MacOS X) yet.
However there is some good news: Donald Becker is
working on a native Windows implementation of
xlib which would mean 'foreign' KDE
applications could run in their own windows alongside
'native' Win32 applications. His project is hosted on
On this topic mosfet wrote:
If you look at the sources of Qt, *very* little of
it is dependent on Xlib. Once you port QWidget,
QPixmap, QFont, and QFontMetrics, virtually everything
else is derived from that. 99% of the work will be in
those 4 classes. Xlib is used in very little of Qt
itself (for obvious reasons since Qt sells a native
Windows lib). You can tell TrollTech was very careful
to minimize the platform dependent code, because they
want to sell the Windows version. Porting the GPL
version to Win32 should not be a massive effort, since
it's the same sources used in the professional version,
just with the Win32 code missing.
There are other classes that would require some work
like the sound and network I/O classes, but KDE doesn't
use these AFAIK. KDE is also a lot less X dependent
than you'd think (which is why we also have
Konq/Embedded ;-) While KWin and KDesktop doesn't make
sense on Windows, getting the rest of kdelibs running
natively on Windows should also be straightforward with
a good Posix compiler.
Habacker (project admin) writes:
Somebody asked me, why one should port all this
software to this X&%$§ windows ? Another one
told me, that this would be perverse. Why are we doing
this real ?
I think, that kde is a great desktop and has the
oppertunity to be a big player in gui apps and desktop
area. Especially because of the famous qt library,
which is designed very platform independed and already
ported to many operation systems, porting kde
application to other unix based operation systems isn't
very much work. The one currently left operation system
Windows is the standard os in many companies. How
could this fact be used to enforce kde propagation ?
The answer is simple: Build something that allow kde
application running on top on windows. This goal we try
to reach with this project.
Paul Leddy [paul dot harbourlight.com] writes:
I setup Cygwin last night. Why not just get a Linux
box? Well, everybody can't just get a Linux box: maybe
they need the tools at a MS-based corporate job, maybe
there is a lack of cash, maybe a lack of know-how. So
making these incredibly useful tools available to them
instantly is wonderful, I think. And it is all
So what is the reason here? Compassion, giving,
What does that say to the commercial outlets and the
consumers? Consumers ask what they should really pay
for. Outlets ask what is necessary to create. It sends
a message to those who are thinking of going into
business building the same tools for Windows that
already exist on Unix-type systems. That message?
Already done; expand and add elsewhere. Or you have
competition, so do a better job somehow. Of course, it
will take time for this message to be heard and for it
to be effective, but it is getting louder everyday.
So what is the reason here? A bit of revenge and
some social efficiency.
By porting KDE, not only KDE, but hundreds of useful
tools will be instantly available. And not just the
command-line ones. What kind of impression does using
KDE GUI apps make on a newbie? There is an
Think of the impression made on the new and navie
this when they hear: "You can get that C++ compiler you
need for your college course setup at home [on a
existing Windows box] for free. Thanks to? Gnu. Heard
What kind of moral message does that send? Do you
think some who hear this message may look at the world
as a little rosier that day than the day before? I
Reason: spread the love.
January (developer) writes:
IIRC, the majority of changes are configuration,
autotool issues, etc. These (in theorey) should be
fixed now - although I haven't tried to compile KDE 3.0
out-of-the-box under Cygwin yet! (I'll make a mental
note to do so in the near future). Some are speed-up
issues that only apply to Windows (e.g. using Win32
native calls instead of Cygwin ones) and it doesn't
make much sense to back-port these. Other things are
bugs that only manifested themselves under Windows or
fringe operating systems - these have been fixed in KDE
Habacker (project admin) writes:
There is only little to add. Currently there are
some patches applied to the kde tree.
- KDE2 uses ':' in filenames, which isn't allowed
under windows (and I have heard in some other
operations systems too). Waldo Bastian has applied
this patch to KDE3.
- Additional some minor changes in the
kde-common/admin/Makefile.common are applied. This
belongs for example for problems with original
upper/lower case names used like "SUBDIRS" and
"subdirs", which under windows are the same and some
targets added to the .PHONY target, which are caused
by upper/lower case problems like cvs: and CVS dir
There are some patches caused by the auto-import
concept (basically this is a problem of the windows
runtime concept), which prohibits referencing to global
vars in dll's with an offset != 0. These patches has to
be applied to all further kde/qt releases (if compiled
with g++) and they are possibly candidates for applying
to the kde tree.
But anyway, the original kde source and any changes
we've made are in the cvs, so it is no problem to apply
any changes to the kde tree at any time (and if the kde
maintainer grant this).
Another point it much more important for the
kde-cygwin project. KDE3 has put the x11 relating
things in separate files like qt does for using qt embedded.
This makes creating of a native kde ports much easier as in kde2,
where one have to look into every sourcefile, if there are any
x11 relating things.
Currently I can't say, if this dividing is complete usable
for a native win32 port, but it seems to me as a great
step towards to a native running KDE.