Replies: 3 comments 4 replies
-
I think it should be possible to get both builds from a single code base using two different build configurations. IIRC in the unit test branch, I already introduced a WinUI build (need to look that up, it's been a while). By using conditions in the .vcxproj for the NuGet references, we can switch to only include the WinUI stuff in the corresponding build configuration. This could be a bit messy when updating the NuGet packages (because that will probably overwrite our confitions). But still if that works, it would be the cleanest solution. For me the bigger question is about the output NuGet packages. Should we ship one package that contains both the WinUI and UWP versions? Or should we ship two separate packages? Should we create a WinUI/Win32 FFmpeg build, to be used by FFmpegInteropX(WinUI)? I guess a separate FFmpeg build would be required if we want to allow file names as source. Once we have the dual build setup done, I do not see much additional work maintaining both UWP and WinUI. After all, most of it is identical, since the core media classes are the same. Only dispatcher handling and UI/Display environment stuff is different, and that is not something we use a lot, luckily. |
Beta Was this translation helpful? Give feedback.
-
All very good points. I guess we can sleep on it a few more months until winUI stabilizes and matures. I'm a little concerned about the cs/winrt project though, it doesn't seem very lively. |
Beta Was this translation helpful? Give feedback.
-
I'm not that impressed with the native android tools either, the xml based ui is akin to spaghetti, even the most basic stuff requires a lot of glue code and magic string matching. The compose stuff looks cool but it is simply not mature enough and seems to have started on the wrong foot already. Witch brings me to xaml. Xaml is very efficient for ui, but it comes with the difficulty of consuming native libraries. I feel that flutter has a better approach to the issue, by allowing you to mix code from different languages in the same project. I'd honestly want visual studio to support compiling kotlin and java and automatically generate the bindings for you. Sort of like the one winRT times... One can only dream of such tooling support. |
Beta Was this translation helpful? Give feedback.
-
I have been thinking about this for a while, how would we approach a winUI specific build?
It seems the code changes are quite extensive in some area, even requiering different nuget packages installed, and different idl file (this last one could theoretically be delt with using compiler directives)
Should we try to use a shared project?
Try to diverge the code base?
I think in the long run, winUI allows for more powerful builds (I think we could technically link libraries which aren't available in UWP) and features.
Perhaps we should consider simply forking the code and backport UWP supported features?
Or try to support UWP for the forseeable future? For how long? We are 2 people after all, so we can't really keep 2 code bases in sync forever.
Beta Was this translation helpful? Give feedback.
All reactions