[DUG] Embarcadero article
Paul Heinz
paul at accredo.co.nz
Mon Jun 15 21:08:52 NZST 2009
David Brennan wrote:
> I just don't see it working unless it is possible to take
> sophisticated
> applications using the current VCL (ie VCL32) and with some
> effort but not a
> complete rewrite (ie NOT replacing the entire component
> library!) modify the
> code using ifdefs etc so that you have single source that can
> compile to
> either platform. Similarly third party providers (eg
> DevExpress) need to be
> able to produce single source versions of their libraries
> fairly easily.
>
> As far as I can tell they are producing a completely new VCL
> for the Mac
> just like CLX was for Kylix... if so then that means they are
> only targeting
> new applications which is a fatal mistake IMO.
>
> Of course doing what I suggest (making the new Mac VCL
> compatible with the
> existing VCL32 BUT still making it appear native on other targets) is
> probably at least an order of magnitude harder than what they
> are trying...
> but if they don't then I don't really see the point.
The VCL is far too tightly coupled with Windows (e.g. depending on deep
internal ordering of Windows message delivery, etc.) for a
IFDEF/recompile to ever work.
Trying to design and build a cross-platform GUI library ahead of time is
a pretty big engineering effort - it's essentially TrollTech's (now
owned by Nokia) entire claim to fame with Qt and they had a lot of
people working full-time on it. That's probably why Borland picked Qt to
underly CLX.
Trying to take a Windows-specific library that was never originally
designed to be cross-platform, and make it seamlessly cross-platform
after the fact is an even bigger engineering effort.
Effectively, you're reimplementing large portions of the Windows API on
Mac and Linux. And the WINE project already attempts to do that and look
how much engineering effort that has taken.
Even if they did manage to pull that miracle off, the end result would
be so full of 'Windows-isms' that the resulting app it always a second
class citizen on the platform. And then there is the Gnome (Gtk) /KDE
(Qt) split in the Linux sphere.
If you want to deliver a VCL Win32 application on Linux or Mac with
minimal effort, the only real answer is to use WINE.
I think CLX failed because it tried to kinda-sorta-be-like the VCL but
the illusion was pretty thin and only possible at all because CLX was so
dumbed down that no existing VCL Windows app could reasonably target it.
Also, by burying Qt under a translation layer, no Linux app wanted to
target it either since as Qt evolved, CLX lagged behind and would always
be a second class KDE citizen. And that's if you were happy with a
Qt-based app in the first place on Linux since you had the GNOME vs KDE
flamewar. That's died down a little now that Qt is finally LGPL but it's
still a Linux platform issue. I don't know how Embarcadero is going to
tackle that one.
As such, it will be interesting to see what Embarcadero does with Linux
given the lack of common GUI frameworks. They may have decided to bypass
them and build directly on X-Windows with appropriate extra support to
wire themselves into GNOME or KDE theming and configuation as necessary.
Project X is a rather suspicious title in that regard :-)
Cheers,
Paul.
More information about the Delphi
mailing list