Webviewcontrol lib- option2#10222
Closed
mjkkirschner wants to merge 4 commits intoDynamoDS:masterfrom
Closed
Conversation
move to MS webView comment out files that are not used refactor resourceProviders so we can call them directly instead of letting CefSharp do it. use string replacement to embed resources into html add more js functions we need to redirect dom events to c# function calls since webView does not expose cross language objects or callbacks - only strings. NodeItemProvider and SeachProvider both now reference IconProvider to embed images as base64 resources when they generate json - will need to do the same with layoutSpec provider. API broken in some places - unsure this matters in this case as short term and I do not consider this extension an API. (it's very cefsharp specifc)
simplify resource handler logic and give all providers access to icon provider to lookup icons for replacement in layout spec and types setup search callback again invoke updates to libary ui from ui thread use dllprovider to lookup icons from resources folder embedded into dlls add methods to layout spec and customization to enable replacement of iconPaths with base64 data get around strange bug with helix3d/sharpDX startup while webView is starting - these controls need to be instantiated non concurrently. (use a task delay) move to package references for this repo to avoid annoying build failure that doesnt actually seem to do anything... but the nuget package states its a requirment guard against icons which have alraedy been replaced.... dont search disk for base64 or svg data as a path. zindex does nothing, lose it.
and to replace create icon in js with base64
15 tasks
Contributor
|
The WebView known issues list makes me a little nervous. To improve startup time, it seems like it would be feasible to implement a simple resource-loading mechanism through |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Purpose
This PR removes CEF and CEFSharp from the libraryViewExtension and replaces it with
Microsoft.Toolkit.Wpf.UI.Controls.WebViewread more here:
https://docs.microsoft.com/en-us/windows/communitytoolkit/controls/wpf-winforms/webview
which renders with edge.
This investigation was started as a way for hosts of Dynamo that have dependencies on other versions of CEF to maintain a functioning and similar user experience.
The available apis are much simpler than CEFSharp - and much more restricted - but after much finagling I think I have almost everything working as before with slower startup time, but faster actual performance during use. The code is simpler, but currently fragile, we can work to improve its robustness over time.
❗️
My intention with this PR is to get feedback and testing - I think to actually deliver this component we should make it a separate extension and test it in other integrations before pulling it into core.
Description of architecture:
This component only really allows interacting between C# and JS in two ways. -
window.external.notify(string) method - which triggers an event on the c# side or -
InvokeScriptAsync(strings)which invokes a method on the js side - only strings can be passed between the contexts.It was not hard to refactor out the events and method calls we were using previously to a single event handler with a dumb format (functionName, params) where params are some json encoded data.
The biggest challenge in this integration is to deal with resource loading - unlike CEFSharp - we cannot intercept requests from the browser context and return data back - we can only serve files from specific folders - I never got this to work, and didnt' really want to serialize data on the fly just to load it back into the webcontext - instead everything(images, fonts svgs etc) is embedded into the json and html that we load or that we serialize and pass to the library functions.
I have refactored the resourceProviders to find the correct resources and convert them to base64 encoded strings which are then used to replace the filePaths which we passed previously. This is likely wasteful and can be optimized if we have repeated icons. We can also likely cache repeated lookups for images we have read from disk previously. None of this is done (except for the default icon because come on 😉 )
interesting facts!
RevitAPI.dll.here is what I have tested:
here is what I know we need to do:
Declarations
Check these if you believe they are true
*.resxfilesReviewers
@QilongTang @reddyashish
FYIs
@Dewb @aparajit-pratap @Amoursol @kronz @angelowang