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