search

Cysharp / R3

The new future of dotnet/reactive and UniRx.
MIT License
2.1k stars 92 forks source link

Added Uno Platform support #187

Closed xperiandri closed 6 months ago

xperiandri commented 6 months ago

https://github.com/Cysharp/R3/issues/186

xperiandri commented 6 months ago

@neuecc approve the workflow, please

neuecc commented 6 months ago

This would make R3.WinUI3 exclusive to Uno, which is unacceptable.

xperiandri commented 6 months ago

What do you mean by exclusive to Uno?

neuecc commented 6 months ago

Thank you, I understand. I was mistaken. However, I'm not very happy about changing the Project Sdk to Uno.Sdk or having complex conditions.

Also, I'm not very familiar with Uno, but is it okay to have only WinUI3 support it?

xperiandri commented 6 months ago

Also, I'm not very familiar with Uno, but is it okay to have only WinUI3 support it?

No, because it makes almost no sense to build WinUI apps without targeting the other platforms that Uno provides. Who will build a single desktop app in 2024 🙂

xperiandri commented 6 months ago

All the project setup I used I copied from Uno project template

xperiandri commented 6 months ago

Nothing from myself 🙂

xperiandri commented 6 months ago

Uno.Sdk just simplifies the csproj logic

neuecc commented 6 months ago

This PR for Uno support seems to function only in WinUI3. For example, the Avalonia support covers all of Avalonia. I would like a detailed and thorough explanation; otherwise, I will have to close this PR.

xperiandri commented 6 months ago

Uno provides source compatibility on the Android, iOS, MacCatalyst, GTK (Linux/WPF), and WebAssembly platforms. Technically it converts XAML into C# code manipulating native Android/iOS/MacCatalyst controls, renders HTML for WASM, and draws on a Skia surface for GTK. All the WinUI ported code (API contract) is mirrored by Uno in Uno.Core.dll and Uno.UI.dll This means that in order to target a particular Uno platform code must be compiled for that platform. Because:

  1. WinUI compiled R3 looks for a WinUI contract in Windows.winmd and for Uno it is located in Uno.Core.dll and Uno.UI.dll
  2. C# code generated from XAML to render UI is different for each platform However, R3 does not generate any XAML, and point 2 is not relevant for us. That is why we do not need to target net8.0-android and others, but just net8.0 to reference the Uno.Core.dll and Uno.UI.dll to redirect API calls. In this case, WinUI targets will use net8.0-windows10.x.xxxxx but Uno targets will use common net8.0
neuecc commented 6 months ago

I consider the current R3.WinUI to be generic support for WinUI, why doesn't Uno work with the current R3.WinUI3? Is it because WinUI3 is now net6?

xperiandri commented 6 months ago

No, because WinUI uses managed to native interop and generates the code that looks for Microsoft.XAML namespaces in the Windows.winmd which is a native code file with .NET like metadata. And Uno is completely managed .NET code. It is impossible to substitute native Windows API implementation at binary level. That is why Uno has its own .NET DLLs that implement the same contract

xperiandri commented 6 months ago

And you cannot build WinUI for anything else than `netx.x-windows10.x.xxxxx’ As it enables that managed to native interop

neuecc commented 6 months ago

Understood, but I don't want to continue maintaining this csproj. If you can introduce a better and cleaner approach, I will reconsider it at that time.

xperiandri commented 6 months ago

If you can introduce a better and cleaner approach

Could you define more measurable criteria?

michaelstonis commented 5 months ago

Uno just released support for a single project solution in 5.2, this might be better to revisit this and see if the changes needed for Uno can be better isolated.

xperiandri commented 5 months ago

@michaelstonis it was already 1 project here as it is a library. I can make that csproj pretty small and look as usual. Waiting for https://github.com/Cysharp/R3/pull/188 to be approved