I need to open a different window that runs a webview. The use case is because i need to load some external third party stuff in that is just web based.
On desktops i use zserge which loads the native webview of the OS browser.
https://github.com/zserge/webview
Its great and easy.
So i am proposing a Flutter Desktop plugin for a Webview, just like the Flutter Mobile plugin here:
https://github.com/dart-flitter/flutter_webview_plugin
The API will be different for now of course.
Here is the golang wrapper over the cpp code.
For example here its obvious: https://github.com/zserge/webview/tree/master/examples/minimal-go
I see 2 options:
If anyone has any other thoughts on this before i drill into this let me know.
I need to open a different window that runs a webview.
This seems like a pretty specific use case (as opposed to doing an inline webview); it's not clear to me this would be sufficiently general-purpose to add to this repository. I'd suggest hosting it separately, and if there's sufficient interest we could look at folding it into this repo. (Although long-term, I expect more federation, not less, with a model matching that used by mobile Flutter.)
Is there a compelling reason for it being developed in this repository?
If you're not developing it in this repo you can build it however you like, but:
i could make a shell call presumable from the Dart side to open the binary
That gives you a new application, not a new window. Those are fundamentally different.
due to zserge having a cpp base language to call
That API appears to be designed for making self-contained applications; it appears to be very poorly suited to showing a window within the context of an application that's doing other things. Going from a platform-specific plugin API to a thin cross-platform wrapper that appears to have the wrong abstraction for your use case which in turn immediately splits back into platform-specific code internally seems strictly worse that doing what you want to do directly using the platform APIs.
Is there a compelling reason for it being developed in this repository?
Absent an answer to this question, closing.
@stuartmorgan sorry missed this issue
thanks for the comment. It helped me alot to what a better way to approach it.
For now i am going to leave this as its way beyond me i have to admit
So is it possible to open a webview in desktop flutter somehow?
If you want it in a new window as requested in this issue, yes: write the platform-specific code to do so as you would in any other native application (e.g., on macOS, create a new NSWindow containing a WKWebView), and then call that code from a plugin.
(Embedding native views within the Flutter view, on the other hand, is currently not possible with the Flutter embedding API.)
@stuartmorgan is this still the case? For example if we want to use google maps in flutter on the desktop would we need to get the embeed views working first on MacOS? for a temporary solution we can still open urls with a urlLauncher right?
For example if we want to use google maps in flutter on the desktop would we need to get the embeed views working first on MacOS?
That's correct. That reminded me that I never filed the bugs for those, although it's certainly something that's been on the radar. I've just filed https://github.com/flutter/flutter/issues/31712, https://github.com/flutter/flutter/issues/31713, and https://github.com/flutter/flutter/issues/31714 for tracking.
for a temporary solution we can still open urls with a urlLauncher right?
I assume you mean the url_launcher plugin? You'd need to write the native side locally, which would be straightforward if you are familiar with writing plugins (or wait for it to be written, which will likely be fairly soon since it's an obvious starting point for experimenting with what the plugin infrastructure will look like on desktop, and the plugin API is much more stable than it used to be.)
Ok I don鈥檛 mind writing the plugin side, using platform channels right?
Is there any way to publish the desktop plugins?
I have a repo of a lot of plugins I made, I would love to add desktop support for them.
Dart Pub shows Flutter and Web, do you think it will show desktop too?
using platform channels right?
Yes. On macOS, the APIs are almost identical to the iOS versions. (A couple of classes still have the FLE prefix, and will change in the future; that will be a breaking change, but one easy to update plugins for.)
Is there any way to publish the desktop plugins?
There's no tooling for automatically managing desktop plugins yet, so you can make them available however you like. Anyone using them at this point will need to manage building, including, and linking themselves.
I have a repo of a lot of plugins I made, I would love to add desktop support for them.
There are currently APIs for all three desktop platforms, so you could do that any time you want. Be aware that there are no guarantees about the stability of those APIs though, so you may need to change or rewrite anything you do now. (In practice, you can consider the macOS APIs that have the Flutter prefix, which is almost everything for plugins, to be stable. Linux and/or Windows APIs could change, possibly including a complete rewrite.)
Dart Pub shows Flutter and Web, do you think it will show desktop too?
There are a lot of open questions about how plugin management will work given a much larger set of possible platforms; I would imagine that some kind of discovery system that takes that added complexity into account would need to be part of that.
Hello, is it possible to embed NSViews view in Flutter view now? I need to embed a WKWebView to display the web, is there a good solution at present?
Webview support requests are tracked in the Flutter repository:
https://github.com/flutter/flutter/issues?q=is%3Aissue+is%3Aopen+webview_flutter+label%3A%22a%3A+desktop%22
Most helpful comment
Yes. On macOS, the APIs are almost identical to the iOS versions. (A couple of classes still have the
FLEprefix, and will change in the future; that will be a breaking change, but one easy to update plugins for.)There's no tooling for automatically managing desktop plugins yet, so you can make them available however you like. Anyone using them at this point will need to manage building, including, and linking themselves.
There are currently APIs for all three desktop platforms, so you could do that any time you want. Be aware that there are no guarantees about the stability of those APIs though, so you may need to change or rewrite anything you do now. (In practice, you can consider the macOS APIs that have the
Flutterprefix, which is almost everything for plugins, to be stable. Linux and/or Windows APIs could change, possibly including a complete rewrite.)There are a lot of open questions about how plugin management will work given a much larger set of possible platforms; I would imagine that some kind of discovery system that takes that added complexity into account would need to be part of that.