Flutter for Linux(snapcraft.io)

460 pointsby CSharpRonvor 6 Jahren215 comments

https://snapcraft.io/blog/canonical-enables-linux-desktop-app-support-with-flutter

224 comments

axegon_vor 6 Jahren

I'm actually a great fan of flutter and imo it is the best cross-platform solution out there. Probably except for web: though it produces very good result performance-wise, the end result is never really "web" and doesn't act like traditional web. As for desktop applications(whether it be windows, linux or mac), it seems like it's too mobile-oriented. I see great potential for simple solutions like self-service operations where you need a basic UI and it would be great if it could easily target platforms like raspberry pi (arm processors running Linux). But at the moment, while possible, it is a very painful thing to tackle and I wouldn't rely on something like that for an end product. I would assume that this is why google is working on fuchsia but way too few devices are supported. And neither of them is cheap(which is what could be a game changer, going back to the raspberry pi).

RivieraKidvor 6 Jahren

I've been using Flutter in the last few months and agree. It's the best multi-platform solution for mobile, although it still doesn't match native behavior and performance, it only gets close.

On the web it's DOA for most use cases - it's just a canvas, so scrolling, text selection, shadow rendering, etc. is custom, doesn't feel native and must be downloaded and compiled.

It can have a future on desktop. One "cultural" obstacle is that the de facto default widget system is Material, which is simply a wrong approach to desktop UI.

akerrovor 6 Jahren

>It's the best multi-platform solution for mobile

They announced beta version for Windows in the last few weeks, so what to expect? I've been using it on linux desktop for 4 months so far, there were many problems, but it's absolutely the best framework so far. It's miles ahead of Qt (which I've been programming in since 2010). Dart and flutter are just years ahead of Java, C#, Qt and React Native in terms of positive programmer experience, productivity, good looking UI. There are so many bad things to say too, but all I can think about are only due to immature ecosystem, but that's changing literally daily.

brntvor 6 Jahren

Hoe is it ahead of Qt (on desktop)?

heavyset_govor 6 Jahren

I'm wondering this, too. While I enjoy Flutter, it doesn't hold a candle to the extensive Qt library and QML.

pjmlpvor 6 Jahren

Specially to the graphical designer tools, or the quality of third party component libraries.

akerrovor 6 Jahren

I wrote it's more pleasant to be used by programmers by giving better experience, then I wrote it's ecosystem is immature, but growing. As of now, it has its better and worse sides.

rowanG077vor 6 Jahren

Dart is the reason I don't like flutter.

Why do you feel C# is worse then Dart?

satvikpendemvor 6 Jahren

Dart is...fine. The real value comes in its code generation features, which enable packages to add whatever language features they want even if the language maintainers don't (yet), such as algebraic data types, functional programming features, etc. You can argue this as being good or bad for future maintenance but it's nice to have the ability to add to the language.

virtualwhysvor 6 Jahren

> The real value comes in its code generation features, which enable packages to add whatever language features they want

Got any eamples of ADTs, pattern matching, immutable collections, data classes, named parameters, etc.?

Coming from Scala and TypeScript the Dart language is pretty unappealing wrt syntax and functionality, kind of archaic actually. Flutter looks amazing and have been hoping that Dart would evolve more quickly than it has.

g5becksvor 6 Jahren

https://pub.dev/packages/freezed is ADTs, pattern matching, Dataclasses. named parameters are already part of the language.

There’s about 4 different packages that provide immutable collections, built_collections might be the most popular.

cutlervor 6 Jahren

Dart is just about tolerable but Dart + Flutter widget hell is not.

_pmf_vor 6 Jahren

> It's miles ahead of Qt (which I've been programming in since 2010).

Would you mind elaborating?

cutlervor 6 Jahren

Flutter widget hell makes Javascript callback trees look tame. I just don't get the buzz around this atrocious style of coding.

rkangelvor 6 Jahren

You commented this elsewhere too without elaboration. I'm curious as to what you mean by 'widget hell'.

I founded the nested tree of widgets syntax good after getting over the (short) initial learning curve. Some basic good programming practice over shared bits and it was very maintainable even for complex screens.

cutlervor 6 Jahren

Why is this style of programming frowned upon in Javascript yet idiomatic in Flutter?

imtringuedvor 6 Jahren

I'm not sure what you are talking about. Javascript developers also use HTML and the ability to nest HTML elements is "idiomatic" as well.

rkangelvor 6 Jahren

This is a wonderful answer and much better than what I was about to write.

Flutter Widgets, like HTML are declarative. They're just hierarchical information. This works in HTML, and it works in Flutter - there's nothing to get confused about.

Nested control flow (if statements, loops etc.) obscures the actual behaviour and so good practice is to break it up until it is clear and understandable.

BiteCode_devvor 6 Jahren

Widgets are declarative, like in HTML, the nesting is additional information. With callback hell, you nest logic, and actually obfusc information about the control flow.

reactchainvor 6 Jahren

Flutter for web feels like going back to the .net "webforms" days, where you could supposedly build a web app the same way as a desktop one and the whole client-server thing was abstracted away. Except it sucked, I still have nightmares about viewstate. Seeing Flutter apps that render everything to canvas feels similar.

Developing once for iOS and Android seems obvious and doable, but extending that to the web is a different game.

pjmlpvor 6 Jahren

Welcome to WebAssembly + WebGL future.

reactchainvor 6 Jahren

I think the goal of running native speed compiled-ish code on the browser in a sandboxed way would be great if it worked. CSS and HTML for "apps" has always seemed like a hack to me. The problem is every single attempt to do this in the past has resulted in a bloated mess. Maybe this time will be different...

nightowl_gamesvor 6 Jahren

I am a believer!

pjmlpvor 6 Jahren

The irony is that with WebAssembly maturing, we will have the revenge of plugins, and stuff like Flash is already being brought back, but hey now it is a standard browser feature.

jamil7vor 6 Jahren

> Developing once for iOS and Android seems obvious and doable

After shipping an app in it this year I've become a big fan of Kotlin Native, you can do enough code sharing to take the edge of doing two apps as a solo dev while having very little friction to access native views and APIs. The two apps feel like platform citizens on each OS but I have networking, persistence, utils and state management shared between them.

bepvtevor 6 Jahren

Flutter only falls back on the canvas, it avoids using anything but html elements if it can. Fancy animations tend to resort to the canvas

muth02446vor 6 Jahren

I wish the dart/flutter team would focus on improving dart for web (e.g. by updating/fixing the JS bindings) instead of chasing flutter for web which seems like a long shot and rather hacky (referring to using the canvas for rendering content)

vesinisavor 6 Jahren

> using the canvas for rendering content

This sounds like Flash all over again. Let me guess - no native text select, copy & paste supported? Scrolling is "wrong" in a subtle way?

timsneathvor 6 Jahren

We haven't reached perfection yet (that's why we're still in beta), but our goal is to be _very_ different to Flash in these kinds of areas.

Here's an example of text fields: https://gallery.flutter.dev/#/demo/text-field

Right-click and you have access to the browser context menu; choose Inspect and you can see a <textarea> or <input> control.

vesinisavor 6 Jahren

Frankly that feels exactly like a Flash page. Natively selecting text content isn't supported on either Firefox or Chrome on Android (apart from within inputs). Scrolling is broken ("yanky").

Flutter for Web further feels like a nightmare for accessibility. I tried enabling the native Google screenreader on my device. It only says "No text found at that location" when I try to read any of the Flutter demo pages in either Chrome or Firefox. In addition to being extremely hostile to people with disabilities, it will soon actually be illegal to build new products with accessibility-hostile tech like Flutter for Web for large parts of the European public and private sector:

https://en.wikipedia.org/wiki/European_Accessibility_Act

> we're still in beta

From these viewpoints that feels more like an early alpha product. In 2020 no accessibility support is a non-starter.

mwcampbellvor 6 Jahren

About accessibility, you need to find the "Enable accessibility" button and press it first. It's not visible on screen, but you should be able to find it with your screen reader's navigation commands (e.g. swiping left and right on a touch device). Yeah, it kind of sucks that the user has to turn accessibility on, and for that reason alone, I will never willingly develop a web application with Flutter. But at least it does support accessibility.

vesinisavor 6 Jahren

Right, to be fair I was able to enable the accessibility mode with your instructions. This way, the text content is indeed accessible to a screen reader. However, navigation in any of the demo apps with a screen reader was completely broken. So a user might be able to read a single page but not discover further content. With normal web pages we usually have <a> elements that enable navigation regardless of visual gimmicks.

dmitriidvor 6 Jahren

Don't kid yourselves. Web target is very much early alpha for Dart.

There are so many obvious problems with it:

- Everything relies on 1500 nested custom elements with hardcoded transforms to put them in place

- This breaks default browser interaction with the page entirely. Because what may look like a page is actually a bunch of absolutely positioned controls with absolutely positioned canvas inside them.

- Scrolling, one of the most important things in a browser, is broken. It's janky and slow (manually re-implemented?). I'm guessing containers have to be explicitly marked as scrollable with correct sizes, because resizing the browser window does not make content scrollable (try it with the demo you linked).

- Text is broken. Because it's rendered onto a canvas. So, all text interactions + accessibility is broken. Fonts are rendered incorrectly. I mean, on the demo page you can't even copy code other than through the "Copy All" button.

- Navigation is broken. Navigating the demo apps (which have more than one page) is not reflected in the url, so the back/forward buttons are broken

- Keyboard navigation is broken. Nearly none of the elements can be tabbed to. Except some buttons in demo pages. I guess they are explicitly marked as such?

- When elements can be navigated to by keyboard, they can only be activated by Spacebar. Even though Enter also exists. I'm pretty sure forms cannot be submitted by pressing enter, either.

- iOS-style date pickers are clipped in Safari

- 2D transformations demo is broken in Safari

It's just me spending five minutes on the demo site.

The effort is certainly commendable. It's not beta yet. It's possible you may want to scrap this and go the Figma route. They implemented their own rendering engine in WebGL: https://www.figma.com/blog/building-a-professional-design-to...

-

tomc1985vor 6 Jahren

That demo runs horribly on Firefox.

And clicking around seems to completely ignore my back button.

And hotspots didnt change to the finger cursor.

It looked pretty slick, except for those points. Oh well...

johndayvor 6 Jahren

It's also super laggy for me on Chrome.

metta2uallvor 6 Jahren

That's really cool but I think all text, such as "Please enter only alphabetical characters", should be selectable. For example someone may want to copy & paste it into a bug report.

nlvor 6 Jahren

https://gallery.flutter.dev/#/fortnightly

Basic features like selecting the text doesn't work.

_pmf_vor 6 Jahren

"Flutter allows content providers to protect their IP by not allowing text theft out of the box"

sciurusvor 6 Jahren

I loaded that page in both Chrome and Firefox Preview on a Pixel 3a and switching between text inputs or scrolling feels quite janky

lenkitevor 6 Jahren

The gallery apps don't even support the browser back button after going into a detail page. I guess this is still alpha stuff presently.

yesimahumanvor 6 Jahren

Yea, Flutter Web isn’t viable and likely never will be. The approach will require re-implementing browser primitives (like copy paste) which means you’re always going to need to ship a ton of JS to clients which makes it antithetical to the PWA approach.

EDIT: thanks for the downvote. But you don’t have to take my word for it, this sentiment is (privately) shared by Googlers themselves working on Chrome and PWAs.

yxhuvudvor 6 Jahren

Om The flip side, modern javascript frameworks seems to like to reinvent the basic primitives as well (based on how often my back button is broken), so I'm not certain that will be a deal-breaker.

spiderfarmervor 6 Jahren

Tie it in with AMP and you have the webdev cocktail from hell.

axegon_vor 6 Jahren

+1 on this one. I've fiddled with angular dart for instance and tbh as someone who is horrible with doing frontend and hates js with a passion, this was enjoyable. Yet the release of the newer version[0] is taking forever.

[0] https://github.com/dart-lang/angular/pull/1892

mikecevor 6 Jahren

Flutter's ability to "compile to web" was something that confused me at first as well, but on second thought it's genius. It makes it easier to ease managers into selecting Flutter since deployments and updates are done via a web browser. If that works for them then maybe there's never a need to go fully native though that option exists if they want to -- and the ability to go back to compiling for web gives managers a sense of "this isn't a one-way, I'm screwed if something goes wrong" journey.

anonms-cowardvor 6 Jahren

> and the ability to go back to compiling for web gives managers a sense of "this isn't a one-way, I'm screwed if something goes wrong" journey

It wouldn't be a good idea to believe that though. Flutter website are just canvas paintings, and have nothing to do with the web. You can't add new html or js to it easily. can't make much use of new improvements in the web world.

Most importantly, if you are running a business, flutter web isn't really accessible, so please don't use it for any non internal tools

kiratpvor 6 Jahren

Or internal tools.

Internal tools should not exclude people needing accessibility features.

blandflakesvor 6 Jahren

Dart actually has a lot of characteristics that make it appealing for a lot of the areas I'd have (begrudgingly) used Go - command-line tools or local utilities. It "can" be scripted, but also AOT compiles, has a saneish type system with generics, and doesn't have pointers to deal with. It's hard for me to want to use it on the web, but I keep watching it and wishing good things for it.

wstrangevor 6 Jahren

Dart produces surprisingly small docker images for server code. I recently created small Cloud Run web service with Dart - the docker image is 5.2MB compressed, 12.9 MB as reported by docker.

I'm not even sure Go would do better on image size. Tree shaking does wonders here.

[deleted]vor 6 Jahren

vetinarivor 6 Jahren

> command-line tools or local utilities.

FFI is quite a PITA, though. Soomer or later you will have to interface some platform libraries, and Dart doesn't make that easy.

timsneathvor 6 Jahren

Curious what platforms you're interested in integrating with. We're experimenting here and looking for feedback. As a fun demonstration of the effectiveness of FFI, you can now build Petzold-style native Windows code with Dart: https://github.com/timsneath/win32/blob/master/example/hello...

And here's a 500-line version of the Kilo console text editor built with Dart: https://github.com/timsneath/dart_console/blob/master/exampl...

Unlike the original, it runs on both Windows and UNIX-based operating systems.

vetinarivor 6 Jahren

I'm actually more interested in Linux side of things. That doesn't prevent me from looking how things are done on Windows, of course.

To be fair, last time I looked into dart, the idea of FFI was ports, which was too overcomplicated and undercapable, if you needed something like Gtk or Vulkan. Looking into it now, I see the dart:ffi package is shaping up nicely, so I will have another look at dart again.

malkiavor 6 Jahren

Tim, it should be possible that the main .exe (or binary on linux/osx) to export functions, and they can be found back through the flutter_engine.dll/.so, right? (At least on windows it's possible for the exe to __declspec(dllexport) things, not sure on Linux).

But even if not, if there is a way to (given might be slow and tedious) to compile what would've been flutter_engine.dll statically linked to your main (host) app, and maybe somewhat hinting here is how to find the "GetProcAddr/dlsym/etc." functions - if one is to look for them.

Further on, the generated from dart .so file can be embded (as resource? or slapped at the end of the binary/.exe?) + slapping all other resource - resulting in single app :)

I know it's possible, just not so easy to support it (I guess). It's similar to have java/python can be packed into one executable with all C/C++ ffi functions they call (at cost of some build time and effort to achieve so).

Then you'll have killer platform for video conferencing (zoom, bluejeans, etc.), messaging (slack, etc.) - and just single binary to deploy.

(Oh, on top of that slap a web server into it, and make it that if called with specific command-line option, now it acts as web-server, and the app is visible through the web).

jamil7vor 6 Jahren

> FFI is quite a PITA

This is what made me nope out of it last time I experimented with a Flutter module in my app. I'm still watching it closely though as it could be a great fit for other projects.

kjksfvor 6 Jahren

This might be outdated opinion (hard to tell without OP explaining what he finds "a PITA").

dart:ffi (https://dart.dev/guides/libraries/c-interop) is a recent addition to Dart and from where I stand it's a decent FFI system.

Maybe not as good as PInvoke in C# or ffi in luajit but better than, say, jni in Java (and any other FFI system that requires you to write glue code in C i.e. python, ruby, nodejs).

malkiavor 6 Jahren

good thing to have in an FFI system is ability from one language to call another from callback, and back and forth (if it need to). I believe Dart allows for that. That to be said, stack walking is going to be painful to decode (probably), best I've seen is C#/C++ on Windows - where it flows naturally from one to another.

jamil7vor 6 Jahren

Thanks good to know, my experience was most likely outdated as well.

kllrnohjvor 6 Jahren

My experience with Flutter was that making the UI itself was pretty great. But making the rest of the app sucked. FFI support is bad. Platform channels are miserable. Doing it all in Dart is awful because there's no cheap concurrency - it's the same multi-heap with expensive "IPC" shittiness that you get with webworkers, but way less justified since you're nearly always on platforms with native threads. It's a huge pain to try and migrate piecemeal too, so if you have an existing app/codebase you're looking at a re-write.

UI performance was fine (not any better than native though), but RAM usage was pretty bad, a lot higher than native.

Really fantastic iteration workflow, though.

xstervor 6 Jahren

> Platform channels are miserable

ya, I hear you. It's a very common annoyance. We've been adding some support in the form of https://pub.dev/packages/pigeon to make the interop calls and data class passing more "direct".

disclosure: in the Flutter team

Abishek_Muthianvor 6 Jahren

What I found ironical with flutter was, besides everything being a 'widget' in flutter it doesn't actually support creation of android widgets or iOS widgets[1].

And that I'm worried that Google might just pull the plug as I feel the community is not in the position to continue development without Google's involvement unlike React Native.

Also, I'm not entirely sure about the future of Dart language now that we have TypeScript. Overall I feel flutter to be a risky investment, I personally would rather develop PWA in-spite of Apple's explicit hurdles(which I think may change after couple of anti-trust litigations).

[1]https://github.com/flutter/flutter/issues/26134

biolurker1vor 6 Jahren

And except for windows..

rstvor 6 Jahren

So, this makes Flutter apps available through Canonical's Snap store... which is Ubuntu-mostly right now, and controversial enough that the top item on the HN front page as I write is about an Ubuntu derivative (Linux Mint) explicitly dropping support for it. https://news.ycombinator.com/item?id=23771847

owaislonevor 6 Jahren

Flutter announced support for Linux. Canonical announced that they'll help the Flutter team in making Flutter a great option to do app dev on Linux. They also published Flutter SDK to the Snap store, the preferred app store for Canonical. None of this means that people cannot package and publish Flutter to Debian, Ark or Fedora repositories. It'll still support Linux as a whole as long as the dependencies are present on the system. Canoncal is just investing resources in making sure it works for their distribution of Linux as well as possible, not to ensure that it only works on Ubuntu.

galgaleshvor 6 Jahren

The snap store support is a small part of what is announced here. The team developed a GTK+ based host for flutter, which works regardless of the packaging method you use.

The end of the blog post talks about modifications to the snapcraft build tool to fully support flutter.

canada_dryvor 6 Jahren

Until SNAP gives me full control (and not just: you can opt-out) over updates/upgrades they're a non-starter.

timClicksvor 6 Jahren

Many snaps provide channels so that you an pin your locally installed version to a specific upstream version. That way you have full control over when you upgrade.

kelvievor 6 Jahren

Also it's ridiculously annoying debugging issues with them, or finding out what source code compiled into a particular snap.

Even with docker hub I can find the sourcecode easily linked 99% of the time.

galgaleshvor 6 Jahren

Yeah, it would be useful to have a metadata field "packaging repository" or something.

Snaps built from GitHub with snapcraft.io include a manifest and the build recipe in the `meta` folder in the root of the snap. This includes all the info about the source code and allow you to reproduce it. Publishers can enable this on their own build infrastructure using an environment variable.

Many snaps also link to the source repository in the "contact <publisher>" link.

lallysinghvor 6 Jahren

Does snap not let you manually do those?

ric2bvor 6 Jahren

No, it updates by itself, sort of like Windows 10.

simosxvor 6 Jahren

Other distributions also use the Snap Store.

See the stats for the Skype snap package for the range of Linux distributions, https://snapcraft.io/skype

jaekashvor 6 Jahren

> Other distributions also use the Snap Store.

Not if I can help it on fedora, and all things I ever tried form there did not work properly.

> See the stats for the Skype snap package for the range of Linux distributions, https://snapcraft.io/skype

Most of those are recycled Ubuntu. Still don't get how the reasoning there works: ah look a garbage distro, let's fork it and make it better? Pick literally anything else.

topspinvor 6 Jahren

"Canonical's Snap store"

Correction: it's "the app store for Linux".

/s

chupasaurusvor 6 Jahren

Show me any repo of snaps other than Snapcraft.

topspinvor 6 Jahren

No. And I can't imagine what relevance that would have.

If Linux has an "app store" it's Docker Hub. But "Linux" doesn't actually have an app store, and attempting to claim that status is tone-deaf hubris.

Rapzidvor 6 Jahren

It just seems like an ad in exchange for the work they did.

jaekashvor 6 Jahren

My first thought when seeing this post links to snapstore was "ugh, not that garbage again". Every time I tried using Snappy on fedora it did not work and was so horrible I reverted to immediately removing snappy from my computer afterwards.

Canonical makes garbage software that is superficially easy to use but flimsy and flaky.

nightowl_gamesvor 6 Jahren

I'm all for Snap criticism, but Ubuntu is clearly good software made by Canonical. We need to stop using this level of inflammation in our discourse.

jaekashvor 6 Jahren

> Ubuntu is clearly good software made by Canonical

I can only speak for my own experience but if I had to choose between using Ubuntu for the rest of my life and losing a finger, I think I would lose a finger.

There is no worse operating system I have ever used. It is Linux made by people who never bothered to open a manpage, software engineered by people who think engineering is waste of time. It is basically the Robert McNamara of operating systems, I can just hear him now, "there is no such thing as planning or engineering, just crisis management". Funny thing is they probably think crisis management is too big an ask.

One of my biggest gripes with Windows is that many parts of it feels like it was created by people who never even tried it because it should be obvious to anybody who ever tried it that it is a horrible user experience.

Ubuntu is basically the dumpster fire version of this. It's like someone read about dumpster fires and thought "wow, that sounds nice, how can we make an operating system like that".

galgaleshvor 6 Jahren

This comment adds no value to the discussion; it's "Ubuntu bad, Canonical bad" stretched over 4 paragraphs. Yes, it's clear that you don't like them. HN discussion are expected to be more substantial than this.

armytricksvor 6 Jahren

Having used Flutter extensively since I was first introduced to it 9 months ago, I can say that it is an absolute joy to use and build interfaces with. An easier way to install the Flutter SDK on linux is only good news and I hope it gets more developers to adopt it.

programmarchyvor 6 Jahren

Agree, Flutter is top notch. I've had trouble pitching it as a technical solution, though. For one, I think word is out that Google will kill projects mercilessly, and there's an odd dynamic between the promotion Flutter and Kotlin/AndroidX. Generally, Kotlin comes out on top as the "safer" choice.

It's a shame, though, because the primary advantage I see with Flutter is its superior UI framework. It's leagues better than the AndroidX compatibility lasagna, in terms of architecture and DX. So it really stands out as a cross platform solution not just across iOS and Android, but especially across the Android ecosystem itself.

[deleted]vor 6 Jahren

awillvor 6 Jahren

Google needs to release desktop apps in Flutter (Youtube Music, Chat, Meet etc..). a Webapp is fine for occasional use, but Google Chat can't compete with Slack without a real app.

kelnosvor 6 Jahren

I uninstalled Slack's desktop "app" a long time ago and never looked back. The browser version is much better, and doesn't require me to have an extra (often buggy, in my experience) browser instance open in order to use it.

Calling it an "app" is somewhat laughable, since it's just their website packaged up in a standalone web browser, plus a minimal amount of platform-specific glue.

tudorconstantinvor 6 Jahren

I am not able to screenshare in slack from browser on Linux, only from the electron app.

spankaleevor 6 Jahren

Totally. You definitely can't compete against Slack's desktop app with web technologies: https://slack.engineering/building-hybrid-applications-with-...

dahfizzvor 6 Jahren

Personally I can't tell the difference between the slack app and slack open in my browser. It is literally identical. In Firefox, I can even go "full screen" but still control the size and location of the window, so I don't have to look at the tab bar. Side by side, I can't tell them apart visually or functionally.

Maybe the Linux version of electron is neutered in some way? I read article you linked and I don't know what bouncing the dock means, maybe that's an important native feature for mac users?

jeffbeevor 6 Jahren

Slack in the browser is visibly superior to the slack app. When I close the tab it's really dead. Great feature.

The slack "app" is just their web site and a web browser zipped together in such a way that it doesn't actually quit when you tell it to quit. Why anyone wants that I cannot begin to imagine.

mathwvor 6 Jahren

Slack is behaving in the same way as innumerable instant messaging clients in the past, because they consider themselves in that category rather than perhaps in an IRC sort of category which is maybe where you see them?

And there's an option to turn that behaviour off, if you don't like it.

But I would prefer if it wasn't all Electron because it really does feel like the resource overhead is unnecessary. But if it wasn't done with this tech, we probably wouldn't have a Linux client at all, and maybe not a Mac one either, and personally I prefer it to feel like an application instead of having to run it inside a browser.

Kind of hoping Flutter helps advance the situation of cross-platform desktop/web things in a positive way.

sciurusvor 6 Jahren

I'm not sure what you mean. On OS X quitting the app certainly seems to actually quit it

jeffbeevor 6 Jahren

"""By default, your app is set to keep running in the notifications area even when the window is closed. Choosing not to leave the app running will remove the Slack icon and badges from your notifications area."""

applecrazyvor 6 Jahren

On macOS, closing all an app’s windows ≠ quitting an application.

When you Command-Q Slack, it should close completely (which afaik it does).

jeffbeevor 6 Jahren

Great, that is a platform that exists, that I bet has almost 10% of Slack's market share.

sciurusvor 6 Jahren

But that's normal for all apps on OS X. Closing their window doesn't mean quitting them. I'm not sure why you'd fault Slack for following the OS's conventions here.

To quit it, choose that from it's menu or use the cmnd-q shortcut IIRC.

solarkraftvor 6 Jahren

> In Firefox, I can even go "full screen"

You mean hiding the browser chrome? Becuase I've been looking for a decent way to do this for years. Do you use a profile for every app? My rationale against this is that I'd like to share the plugins and settings.

judge2020vor 6 Jahren

Their focus seems to be full-on installable PWAs for everything, which YT Music and YT TV already having them (and PWAs are only marginally better than Electron since they all share the same parent chrome process).

imtringuedvor 6 Jahren

If they share the same process then they are better by orders of magnitude in terms of memory usage. Although not everything should be a PWA, you can still write good PWAs if you want to.

eklavyavor 6 Jahren

I am so excited about flutter ecosystem. Hopefully linux gets first class beautiful native apps now. I also hope against hope that qt is officially supported as a backend so KDE is not left out.

zellyvor 6 Jahren

Flutter implements a bespoke renderer called Skia. It is its own backend. For Qt to be compatible with Flutter you'd have to port Qt to Dart. There's nothing wrong with running Flutter apps and Qt apps simulatenously.

It would be an interesting project for someone to create a KDE type of desktop environment in Flutter. Can it be done?

devxpyvor 6 Jahren

There's an experiment from a flutter core dev -- running flutter on a raspberry pi without any desktop environment.

https://medium.com/flutter/flutter-on-raspberry-pi-mostly-fr...

A DE written in flutter sounds like a great accelerator/toy project for making flutter desktop polished and ready for the masses.

andrepdvor 6 Jahren

Judging by the example in TFA, we must have very different conceptions of what "beautiful" means. That is an atrocious application.

* Ungodly amounts of whitespace (seriously, look at that sidebar, look at that search bar. WHY? too much optimisation for what "looks good on a screenshot", maybe?)

* Undecipherable symbols where there's plenty of f#cking space to write labels god damn it

* I bet bad/nonexistant keyboard support (remember alt-* to navigate menus?)

* Ugly to look at (subjective)

zellyvor 6 Jahren

You can style the widgets however you like. You don't have to use the default Material toolkit, the same way you can design Qt widgets in QML and don't have to use those default 1990s-style gray box widgets.

> remember alt-* to navigate menus?

I do, but most people reading this probably won't, or there will come a time shortly when most people won't remember. I think most people are used to everything being a web/Electron app. Users do not expect a standard design language (like Win32/Swing/Qt) for desktop apps anymore (and indeed a Win32-style desktop app will soon look as foreign as a webapp since even the Windows shell looks like a webapp now).

Flutter lets you create "webapps" (which is the new standard) but with native performance and ability to make syscalls (being native).

The only alternative tech stacks to this end are QML/QtQuick, JavaFX, an embedded WebView, or embedded Chromium (e.g. Electron or Chromium Emebedded Framework)--all of which having some sort of baggage. Flutter's baggage is you have to use Dart. The alternatives all also require that you use some sort of DSL (QML (Qt), FXML (JavaFX), JS (Electron)) so that's not a unique disadvantage. (It really isn't a disadvantage--imagine the hell if there weren't a DSL for the View layer and every language had to have bindings.)

GUI programming is downright suffering no matter which way you slice it. There are no interesting problems to solve, unless you're working on the GUI framework itself. Flutter makes this suffering slightly better. I don't see how it's not an absolute good.

Spivakvor 6 Jahren

You do know that none of that is really do do with Flutter, right? Like you're just taking it out on the designers of Flock.

lultimouomovor 6 Jahren

In defence of GP, the article says

> we’ve seen more than 80,000 fast, beautiful Flutter apps published to Google Play

thus somehow tying the app looks to the fact that they use Flutter.

ocdtrekkievor 6 Jahren

This isn't true: Google preloads their design conceptions, namely Material, into Flutter at the ground level, and Material is a terrible set of UI patterns, such as the ones the parent comment was complaining about.

satvikpendemvor 6 Jahren

You don't have to use the material design stuff, you can just make your own components, all custom, just as you would on the web. Just replace MaterialApp with WidgetsApp at the root of the application tree.

ocdtrekkievor 6 Jahren

You don't have to, but it is the default, which means it sets the standard of design there. Unsurprisingly, most things you see made with Flutter tend to either be or be similar to Material.

solarkraftvor 6 Jahren

> I also hope against hope that qt is officially supported as a backend so KDE is not left out.

Unlikely (GNOME market share) and I can't see why it'd be that important. Platform protocols can be implemented around GTK and as far as I understand GTK is just a vehicle for getting X11/Wayland compatibility, the rendering itself will always be done by Flutter's engine anyway.

RivieraKidvor 6 Jahren

I wouldn't call Material UI on the desktop beautiful. Mac OS is beautiful. Gnome 2 too relative to other Linux DEs. It won't use Qt but Skia.

me551ahvor 6 Jahren

The future of cross platform desktop development looks bright. Microsoft is coming up with .NET 6 and Google has flutter. I just hope that these frameworks can replace bulky electron apps.

k__vor 6 Jahren

Revery also looks nice.

I wish they had more funding, tho. I find Reason/OCaml more compelling than Dart.

thomasfortesvor 6 Jahren

There's a guy that managed to compile and run revery on android, I would love to have that as an option since I'm already familiar with ocaml/reason and only barely literate in Dart (and also prefer functional languages over object oriented ones)...

https://github.com/EduardoRFS/reason-mobile

k__vor 6 Jahren

Pretty cool!

They have mobile platforms on their roadmap for quite some time now, but somehow the project doesn't seem to get much traction.

I guess, Dart would be dead by now, if it wasn't for Google pushing it with Flutter.

sly010vor 6 Jahren

How is OCaml's multithreading story? Google says it's basically GIL-ed.

blandflakesvor 6 Jahren

Simultaneously in a state of having-been vaporware and making real progress towards being merged to master:

https://discuss.ocaml.org/t/multicore-ocaml-june-2020/6047

wishinghandvor 6 Jahren

What's GIL-ed?

WorldMakervor 6 Jahren

The "Next" and "Next + 1" versions of React Native are starting to look quite exciting too. The Microsoft-backed full C++/WinRT rewrite of the Windows desktop support seems to be making good progress. With the Office team supposedly backing React Native as their preferred cross-platform toolkit moving forward, Microsoft looks like they'll be investing in RN for the long haul.

It seems good for everybody that Microsoft seems to be putting so much work into cross-platform dev in both .NET 6 and RN.

drannexvor 6 Jahren

I'm looking forward to the first stable version of Blazor, and a way to combine it with proper native mobile bindings to device APIs. Currently working on a version combined with CapacitorJS and I am in love with the possibilities.

.Net 6 is going to be beautiful.

harikbvor 6 Jahren

I have a request for all the Flutter folks/fans - it would be great if you all can say something about how you can get over / stay sane with the staircase looking nesting of code blocks and how you manage to keep it all in your head to navigate the code base.

I started my career writing single threaded Palm OS apps (64k limit) - there was like 10 possible widgets with 5 possible events on each widget and rest of it was application code. Mobile app development is a different beast now. Yes, I sound like old-man-yelling-at-cloud. Is this table-stakes for all UI and App development?

heavyset_govor 6 Jahren

> it would be great if you all can say something about how you can get over / stay sane with the staircase looking nesting of code blocks and how you manage to keep it all in your head to navigate the code base.

The same way you would in any other code base, with the ample use of names and modules, and breaking nested components and logic into their own classes and functions.

The problem is that it requires discipline, or at least a standard style guide, to adhere to. It's similar to JavaScript in that regard, where bad practices can seemingly be ignored or even encouraged.

runeksvor 6 Jahren

I gotta say that I miss some from of let-binding, so I don't have to choose between (a) local variables plus newline-separated statements, including "return", wrapped in {}, and (b) the lovely syntax of `Widget build = (context) => ...`.

E.g. instead of writing

    Widget helloWidget(BuildContext context) {
      final db = Provider.of<MyDatabase>(context, listen: false);
      return Row(
        children: <Widget>[
          Text("Hello, "),
          FutureBuilder<String>(
            future: db.username,
            builder: (ctx, snapshot) =>
              snapshot.hasData ? Text(snapshot.data) : CircularProgressIndicator(),
          ),
        ]
      );
    }

i'd like to write:

    Widget helloWidget = (BuildContext context) =>
      let db = Provider.of<MyDatabase>(context, listen: false)
      in Row(
        children: <Widget>[
          Text("Hello, "),
          FutureBuilder<String>(
            future: db.username,
            builder: (ctx, snapshot) =>
              snapshot.hasData ? Text(snapshot.data) : CircularProgressIndicator(),
          ),
        ]
      );

cutlervor 6 Jahren

Trouble is that in most Flutter code the widget staircase is idiomatic. Swift UI also seems to have chosen the same path.

solarkraftvor 6 Jahren

I don't really see the issue. Widget layouts are trees. Why shouldn't you represent them as such in your declarative code?

heavyset_govor 6 Jahren

You're downvoted, but I agree. It's unfortunate, but that is why I say that discipline or an enforced style guide is required.

liquidisevor 6 Jahren

I have [self-diagnosed] Code Style OCD. Like you, the Flutter nesting levels was a major fear entering the space. It feels both ugly and inelegant.

I found i was over this fear in days if not hours, and continued to improve with my ongoing discovery of helpful UI components. Furthermore, defining your own components and breaking out inline functions into proper functions in your UI classes goes a long way, too.

Android Studio, if you use it (i didn't), auto-appends closing bracket comments to keep you visually aware of your nesting. For the reasons i stated, i don't think it is as important as you might think.

If you haven't tried Flutter, particularly for syntactical reasons, i would urge you dip your toes in.

runeksvor 6 Jahren

> Android Studio, if you use it (i didn't), auto-appends closing bracket comments to keep you visually aware of your nesting.

So does VS Code. I stared writing my first Flutter app a couple of weeks ago. I’m using VS Code and I have to say the IDE support is pretty great.

Regarding syntax and nesting levels, what I don’t is the `git diff` from wrapping the top-most expression in a new class, thus causing everything inside/below it to be indented further, even though only a single class was added. So e.g. wrapping an outer Column in a SingleChildScrollView causes everything inside the column to change in the diff because of added indentation.

kennethhvor 6 Jahren

Use the built in git tool in visual code. It highlights differently for white space or you can also turn off white space differences.

Liongavor 6 Jahren

You just don't throw everything in a big build method, but make small functions for every logical unit instead. Simple, easy, clean and maintainable.

tarkin2vor 6 Jahren

Smaller staircases. Split your component into functions.

I’ve seen some horribly large components that would be much better if split up.

Google should really advise this.

gladimdimvor 6 Jahren

You can also use Flutter Inspector - a UI tree representing your runtime layout. It allows to quickly jump between widgets

[deleted]vor 6 Jahren

hexovor 6 Jahren

From the screenshots and gifs over there I can tell that someone is again forcing people to look at 1) animations 2) grey fonts instead of black and they are even bragging about it being beautiful. These also tend to enormously waste screen space.

Are especially those two things configurable by user? I mean - there has to be no animations at all (why does anyone insist on animating theme change? that is just ridiculous), and black text, not grey. If not, that is complete deal breaker. Please tell me I'm wrong and one can configure everything there.

Single word: accessibility. More words: normal accessibility without needing to re-set whole system to be "accessible" just because one app developer can't behave.

solarkraftvor 6 Jahren

Non-animated changed are offensive to me. Humans are built to track moving things, not a thing instantly disappearing at one point and another, similar looking thing instantly appearing at another place, with no context telling you whether it's actually the same object. This gets worse the larger the state change is.

Similarly information overload is an issue, but of course too little information is as well. That's on the designers, though, you can certainly build information dense apps with Flutter if you want to.

From what I can tell there seems to be a platform multiplier for animations to enable slow motion mode (an important tool for developing good transitions), which I suppose you could just set to 0. And if it doesn't it's just on the developer again.

Basically: I won't deny that it can certainly influence decisions (actually I think it's an important thing to consider), but ultimately it's not really the plattform's fault if a developer decides to make an app you don't like.

hexovor 6 Jahren

Yes, animations really influence decisions. Mainly about using the particular piece of software at all (animations are no go for me and a lot of other people).

Some folks do not have the luxury to spend hundreds of miliseconds to seconds each time they do some action (and believe me or not, they do A LOT of actions per day).

Some people are actually using computers to do stuff as fast as possible so they have fast computers. Having fast computer doesnt automatically mean someone is willing to spend those resources on some eye candy.

Stuff moving around actually increases information overload as it adds to state one needs to track (moving object). To some folks this this even causes problems from medical reasons.

When it comes to information density, this should actually be up to user as well (lets call it compact mode for example) but at least to me it is not as critical as movements. Best would be being able to set "margin sizes" or something like that. And even that should be completely trivial given that no one should really write fixed-widget-position applications these days (i havent done so in ages, i'm using vertical/horizontal containers and spacers).

As should be application color theme as we are/were used to for a loooong time. But I understand that it isn't something Windows users are aware of, since each and every program there forces you to look at completely different interface that behaves in other way and has other ux logic.

I do think we can both agree that being able to stop all and every animation (including fading and whatever else in this category) is very important for user inclusion and accessibility. And since (as you said) slowing those down is needed for their development, "disabling" that feature should already be trivial. It just has to be available to user. Otherwise it's just an arrogant negligence and showing over-supremacy by "i know better what you like to look at".

avilesjvor 6 Jahren

I'm excited to have another contender on multi platform apps space but in the case of Flutter for desktop I just wonder about the RAM consumption compared to Electron.

programmarchyvor 6 Jahren

Dart compiles to native machine code, so unlike Electron doesn't need to host an interpreter, which tends to aggressively allocate memory. Should be much friendlier on RAM.

CSharpRonvor 6 Jahren

Great news for sure. There's a React Native application that I am maintaining; it's not too complex but I would love to give a rewrite a try with Flutter and see how it does on Ubuntu.

haolezvor 6 Jahren

For my usage, Flutter is a no-go for web development for the same reason as Qt: it's just a canvas, so text selection, accessibility, etc doesn't work nicely or at all.

heavyset_govor 6 Jahren

Having recently chosen a Qt stack for cross-platform desktop development over Electron, I'm happy to see that Flutter is now a real contender in this space.

I'm curious about Flutter and Dart bindings and calling interfaces for other languages. If you can integrate a Flutter front end with a back end language of your choice, that would change a lot of things for the better. The only reactive UI offerings for cross-platform desktop development with multiple language bindings are QML, which is great, or Electron with React, which is not so great if you want to use anything but JavaScript for your back end.

kelnosvor 6 Jahren

> Canonical is making it very easy for application developers to publish their apps for Linux users via the Snap Store, the app store for Linux.

Ugh. No, Canonical, no matter how much you'd like it to be, the Snap Store is not, and will never be, "the app store for Linux". The last thing the Linux community wants or needs is a closed-source[0], walled-garden approach to distributing applications.

[0] For the pedants out there: yes, you can create Snaps with open tools, but the only Snap server implementation is closed.

oaieyvor 6 Jahren

Microsoft really has to speed up the Xamarin.Forms / Maui development. The omission of Linux is a really a pity.

jayd16vor 6 Jahren

They said they'll have a preview by the end of the year. I'm excited to see it but I'd rather they do it right instead of right now.

CSharpRonvor 6 Jahren

TIL about Maui. From my light researching, it looks like any Linux implementation of Maui will be community-led instead of Microsoft led like the Windows and MacOS implementations.

https://github.com/dotnet/maui

langitbiruvor 6 Jahren

Their project, React Native for Desktop, also omits Linux.

https://microsoft.github.io/react-native-windows/

oaieyvor 6 Jahren

Well, here the vendor of a platform supports a framework. They are not the framework owner there (like they are for Xamarin, .NET, ...).

[deleted]vor 6 Jahren

ryuukk_vor 6 Jahren

etsevor 6 Jahren

What are some high quality non-Material, non-Cupertino themes that any Flutter (mobile) developers can recommend?

Material is well done, except I really don't like the actual design. Cupertino looks more like iOS 7 than iOS 14 and lacks something…

mixmastamykvor 6 Jahren

Good to see. I've been wanting to use Flutter for a Linux-based appliance but it still needed a lot of work on that front until recently. If there was a bittorrent library in Dart as well I'd be off to the races.

Up until this time I've been using Kivy for the application, but it has a ton of issues and doesn't seem to receive much investment or support, even if you wave money around.

olingernvor 6 Jahren

I haven’t dug into this, but I wonder what compatibility this will have with window managers, like i3

knotty66vor 6 Jahren

I've just tested on regular i3 (no Sway).

Works pretty well until you start moving or resizing the window but once I did it crashed the app a couple of times.

I also couldn't start the app fullscreen on a 4K display - it just displayed a small black rectangle. Other than that it felt fast and smooth.

It is an alpha though, so I thought it was promising nonetheless.

l3s2dvor 6 Jahren

Just tested on sway, it draws the title bar, but otherwise seems to work.

fungosvor 6 Jahren

Flutter: yay!

Snap: nope!

Anyway, hopefully this will cause a push for flutter support on other distros that are snap free.

timsneathvor 6 Jahren

It's worth noting that Ubuntu support and Snap support are orthogonal. The Flutter work here generates standard ELF binaries that can be distributed outside of Snap, and Canonical's contributions to create a high-quality desktop embedder for Linux are applicable across all distros.

jaekashvor 6 Jahren

Andrexvor 6 Jahren

I'm still excited because when Canonical backtracks on Snap in a few years (like they seem to always do when trying to push some homegrown aspect of Linux), their Flutter work will still be there and will have seen years of improvements.

jaekashvor 6 Jahren

That seems like it would be great, except for that it would still be Canonical's work and with everything they do it would probably be better for everyone if they did not bother.

Andrexvor 6 Jahren

That's not true, their upstream work for Gnome shell after ditching Unity is very appreciated.

Their announcement also pointedly remarks that the Flutter work will benefit "most distributions" of Linux. That's another good sign that this work won't be too tied up in Canonical's fiefdom.

reddotXvor 6 Jahren

flutter on Ubuntu 20.04 https://www.youtube.com/watch?v=MnXKtwKNAB4

flutter create flutter run

done

Dowwievor 6 Jahren

see the flutter-rust ffi: https://github.com/brickpop/flutter-rust-ffi

Is anyone considering writing flutter + rust desktop apps in linux?

g5becksvor 6 Jahren

Really wish Dart was more useful for server development. There’s a lot of missing packages that no one seems to be interested in writing right now though.

mleonhardvor 6 Jahren

That's normal for Google APIs. Only interesting stuff gets done. Boring problems stick around forever, wasting millions of user engineer hours.

Examples:

- Chain.capture() not working in tests https://github.com/dart-lang/stack_trace/issues/50

- Document exceptions thrown https://github.com/dart-lang/http/issues/245

- It's difficult to find content using normal browser find https://github.com/dart-lang/dartdoc/issues/2131

- SecurityContext.setTrustedCertificatesBytes fails with BAD_PKCS12_DATA https://github.com/flutter/flutter/issues/39190

- Add remote port information to Socket errors (2013!) https://github.com/dart-lang/sdk/issues/12693

- setTrustedCertificates doesn't work. Causes HandshakeException all the time https://github.com/dart-lang/sdk/issues/35462

- badCertificateCallback is called with issuer certificate instead of leaf certificate for LetsEncrypt published certificate https://github.com/dart-lang/sdk/issues/39425

- No way to preload Image from assets before first builder (needed for smooth splash screen with images) https://github.com/flutter/flutter/issues/26127

- Provide function to get the current system timezone name https://github.com/dart-lang/sdk/issues/21758

- Create an easy and consistent Exception base class https://github.com/dart-lang/sdk/issues/2909

- Google please provide a Location module https://github.com/flutter/flutter/issues/31453

- Widgets inserted in MaterialApp Navigator Overlay don't get theme https://github.com/flutter/flutter/issues/39379

- [firebase_messaging] PHONE_REGISTRATION_ERROR on Android API 18 with Google APIs https://github.com/FirebaseExtended/flutterfire/issues/1471

- Use layer style for colors in Design Kit for Sketch https://github.com/material-components/material-components/i...

ZeroCool2uvor 6 Jahren

I'm a huge fan of Flutter for a number of reasons, but I just tried the demo app Flokk and it doesn't work at all on vanilla Ubuntu 20.04 running Wayland. They actually had this working over a year ago on desktop, not sure how such a massive regression like this made it through.

topspinvor 6 Jahren

Interesting that Flutter "Desktop support" exists for macOS and Linux, but not Windows.

kjksfvor 6 Jahren

It does exist for Windows (i.e. I compiled and ran Flutter app on Windows).

It's just slightly behind macOS and Linux in maturity.

In general desktop support is "early alpha" quality.

I'm hoping that in a year or two Flutter will be a solid option for mac/linux/windows desktop apps.

For now we have to accept that it's an alpha quality software.

sgtvor 6 Jahren

Does this work well on RPi 4?

paulcarrotyvor 6 Jahren

Good news, but all depends how much Google interested in Linux desktop support in Flutter. I'm highly skeptical due to their "hyper activity" in Linux desktop niche.

thomascgalvinvor 6 Jahren

Does Flutter have a native HTML widget yet? It didn't when I first started poking around with Flutter, and a quick Google doesn't reveal anything first-party.

grizzlesvor 6 Jahren

WebView is such a core component.

In the interests of completeness, Flutter.dev really ought to bundle an android-like webview component in the core libs.

It really breaks the WORA value prop if you need to if-elif your way around platform specific impls.

mnazimvor 6 Jahren

A number of packages provide webview, which can be used to render html pages.

ellsthrowvor 6 Jahren

These still aren't "production" ready yet though unfortunately e.g. they don't currently support keyboard input

realusernamevor 6 Jahren

You do have Webviews but it's stil in an alpha state right now, they have poor keyboard support, no multiple tab support and are not available on anything else than Android & iOS.

Rapzidvor 6 Jahren

What's the story for extending a flutter application dynamically? Is it possible to write and load plugins for them?

ameliusvor 6 Jahren

Wouldn't it be possible to install Flutter with the usual ./configure; make?

[deleted]vor 6 Jahren

colesantiagovor 6 Jahren

What is the off chance that Google will drop Flutter?

cxrvor 6 Jahren

If the Vala folks and Gnome in general could be convinced to drop Vala in favor Dart, or move valac in the direction of accepting a language that looks like (a subset or a complex supersubset of) Dart, it could be an effective hedge against Google pulling out. It would also be an instance of Gnome and the various commercial vendors who rely on it being ahead of the curve—particularly for mobile, while proprietary vendors are still left dealing with the legacy of Android, Dalvik, and Java.

dathinabvor 6 Jahren

> Gnome in general could be convinced to drop Vala in favor Dart

I would be very surprised if that happens.

The last time I checked it seems that if anything changes then that bit-by-bit some components get replaced with new ones written in rust.

Also I honestly would be very surprised if Gnome would move from gtk-based UI to a flutter based UI interface.

I mean besides political reasons the amount of rework you would have to do is probably in a degree which makes it unpractical.

And in context of libre5 and some other developments there was a lot of effort to make gtk-based UI ready to be used with handheld devices.

pjmlpvor 6 Jahren

Gnome is already adopting Rust, and GJS has been the Vala alternative for ages, so no luck for Dart.

Also Gnome has had multiple language bindings since the early days, most of them have more use across Gnome apps than Vala.

cxrvor 6 Jahren

> Gnome is already adopting Rust

That's not accurate. There are some Gnome contributors opting for Rust. Gnome is not adopting Rust.

pjmlpvor 6 Jahren

GUADEC Rust meetings and the GStreamer improvements show another picture.

cxrvor 6 Jahren

No, the picture is exactly what I just described—that those contributors are using Rust.

pjmlpvor 6 Jahren

So unless GStreamer isn't a part of Gnome, Gnome is indeed using Rust as well.

cxrvor 6 Jahren

You mean the GStreamer bindings? And it would matter—some contributors could choose Rust, but Gnome as a project isn't moving to Rust. What aren't you getting here? Are you going to point at people using C++ or C# next? I'm done with this conversation.

pjmlpvor 6 Jahren

So those bindings are official part of Gnome project or not?

As for C++ it looks pretty official to me, it is even considered an internal resource:

https://developer.gnome.org/references#api-bindings

As for being done with me, who cares when the official web site sends another message.

pjmlpvor 6 Jahren

And here is another update from Gnome project regarding Rust adoption for Gnome Shell.

https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/...

[deleted]vor 6 Jahren

sudhirjvor 6 Jahren

This matters only if Flutter is a closed source project – but it's not. You can fork it on Github right now and continue working on it even if Google pulls its engineers off. I'd assume that those of us (and there seem be a lot of people) invested in it will continue working on it.

heavyset_govor 6 Jahren

> This matters only if Flutter is a closed source project – but it's not

It certainly matters. Without a team of dedicated developers maintaining the project, the APIs it depends on will become deprecated, and it'll slowly become unusable.

Flutter touches a lot of APIs across many platforms. It's a complicated project that needs to support virtually every popular operating system in a visually and behaviorally consistent way.

Flutter also depends on Dart's maintenance, which is another project without significant open-source contributor activity outside of Google employees.

> I'd assume that those of us (and there seem be a lot of people) invested in it will continue working on it.

Having contributed fixes to Flutter and Dart, Google does not go out of their way to build an open-source contributor community around the projects. I would be surprised to learn that any significant support is provided by open-source contributors to Flutter or Dart.

IshKebabvor 6 Jahren

> This matters only if Flutter is a closed source project

Nonsense. Even though it is open source, if Google drops it it will be effectively a dead project since the vast majority of the work is done by Google, and Flutter still isn't a mature project.

rkangelvor 6 Jahren

I like the architecture that Flutter has chosen where the only thing you need from the OS is a canvas and everything is painted by Flutter. It gets you a good programming model and predictable results regardless of target.

The downside is that in order to produce iOS or Android looking UIs someone needs to create every iOS and Android standard widget, with the same behaviour. If those widgets change in future versions of the OS, or new ones are created then more work needs to be done.

This is fine in the current project setup - the work is worth it to Google, but without a corporate backer that's the sort of thing that will fall behind.

dathinabvor 6 Jahren

It might make it even more interesting for some people ;-)

dathinabvor 6 Jahren

Only iff they drop Fuchisa.

And if they drop Fuchisa and flutter has enough (relevant) apps using it in the Android Ecosystem they probably would keep it still around.

But my guess is that one long play Google want's to keep open for them is to start replacing Android with Fuchisa and push for a ecosystem where they have control more similar to apple. I.e. directly push updates to phones without the phone manufacturer as middle man. As this is a source of a lot of problems with Android making it less competitive against iOs.

mikecevor 6 Jahren

"Only if they drop Fuchsia."

I hate to say it, but this is beginning to look like a real possibility. It looks like Google has been implementing into Android a lot of the modular, "make the system easier to update" aspects of Fuchsia with each release of Android. I think Oracle's continuing fight to make Google pay financially for using Java is doing more to keep Fuchsia alive anything else. If Oracle relents then it's possible that Nest devices (the only Fuchsia-based products currently shipping afaik) could eventually switch to an IoT version of Android... but since Oracle is a litigation firm that also happens to sell databases I don't see them ever stopping the lawsuits.

The_rationalistvor 6 Jahren

If Android switch to openjdk like everybody else, they'll be lawsuit proof

kllrnohjvor 6 Jahren

They did: https://arstechnica.com/tech-policy/2016/01/android-n-switch...

The runtime remains ART, though, but that wasn't the issue in the lawsuit.

pjmlpvor 6 Jahren

They did not, that article doesn't show the actual reality.

As one can follow up on AOSP Gerrit comments, code from OpenJDK gets cherry picked into Android.

https://android-review.googlesource.com/q/project:platform%2...

The_rationalistvor 6 Jahren

I had read that too and I do not understand at all. What is openjdk beyond a runtime VM ? They do not use what truly qualify as openjdk otherwise they would have C2 and G1 and therefore true java 8+ support, for free.

kllrnohjvor 6 Jahren

They're using the libraries - the part that Oracle is claiming is copyrighted. The java.* packages.

The_rationalistvor 6 Jahren

javax.* is copyrighted and is now copyleft if you use the jakarta.* namespace instead.

as for java.* I don't see how one could have issues, for example Kotlin use and extend the java standard library without any lawsuit. I believe that the issue was that Android devs copy pasted copyrighted code and putted them in their own reimplementation of the jdk without respecting the original authors. Their reimplementation (dalvik & ci) is the root of all evil and is technically a mess with antic java support. It's such a shame that we can't have ZGC or senandoah on android...

kllrnohjvor 6 Jahren

> I believe that the issue was that Android devs copy pasted copyrighted code and putted them in their own reimplementation of the jdk without respecting the original authors.

Your belief is firmly incorrect. The "copied code" claim was for a 9-line rangeCheck function and was otherwise dropped. The main claim is entirely that the java.* API definitions are copyrighted, and therefore Google's clean room re-implementation of the APIs still violates the copyright of the API itself.

Which is a lawsuit that Oracle won, by the way: https://en.wikipedia.org/wiki/Google_v._Oracle_America#First...

The open question at this point is whether a clean-room re-implementation of a copyrighted API for the purposes of compatibility is considered fair use or not. Which so far Oracle has been winning. Which means approximately everything is in copyright violation in the tech world. POSIX, for example, took the API from commercial Unix OS's of the time. The current owners of Unix, Micro Focus, could sue approximately everyone if Oracle wins.

The_rationalistvor 6 Jahren

I stand corrected yet while the legal implications are interesting and important the point still is that Android should totally switch to openjdk, end of story.

kllrnohjvor 6 Jahren

> important the point still is that Android should totally switch to openjdk, end of story

Not "end of story" at all - why should Android switch? You mentioned ZGC & Shenandoah, but why do you think that would be a benefit? Have you actually tried benchmarking your app in ART vs. OpenJDK? Do you have any clue at all if ZGC would even be an improvement in your workloads, or the workloads of a typical Android app for that matter? There's a lot of really cool work going on in that space, but for example ZGC's NUMA awareness won't do diddly shit for your Android app, so things like that are pretty moot.

Meanwhile ART has optimizations that OpenJDK doesn't, like importing profiles to AOT compile parts of an app that's never been run locally before: https://android-developers.googleblog.com/2019/04/improving-...

Similarly OpenJDK's startup time & memory usage is historically quite bad, because it's just not a primary use case for them in the same way it is for ART. OpenJDK finally got some improvements in those areas very very recently ( https://cl4es.github.io/2019/11/20/OpenJDK-Startup-Update.ht... ), but it's still not good and far from being obviously superior on all metrics to ART. And ART isn't standing still, either, with new improvements like even faster incredibly fast FFI support: https://android-review.googlesource.com/c/platform/art/+/132... Which is important for achieving things like 120hz 2D UI rendering while also running on incredibly slow in-order non-speculating power saving little cores. Which is a use case & scenario OpenJDK has never been asked to deal with nor optimized to handle.

OpenJDK isn't the end-all be-all excellent-at-everything pinnacle here. After all, nobody ever accused a Java desktop application of being fast & responsive.

pjmlpvor 6 Jahren

> OpenJDK isn't the end-all be-all excellent-at-everything pinnacle here.

Indeed, that is why since around 2000 there are multiple JVM implementations, including plenty of them with AOT and JIT cache capabilities.

The now gone WebSphere Realtime JVM already supported importing profiles for their AOT/JIT compilers.

And in what concerns phone devices, Microsoft did it first with their Cloud compiler for MSIL on Windows Store, first with MDIL/Bartok taken from Singularity for Windows Phone 8.x, followed up by the .NET Native toolchain on Windows 10.

Google's marketing is good, but not very influential for those that actually know the Java eco-system and the offerings available across all major vendors.

Also here is the confirmation that they will carry on cherry picking OpenJDK features instead of full compatibility.

" u/dessert_maker: We pick additional OpenJDK APIs for each Android release based on inputs from our developers. Android 11 will support additional APIs from OpenJDK 9. Everyone that is developing in Java and Kotlin should be able to take advantage of these newer additions.

In addition, we have added library desugaring to the build toolchain in Android Studio to make a wide variety of APIs across OpenJDK 8, 9, 10, and 11 available regardless of what version of Android your app runs on.

We expect to add support to the platform for more modern APIs (11,13,14) based on the level of adoption we see from our broader developer community in future versions. As mentioned in last year's AMA, making the overall runtime updatable is something we are thinking about as part of Project Mainline."

-- https://old.reddit.com/r/androiddev/comments/hk3hrq/were_on_...

So thank you Google for Android Java and like J++, forcing Java library authors to code specifically for Android, or just ignore it and focus on the myriad of JVM compatible implementations instead.

plqvor 6 Jahren

My hunch is that Google is trying to migrate away from Android. Flutter is both the abstraction layer to do that and the new SDK for the new platform.

If that's the case, it's higly unlikely.

daknavor 6 Jahren

I think Google realized they needed a compelling cross-plattform solution because React Native started to gain so much traction.

In terms of migrating away from Android, I think they will use the newer AndroidX packages as the future abstraction layer, which would enable them to replace the underlying runtime with something more native for each platform. It would be a compilation target for Kotlin as well as Dart. All while not deprecating the massive amount of production code out there. But, this is also just a guess.

izacusvor 6 Jahren

That's a really wierd take if you actually look at what AndroidX is - it's a set of utility libraries to complement Android so it being some kind of abstraction layer is rather nonsensical. It's like saying boost is an abstraction layer for Linux and it allows its replacement. It's an orthogonal thing that doesn't stand alone.

daknavor 6 Jahren

Yes, it's a set of libraries under one package name. With Google's massive investment in refactoring it has a pretty big surface already, from persistence to UI and almost everything in between.

https://developer.android.com/reference/androidx/packages

It's current implementation uses classes that are part of the Android layer, mostly the old support library plus some new abstractions like LiveData and Room and Navigation. I see no reason why you could not use the public interface of that library as a compatibility layer for application level code and let it run on a different platform.

Not today, but given the fact that you can't just kill the worlds most used operating system, you either use virtualization like Apple now does again for ARM (and before when replacing Motorola with Intel) or you change the underlying dependencies of the libraries used and compile again.

pjmlpvor 6 Jahren

That is more a defense move given that Kotlin cannot rely on Java FFI going forward than anything else.

pjmlpvor 6 Jahren

Except that Android team hasn't got the memo, hence Jetpack Composer, and increased adoption of Kotlin multiplatform as a defensive reaction against Flutter hype.

skcvor 6 Jahren

Google not too long ago released Jetpack Compose which has some overlap with flutter so it's anybody's guess.

https://developer.android.com/jetpack/compose

77pt77vor 6 Jahren

The level of redundancy between all these projects never ceases to amaze me.

ryuukk_vor 6 Jahren

adonesevor 6 Jahren

I think being used with Fuschia is a good sign

jillesvangurpvor 6 Jahren

It's not so much that they will drop it but they may loose interest in it and let it die off naturally. It all depends if they can convince enough people to use it. I've not actually seen or used any flutter apps yet. I'm sure they exist if you go looking for them but it's early days. Most stuff out there is not flutter based.

Google needs to work on untangling it from Dart and start actively working on Kotlin support. Dart is actually compiled to native code and the most of the UI stuff is basically written in C++. Kotlin has a native compiler already, so that's not necessarily a show stopper. And given the huge amount of Android Kotlin developers out there, it's kind of an obvious thing to do. Yet they choose not to work on this.

Fixing this would result in a lot of existing developers having an easy transition to flutter that are currently not planning to go there.

The reasons they are not doing this are entirely political and can be summarized as "not invented here".

Kotlin is a problem for them because it's 1) popular 2) the main language for Android development and 3) controlled by a company that is not Google.

Flutter is their attempt to fix this. They can't kill Kotlin because it's popular but they can try to replace it and nudge developers away from it. The problem for them is that Dart is not good enough. It's a hard sell and effectively a downgrade if you are used to Kotlin. They've been trying to fix that by adding features to Dart that are clearly intended to narrow the gap.

Fuchsia exists for the same reason. Yes there are technical reasons for it as well but the real reason is control over the ecosystem. The combined strategy is risky and dependent on the success in the market of their pixel phones. So far this is not looking great. Google convincing OEMs to jump on the bandwagon is going to be very dependent on them being able to launch a fuchsia phone. I'm pretty sure none of the OEMs is keen of having more Google control and oversight. So effectively, Google would have to launch a Fuchsia phone, make sure it becomes popular, and then twist the arms of all their OEMs to abandon Android. Failing to do that would result in a new phone platform with tiny marketshare that users, developers and OEMs can safely ignore. The mere prospect of that is the reason I expect it will never make it to market.

Flutter may or may not survive that decision. What's going to be interesting is what everybody else does. Flutter and react native are so far the two dominant cross platform approaches. React native could get a lot more interesting with things like wasm opening up that space for Kotlin and Swift developers. A lot of Kotlin developers favoring React Native over Flutter would be a big problem for Google.

skratlovor 6 Jahren

Yay, Macromedia Flash for desktop is here, made in Google, Dart instead of ActionScript, wow, just wow.

yjftsjthsd-hvor 6 Jahren

I assume that this is meant as a criticism, but Flash was quite good at easy-to-make portable graphical apps; they had massive security issues and some lack of polish, but there's a reason why Flash dominated its era. (Also, "Macromedia Flash for desktop" was already a thing, no?) So yeah, "Flash but modern and safe" would be a pretty strong selling point.

snodnippervor 6 Jahren

Flash remains the most productive UI development environment I have had over the past twenty years. Getting graphical apps working on all major platforms is a fabulous achievement by the Flutter folks.

I have no love for what Android has become and where Kotlin is going. The web today feels like a PDF...huge amounts of movement but not necessarily progress.

I hope more than anything that Flutter continues to gain traction. To my mind it is perfectly reasonable for next generation tech to write to the canvas with the latest widgets as long as there is good accessibility support.

Apocryphonvor 6 Jahren

There was just a thread bemoaning the lost art of Flash games last week:

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

zellyvor 6 Jahren

Yes, but this time it will work on Apple products.

akievor 6 Jahren

You're not wrong.

Spivakvor 6 Jahren

I think they're mostly wrong. I think we put too much stock into the default UI toolkits on each platform since this really isn't much different than how GTK and QT work. They have their own rendering engines and have to draw all their widgets from scratch just like this. The only difference is that GTK and QT are blessed.

I think there's a case to be made for sticking to the defaults for consistency's sake but Flutter is just as native as any other UI toolkit on Linux.