Live data from Hacker News

Graphical User Interface Using Flutter in Embedded Systems [pdf]

static.sched.com

121–130 of 202 posts

Re: Graphical User Interface Using Flutter in Embedded Systems [pdf]

#121
post #88

Earlier quoted context omitted.

I see this on dark.dev for web "Warning: While in development, web support is available in the beta channel" What is your experience? Is it OK to use this is in production app. Right now I need a web and desktop app and curious to know if Flutter can be used. But I see the Flutter web is beta quality and Flutter desktop is alpha quality as of now

Flutter Web does it's own rendering via canvas, so accessibility is off the table for now and there is no easy path to get there. That alone should kill it for most production use unless it's an internal tool. ("should" because many apps sadly just don't care) edit: I was wrong, see below. Glad to be wrong actually, because Flutter is great.

That isn’t true and hasn’t been for a while. It’s nowhere near “web native” still but it is yet to even get a non beta release so I will give it some slack.

But I think Flutter is probably the best hope out there right now for the ever elusive dream of write once and run anywhere with native performance.

Re: Graphical User Interface Using Flutter in Embedded Systems [pdf]

#122
post #88

Earlier quoted context omitted.

I see this on dark.dev for web "Warning: While in development, web support is available in the beta channel" What is your experience? Is it OK to use this is in production app. Right now I need a web and desktop app and curious to know if Flutter can be used. But I see the Flutter web is beta quality and Flutter desktop is alpha quality as of now

Flutter Web does it's own rendering via canvas, so accessibility is off the table for now and there is no easy path to get there. That alone should kill it for most production use unless it's an internal tool. ("should" because many apps sadly just don't care) edit: I was wrong, see below. Glad to be wrong actually, because Flutter is great.

Apparently this is not true. It does support accessibility.

https://news.ycombinator.com/item?id=24922849

Re: Graphical User Interface Using Flutter in Embedded Systems [pdf]

#123
post #12

So far I've only been able to find Flutter on Linux with ARM cpus as an initial proof of concept project someone did specifically on a raspberry pi. Is there now an official path for full Linux flutter support on ARM? I'm learning Flutter now and would love to start writing some useful apps for my Pinephone and Pinebook. On an x86 Linux desktop, Flutter apps can run pretty well and very fast. I hope that holds true o…

There is indeed an official path for full linux support or at least in the sense that is outlined here https://medium.com/flutter/announcing-flutter-linux-alpha-wi...

Re: Graphical User Interface Using Flutter in Embedded Systems [pdf]

#124
post #30

Somewhat of an aside, since this article is about Flutter on embedded systems where React Native isn't even a consideration but... I've used both Flutter and React Native. Hands down, Flutter is the more enjoyable experience. Everything from the language, to the toolkit, to the IDE, to the final product, is just BETTER. React Native is a bloated, hacky, slow, garbage pile by comparison.

I can't figure out flutter. I see so many rave reviews. But I personally tried it and strongly disliked it. The toolkit and Android Studio run horribly slow - like really slow. And the output is basically this generation's flash. Some of the samples I tried on their gallery are mediocre. Very slight, but noticeable sluggishness. Some are just terrible; the 2d transformations moves at like 7fps. Plus there are so many…

> The toolkit and Android Studio run horribly slow

I'm doing everything Flutter related with vim + CLI, so one doesn't have to work with android studio, even did so when trying a native Windows build (out of interest) a bit ago.

> And the output is basically this generation's flash.

I did some flash quite a while ago, and no that does not compare at al, similar to that it is not like Java. The closed comparison is possible Qt, from a built output.

> Some of the samples I tried on their gallery are mediocre.

That's true, and I never understood why they don't improve that, it hurts their publicity.

> I would honestly have thought that flutter is dead in the water - every personal experience I've had with it has been bad, there are objective facts about it that are bad, and yet so many people love it.

I thought about roughly the same a year and a half ago, a coworker then did some small private stuff with it, and we talked here and then, as the base premise still sounded interesting. Comparing it now to then it just shows how much improved and gives a glimpse to what more will be possible, and I now could imagine that it will stay and even become rather useful.

tldr; It's IMO far from dead in the water, but there's also quite a bit of work to do.

Re: Graphical User Interface Using Flutter in Embedded Systems [pdf]

#125
post #59

Earlier quoted context omitted.

I've been following Dart since it's first release in 2012. I was able to be productive with right away back then. The JavaScript community freaked out because some Google exec in an email said Dart was a JavaScript killer. That did a lot of damage to it's acceptance. Dart was written with 2 things in mind afaik: 1) Replace Java based Google Web Kit used to write JavaScript (GMail circa mid 2000's) and 2) to serve as…

> and I think by that comparison, Flutter wins hands down. I'd be interested to hear your experience about why that is.

I really like C# and .Net for getting the job done but Balzor runs Mono .Net in Wasm and the startup time is brutal for the public internet. 2 to 3 seconds. This leads me to believe Blazor is targeted at corporate intranets on high speed networks where you have a ready supply of C# programmers

Re: Graphical User Interface Using Flutter in Embedded Systems [pdf]

#126

I also, independently, started writing an app in Flutter for fun (no experience in mobile/desktop GUI work, several years since I've worked in front-end web). I can give a list of pros/cons that probably overlaps what you've heard: Pros: - The toolkit feels fairly mature and not too hard to parse. I think there's a lot of "this class works with defaults and breaks otherwise" feeling, though the core components are ro…

> My computer ran hot while running Flutter, though not sure how much of that is debug/release mode.

Debug mode is easily 5-10x slower/more resource-intensive than release on devices I've tested on.

Re: Graphical User Interface Using Flutter in Embedded Systems [pdf]

#127
post #32

Earlier quoted context omitted.

It's unfortunate that the web mode uses a canvas and won't work with native browser accessibility stuff. That was the show stopper for me last time I've tried it.

That has been worked on, they do use proper tags instead of a canvas so accessibility now works fine. The next issue is performance / scroll jank though and that will be tough to solve since the rendering model is very different from the web.

I tried it briefly and no they don't?

For example, pressing "f" with Vimium should enumerate things that can be clicked(think anchor elements and button elements) but it enumerates nothing on https://gallery.flutter.dev/#/. This is a pretty good proxy for accessibility too i.e. things that can be clicked look like they can be to the machine. A quick document.querySelectorAll('a') and document.querySelectorAll('button') in the console verifies that there are no such elements.

Another one, basic browser features like backswipe on the trackpad to go back just doens't work.

Custom user agent stylesheets is another accessibility/power user feature that will not work

You cannot select any text as far as I can tell

Reader mode doesn’t work, not even on the news demo which is a prime example of where it should work

You cannot copy or preview link URLs

You cannot copy image URLs

Navigating by landmarks(such as headings) probably also doesn’t work(I haven’t tried this yet)

Re: Graphical User Interface Using Flutter in Embedded Systems [pdf]

#128
post #34

Earlier quoted context omitted.

An important distinction is Embedded and Real-time. Embedded is the all-encompassing tent, while Real-time is a subset thereof. Embedded includes things with GUIs, like fridges. We're not dealing with 128k of RAM. These can run basic GC'd apps just fine. Pauses really aren't any more of a concern than on desktop, or even less so.

My experience is not this. I've never seen an embedded app with GC. And embedded is usually dog slow processor running at minimum clock, to save power. So pauses are 10X or more the issue re: desktop.

"Embedded" means different things to different people.

Back when I was a game developer at EA, Madden and many other sports console games all shipped using Flash (!) interpreters with full GC. These were games running on PS2, NGC, XBox, etc.

Re: Graphical User Interface Using Flutter in Embedded Systems [pdf]

#130

Embedded doesn’t need wayland nor X.org. These two things implement desktop managers. Why would you run a desktop manager on a computer that runs one program only? For embedded, drm/kms is IMO better level of abstraction to base on. It only takes couple pages of code to get yourself a full-screen DRM-backed EGL context. I did it a few times for various Linuxes using Broadcom and Mali GPUs. I’ve evaluated Flutter coup…

>Embedded doesn’t need wayland nor X.org It depends. In this particular case, the demo seems to contain a launcher which allows to start multiple apps and switch between them. A window manager sounds preferable in this case. Also, Flutter handles all of the Wayland/X11 implementation details. In this case it's less work to just use the already-existing backend.

> the demo seems to contain a launcher which allows to start multiple apps and switch between them.

If the count of apps is small, and all of them are written by you, it's not terribly complicated to pass exclusive access to display across processes.

Only becomes too complicated if you want many apps updating their windows at the same time, or support third-party apps.

> it's less work to just use the already-existing backend.

Short term, yes. Short term, a desktop OS and Electron is even less work.

Long term, desktop environments are huge, and you'll be dealing with long tail of issues related to their features. Each time they break something, you might need to pay hundreds of dollars just to ship the equipment to you for repairs and back.

When a desktop environment is physically missing from the system, along with all related GUI software, services, and libraries, it leaves much less things to break. Users can connect a USB/BT keyboard or mouse, no one gonna handle the events. They can do rude multitouch gestures on the touch screen, nothing unexpected gonna happen either.

Post reply on HN