There is enough speculation about what library / libraries we’ll encounter in the next version(s) of Delphi. We know that the next version code-named Fullcrum (don’t click here and here – AFAIK the links aren’t related with the team’s intentions ;-)) will be a cross-platform product which will target Windows, Mac OSX and Linux…
It seems that it will be only a 32-bit version and the Linux support will be in the ‘preview mode’ even if it seems that they will try to do their best. Take it rather as Mac OSX is the first GUI target after Windows.
Also we know that the compiler suffer a major overhaul, having a back-end / front-end architecture, thus giving the possibility of more codegens and more languages, even if for us, delphians, the biggest gain should be the language improvements which such a modern code base should provide.
But what about libraries?
We know that VCL is tied to Win32 API, hence there was a lot of speculation about a presumable VCL 2.0 which will be the cross-platform cousin of the actual VCL. Such a library exists (is in development) and will be delivered alongside with VCL which will be kept for Windows development. The team called it VCLX in the newsgroups and elsewhere – even if it seems that the actual, release name will be different 😉 – and in the roadmap it is written about it “Limited backward compatibility”.
But where we can found more info about VCLX?
Breaking NDAs are not a solution, believe me. I’m against such practices because it isn’t fair and even if we tend to forget that we are men, at least in the 11th hour, let’s try to keep the last drop of humanity which remained.
…And in fact, if I wouldn’t find a public information about it, I wouldn’t make this post.
But the public information about VCLX is a little bit hard to find so, I think that’s better to pinpoint it and discuss a little bit the implications. So, where is that ‘public information’ which will inform us about this mysterious VCLX?
Perhaps is here? (Screenshot bellow – read it carefully)
Well, in fact isn’t a big surprise at all. Because even if Mac’s OSX has a ‘native’ framework, for Linux such a thing just doesn’t exist. So, they must rely on some already established framework because starting from scratch on Linux isn’t feasible at all because of many reasons. Also, because of many reasons, Qt seems the most logical choice.
And now a word for the Mac fans: Guys, it seems that they dig quite deep in the Mac OSX’s inner workings an (perhaps) we should expect some nice surprises. I think that if they would limit to QT support on Macs they wouldn’t do such an extensive research in the area. See on the matter a series of posts from one of the compiler engineers. Also, we know that Chris Bensen (one of Embarcadero’s senior R&D engineers) went to Apple in order to discuss some core technical issues with the guys there (among them there are some ex-Borlanders who worked on Delphi years ago – don’t be cheated by his webpage content – a nice one btw – click on that ‘About’ link…)
The Win64 ‘problem’
Oh, 64-bit development… Fear not, Nick made it clear that VCL will be used for 64-bit development:
Hence we have:
- VCL for Win32 and Win64
- QT-based VCLX (aka CLX) for Win32, Mac OSX and Linux
Well, I think that this is really great news and a good direction, but some points are very interesting to discuss:
- CLX was very famous for its bugs which created a very anti-CLX thinking current. I think that one of the main targets of the team who works on the “new” VCLX is its quality. And this stands even if VCLX is QT-based or not.
- QT-dependency. We know that QT is pretty big. We will have the same deployment problems which .NET ecosystem has? I think that perhaps is possible to deploy (even statically link in some cases) with ease only the QT part which is actually used – this, of course, aside of possibility to deploy the executable without any QT library inside (assuming that the QT is already installed on the target machine).
- Native Mac. If we will not have a Mac native library, how ‘native’ will be QT on Mac? Ok, there are some applications which doesn’t care about being native (multimedia editors, other skinned applications etc.) but fact is that Mac community is pretty sensible at Mac’s look & feel. I think that we need a response on this.
- Performance and flexibility. Pascal layer over QT layer over OS layer… Seems obvious. But here we should mention two things: The FreePascal crowd doesn’t complain too much about performance issues (at least as far as I know, correct me if I’m wrong)
The GUI part (the part where the cross platform framework is badly needed) isn’t so demanding in terms of speed. Perhaps it would be feasible to provide a thin (ok, as thicker as it can 🙂 ) direct access layer to the Operating System’s API/ABI?
- Compatibility. Uhhhh… compatibility. With VCL of course. Granted, we cannot have the same UI widgets. But I think that we can gain (sometimes a lot) from the same RTL and same non-visual classes (think
TStringList, for example) – also if this is low-cost-high-gain for Prism also, then why not?
- 3rd Party Support.. Related to the above. Of course, we think that in order to succeed, VCLX should have a strong 3rd Party Support. But an interesting thing to mention here is that if, the Out of the Box components are good enough to be usable in 2010 AD, then the pressure over the 2ndary market will be much lower. For example, if the VCLX’s DBGrid will be good enough (guys, not every field can be displayed and edited in a TDBEdit) then many customers will limit their demand to this. If not, they will not commit to buy. And will wait. And will wait… or switch, of course.
- Price. What will make us buy Delphi when QT and QTCreator exists? When XCode exists? Language? IDE? Extra features in VCLX / RTL? DataSnapX? Till now DataSnap was available only in the Architect edition. I think that RAD Studio 2011 should have concrete distinctive features in order to have clear selling points against both QT as well as against Apple’s free toolchain (XCode / Interface Builder).
So, after all these points (also, I’m sure that there are much more – please feel free to add them in comments) I still do think that it is a good direction, but all boils down on how this direction will be executed.