The current Linux implementation is based on GLFW, and is mostly suited to just bringing up a single window containing nothing but the Flutter application. Ideally we want something more like the macOS implementation where Flutter could be a view within a native application.
Unlike macOS and Windows there's not a clear choice of toolkit to use, but GTK is one possible option.
there was interesting discussion about this on twitter some time ago:
That discussion seems to assume that the only goal is to simply launch a Flutter app as a desktop app; I don't see any mention of hybrid app development. Given that a somewhat popular question on the flutter-dev list recently has been how to embed a Flutter view into a native mobile application, it seems important to consider on desktop where it seems more likely to be potentially useful than on mobile.
GLFW is fundamentally at odds with supporting hybrid applications as far as I can tell.
makes sense. maybe make gtk and qt solutions later on.
At the same time, using GLFW has benefits (no dependency on gtk, for examle). So the goal is to support both strategies?
The current plan is to eliminate the GLFW implementations as the view-based solutions for each solution are implemented.
While we could potentially keep the GLFW implementation as well, it has fundamental limitations (e.g., the menubar plugin will never work well), and supporting four implementations rather than three would add more complexity. But if there end up being important use cases for a GLFW implementation it could be kept.
I would say that for pure-flutter applications the GTK only adds extra overhead. I'm not sure if there is a performance difference between GTK and GLFW, the latter feels simpler.
Anyhow, a menubar can be implemented in pure flutter as well. VS Code recently added a custom menubar so it's not depending on the native one anymore, it aligns the look and feel on each platform and allows for better styling with the rest of the application.
At the same time I can see how maintaining two implementations adds complexity, so yes it should only be done if GLFW is actually used and has real-world advantages over GTK (or other toolkit).
Peanut gallery/couch programmer comment but genuinely interested if you're open to responding, Why is not using Skia like Flutter does on Android/iOS?
I would say that for pure-flutter applications the GTK only adds extra overhead.
It certainly adds dependencies. Whether that will be a significant issue in practice remains to be seen.
for pure-flutter applications [...] the latter feels simpler
I suspect most people doing pure-Flutter applications on mobile don't think/care much about what the platform implementation looks like, and similarly won't care much (again, beyond potential concerns about dependencies) about whether the Linux implementation uses GLFW or GTK once there's Flutter-like tooling that abstracts away the need for most people to interact with that code.
Anyhow, a menubar can be implemented in pure flutter as well.
It was just an example. The fact that it's possible to implement things entirely in Flutter has not eliminated a desire in the existing mobile Flutter development space for support for hybrid development, and GLFW can't support that. GTK, on the other hand, can support both models of development.
Why is not using Skia like Flutter does on Android/iOS?
I don't understand the question; I'm not aware of any difference between how Skia is used by the Flutter engine on Linux vs Android and iOS. But if you have questions about the details of the implementation of the Flutter engine, this project isn't a good place to get answers since it's just a client of the engine.
@ninjatraderdev Skia is still used here. GTK and GLFW can be seen as a "frame" around the rendered application UI. GTK or GLFW just handles the creation and management of a window in which the Flutter application is rendered (by Skia).
Of course GTK can draw things like buttons itself as well, but that's not being used by Flutter.