Platform-specific APIs.

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?

[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.

[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.