Windows/FAQ

Technical

How to replace windows explorer as shell?

Download and run autorun from http://technet.microsoft.com/en-us/sysinternals/bb963902.aspx - enter the tab 'Logon' and replace the value of HKCU\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\Shell with the plasma-desktop path - but - be aware that explorer provides almost everything in the system settings area and other stuff.

What versions of windows does KDE windows work on?

KDE4 is known to run on various versions of Windows XP and Vista, as well as Windows 7.

Is it easy to uninstall if I don't want it on my system?

It is easy to uninstall. You can run the installer and select the "Remove installed packages" option. To clean out your personal settings, you will need to remove the ".kde" directory in your Application Data directory (%APPDATA%).

Is it stable?

No, it is not stable yet. While most of the applications should run fine, there are a lot of problems that come in with porting software to new platforms. The KDE on Windows team is working hard to fix bugs and resolve issues with this port, so be patient and let them know what you think.

Is it possible to replace Windows' WM with KWin or would it ever be?

It is possible to use replace windows shell (called 'explorer.exe') with our 'plasma-desktop.exe'. This would give you the normal background (e.g. the widgets and the taskbar) of the Linux desktop. Since for plasma on windows there are still key features missing (as a working taskbar, multiple desktops, a system tray and the integration of the windows start menu) the easy way to replace the shell is not yet enabled (it will be as soon as the above features are implemented).

Reasons for KDE on Windows

... tell me who except über geeks need KDE on Windows?

We need KDE on Windows for three reasons:

1. Most businesses can't just switch to Linux. I've heard more than enough stories of workers being stuck with Windows as they're of course not allowed or able (because of special apps) to convert their boxes to Linux. KDE might provide them with a comfortable working environment to which they are used.

2. Most businesses won't suddenly switch. Clear step-by-step migration paths (Windows + Office + Explorer -> Windows + OpenOffice + Konqueror -> Linux + OpenOffice + Konqueror) make it easier for the IT deciders to enter this process. (Something along the lines of "If the users do not like Konqueror, they can still use Explorer.") Yes, I know that Konqueror is not a good example, as many Windows users have just learned Firefox and will most probably not look into learning yet another browser.

3. Having FOSS applications available on the Windows platform is crucial for attracting users. Not many people go into the store and buy a SuSE box, but many people get single FOSS apps like OOo or Firefox because they read about it in some magazine, or some friend recommended it to them.

KDE on windows attracts developer

A few years ago (leading up to Akademy 2007 IIRC) we had a huge discussion on the planet about the merits of making KDE applications available on Windows. The core of my argument for doing that then was, and still is, that its really in the interest of KDE to do this because it attracts developers who would otherwise not contribute.

Take Amarok for instance. The core developers spend very little time on making Amarok run on windows (I think the total amount of work I have done on this amounts to one time changing the order of some things in a CMake file as someone reported that it otherwise broke the build on Windows.) So all in all, this is not something that takes much time away from developing Amarok itself. On the other hand, the original implementation of the Last.fm service was written by a developer whose original intention was to make Amarok work better on Windows. Once he had gotten as far as he could at the time, he started, still using Windows, to hack on other stuff that benefits all users of Amarok. He did not use linux at all, and only contributed because it was possible to run and work on Amarok using Windows.

So I really think it is wrong to look at this as a zero sum game as time spent making stuff run on windows is not automatically time taken away from developing the core application. Quite contrary, making the application usable on other platforms will also attract developers who would not otherwise have worked on it. Of course there is a tipping point for this as the applications have to be working well and have a significant user base on Windows before any significant amount of developers shows up, but as my example about Amarok illustrates, people are already taking notice.

And then there is the whole issue about philosophy. To me, Free Software is about just that, freedom. I think it would be against the spirit of that to artificially limit the platforms that our software runs on. that is for all the "other" guys to do, I think we are better than that! :-)

Morty wrote - Not the desktop

... The power of KDE are its library and the applications made with it, and those are also interresting for the Windows platform.

And for KDE as a whole, any developers brought in and bugs fixed by the Windows port are a net win for KDE.

majorTomBelgium wrote about amarok, dolphin, ...

really, having all the nice kde programs available on windows is very cool. amarok, dolphin, ktorrent, kwrite, etc. and also, the educational programs are important.

+1 for kde on windows for me! it's like an artist being on a smaller label with almost no air time converting to a bigger label and getting his records played on the radio...

back to KDE on Windows

Development

Multiple compiler support

Why do you support so many compilers? Is that really what the project needs, at this time?

You are not the first to bring up this suggestion, and the decision to support multiple compilers has not been entirely uncontroversial. However, we have reached a decision on topic (on the 2007 Developers meet in Berlin, if you want to know), and we do intend to stick with it for the foreseeable future. Here are some of the primary reasons:

1. Having multiple compilers going through the code helps catch issues, as different compilers produce different warnings about problems.
2. Unfortunately, C++-libraries compiled with MSVC cannot be linked against with GCC, and vice versa, so the two cannot be mixed. We want to give developers the chance to compile their applications with the compiler of their choice. But that means compiling everything (well, mostly everything) with both compilers.
3. Some features / applications cannot be compiled or do not work when compiled with MSVC, some others don't work with GCC. This is a relatively small share of the software we offer, but still, dropping either compiler would mean dropping the respective features. Supporting both compilers still does not allow to have all these features in one KDE installation, but at least it will allow users to use these features at all.
4. So perhaps having support for multiple compilers is not all that important to you. But keep in mind that the majority of KDE on Windows developers are volunteers. We are glad, if our project is useful to you, but our priority is to work on the things that we care about. And yes, support for multiple compilers is a thing that some of the primary developers do care about.

Ok, so having multiple compilers is a good thing for developers, but do we really need to include multiple compilers in the installer for end users?

Keep in mind that some features / applications can only be compiled with either MSVC or GCC (see above). Also, application developers, too, may be interested in using the installer to install ready-made packages, and they should be able to build their software with the compiler of their choice (see above).

I still don't agree on the compiler issue. Is this your final word?

Well, never say never. But again, this has been discussed, before, we do intend to stick to our decision for the foreseeable future, and any discussion about it is very, very likely to be a complete waste of time, for you and for us.

Of course that does not mean everything has to stay the way it is for all times. For instance, it has been suggested to make it possible to create releases for the different compilers on independent schedules, and possibly even in independent installers ([1] [2]). Even for those, you'd need to spend some work to convince us going this way is worth the trouble (and be prepared to actually do the work to implement them, too). But at least discussing such reforms may not be entirely fruitless.