A Go Custom Flutter Engine Embedder for Desktop
github.com
github.com
Can I make a cross-platform GUI with it (a) in the current state, (b) maybe later? If so, what features does it support? How does it compare to Qt, Lazarus, Sciter, Elektron, etc? Does it have internal drag & drop? External drag & drop? Standard file and folder dialogs? Are widgets native or not (I suppose not, but it should be clear from a glance at the page)? Which widgets are supported? Does it have rich text support? Does it have OS-level clipboard support? Does it have transitions or not? Is it themeable? Is it fast? How large are executables built with it? Is it intended for ease of use or somewhat complicated? Do I need to write in other languages (HTML, markup, Javascript) to get things done or can everything be written directly in Go?
All of this is absolutely essential information. Nobody can reasonably decide whether to use this GUI toolkit or not without getting answers to all of the above question. So please, please explain in one sentence what Flutter is and make a section with keyword features.
[Please don't take this wrong, I'm not a naysayer. This is meant as a constructive criticism, not just of this page but of many similar ones. It sure looks like an interesting project.]
I would say for every product that is in a well defined category (like GUI toolkit) there is a default set of FAQ that an intro for it should answer. Maybe it would be a good idea to create an issue with a template of those FAQ, so other projects can use them as well.
It appears to produce a commercial quality cross-platform GUI, with not-so-bad looking, your only choice is Qt, be it Pyside2 or Qt/C++. For me I decide to use Pyside2.
I can't parse that. I know for certain that kivy runs very well on desktop platforms.
QT is OK if your GUI is very complex and you're targeting a desktop OS.
For simple GUI QT is just too big.
For GUIs without a desktop OS (mobile, embedded), QT is not a good fit either, not enough mobile support, and their embedded license can be prohibitively expensive.
I have positive experience building moderately complex commercial quality GUIs on top of this: https://github.com/memononen/nanovg
in my case I want to build a file manager and after some research I ended up with Pyside2
"Go Flutter desktop embedder". Well, that's that? Click (https://github.com/flutter/flutter/wiki/Custom-Flutter-Engin...)
"The Flutter Engine is window toolkit agnostic. " What's flutter engine? Click (https://github.com/google/flutter-desktop-embedding)
"The purpose of this project is to support building applications that use Flutter " Ok, but what's Flutter? Click (https://github.com/flutter/flutter)
"Flutter is Google’s mobile app SDK for crafting high-quality native interfaces on iOS and Android in record time."
OOOOH. Ok.
Does that help?
Anyway, back on topic: this is interesting, has anyone used GLFW for Go? What if I don't have a C or C++ compiler, how does Go handle C / C++ dependencies? Do you need everything required to build those too? I usually try to stick to things Go can compile in native Go as much as possible so I'm not familiar with this.
<details>
<summary>Click to expand</summary>
<div>Hidden until expanded, no JS or CSS required!</div>
</details>Ultimately though I’m not going to complain that an open source developer has documented their free code in a way that differs from my own personal preferences. But before jumping on the bandwagon it’s worth thinking about whether you want your README to be readable as plain text as well.
Actually, I've written an article a few days ago fantasising on how it could look like – "Thought Experiment: Flutter in Go"
tbh I don't really care in what language is written, but I would really like to create Apps with Kotlin using Flutter instead of having to learn another language that it's (in my opinion) a bit inferior than the one I'm currently using.
I can see myself using flutter as a thin UI layer and just forget about the mess that Android UI layer is...
Plus you never have to mess around with the Android UI layer...
LispWorks, Allegro, Cincom, GemTalk are still in business.
Please don't be shy and let us know about all those amazing Flutter/Dart applications in production that outnumber any of those vendors, both in customer base and business value.
Other than Ad Words that is.
I start with a couple,
- Google's own ITA (CL)
- Siscog traffic management solutions used across European train networks (CL)
- JP Morgan financial risk management (Smalltalk)
I like both of them, and they're historically important languages, but are not mainstream, and weren't mainstream even on their heyday.
I expected you to mean some post-Pascal Wirth-derived language though, or some other such project.
>Please don't be shy and let us know about all those amazing Flutter/Dart applications in production that outnumber any of those vendors, both in customer base and business value.
Well, Flutter 1.0 was just announced on Dec 2018 (so like a month ago) and the others had a 4+ decade headstart.
Still, some historical CL/Smalltalk apps aside (few enough to be enumerated in "success stories" style posts), in 2-3 years there will be more Flutter/Dart apps than CL and Smalltalk apps combined.
Heck, there are more Go apps in production "that outnumber any of those vendors, both in customer base and business value", and that went 1.0 less than 7 years ago.
If a language can enumerate it's success stories, it has already lost the popularity game. I've read the same "success stories" (and more) in Lisp forums and Smalltalk advocacy posts.
In fact, Dart before Flutter, was in the same boat "yeah, we use it in Google's ad management, and company X uses it for Y". But I have no doubt it will explode in popularity with Flutter.
Smalltalk.
Erlang.
Elixir.
Ruby.
Java (limited in core JDK/OpenJDK, though there is third-party support for more complete hot swapping via DECVM and HotswapAgent).
Does anyone know how Flutter fares when it comes to accessibility?
I think the web GUI stack is the only viable solution, but it can't be electron because of the redundant bulk--it will have to be something like ChromeOS: every program's GUI runs in its own "tab" (except tabs are laid out like windows); however, instead of pulling HTML/CSS/JS from remote servers, the servers would run as local daemons (it wouldn't really matter where the servers ran, to be honest; network transparency and all that).
I don't know how you get that. GTK needs more work, but Qt is spot on.
This is my opinion as a former Qt developer who dabbled in GTK in my spare time. Qt is all written in 90's C++ with all of the garbage that entails--awful memory management, CMake as a build system, no widely used package manager, shitty tools, etc. It's actually _worse_ than 90's C++ because it depends on a convoluted soup of preprocessor macros and a metaobject compiler in order to bolt onto C++ things like a dynamic type system and reflection. This means there's only one IDE that really understands it, and it was really buggy when I last used it (~2014). The one nice thing about Qt is QML, which is only nice to the extent that it removes or papers over the aforemetioned list of shitty Qt characteristics.
And GTK is strictly worse than Qt.
For all its issues, web development is nowhere near this bad--it's cheaper and easier for an organization to ship a bastardized browser alongside their web app than to build a Qt app.
I think a lot of this stems from the fact that Linux (or BSD for that matter) don't really have a "native" toolkit.
Also, I think people overestimate the importance of using native widgets. Anecdotally I would say that only about half of the apps I use on a daily basis actually utilize the native toolkit. Microsoft Office, Adobe Reader, IntelliJ IDEA/Android Studio, Visual Studio Code, Chrome, and Firefox are great examples of very successful software that are not built using the native toolkit.
On Linux too, the toolkits of a handful of the applications I use are also, shall we say, "home made".
In fact, widgets in Windows have been theme-able since XP. Why couldn't that have been made more available?
There's just no way that any generic widget set is going to 100% fill the needs of an easy-to-use, complicated GUI application. Nowadays when UI/UX actually matters in the success of software, it makes sense that developers are taking control of their UI's widgets. Cobbling together a GUI with a limited set of cookie-cutter widgets that are difficult to modify is no longer acceptable.
It's really not that bad but the world seems to ignore it.
No, and most of them are crap like Electron.
I believe one of the Dev sprints before 1.0 focused primarily on accessibility and there is a label widget that can wrap any widget to provide a name for screen readers.
I think the Flutter team takes accessibility quite seriously; https://flutter.io/docs/development/accessibility-and-locali...
EditTexts feel different, but as a user I don't see much difference..
Great job! and props to you for making it open source
But it is competing, isn't it?
Dart doesn't have the library issues like JS or the bloat like Java. In addition, Dart is an ECMA spec (like JS), so there are no copyright issues like with Java (other companies can even get committee members if they really wanted to invest in the language).
Dart was designed to prevent all the dynamic coding techniques that make JS slow (you can write very fast JS, but not in a normal style). Dart should be able to perform about as well as Java (it could beat Java on some benchmarks a few years ago).
https://www.nikolaybotev.com/blog/dart-vs-java-the-deltablue...
When you consider Java is multi-threading while the Dart implementations generally are not, performance is quite similar in the benchmark game too
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
Off-topic, but for the pidigit test, Java just unloads all the work to a C lib. How is that a Java test? Any language will be "fast" if they are actually just leveraging highly-optimized C libs.
No, not "instead-of" but "as-well-as".
Dart is a pain to work with. But to be honest, Flutter makes it worth putting up with.
I'd love for Standard ML to become popular as it offers all the things in a pragmatic package. The ML languages (and their hindley-milner roots) have sat around for over 45 years without being adopted into the mainstream. At some point you have to admit that the world isn't ready for a great language yet and go with something that is a step in the right direction.
If I have to use a lowest-common-denominator language, I'll take Dart over Java any day. The syntax is better, first-class functions with closures are far superior to anything Java offers, decent type inference, etc are all steps closer to SML and make life easier.
Even comparing with Java 8, dart syntax is much better IMO. Java 8 type inference gets better, but still not as good (Java 10 looks to be getting closer).
Java 8 type inference gets better, but still not as good (Java 10 looks to be getting closer). Java lambdas are a joke compared to Dart. This stems from functions being first-class in Dart, but being second-class citizens in Java. Dart can handle a much more functional programming approach much more easily than Java.
Java closures only work with final variables while dart works with all enclosed variables. In Java, if I want a function to accept another function, I have to explicitly say that I accept a Lambda because Lambdas are special cases. With dart, I can accept any function that matches my expected types because functions are first-class. Another big difference is that Dart functions can be top-level. If I need a one-off function somewhere, I don't need to pack it in a class. I just make it and use it.
I also prefer Dart syntax because of things like private variables, implicit setters/getters, named parameters, async/await, no need for `new` keyword everywhere, implicit interfaces, generators, etc.
And if we get started on supported OSes, available libraries, modelling tools, industrial vendor and IDE support, then it is a non-starter.
This putting aside that Kotlin, Scala, Common Lisp and Clojure are also options on the JVM.
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
Fuchsia also uses Flutter and Dart for the UI, but they are now playing with alternative UI engines and the Android team is adding support to run ART on top of Fucshia.
Java does the latter badly, and Javascript doesn't do static types and AOT (with the possible exception of someone's custom bizarro Rube Goldberg JS compiler).
It's also simpler than Java, saner than Javascript, and more under Google's vision and control than either.
From what i understand, it allows you to package your flutter application (android/ios framework using dart) as a standalone binary on windows/mac/linux.
- I don't want to return to C++
- I dislike javascript for large projects because even the best tooling is lacking, and the exploding dependency count.
- I love C#, but WPF renders worse than Electron (and Windows only).
- WinForms - mothballed.
- VB6/Delphi are EOL.
- UWP - Very lacking, will probably be abandoned.
- Java - I have no experience.
It will be a case of Flutter sucking less than the current options. Dart is actually a nice language, especially considering the runtime size - there's no framework overhead/bloat.
I imagine it to be Electron, but with a decent set of widgets and without the overhead.
Edit - to answer the main question:
Personally, I wouldn't develop anything more than a throw-away or personal project right now, but it's worth keeping an eye on it.
It would be nice to have a cross-device framework.
I think it's unwarranted, though.
If I'm going to contribute to an open source project in my free time, I'm more likely to contribute to a project if it is written in a language I enjoy working with.
It's an interesting line. I like the notion of apps I use being written in one of the more modern languages (GO or Rust) but it's not a core feature to a user. This means I can appreciate the language being mentioned but in a much less prominent way. If language isn't critical to a user or developer (of other things) IMO it shouldn't be so prominently mentioned.
I don’t think it’s much of a trend. It seems a practical thing to do to ensure your project can be found by others—it helps when you want your <thing> to be found when someone searches for “<language> library for <thing>” or “do <thing> in <language>”. For Go specifically, it often may be mentioned alongside “cross-platform”, a signifier that you can use it for such work and, I think, also to help when people search for that term when looking to do <thing>.
While this is a feature not strictly limited to Go, Go applications on the whole have been very easy to install, so it piques my interest when I can have some confidence that using it is just a simple command away.
Go has very simple dependency management. A library written in Go generally needs very little environment management and will often integrate easily with a Go codebase. This is further enhanced with Go’s implicit inheritance model.
Go compiles to a static linked binary. A library written in Go usually can be static linked as well with no system dependencies.
Go has excellent cross platform support. Unless a library makes system calls (and sometimes even then), it will also be cross platform.
Go has a clean, simple, style. The lack of features like generics, operator overloading, and constructors means you can look at the code and instantly understand what it does. There is no spooky action at a distance because a variable declaration turns out to be a complex function call. This makes it much easier to understand the overall system impact of using libraries written in Go.
Applications and libraries written in Go build very quickly. My experience with other languages is that trying a substantial new package is a go-make-a-sandwich level of inconvenience. Go libraries usually are ready to use as soon as git clone finishes.
By default. Go has supported dynamic linking for a while now.
Go's actually on the tail end of that right now; I've seen a number of things posted to HN that are just implemented in Go without saying so. Of course if you don't click through and look, you won't notice. :) But at this point, if I click through to a GitHub of some project and it's in Go, it's only mild surprise at best; it is most of the way to being just one of the default choices.
There's an even earlier version of this phase, which is when all the projects include the language in the name of the project, i.e., "gosql", "gobrowser", "punwithgo", etc. Go's been out of that one for long enough that I think it's kinda off when a new library has "go" in it unless there's a really good reason (for instance, development tools that really are about Go specifically and not just implemented in Go).