You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We should use Avalonia instead of Eto. Avalonia supports more of what we need/want (see #237 as well as #71 and #326, all of which are Eto-specific issues). Jettisoning GtkSharp will be a massive boon for the Linux port in particular. Finally, this will potentially allow us to target mobile and web platforms (no idea if we'd want to do that, but we could!).
Our reasons for picking Eto were twofold:
XAML is hard and we wanted to focus more on UI in code
Eto would allow us more flexibility as it has the ability to create custom native controls per-platform
The first is still true. The second is, for the most important case at least, decidedly not. In #358, I proved that it was possible to have different audio backends when multi-targeting frameworks in Avalonia via platform-specific code directives.
With that major hurdle decidedly out of the way, we should start migrating to Avalonia.
The text was updated successfully, but these errors were encountered:
We should use Avalonia instead of Eto. Avalonia supports more of what we need/want (see #237 as well as #71 and #326, all of which are Eto-specific issues). Jettisoning GtkSharp will be a massive boon for the Linux port in particular. Finally, this will potentially allow us to target mobile and web platforms (no idea if we'd want to do that, but we could!).
Our reasons for picking Eto were twofold:
The first is still true. The second is, for the most important case at least, decidedly not. In #358, I proved that it was possible to have different audio backends when multi-targeting frameworks in Avalonia via platform-specific code directives.
With that major hurdle decidedly out of the way, we should start migrating to Avalonia.
The text was updated successfully, but these errors were encountered: