Flutter engine is written by C++, original for Flutter framework based on Dark language.

But there is project to rewrite Flutter framework in TypeScript and C++ language, so they can developer mobile and desktop and IOT UI framework from TypeScript and C++.

They are cross platform (for android, IOS, window & macOS & linux) with native GPU acceleration UI framework.

examples: https://github.com/TGIF-iMatrix/MXFlutter  (and there also C++ and IOT project, I just cant find it)

The Alibaba ( biggest electronic business platform in China) use flutter to build they mobile
 app https://play.google.com/store/apps/details?id=com.taobao.idlefish

D has native C++ ABI support, is there any one interested to implement flutter framework on D language ?

On Sunday, 12 January 2020 at 14:15:35 UTC, Newbie2019 wrote:
> Flutter engine is written by C++, original for Flutter framework based on Dark language.
> D has native C++ ABI support, is there any one interested to implement flutter framework on D language ?

typo:  Dark language should be Dart language.

On Sunday, 12 January 2020 at 14:15:35 UTC, Newbie2019 wrote:
> Flutter engine is written by C++, original for Flutter framework based on Dark language.
>
> But there is project to rewrite Flutter framework in TypeScript and C++ language, so they can developer mobile and desktop and IOT UI framework from TypeScript and C++.
>
> They are cross platform (for android, IOS, window & macOS & linux) with native GPU acceleration UI framework.
>
> examples: https://github.com/TGIF-iMatrix/MXFlutter  (and there also C++ and IOT project, I just cant find it)
>
> The Alibaba ( biggest electronic business platform in China) use flutter to build they mobile
>  app https://play.google.com/store/apps/details?id=com.taobao.idlefish
>
> D has native C++ ABI support, is there any one interested to implement flutter framework on D language ?

At work, I started researching the available frameworks for cross-platform mobile development in the beginning of 2019, and I looked at various things such as Xamarin, Native Script and React Native, before I stumbled upon Flutter. The biggest requirement for us was solid performance and total control over every pixel on the screen (we're going for a custom design language system, and not native look and feel) and naturally Flutter fit the bill very nicely. Since then then we built two prototypes in it and overall I can say that I like the framework and the development experience, but Dart feels much less expressive than TypeScript (and of course it can't even be compared to D).

For quite a while I have been meaning to create my UI framework with D, with the following goals:
* GPU rendering, based on Vulkan, WebGL (or in the future WebGPU). No plans for DirectX as Vulkan covers everything I need on Windows and MoltenVK provides a Vulkan API based on Metal for macOS/iOS.

* Cross-platform:
Start with Linux (as it's the platform I mainly care about) with wayland (not sure about xcb right now) and soon after add Windows support based on user32.dll (no short-term plans for UWP). Add Android support based on Adam D. Ruppe's amazing work some time later. Look into using WebAssembly to provide a WebGL version, based on Sebastiaan Koppe's also amazing work.

* Start with a low-level API - windows and basic drawing - similar to the level of skia [1]. See how far I can go with @nogc.

* End-goal: high-level functional-style API, similar to Elm, React.js and Flutter. For state-management I have experience with RX [3] and Redux [4][5], but I also recently started looking to @ngrx/data [6] for inspiration. I have several years of professional experience with WPF/SL and MVVM, but I really want run away from that, in terms of API design.

Since I have very limited free time to create everything from scratch I decided to start by making a wrapper for libskia. So far I have the C API done [2]. I haven't tested it completely, but as far I remember I had all the C headers translated. However, AFAIK, it is much more limited than the native C++ API. I think I'll stick to the C API for a while, polish my work and push it to code.dlang.org. I would see how far I can reach, before I would need to go for the C++ API.

[1]: https://skia.org/
[2]: https://github.com/PetarKirov/skia-d
[3]: http://reactivex.io/
[4]: https://redux.js.org/
[5]: https://redux-observable.js.org/
[6]: https://ngrx.io/guide/data

On Sunday, 12 January 2020 at 14:15:35 UTC, Newbie2019 wrote:
> But there is project to rewrite Flutter framework in TypeScript and C++ language, so they can developer mobile and desktop and IOT UI framework from TypeScript and C++.
>
> [...]
>
> D has native C++ ABI support, is there any one interested to implement flutter framework on D language ?

I rather generate bindings to them. Implementing a flutter framework is a lot of work and maintaining that even more; I rather have someone else do it.

For the last half decade there has been a push to composable UI components, I think we should push that further and have the components cross the language barrier. Why shouldn't I be able to construct React Native or Flutter components in my D app? If you compare all the declarative UI frameworks on a high level you can see they are all pretty much the same: nested components with properties and callbacks.

On Sunday, 12 January 2020 at 17:23:05 UTC, Sebastiaan Koppe wrote:
> components, I think we should push that further and have the components cross the language barrier. Why shouldn't I be able to construct React Native or Flutter components in my D app? If you compare all the declarative UI frameworks on a high level you can see they are all pretty much the same: nested components with properties and callbacks.

Hm, how would you do that when the UI components are written in Dart? Generate Dart VM code?

On Sunday, 12 January 2020 at 14:15:35 UTC, Newbie2019 wrote:
> D has native C++ ABI support, is there any one interested to implement flutter framework on D language ?

I was thinking about it a year ago.
Also ready to do it, just don't have free time to advance the client project.

On Sunday, 12 January 2020 at 23:08:16 UTC, Ola Fosheim Grøstad wrote:
> Hm, how would you do that when the UI components are written in Dart? Generate Dart VM code?

I don't know, I haven't looked into it. But the repo the OP linked to did the same from JS, and Dart has a C FFI as well, so there must be a way in somehow.

The point is that we ought to be able to, otherwise the UI programming community is just replacing one silo for another.

On Sunday, 12 January 2020 at 15:39:47 UTC, Petar Kirov [ZombineDev] wrote:
>
> * Start with a low-level API - windows and basic drawing - similar to the level of skia [1]. See how far I can go with @nogc.
>
> * End-goal: high-level functional-style API, similar to Elm, React.js and Flutter. For state-management I have experience with RX [3] and Redux [4][5], but I also recently started looking to @ngrx/data [6] for inspiration. I have several years of professional experience with WPF/SL and MVVM, but I really want run away from that, in terms of API design.
>

I will try your skia project.

On Sunday, 12 January 2020 at 17:23:05 UTC, Sebastiaan Koppe wrote:
> I rather generate bindings to them. Implementing a flutter framework is a lot of work and maintaining that even more; I rather have someone else do it.

I agree to start the project could use bindings to reduce the work and easy maintain.
MXFlutter translate TypeScript object into dart vm object, they are also choice this way.

If the project is stable and a lot user, it worth to migrate the framework into D.  Because this way could provide best performance compare the a VM language. The snap UI experience will be a big win for D on mobile platform.


> For the last half decade there has been a push to composable UI components, I think we should push that further and have the components cross the language barrier. Why shouldn't I be able to construct React Native or Flutter components in my D app? If you compare all the declarative UI frameworks on a high level you can see they are all pretty much the same: nested components with properties and callbacks.

Is there any example project for this kind attempt?

https://github.com/lc-soft/trad translate javascript into c, but not a cross language solution.


On Monday, 13 January 2020 at 02:10:43 UTC, zoujiaqing wrote:
> I was thinking about it a year ago.
> Also ready to do it, just don't have free time to advance the client project.

good to know there is someone think it is doable.

On Sunday, 12 January 2020 at 14:15:35 UTC, Newbie2019 wrote:
> Flutter engine is written by C++, original for Flutter framework based on Dark language.
>
> But there is project to rewrite Flutter framework in TypeScript and C++ language, so they can developer mobile and desktop and IOT UI framework from TypeScript and C++.
>
> They are cross platform (for android, IOS, window & macOS & linux) with native GPU acceleration UI framework.
>
> examples: https://github.com/TGIF-iMatrix/MXFlutter  (and there also C++ and IOT project, I just cant find it)
>
> The Alibaba ( biggest electronic business platform in China) use flutter to build they mobile
>  app https://play.google.com/store/apps/details?id=com.taobao.idlefish
>
> D has native C++ ABI support, is there any one interested to implement flutter framework on D language ?

You might be interested in a binding to Nuklear[1]. Nuklear is completely decoupled from enviroment, so at least in theory it should work on every platform there is a low-level windowing library. It does not automatically bind to interface of any library, which means user code needs to include glue, but also makes the backend interface agnostic so you can use any windowing library just as well: glfw, sdl, sfml, cocoa, arsd.simpledisplay, HTMLCanvasElement or whatever. For mobile platforms, the widgets might require some redesign, but it should be doable without changing the UI invoking code, assuming it does not rely on e.g mouse movements.

GPU acceleration is also there. It's drawing can also be bound to OpenGL one wants to. I'm not sure if it could use Vulkan/Metal/DirectX/BGFX with no-compromise performance, but I wouldn't be surprised.

I have recently started to use it and the best thing I like about it that it won't steal any control away from the user. It'll let you to access the window pixels directly just as happily as your windowing library. And where most GUI libraries take control of the app and run your code when they deem they have to, Nuklear processes events and draws stuff only when you command it. Stop invoking it, and there is nothing happening in the background.

If libraries like this continue to develop, I think that soon the only points for using traditional widget libraries are that you either want the backend to make native widgets (including HTML), or need a non-graphical backend, like a console GUI you can design with DLangUI. And AFAIK neither of these two features are currently terriby common in widget libraries anyway.

1: https://code.dlang.org/packages/bindbc-nuklear

On Monday, 13 January 2020 at 08:11:49 UTC, Sebastiaan Koppe wrote:
> On Sunday, 12 January 2020 at 23:08:16 UTC, Ola Fosheim Grøstad wrote:
>> Hm, how would you do that when the UI components are written in Dart? Generate Dart VM code?
>
> I don't know, I haven't looked into it. But the repo the OP linked to did the same from JS, and Dart has a C FFI as well, so there must be a way in somehow.

Ok, I don't know how they go about this, but there is a way to add isolates dynamically through data URIs in the JITted version of Dart. Never tried myself though.

Apparently this capability is not available when using AoT (seems reasonable).

> The point is that we ought to be able to, otherwise the UI programming community is just replacing one silo for another.

Yes, although it makes more sense to do all the UI stuff in Dart and instead use other languages as "service providers".

Building a UI on top of Skia in D certainly is possible,  but it would have to be very modest...

The problem is really scaling down the ambitions and do something limited with very high quality rather than aim for something "feature complete" and end up with something half-baked and "patched-up".