What is the roadmap for Island UI framwork

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?

Wuping,

there’s two parts to this story.

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.

does that make sense?

1 Like

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

Can you elaborate? Hydra solves a lot of problems but I don’t see it solving guis

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.

I guess I am looking for something like Qt

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.:slight_smile:

Just my thoughts. I could be very wrong

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.

2 Likes

@davidizadar
Just curious - where was “MFC” ever mentioned in this thread?

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)?

1 Like