Open d0mmi opened 4 years ago
A little update here:
WINDOWS
I have used and modified the C++ code used by webview_windows
to have some initial Platform View on Windows working to be able to implement the InAppWebView
widget as a Flutter Texture, using the native ICoreWebView2CompositionController class to support visual hosting.
Unfortunately, there are some limitations, for example possible problems with scrolling inner HTML elements and, maybe, the rendering of the default context menu (I need to check about that, but currently, the default one is not rendering at the correct position for some strange reason).
I don't know if these issues are bugs of ICoreWebView2CompositionController
or if visual hosting is not working correctly when used with Flutter itself for some reason.
At least, we should have something, but it could not be usable in all possible use cases because of these issues.
Instead, InAppBrowser
is not suffering from these issues because uses a native window (as we have on macOS).
Currently, I'm working on setting up some JavaScript handlers communication and the User Scripts feature as we have already on Android/iOS/macOS.
MACOS
In the meantime, I have also checked the status of the AppKitView class for implementing the InAppWebView
widget on macOS, but it's still not usable.
Currently, it just renders the native view correctly but you can't interact with it (so: no click, no scroll, etc..), but, at least, the webview controller methods can be used (for example, you will able to evaluate javascript).
I need to try to implement something that wraps it, for example using MouseRegion, to check if we can create a workaround about it somehow and dispatch the gestures natively by ourselves. If it is not possible to implement such workaround for some reason, we can still use the version without interaction, just to display the content and hope the Flutter team adds full support about it as soon as possible.
@pichillilorenzo Thanks for the update and congratulations on your fantastic work! I don't have time to help, but I'm following your progress as I'm using your InAppWebView in an open source Epub reader (Iridium) and in soon to be released language learning apps based on this Epub reader. Iridium is not actively maintained at the moment, as the number of open issues and PRs shows, but I'm planning an iteration soon, and I'd be very happy to test any experimental version you might release. Extending the reach of our Epub reader from Android+iOS to other platforms will be very exciting .
Our Epub viewing component relies on a rather complex combination of InAppWebViews (they are laid out inside a PreloadPageView, the content of each WebView is paginated, and scrolling between WebViews and the enclosing PageView is handled thanks to positioned elements that trigger notifications when they become visible). In our private version, we also use the HeadlessInAppWebView to take screenshots of each page to provide thumbnails.
I guess that's quite a good real-life use-case 😄
Here is a little update about Windows. I managed to fix this:
Unfortunately, there are some limitations, for example possible problems with scrolling inner HTML elements and, maybe, the rendering of the default context menu (I need to check about that, but currently, the default one is not rendering at the correct position for some strange reason).
@jmgeffroy I have added an initial implementation of the HeadlessInAppWebView but I need to implement the method to capture screenshots, that should be easy.
I will implement the CookieManager next, but it seems to work differently than other platforms.
After that, I think I'm able to release an initial release 0.1.0
for Windows.
@pichillilorenzo Hi, thanks for the update, looks promising!
In our case (ebook reader), InAppBrowser can't be used since we integrate the WebView into a PageView (to provide smooth transitions between spine elements, i.e. chapters).
But in a private integration of our open source Iridium, we create thumbnails of the pages and display them in a navigation slider. So maybe I'll take some time to add this fun feature to the open source Iridium and test your MacOS and Windows implementations. I could even do what we did in our apps for e-paper devices: just use full-size screenshots taken with the HeadlessInAppWebView and display them in a page flipper (PreloadPageView or anything similar). We could also handle text selection and any other features, since that's what we did "back in the day" and it worked extremely well on devices with very limited CPU... 🤔 But I digress 😄
Keep it up!
Any further update on Windows? Anything I can help with?
Any update on this?
Any updates?
Any updates about Windows support?
Please avoid comments asking for updates.
We know that if there is no response, it means there is no new information. Instead, let's focus on how we can help meet current needs.
With the next version 6.1.0 I'm going to release the initial Windows implementation. In the meantime, thanks for the support.
With the next version 6.1.0 I'm going to release the initial Windows implementation. In the meantime, thanks for the support.
Macos now has webview support with flutter 3.24 iirc. Will this be included too?
@rchavik My latest commit 2ff7e8875fdf42a04d5231c3db43368e25ca04ed contains the code to support also the InAppWebView
widget on MacOS 👍
Released new version 6.1.0 with Windows initial support and MacOS InAppWebView support
I will try to update the plugin website docs for Windows as soon as possible.
Updated plugin docs:
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.