Uno wants applications to look the same across platforms (as Flutter does) but still wants to use native controls. So their approach[0] is to have default styling applied to every control which makes the native controls look the same on each device [0].

I think the main benefit with this approach is expected-behaviour (like how different desktop operating systems have different textbox behaviour), and that whatever accessibility you get by default with native controls is there. [1]

I don't really find their approach to GUI development compelling though, with them choosing a middle ground between "wrapper around native controls" and "implement everything yourself".

[0] Except on Linux and web, where Uno draws everything itself, imitating controls that look like GTK (on Linux) or UWP/WinUI (on web). These are the platforms I briefly tested on and I didn't have an enjoyable experience with the output due to non-native/non-expected behaviours.

[1] Page on accessibility: https://platform.uno/docs/articles/features/working-with-acc...

That's the choice people face: "native" (different on all platforms) vs "synthetic" (looks the same but loses true native functionality).

Correct - and with Uno you get to chose either one of those approaches - https://platform.uno/pixel-perfect/

Uno Maintainer here - Thanks for trying out Uno! At this time, the default render mode is provide a uniform look across platforms, and it's possible to alter the theme using Material, Fluent or Cupertino, or to design your own theme using control template styling, or even use native controls directly where applicable.

On Linux, we've just released our support for X11, removing the need for GTK. As we're drawing the whole app surface, we're always interested in adjust the UX of our controls on individual platforms. If you have examples, let us know.

Finally, for WebAssembly, our current rendering backend is using the HTML DOM, which means that accessibility and other native behaviors are functional. Same here, if anything accessibility related is missing, we're all ears!

Hi there. Appreciate the response!

I didn't know that the HTML DOM is being used for Uno's web output but that's good to hear. I was under the impression that things were being drawn to canvas (like how Flutter's web output works) but functionality like Ctrl-F (text search) works on https://gallery.platform.uno/, showing that's not the case.

I'm not sure why I had the impression that the web output used HTML canvas, but maybe that was something that changed since I last looked a few years ago or there might be another reason I was mistaken.

I think one misleading thing that gives the wrong impression is that text isn't selectable on Uno's web output (like https://gallery.platform.uno/), similar to how text isn't selectable on HTML canvas.

I think it's worth having a discussion about that with other employees, because it's one divergence from user expectations about how the web usually works (but application developers may also prefer to make text not selectable so it may be the behaviour you want in some cases after all).

Indeed, text selection is a specific behavior that was chosen to be disabled by default in order to be closer to the original behavior of WinUI on desktop. This is a configurable behavior on the TextBlock control, though.

I don’t think native here refers to the control styling being similar to Win32 on Windows.

I could be wrong, but it might be able to host native components or draw your own.

Indeed, an Uno app is a native app, it uses UIKit on iOS, Views on Android, HTML on Web, except on Linux where you only have access to our Skia renderer.

Therefore you can embed native controls.

"on Linux where you only have access to our Skia renderer" ... means what? Can I make a basic GUI app on Linux with Uno. If yes how ?

Yes, on Linux it behaves similar to Flutter and draws directly to a Skia Canvas.

It used to have a dependency on GTK but no more since the 5.2 release.

There's just no notion of "native controls" that you can embed in an Uno Linux app like you could have if you wanted to embed a 3rd party native UIKit control on iOS.

Uno is based on UWP, on Windows it uses the native UWP stack.

Dear neosunset, go make .NET advocacy elsewhere, and stop identifying yourself with the platform.

Thank you very much.

Uno is a third-party open-source project. It is not related to UWP beyond the fact of being a .NET GUI framework.

It's like complaining that a particular Yamaha bike is bad because a Yamaha digital piano of particular model is bad.

Do take pills before posting, thanks.

Not only do I have taken my pills, I am well aware of what abstraction layer Uno makes us of, when deploying on Windows.

Which if you had done the same, instead of being hurt in your .NET feelings, you would also be aware that what differentiates Uno from Avalonia, is that the former offers a migration path for UWP developers, while the latter does the same for WPF developers.

I said enough times "how high?" when Microsoft shouts "Jump!", since MS-DOS 3.3 was new on the market.

So if you cannot face criticism, well, that is on you to get used to.

And if trolling me makes your fancy, I hope you have been equally trained on BBS and Usenet on their darker days.

Uno Platform maintainer here - Uno is compatible with both WinAppSDK/WinUI and UWP API sets. Our default project templates have been on WinUI for two years now, UWP mainly being supported for temporary upgrade scenarios to WinUI.

Nope it is not.