Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Question] How does this compare to the "official" flutter desktop? #191

Open
StefanLobbenmeier opened this issue Jul 15, 2019 · 8 comments

Comments

@StefanLobbenmeier
Copy link
Contributor

commented Jul 15, 2019

Hi,

I found this article on medium. From my understanding, that means that flutter has an official approach to flutter-desktop, what does this mean for the future of this approach?

@Drakirus

This comment has been minimized.

Copy link
Member

commented Jul 15, 2019

@GeertJohan and I are maintaining this alternative desktop embedder.

This approach has some benefits: plugins are way easier to write in Golang than in C++/Objective-C; and our API is easier to use for non-system developers. Those reasons are why we are maintaining such package.

The major drawback is that we aren't part of the flutter team. So at some point, if @GeertJohan and I stop maintaining this package, it is going to die.

That been said, the embedder is a relatively small layer between the flutter/engine and a rendering API (GLFW in our case). The flutter/engine ABI is stable, and shouldn't change too much. I don't think go-flutter will stop working; most of the bugs are fixed. The only deprecated feature we are using from the engine should be resolved by #175

My opinion is:

  • Your Flutter app works regardless of the embedder you use, official or unofficial?
    • Choose the embedder you prefer!
  • You have an issue with the 'official' flutter desktop
    • Give go-flutter a try, it's rare, but sometimes features are available in go-flutter before FDE.
  • You have to write a plugin:

Your core business logic is written in Dart; there is no cost in swapping the embedder!
The only waste you can make is: you have written a go-flutter plugin, and the go-flutter project suddenly stops working with the latest version of flutter, you have to throw your golang code and rewrite it into C++/Objective-C (Keep in mind that C++/Objective-C codes are usually more cost-heavy to develop and maintain).

To sum up,

How does this compare to the "official" flutter desktop?

Not that much, modulo some implementation differences, it's the same, but in another programing language.
You will have to use hover instead of flutter / export ENABLE_FLUTTER_DESKTOP=true because we cannot plug our-self into the flutter toolkit for building the embedder. Using the flutter toolkit or hover, your flutter dart code will be compiled the same way (with flutter build bundle)

what does this mean for the future of this approach?

At some point, FDE will have more feature than what go-flutter offers. I'm okay with that; we aren't google!
Also, more importantly, if you miss a feature from go-flutter and need to use FDE to have that feature, than go, it's basically free!!!


Edit1: what I was calling FDE is now part of flutter, it should now simply be called 'flutter desktop'.


Edit2: it's possible to write macos plugins in swift.


Edit3: Look at the below #191 (comment) to get the latest differences.

@Drakirus Drakirus added the question label Jul 15, 2019
@davidmartos96

This comment has been minimized.

Copy link
Contributor

commented Jul 16, 2019

@Drakirus I think the answer to this question would be great to have it linked in the README or in the Wiki. I also had this question when looking at the different desktop alternatives with Flutter.

@Drakirus

This comment has been minimized.

Copy link
Member

commented Jul 16, 2019

@davidmartos96 I have linked the question in the Wiki. Also, the README notices the user of the existence of a wiki.

Leaving this Issue open; If anyone has questions about this package, we will be happy to answer them!

@Drakirus Drakirus pinned this issue Jul 16, 2019
@StefanLobbenmeier

This comment has been minimized.

Copy link
Contributor Author

commented Jul 16, 2019

Thanks for the elaborate answer :)

@stuartmorgan

This comment has been minimized.

Copy link

commented Sep 13, 2019

A few minor notes, since there have been a number of changes since July. (Please don't take this as criticism; I think your overview of the similarities and differences is excellent!)

  • it's the same, but in another programing language

    This is no longer true on Windows, and has actually never been true on macOS. Only Linux is using GLFW now.

  • export ENABLE_FLUTTER_DESKTOP=true

    This is no longer used

  • your flutter dart code will be compiled the same way

    This is no longer true on macOS, where release mode is now AOT rather than JIT. (That will follow for other platforms in the future.)

  • it's possible to write macos plugins in swift

    Not just possible, but the default.

@phanirithvij

This comment has been minimized.

Copy link

commented Sep 28, 2019

@stuartmorgan is it possible to use go plugins from the official flutter-desktop-embedding repo? I'm assuming that's not in the project's goals.

@Drakirus

This comment has been minimized.

Copy link
Member

commented Sep 28, 2019

@phanirithvij go-flutter plugins aren't compatible with Flutter Desktop (used to be flutter-desktop-embedding) and Flutter Desktop plugins aren't compatible with go-flutter.

@stuartmorgan

This comment has been minimized.

Copy link

commented Sep 28, 2019

To expand on that a bit:

is it possible to use go plugins

Flutter plugin APIs are part of each embedding, not Flutter itself; there's no such thing as "go plugins" for Flutter in a generic sense, there are go-flutter plugins. The lack of interoperability isn't primarily about them being in Go, but that the APIs are not the same.

As one concrete example: go-flutter's plugin API appears to include a way of getting a pointer to the GLFW window. Flutter's macOS and Windows embeddings have no GLFW windows (Linux won't either, eventually), so it's impossible to use a plugin that expects one. The richer the plugin APIs become, the more of that kind of problem will exist.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
5 participants
You can’t perform that action at this time.