There is a blog post talking Island VCL but the contradictory messages contained thereof are quite confusing
On one hand it said Island VCL is not to encourage the use of VCl but just help transitioning from Delphi, on the other hand it said there is a long term plan to expand the VCL infrastructure. And it is also said there is next step to map VCL to WPF
If I were allowed to voice my opinion, probably WPF is more worthy than fiddling with VCL. It would be really interesting to have WPF on native Island platform.
What is the road map for Island? What is its intended app domain? Will its application be primarily limited to something like C (performance-oriented or embedded app), or reinvent another monster wheel like Delphi with VCL/FireMonkey?
I am really confused on this matter. @mh Mind share some lights?
Delphi RTL/VCL is supposed to be a lightweight wrapper around existing APIs (System and Elements RTL) for Delphi compatibility. It is not covering the real Delphi APIs very extensively yet, especially on the VCL level, so those parts will be improved. But, yes, Delphi RTL/VCL is not something we encourage to use for new project (or for new users not coming from Delphi), itâs there purely to help get some code over.
We are in the early planning stages of a cross-platform UI abstraction layer that would allow to define simple non-fancy UIs (think, data entry forms) in a platform-independent way (whether with a designer, a user-editable non-code format (like DFM or WPF) or in code), and have that map to ânativeâ controls on each platform (eg Win32, Cocoa, WPF, HTML controls).
Once we have that, Delphi VCL/DFM support will be(come) an abstraction on top of that. You can think of the internals of the current Delphi VCL as a first play-around with how such an abstraction would work, but the final âEFormsâ will not be based on whatâs in Delphi VCL now, but rather Delphi VCL will be based on it.
Instead of âreinventing â a wheel (big or small) absorbing your precious resources, why not just do a better Hydra way? I tend to think Hydra facilitate better MVVM design
Is it possible to have Island Host a Hydra GUI plug-in, with Island code acts as the model and Hydra GUI plugin as the View, and some abstract layer in between as View Model (ie connecting the Events in GUI to the event handler implemented by Island or something like that)
IIRC we donât have Island Hosts yet, and the gui would have to be flexible enough to allow âanyâ gui work. Above could work for a single project, but I donât see it working as a generic solution.
An analogy would be
Qt-C++ part = Island Code Part
Qt-Qml part = Hydra GUI part
and we need a way to establish the event - event handler connection between island code and the Hydra GUI, just like Qt establishes signal-slot between the C++ part and Qml part
I think this is would perfectly render Island as a C/C++ replacement for computation intensive task, while the GUI part is handled by Hydra plugin (be it WPF, Delphi or what ever). This naturally fosters good MVVM design too, while the precious time/resource of our RemObjects friends can focus on the more important stuff.
Please, something like VCL or WPF looks good, but MFC was a disaster by embedding the design as part of the code. Having some external resource describing the UI and linking events allows for some manual design or multiple visual designers. I just hope to get free from Delphi and move 100% to Oxygene.
It wasnât. But it was based on generating the code from the visual design, making it more difficult to extract the information required for redesigning.
I know this isnât going to make everyone happy but I think the next focus should be to make amazing support for Chromium as the UI on all targets - Windows, Mac, Linux, iOS (perhaps standard UIWebKit here) & Android. If you could demonstrate native UI that doesnât need .NET to render a chromium full form browser and build in full support similar to DCEF4 for the callbacks etc, this would allow the next generation of apps to start being coded in Oxygene. Almost every new project is WPF/Mobile Native or HTML5. If someone wants VCL, they probably arenât going to be the next Oxygene customer. It is also really important to see a Linux daemon demo and a linux Apache module demo. Both key building blocks to modern apps.
Whatâs the selling point for âdoesnât need .NETâ? As far as I can tell, the only people who have a problem with .NET are those who think its too slow and bloated (itâs not) ir that its an :âexternal dependencyâ (itâs not, nice every Windows since XP SP2 ships it).
Surely relying on embedding Chrome is worse in every single regard for that (and every Electron app Iâve ever used proves it)?