By: John Kaster
Abstract: Michael Swindell, Director of Linux Tools, provides some details of our plans for Kylix
Michael Swindell, Director of Product Management - Linux Tools, has been putting in a lot of time in the
borland.public.kylix.non-technical clearing up misconceptions about Kylix and what we are
planning for it. The messages provide some really good explanations, so most of this article
is simply collating Michael's replies to questions on the newsgroup.
There was a thread in the newsgroup discussing the
press release regarding our collaboration
with Troll Tech for using Qt with Kylix. Something I've noticed from newsgroup messages
is that people don't seem to read the entire press release. Instead, they read the headline
and maybe the first paragraph, then start wild extrapolations from there. Therefore, I let me
make a humble suggestion: if you want to discuss a press release on our newsgroups, please
read the entire message first.
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
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
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.
I hope this helps to clear up some misunderstandings about Kylix.
Download Delphi XE4!
Free Trial License
Webinars on demand!
More social media choices:
Delphi on Google+
@RADTools on Twitter
Server Response from: ETNASC01