Platform-specific APIs.

[grokys]

There are various APIs which are specific to a platform (i.e. have no corresponding APIs on other platforms) but would still be useful to be accessed from Avalonia.

One example of this which recently came up is NSWindowLevel on macOS: other platforms don't have an equivalent so it doesn't make sense as a general API, but still it's really useful in certain situations to be able to set this for a window.

One way of providing these APIs might be as attached properties, for example one could set:

<Window MacOS.WindowLevel="FloatingWindow">

Such a property would only have effect when running on macOS.

The main question with regards to such APIs, is in which assembly should they live?

So, a few questions to start the ball rolling:

• Is it a good idea to provide such APIs?
• Which APIs might be good candidates?
• Is the attached property idea a good one?
• Where should the APIs live?

[robloo]

Is it a good idea to provide such APIs?

Yes

Is the attached property idea a good one?

This is a really good idea. It's perfectly clear this is platform specific and also doesn't exist on the shared type. The syntax is really nice too!

Where should the APIs live?

I've often thought Avalonia should have an Avalonia.Platforms parent directory. Then all platform implementations go in there. Avalonia.Android, Avalonia.X11, etc. That would really clean up the main src directory IMO.

Then these types of attached properties should probably go inside a PlatformIntegration directory or something within the specific platform. Then you can have files for Window.cs, etc and inside there put whatever platform specific code.

Alternatively, the idea started with Xamarin is to have Window.cs and Window.macOS.cs, etc. Platform specific code is in a partial class file next to the shared code. The file suffix states the platform. Not a huge fan of this for Avalonia though as it's extremely rare to need platform specific code so far. It makes more sense to be with the platform implementations.

[kekekeks]

Note that an app using some platform features in XAML should not be forced to reference a platform backend when running on a different platform. Especially since one can't reference wasm, mobile and desktop at the same time.

[robloo]

@kekekeks That's true. But I think the code should still exist with other platform-specific code. You can move it to a shared Avalonia.Platforms.Integration namespace or something. That would complicate the build though if you left it in with other platform-specific code but is still doable.

[kekekeks]

The support code can live where it wants to live, but the API should still be accessible when targeting netstandard2.0 with only Avalonia package referenced.

[workgroupengineering]

I think you could implement in XamlX a mechanism similar to MAUI OnPlatform that when dotnet publish is run on a specific Target (iOs, Androdi, ecc..) platform it removes everything not related to the specific platform.

[rabbitism]

And it will nice to support platform suffix .cs compilation.

[maxkatz6]

@workgroupengineering it won't work if XAML project uses generic .netstandard of .net6.0 target (not a platform specific one). It's not a problem in MAUI, where you have a new target for each platform. And every third party library can target all platforms at once to get this XAML compilation-time trimming.

That's why we want a different way in our implementation of OnPlatform extension. Where we rely on postproccessing linker trimming depending on runtime identifier of the actual application (i.e., libraries contain all the branches of OnPlatform as they are platform agnostic).

[maxkatz6]

And it will nice to support platform suffix .cs compilation.

Unrelated to this issue.

And you already have it in the SDK - ExcludeFromCurrentConfiguration. It can be done with simple msbuild condition.
Like this one - https://github.com/AvaloniaUI/Avalonia/pull/9613/files#diff-f187e1f8a2658efbbfc23efe2c18a51c40156749cf078645534481518139779eR80-R102

Note, "linux" and "browser" branches will not work...because there are no targets for these platforms. Yet?

For XAML support you would need to exclude AvaloniaXaml entries as well, I suppose.

While it would be nice to have built in, we just can't because how .NET SDK works and what target frameworks we have on our hands.

[maxkatz6]

We now have MacOSProperties, Win32Properties and soon will get X11Properties.