Developers switching from Delphi to Oxygene are loving our "Delphi RTL" compatibility library, as it helps them move their code over to new platforms without having to embrace all the new APIs at once.
With the new Elements 10 builds we shipped in the past couple of weeks, we're taking this to the next level by expanding it to cover the VCL, Delphi's Visual component library, as well.
As with the core Delphi RTL, the goal is not to encourage the use of VCL in Oxygene as the main way to develop UI – there are better ways to do this, specific to each platform (and even for multiple platforms) – but to make it easy to get some code moved over quickly, without having to convert too much at once.
The Delphi VCL library available in the current builds is a very first and early peek at this, and it will be an ongoing (and hopefully community-driven) effort to push this further. As it stands, a limited set of components (and platforms) are supported for now, while we're focusing on laying the groundwork.
Right now, the VCL part of Delphi RTL is supported for two target platforms: Windows native (via Island) and WebAssembly, and the focus has been on base infrastructure (
TControl and friends) and DFM support.
We're taking a middle-of-the-road approach for the architetcure of Delphi VCL. On the one hand, we're trying to keep the class hierarchy and even its implementation details as compatible to Delphi's version as possible, so that at the higher level, many components (including third party ones) might port over easily or even without any changes. On the other hand, we also want to keep the general architecture as platform-agnostic as possible, so that we can expand it to more platforms over time (including Cocoa and WPF).
As an example, there is of course
TWinControl in the class hierarchy for visual controls on the Windows platform – exposing all the nitty-gritty Win32 details a VCL component might need access to. But on the flip side, as we go up the chain, classes like TButton will looks similar, for user-facing APIs across the platforms.
As mentioned above, right now we're focused on Island/Windows and Island/WebAssembly, and have usable previews for both (you can download a sample project here). On Windows, VCL builds directly on top of Win32, GDI and Windows controls – same as the original VCL in Delphi. On WebAssembly it builds on HTML controls and HTML features such as Canvas and CSS.
The next two platforms we want to look at (parallel to extending VCL on the above two, of course) are Cocoa (where we'd build on existing native AppKit and UIKit controls) and WPF (where again VCL components would/can map to existing controls provided by the platform).
What's functional right now is the base architecture and "plumbing" on the two platforms, along with a handful of the simplest controls (think
TCheckBox & the like). Controls can be created from code, of course, or forms can be streamed in from .DFM files (pre-processed by EBuild), so that an application using the VCL can look very much, in code and file structure, like one built in Delphi.
Of course both .DFMs and form class implementations can be shared between platforms, if so desired.
Next steps here are to flesh out the infrastructure more – with a focus on compatibility with Delphi's VCL for component implementors, for the Windows side, and a general focus on making it easy to create components across platforms that look the same, API wise, to the app developer. And of course we'll also look at adding more of the standard components, and talking to Delphi third party devs to see what they need to make their components work with Delphi VCL.
While obviously the main interest for this library will be to reuse existing Delphi Object Pascal code with Oxygene, in theory the library and infrastructre will of course work with all Elements languages. So there's nothing stopping you from implementing your next DFM-based
TForm in Swift, C# or Java!
Check out the library in the latest Elements build (.2321 or later), with one of these samples: