News for hackers. Stuff that matters.
Re:Flutter desktop shells by mamcx on Thursday April 25, 2019 @12:46PM (#19749948)
As I write in

https://www.reddit.com/r/rust/comments/9bapwt/thoughts_on_wh...

I think the solution is to split in 2: A UI back-end with logic, layout, etc and a UI front-end renders in each UI native toolkit.

So when write Button(title="hello") is NOT a widget, but a struct with data. It must be pushed to UI.Coccoa.render(button) to show up. But not only that, is possible to say:

  Form
    when(toolkit=UIKit) Field(UILabel="UserName", UiTextBox(PlaceHolder="Write your user")
    Field(Label="UserName", Edit(PlaceHolder="Write your user")
to specialize per specific platform.
Re:Flutter desktop shells by yellowapple on Thursday April 25, 2019 @04:56PM (#19752449)
Sounds like what Scenic's trying to do for Erlang/Elixir GUI programming, albeit at a lower level.

Also sounds like what wxWidgets already does.

Re:Flutter desktop shells by pier25 on Thursday April 25, 2019 @01:45PM (#19750629)
So controllers and views?
Re:Flutter desktop shells by mamcx on Thursday April 25, 2019 @03:07PM (#19751481)
Yes, the "novel" idea is the split in the actual binaries/languages: Do the core on rust/c and the render on swift/kotlin/.net...
Re:Flutter desktop shells by ec109685 on Friday April 26, 2019 @01:05AM (#19754983)
That’s what ReactNative does
Re:Flutter desktop shells by mamcx on Friday April 26, 2019 @03:21PM (#19760938)
No. Almost.

You must buy the whole Package with react and others. You don't code normal UI on Swift and still be part of the react world.

Think is like build a JSON API. My idea is that. This mean that on the client, is full native (with some minimal coupling to the how transfer data).