OptionalFeatureProvider in Linux Framebuffer platform

[Oaz]

Is your feature request related to a problem? Please describe.

FramebufferToplevelImpl.TryGetFeature currently return "null". public object TryGetFeature(Type featureType) => null;

As a consequence, optional features such as Clipboard cannot work on Linux Framebuffer platform

Describe the solution you'd like

FramebufferToplevelImpl could implement basic optional services retrieval

e.g. public object? TryGetFeature(Type featureType) => AvaloniaLocator.Current.GetRequiredService(featureType);

As far as I can tell, it would be enough for a working custom clipboard in Linux Framebuffer. The clipboard could just be injected with

  private static AppBuilder BuildAvaloniaApp() => AppBuilder.Configure<App>()
      .With((IClipboard) new MyCustomClipboard())

Describe alternatives you've considered

I could not find any other option to inject a clipboard in Linux Framebuffer as creation of FramebufferToplevelImpl is hardcoded in LinuxFramebufferPlatform. The only alternative would be to entirely rewrite LinuxFramebufferPlatform.

Additional context

This issue came up as I was writing an extended LibInputBackend with keyboard event handling : https://github.com/Oaz/Avalonia.LibInputExperiments

In a TextBox control most of Ctrl Keys are working fine (Ctrl-A, Ctrl-Z...) but copy pasting is not working even though the CopyingToClipboard/PastingFromClipboard events are raised as expected. I eventually figured out that a clipboard instance was missing.

[maxkatz6]

public object? TryGetFeature(Type featureType) => AvaloniaLocator.Current.GetRequiredService(featureType);

It shouldn't call GetRequiredService on any type. Instead, it should check only for known interfaces, like IClipboard.

[kekekeks]

We should probably provide a stub clipboard implementation for fbdev, yes. However we shoudn't fallback to locator.

[Oaz]

As far as I am concerned, just having a clipboard is fine.

Though, by curiosity, I'd like to know what is wrong with calling locator on any required type in this scenario since AppBuilder.With binds the options into the locator with no type filtering? The absence of symmetry does not feel intuitive to me.

[maxkatz6]

We don't encourage AppBuilder.With/TryGetService to be used as a public service locator.