roozbehid
Later dotnet support (9.0)
I see that this project requires dotnet 2.0 . Is there anything that makes it tied to this version (which no longer exists like CoreRT, CoreRT ILC, etc.)? It says it needs 2.0 when imported as a nuget dependency.
Thank you.
Thank you for your response; I have had limited success (trivial applications do work on at least GNU/Linux natively) porting Eto.Forms to Core.System.Windows.Forms which is Mono's version ported back to the normal dotnet (works with net10, can confirm) so that WinForms apps can still run natively on Unix-likes. I will try to get it to work with Wasm as well, but I don't have high hopes because the app itself is net10.0 and this is netstandard and needs Mono (which can maximum only do netstandard2.0, even net5.0 is unsupported).
Meanwhile, the official dotnet got much faster.
Now apparently dotnet does support WebAssembly. I have no idea how any of this works, all I know is that it runs with microwindows and some Cairo port over it. If it doesn't work, for the proof of concept, I may have to use some x86 emulator like tinyEMU or v86 which are slower, later.
Well technically the winforms mono that comes with this repo is already pprted to netstandard2.0 And netstandars2.0 should work with all .net core versions. You .ight get errors/warnings but they should be resolvable
Thank you for the reply. Does it still depend on mono for compiling it, or does the compilation also work with the modern dotnet wasm target too?
well it depends on mono for rendering of components and this was way before dotnet introduced "dotnet wasm", I implemented a wasm target for this. TBH I dont think fixing these and adjusting would be major problem. Eventually backend is emscripten doing compilation. So depending on what is exactly your pain point and what you need to achieve I might be able to help....
Thank you for your reply. I am maintaining a lighter fork of libgdiplus with lighter dependencies and limited one-language (can be set - once set which language it is, it works quite well for complex scripts like Tamil) internationalization (directly hooking to HarfBuzz instead of the Cairo toy renderer so no pango). I am planning to maintain it for longer as libgdiplus is abandoned now. It is a part of a series of getting Eto.Forms to work in the browser.
Core.System.Windows.Forms seems to be in active development as well. I have no idea how I can go about making it work through WASM, maybe at the worst case will run a VNC (or even better an X11-JS server if it would work). There is also Platform.Uno which can be targeted, but the Eto backend is not ready (the working parts of the backend are already working through Blazor/WASM through Uno, which is way better than Skia as it is not an accessibility nightmare).