Tried nuget-importing ‘Bridge.Html5’ (to see if it works properly with the new backend.)
When adding the depedency I get the following error:
bridgeError.log (52.1 KB)
and it repeats thereafter.
have you tried the same with latest 2019.1 preview and it works?
Not exactly. In Beta39 VL it imports okay, but if I try to create an object it gives me this error:Beta_NugetUsageError.log (34.8 KB)
In the upcoming preview the error shouldn’t popup as nasty anymore, but I fear it’ll just come back as a runtime error because what I understand from Bridge is that it basically wants to replace the whole mscorlib - if you peek inside you’ll see that they have their own implementation for all the standard types like System.Object etc. Loading a different System.Object (not the one implicitly provided by the .NET runtime) is a tricky business you can somehow grasp when you follow their getting started guide and peek into the targets files referenced by your C# project file.
Supporting this thing out of the box from VL would be interesting but also very hard. A first needed step would be to run the user patch out-of-process. Second step would be to remove certain assumptions about mscorlib in our code base, but I fear then it just goes on with things like tooltips not renderable because for sure skia will not run etc. etc. Their whole thing is build on the idea that the final output runs as javascript in your browser and not in the .NET world. Correct me if I’m wrong.
Hmm, not a small task. I think you’re probably right.
A couple other questions:
- ‘out-of-process’ - what would that look/feel like for a user?
- ‘remove certain assumptions about mscorlib’ - skia aside, do these assumptions percolate the the construction of VL design itself or the libraries that use Mscorlib components?
I think it would be interesting, but it sounds like it would need a different version of the vvvv product range (Delta?) to do it, still using the underlying language, so the knowledge is transferable, but with the specific target of typescript/html.
If it could preview the content on the fly, that might make the lack of tooltips a concession users might be prepared to swallow in the short-term, and in web design/development terms it would be immediately useful.
Or do you think it Blazor would be better potential fit with VL? I’m afraid to test at the moment. Looks like another rabbit hole :-)
Regarding “out-of-process”: Say we wanna use the existing editor (running on .net framework) and build such a web-app (running on asp core in case of blazor server, or webassembly in case of blazor client) the user program must run in another process as there’s no way to mix those .net (or web) runtimes.
So that’s a must have.
Once the user program can run with its own runtime we can think of what’s needed to get our compiler also running there. In case of a blazor server app that should be “easy”, for the blazor client scenario using webassembly I don’t know at this time - the user app would essentially be the browser, howto reload webassemblies or if it’s even possible - no idea.
In any case, say that’s also solved, one can finally think about how to get the tooltips back ;)
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.