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. _______________________________________________ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@delphi.org.nz with Subject: unsubscribe
