Support for Flutter Desktop

[d0mmi]

Environment

Flutter version: newest Plugin version: newest Android version: - iOS version: - Xcode version: - Device information: Windows / Linux / MacOS Desktop

Description

What you'd like to happen: I would like to have this to be compatible with the Flutter Desktop version. Most important for me would be the Flutter Desktop for Windows.

[nmcain]

I would love this too, is it possible?

[nmcain]

I dont even know where to begin, what language would you use on Linux?

[pichillilorenzo]

For macOS, it should be easy, as WKWebView is the same as iOS. For Linux, I think we can use something like this: https://webkitgtk.org/. For Windows, we can use Microsoft Edge WebView2 (https://docs.microsoft.com/en-us/microsoft-edge/webview2/).

[breebee]

Hey guys whats the progress here with desktop targets? Where can I follow the progress, if there isnt much work left to do I want to hire someone to finish the job.

[CodeDoctorDE]

I need it too :)

[pichillilorenzo]

To follow Flutter PlatformView API availability for Desktop, see:

• MacOS: https://github.com/flutter/flutter/issues/41722
• Linux: https://github.com/flutter/flutter/issues/41724
• Windows: https://github.com/flutter/flutter/issues/31713

The only thing I can do now, probably, is to implement only the InAppBrowser class (so, no Flutter widget integrated to the flutter widgets tree at the moment!) for these platforms. For Linux and Windows platforms, it is also more difficult because I need to write native C++ code, so probably it will take more time (especially because I have zero experience with C++).

[devilAPI]

please implement this, that would be great

[pichillilorenzo]

I think that MacOS will be the first platform to be supported because it should be the easiest one, using the same code of iOS

[ghost]

It'd be great to support macos & windows.

[pichillilorenzo]

Here is an update:

Starting from plugin version 5.4.0, there will be a lot of deprecation that will help me to initialize the work for Desktop Support. It means that every event/class/method/property/etc. that starts with the "android" or "ios" keyword will be renamed without that keyword unless for specific reasons.

For example, events such as androidShouldInterceptRequest and iosOnNavigationResponse will be renamed to shouldInterceptRequest and onNavigationResponse (or something like this). So, androidShouldInterceptRequest, iosOnNavigationResponse, etc... will not be deleted, just deprecated respect to the new counterpart. It doesn't mean that the particular event/class/method/property/etc. will be supported by all platforms. The list of platforms supported of an API will be documented on the specific Docs of it.

Also, consider to support this project making a donation: https://inappwebview.dev/donate/

[acx70]

I look forward for some news too ... (good job by the way)

[CaptainDario]

This plugin is absolutely amazing! I would love to port my app which uses WebView to desktop. @pichillilorenzo Therefore I am curious if desktop support can only be achieved once the flutter team adds PlatformView support to flutter on MacOS, Windows and Linux? All of them are tagged with "P4" and will sadly take a long time to be implemented...

[CaptainDario]

While researching about WebView and desktop platforms in Flutter I found a package which makes a WebView available for windows. @pichillilorenzo Maybe this can be used for this package on windows?

[epvbergen]

The desktop_webview plugin supports all 3 desktop platforms. Can that effort help inapp_webview?

It would be fine for inapp_webview to initially offer limited support only and open a separate window on desktop platforms. But it would be great if Flutter applications would only need one API, not two (inapp_webview on mobile and desktop_webview_window on desktop). One of the biggest pluses of Flutter is that it allows a single code base that works everywhere and offers good performance and good native bindings.

I'd rather use a desktop capable inapp_webview, as that produces support for SFSafariViewController on iOS. desktop_webview only does WKWebview, which is a bit of a second class citizen in the kingdom of Apple. uche WebRTC uche.

[marco-1988]

Hello

Is there any news about a plugin update with Linux platform support?

I can't find any webview plugins that work on Linux. I had read that from version 5.4.0 some actions would be initiated that would lead to a start of support towards the desktop.

Do you know anything about it? A roadmap of when it will also be supported by Linux? Around I find plugins that work for Windows, for macOS, for the web, except for Linux, which the only one is dekstop_webview_window but it's not good because it opens in a new window and I need it integrated into the app.

Thanks

[liaoxuewei]

It'd be great to support macos & windows.

Yeah, I think so. This will take flutter to the next level.

[CaptainDario]

@pichillilorenzo recently I found the webview_cef package. Maybe until platform views are ready this could be a great alternative?

[pichillilorenzo]

@CaptainDario I'm currently working on the macOS implementation (without platform views but using a separate Window such as the plugin you mentioned). It should be available with 6.0.0-beta.3 soon.

[CaptainDario]

The desktop_webview plugin supports all 3 desktop platforms. Can that effort help inapp_webview?

I guess you mean this package that opens a separate window. But the plugin I mentioned does not open a separate window (if i am not mistaken), it uses chromium embedded framework to render as a normal flutter widget.

[pichillilorenzo]

Ah wow, I didn't notice it. Also, just checked platform view support for macOS and it seems it is already available in a certain way. I will try it

[CaptainDario]

Ah wow, I didn't notice it. Also, just checked platform view support for macOS and it seems it is already available in a certain way. I will try it

Windows also already has some progress on the platform view problem.

[pichillilorenzo]

Version 6.0.0-beta.3 with MacOS support is released now!

Unfortunately, I tried the current platform view implementation for MacOS but it still not working, so we need to wait for the Flutter team to fix it.

The current MacOS WebView implementations are the InAppBrowser and HeadlessWebView classes! Check Setup MacOS

[jaroslawdabrowski]

@pichillilorenzo that is great news! We are very happy to see the macOS support. I have already tried it and it works great. The way it opens in a separate window is fine for us. Are you also planning to add support for windows soon? Thanks in advance for you response.

[pichillilorenzo]

@jaroslawdabrowski unfortunately, there is no plan to add support for Windows and Linux soon. They require C/C++ knowledge, which I don't have. There is a proposal for Windows to make C# usable for Flutter plugins that will help a lot:

• https://github.com/flutter/flutter/issues/64958

So, until then, there is no plan for Windows.

[stevehayles]

The Windows WebView2 component has been integrated into Flutter in a couple of repos, including this one. This utilizes off screen rendering via the Windows 10 API's to allow a non-windowed "in_app_webview" style integration.

I have had a quick go at integrating it into this library and it worked straight away so I think Windows integration is very achievable. Pull from my fork here and run 'flutter build windows --verbose' for a build in the 'example\build\windows\runner\Release' folder or 'flutter run -d windows '.

There is an outstanding issue with High DPI screens and I haven't considered licensing but it looks like a merging of the controllers used in each library would be possible. Only a proof of concept and I won't be able to take it much further due to time constraints. Please check licensing and give due consideration to the author if anyone takes it further

[liaoxuewei]

The Windows WebView2 component has been integrated into Flutter in a couple of repos, including https://github.com/jnschulze/flutter-webview-windows. This utilizes off screen rendering via the Windows 10 API's to allow a non-windowed "in_app_webview" style integration.

I have had a quick go at integrating it into this library and it worked straight away so I think Windows integration is very achievable. Pull from my fork at https://github.com/stevehayles/flutter_inappwebview and run 'flutter build windows --verbose' for a build in the 'example\build\windows\runner\Release' folder or 'flutter run -d windows '.

There is an outstanding issue with High DPI screens and I haven't considered licensing but it looks like a merging of the controllers used in each library would be possible. Only a proof of concept and I won't be able to take it much further due to time constraints. Please check licensing and give due consideration to the author if anyone takes it further

Very good news. I'm looking forward to it!

[pichillilorenzo]

@stevehayles the problem is not that I can't develop the plugin for Windows or Linux. The problem is that they require C/C++ knowledge, which I don't have! Using C/C++ will be too much work for me. It's not straightforward. Also, plugin maintenance for these platforms will be a lot harder for me. At least, for Windows, I will wait for C# support, so that should be easier.

[stevehayles]

@pichillilorenzo I was just pointing anyone that was interested to my working solution which has the Windows WebView2 component integrated into your library. Pretty much all of the C++ code won't need touching and the build chain and plugin integration is also fairly complete. Having tested it, I have decided it's not the right solution for my particular use case but it's hard to search through the numerous forks these projects end up with and I figured it might be a good starting solution for someone.

Don't hold your breath on C# support in Flutter, that will be a very controversial inclusion....!

[pichillilorenzo]

@stevehayles unfortunately, the integration you made isn't a valid integration for the plugin because it isn't using the official InAppWebViewController class or other classes of the flutter_inappwebview plugin. It seems to be just a copy and paste of the Windows code of the other flutter plugin, so it's not the right way to do it. All the integrations should use the main classes, such as InAppBrowser, HeadlesswebView, etc... (as I have done for the macOS platform), otherwise, it doesn't make any sense because it won't be a cross-platform plugin.

What do you mean by "controversial inclusion"?

What I mean is that C# is more suitable for me because it's more like Java, so it's easier to develop and maintain the plugin code for me.

[stevehayles]

@pichillilorenzo What the Windows plugin code does is use a WebView2 native windows component and renders it to an offscreen buffer that is usable from within Flutter. The adaptation of this approach to your existing InAppBrowser only really touches the Dart / Flutter side of the plugin. If you look at the code here I think you could fairly easily adapt the code to use your existing controllers and fully integrate it without touching any of the C++ code.

If and when C# integration is implemented for Flutter plugins, I think you will end up creating almost exactly the same thing from the native side of the plug-in with all the overhead and performance hit of doing it in managed code which in reality will just be a P/Invoke wrapper around some very similar C++ calls. I'll leave it there as it's not the right solution for my scenario; I think it's still usable for anyone that wishes to take it further. Nice work on the library in general!

[pichillilorenzo]

@stevehayles ok, thanks for your point! 👍

Yes, I know, but currently, I think it will be simpler for me to use C# than C/C++. You need to consider that I'm not just exposing native methods/events to the dart/flutter side! In some cases, when there is a feature that is not available natively for a specific platform but could be implemented in some way, I implement it on the native side directly (examples are: Content Worlds for Android, User Scripts for Android, Web Message Channels and Web Message Listeners for iOS and macOS, and so on ...).

However, maybe, when I will have more time, I could try to go deeply into it with C/C++, but I strongly prefer C# if I need to write native code to implement features not available natively on Windows WebView2.

[liaoxuewei]

Now this discussion result means that we won't further support windows in the near future?

[pichillilorenzo]

@liaoxuewei unfortunately, currently, there is no plan for it in the near future.

[sugur]

@CaptainDario I'm currently working on the macOS implementation (without platform views but using a separate Window such as the plugin you mentioned). It should be available with 6.0.0-beta.3 soon.

Can embedded in one window not open a new window for macos ?

[pichillilorenzo]

@sugur as I said:

Unfortunately, I tried the current platform view implementation for MacOS but it still not working, so we need to wait for the Flutter team to fix it. The current MacOS WebView implementations are the InAppBrowser and HeadlessWebView classes!

[sugur]

@sugur as I said:

Unfortunately, I tried the current platform view implementation for MacOS but it still not working, so we need to wait for the Flutter team to fix it. The current MacOS WebView implementations are the InAppBrowser and HeadlessWebView classes!

Thanks , if update for this , please talk to me.

[vorte]

There is a webview_windows package which works quite well. Maybe it can be used as a base for the windows implementation here?

[sugur]

There is a webview_windows package which works quite well. Maybe it can be used as a base for the windows implementation here?

But it not support MacOS platform.

[TekExplorer]

There is a webview_windows package which works quite well. Maybe it can be used as a base for the windows implementation here?

But it not support MacOS platform.

Thats still a good starting point. Its not like desktop needs to be supported all at once. also, i see flutter_macos_webview exists, so maybe thats something?

[sugur]

@sugur as I said:

Unfortunately, I tried the current platform view implementation for MacOS but it still not working, so we need to wait for the Flutter team to fix it. The current MacOS WebView implementations are the InAppBrowser and HeadlessWebView classes!

@pichillilorenzo Is support in-app webview for macOS platform now? thanks!

[sugur]

flutter_macos_webview

@TekExplorer it not in app webview , in like popup new window or dialog.

[gslender]

I'd be happy to migrate the Windows code using my skills in C++ to make this integration between https://pub.dev/packages/webview_windows and https://pub.dev/packages/flutter_inappwebview work in accordance with how the flutter_inappwebview library works... ??

[mateojc008]

Does anyone have any idea when InAppWebView will be available for the MAC? Currently only InAppBrowser and HeadLessWebView are available.

[SinyimZhi]

@jaroslawdabrowski unfortunately, there is no plan to add support for Windows and Linux soon. They require C/C++ knowledge, which I don't have. There is a proposal for Windows to make C# usable for Flutter plugins that will help a lot:

• Make it easy to use C# for Windows plugins flutter/flutter#64958

So, until then, there is no plan for Windows.

Is there any news for Linux support?

[KristijanZic]

Any info on Linux support??

[SinyimZhi]

Any info on Linux support??

webview_cef maybe helps you on it’s linux branch. Although it is a beta version.

[pichillilorenzo]

Hello to everyone, these days I will try to start the work for Windows and Linux. Trying to get something minimal and usable. PlatformView still not implemented by Flutter team yet on Desktop.

[jmgeffroy]

Hello @pichillilorenzo, do you have some progress to share ? Are you using the suggested webview_cef, or webview_windows as others suggested?

[pichillilorenzo]

@jmgeffroy none of those, I'm implementing the Windows plugin using Microsoft Edge WebView2 (https://docs.microsoft.com/en-us/microsoft-edge/webview2/) with C++ Win32 API. Here is the specific repo branch where I'm working for Windows support: https://github.com/pichillilorenzo/flutter_inappwebview/tree/feature/flutter_inappwebview_windows It's taking time because C++ is a little more complicated to handle and work with. I'm trying to write it in a way that I can reuse part of it somehow also for Linux (trying to use C++ standard wherever possible).

These plugins are fundamentally different from mine and don't offer the same features, so it wouldn't work as expected. Also, webview_cef is not using WebView2 from Windows but CEF (https://github.com/chromiumembedded/cef).

Maybe webview_windows code could be looked at to understand how to implement a custom platform view for Flutter, but it seems that's kind of difficult. It's not an easy task and it would require a lot of work probably, for example, to be able to dispatch action, such as keyboard keys, clicks, etc. correctly. In that case, I would rather wait for the Flutter Team to release official Platform View support for desktop platforms to make it work with InAppWebView: https://github.com/pichillilorenzo/flutter_inappwebview/issues/460#issuecomment-784213718

Also, if you want guys, please consider supporting this project by making a donation at: https://inappwebview.dev/donate/ Thanks!

[anchao-lu]

Mark!!!