www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Flutter engine based ui framework

reply Newbie2019 <newbie2019 gmail.com> writes:
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 ?
Jan 12 2020
next sibling parent Newbie2019 <newbie2019 gmail.com> writes:
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.
Jan 12 2020
prev sibling next sibling parent Petar Kirov [ZombineDev] <petar.p.kirov gmail.com> writes:
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
Jan 12 2020
prev sibling next sibling parent reply Sebastiaan Koppe <mail skoppe.eu> writes:
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.
Jan 12 2020
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
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?
Jan 12 2020
parent reply Sebastiaan Koppe <mail skoppe.eu> writes:
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.
Jan 13 2020
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
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".
Jan 14 2020
next sibling parent reply Dukc <ajieskola gmail.com> writes:
On Tuesday, 14 January 2020 at 12:01:05 UTC, Ola Fosheim Grøstad 
wrote:

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


I'm sceptical of that. I do basically the same with Bridge.Net 
(with the difference that big part of "services" code is also in 

because spasm didn't exist yet when I started, D was added later.

And I can tell you that interfacing D-borne wasm with Bridge.Net 
is a low of work. D code can't take or pass JavaScript objects 
directly due to how WASM is designed, only their indexes if they 
are positioned in a purpose-built global array. This means that 
if you want to call your D functions in any easily readable way, 
you have to develop an automatic interface template in the ui 
language - introspection capabilites of D will not help. Perhaps 

it could be done even nearly as well.
Jan 14 2020
next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Tuesday, 14 January 2020 at 15:01:06 UTC, Dukc wrote:

 array. This means that if you want to call your D functions in 
 any easily readable way, you have to develop an automatic 
 interface template in the ui language - introspection 

 or Dart, but sounds unlikely to me that it could be done even 
 nearly as well.


You need some kind of IDL compiler. I assume you could use 
attributes to specify the D code that should be used for 
generating Dart interfacing code?
Jan 14 2020
prev sibling parent reply Sebastiaan Koppe <mail skoppe.eu> writes:
On Tuesday, 14 January 2020 at 15:01:06 UTC, Dukc wrote:

 On Tuesday, 14 January 2020 at 12:01:05 UTC, Ola Fosheim 
 Grøstad wrote:

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


 I'm sceptical of that. I do basically the same with Bridge.Net 
 (with the difference that big part of "services" code is also 

 way because spasm didn't exist yet when I started, D was added 
 later.

 And I can tell you that interfacing D-borne wasm with 
 Bridge.Net is a low of work. D code can't take or pass 
 JavaScript objects directly due to how WASM is designed, only 
 their indexes if they are positioned in a purpose-built global 
 array.


Isn't that what the webidl bindings generator does? It takes the 
definitions and generates D bindings and wrappers, JS code and 
glues everything together. You can add your own webidl files to 
generate D and JS glue code to interface with other things. 
(Although with Bridge.NET you have to take into account how they 

around Bridge.NET it might be possible).

With my (unfinished) typescript binding generator I am doing the 
same thing as from webidl, but instead it is based on typescript 
files, so you can interface D with typescript libraries (or JS 
libraries with ts typings).


 This means that if you want to call your D functions in any 
 easily readable way, you have to develop an automatic interface 
 template in the ui language - introspection capabilites of D 
 will not help.


Calling D functions isn't so well supported in my webidl bindings 
generator, except for delegates which are used for callbacks. But 
we can definitely fix that.
Jan 16 2020
parent Dukc <ajieskola gmail.com> writes:
On Thursday, 16 January 2020 at 09:21:32 UTC, Sebastiaan Koppe 
wrote:

 Calling D functions isn't so well supported in my webidl 
 bindings generator, except for delegates which are used for 
 callbacks.



have to call D from it, not vice-versa (I think?). But if you 
interface with a framework directly the situation should change. 
Well, presumably one needs to write a Dart wrappers for the 
events, if Flutter uses them, I'm not familiar with it...


 But we can definitely fix that.


...but if that is done, it should work in any case.

Just to be clear, I don't personally think I'm going to use 
Flutter. I've grown to dislike frameworks, preferring to use 
libraries. The language agnosticity you lobby for is among the 
reasons, but not the only one.
Jan 16 2020
prev sibling parent reply Sebastiaan Koppe <mail skoppe.eu> writes:
On Tuesday, 14 January 2020 at 12:01:05 UTC, Ola Fosheim Grøstad 
wrote:

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


Nah. I think they generate some Dart glue code to help with the 
interfacing.


 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".


I am talking about leveraging the multi-platform components from 
Flutter, and move as much of the UI composition and logic to D.

Not just Flutter really, anything. I mean, I like React, but no 
JS. I like Flutter, but no Dart. Why do all these frameworks get 
you locked into their language? Is there a technical reason?
Jan 16 2020
next sibling parent Paulo Pinto <pjmlp progtools.org> writes:
On Thursday, 16 January 2020 at 09:35:33 UTC, Sebastiaan Koppe 
wrote:

 On Tuesday, 14 January 2020 at 12:01:05 UTC, Ola Fosheim 
 Grøstad wrote:

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


 Nah. I think they generate some Dart glue code to help with the 
 interfacing.


 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".


 I am talking about leveraging the multi-platform components 
 from Flutter, and move as much of the UI composition and logic 
 to D.

 Not just Flutter really, anything. I mean, I like React, but no 
 JS. I like Flutter, but no Dart. Why do all these frameworks 
 get you locked into their language? Is there a technical reason?


There is, developing a programing language that takes into 
account designer and IDE tooling leads to more productive 
experiences.

Swift and Kotlin are also getting features that make it easier 
for SwiftUI and Jetpack Composer development.



Without such features, the tooling needs to be clever about 
specific programming patterns, which always breaks down when the 
developers decide to manually change the code.
Jan 16 2020
prev sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Thursday, 16 January 2020 at 09:35:33 UTC, Sebastiaan Koppe 
wrote:

 Nah. I think they generate some Dart glue code to help with the 
 interfacing.


Apparently they build proxies:

https://github.com/TGIF-iMatrix/MXFlutter/blob/master/js_flutter_src/js_framework_lib/js_flutter_basic_types.js#L83

Not something I want to deal with...


 I am talking about leveraging the multi-platform components 
 from Flutter, and move as much of the UI composition and logic 
 to D.


Then the advantage of hot patching is lost and it will be 
difficult to interface with all Dart-based Flutter components.

One big advantage with Flutter is that you see visual changes in 
a running application right after hitting  the save menu item in 
the editor (or keyboard shortcut).


 Why do all these frameworks get you locked into their language? 
 Is there a technical reason?


As frameworks grow they tend to start using language-features in 
ways that are difficult to interface with.
Jan 16 2020
parent reply Newbie2019 <newbie2019 gmail.com> writes:
On Thursday, 16 January 2020 at 16:02:28 UTC, Ola Fosheim Grøstad 
wrote:

 Then the advantage of hot patching is lost and it will be 
 difficult to interface with all Dart-based Flutter components.

 One big advantage with Flutter is that you see visual changes 
 in a running application right after hitting  the save menu 
 item in the editor (or keyboard shortcut).


There is a way to do this with static build: 
https://github.com/lc-soft/trad

It use a limit javascript subset at develop stage, and can build 
into c binary in release mode.
Jan 16 2020
parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Friday, 17 January 2020 at 06:28:55 UTC, Newbie2019 wrote:

 On Thursday, 16 January 2020 at 16:02:28 UTC, Ola Fosheim 
 Grøstad wrote:

 Then the advantage of hot patching is lost and it will be 
 difficult to interface with all Dart-based Flutter components.

 One big advantage with Flutter is that you see visual changes 
 in a running application right after hitting  the save menu 
 item in the editor (or keyboard shortcut).


 There is a way to do this with static build: 
 https://github.com/lc-soft/trad

 It use a limit javascript subset at develop stage, and can 
 build into c binary in release mode.


It does not preserve state between changes like Flutter does.
Jan 16 2020
parent Newbie2019 <newbie2019 gmail.com> writes:
On Friday, 17 January 2020 at 07:38:42 UTC, Paulo Pinto wrote:

 It does not preserve state between changes like Flutter does.


In develop emulator it dose, because that is a pure nodejs 
implement.  only in release mode it generate pure binary code.
Jan 16 2020
prev sibling parent Newbie2019 <newbie2019 gmail.com> writes:
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.
Jan 13 2020
prev sibling next sibling parent zoujiaqing <zoujiaqing gmail.com> writes:
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.
Jan 12 2020
prev sibling parent Dukc <ajieskola gmail.com> writes:
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
Jan 14 2020