That's not really the case at all. Kylix has been intentionally desktop neutral from the start. It's been our position that it should not be up to the development tools vendor nor the application developer to choose which desktop the end user of a developed application should run. One of the best things about Linux is freedom of choice and forcing a desktop decision steals from that.

The team is working with both the KDE and Gnome organizations on a number of Desktop isuues such as component and theme standardization. Kylix apps out of the box will work in either desktop. The issue will be how many specific desktop features will be supported either automagically or for the developer for each desktop in the first release. Because we inherit a headstart with Qt it's likely that the first release of Kylix will have more support specifically for KDE features. Obviously cutcopypaste and drag-n-drop will work in both desktops. The goal would be that Kylix apps recognize both theme engines and automatically look and feel like the desktop theme you are running- though it's not clear at this time whether or not themes will be recognised for both KDE and Gnome in the first release. Binary desktop component support, analogous to ActiveX components, will likely not be cross compatible between desktops in the first release because, though the two organizations are making a lot of progress in this area and Borland is participating, common desktop component standards won't be ready when the first release of Kylix ships. However we will continue to work with both organizations and the Bonobo group to ensure that Kylix supports common desktop component standards when they are ready. It's our goal for Kylix to support all the user and developer features of both desktop environments and ultimately for developers to be able to mix and match components and have everything work seamlessly in which ever desktop the end user chooses to run.

The most important thing however is to know that Kylix applications will work in either KDE and Gnome and the R&D team is developing and testing in both desktop environments.

It's really the opposite. We are taking great measures to make sure that Gnome is still part of the Kylix world in the long run. A widget set had to be chosen because the kernel does not define one like Windows does. Borland could have written it's own widget set, which we are perfectly capable of doing. But that didn't make any sense. There are two very popular widget libraries out there and the two most popular desktop environments are based on them as well.

It made far more sense for us to choose a widget set that existed and was already popular. Unfortunately we had to choose and in 1999 the two widget sets were closely tied to the two desktops. There is an implied endorsement of a desktop in choosing one widget set over another and that's not a position that, philosophically, we felt a development tools vendor should be in. We feel it should the end user of the application that chooses which desktop they run, not the developer of the app. We looked very seriously and closely at building the new component library on top of an abstraction that could plug into either GTK or Qt, but the two differ so greatly architecturally that it would be years before a solution as complete as Delphi would be able to ship with that approach. It would also impose a lot of compromises and create an additional level of overhead. So the approach we took was to implement the GUI subset of component library over the widget that best matched our needs.

We wanted very good Windows/Linux cross compatibility and we wanted the new component library to be as functionally identical to the Delphi for Windows VCL as possible. At first we were marching along with GTK, but it ended up that the design of Qt married up with the VCL architecture more cleanly than did GTK and the Troll Tech seems to invest equally in Windows and Linux for Qt. That was really our criteria and decision making process.

Having chosen Qt, we immediately began working closely with Troll Tech, KDE, and Gnome/Bonobo organizations to ensure that in the long run Kylix applications would work and directly support both KDE and Gnome features such as themability, interapp communications, and components. You may have noticed in the press release that we have also made an investment in Troll Tech - having this kind of close relationship with Troll Tech will help both of us meet our goals - which is success for Linux and real native cross platform development. We are still a little ways off from having the kind of standardization needed but we will be tracking and participating in the process and as these things become standardized you can be sure that Kylix will be right there to support both.

The new cross-platform component library has four areas - Visual, Database, Internet, and RTL. Qt is the widget set that the Visual subset of the library calls. The other areas of the component library don't necessarily use Qt.

Yes, the VCL in windows is a deep abstraction of the underlying OS, GUI, database access, internet, etc. For GUI components and graphical drawing functions the Windows VCL calls Win32 common controls and api functions like GDI. In Kylix the component library will be calling Qt instead of the Win32 equivalents for graphical and GUI duties. You can think of Qt as a common control and graphics api replacement for Win32 in Kylix. Qt matches quite closely to the way Win32 was used for graphics and UI in Delphi for Windows.

That and it will make developing applications for either platform much easier to port to the other.

Far more important to me than the current KDE/Qt Gtk/Gnome arguments are the basic license problems Kylix developers will face. For example, as far as I know, it will be impossible for me to create a fully GPLed, GUI, VCL-based program in Kylix, since the VCL libraries aren't GPLed.

The Kylix component library license has not been announced or publicly disclosed to anyone. The VCL that you are referring to is a Windows library with, currently, a traditional proprietary commercial license. That does not mean and should not imply that Kylix runtime libraries will have the same license. We are sensitive to open source licensing issues and are spending great efforts to make sure that Kylix will meet the needs of both open source and proprietary developers to the best of our ability. I'm not promising GPL, but what I am promising is that open source has been an important consideration in the Kylix project from the beginning and will continue to be.