Way forward for window and screen native interfaces for KDE

Qt 6 introduced the QNativeInterface API that allows to access underlying platform specific native objects of Qt types as a replacement for the platform specific extras modules such as QX11Extras.

In general we in KDE try to follow guidance of not using private API in Qt but sometimes we had to use QPlatformNativeInterface for this use case which is only available via qpa headers. In addition it is also not nice to use with its string based API that is not type safe.

The new API is a big improvement in this regard and a promising direction, however it requires that final push to be a complete replacement.

Some interfaces on the integration classes are already public  and documented  (QAndroidApplication, QX11Application and QWaylandApplication). The same holds for graphic related things such as gl contexts and textures. All other interfaces reside currently in the QNativeInterface::Private sub-namespace and are only accessible via private headers. This includes:

• QWindowsApplication
• interfaces to gl integrations
• interfaces on QWindow on all platforms
• interfaces on QScreen on all platforms

In a recent discussion with Eskil we have a list of all our use-cases within KDE for native interfaces on screens and windows that we currently use with the string based API in an attempt to help move this forward (raw search results https://lxr.kde.org/search?%21v=kf5-qt5&_filestring=&_string=nativeResourceFor )

1. Getting  ICC profiles on Windows
   Our digital painting app casts the screen to a HMonitor class in order to extract some colour profile metadata
2. Inhibiting Global Shortcuts on Wayland
   This is especially useful when entering new shortcuts. The API takes a wl_surface object to determine which window is making the request.
   There is no equivalent Qt API for it to map to
3. Locked/Constrained pointers
   Pointer locking is a mechanism to keep the cursor in place, and get notified about relative mouse events. This is useful in games or capturing input in a remote casting session or VMs. One case in our code was our remote control application KDE connect. 
   There is no equivalent Qt API for it to map to 
4. Focus passing
   To get a token for passing focus to another window the standard API requires passing a wl_surface object. 
   Qt has code internally to do this when Qt opens a URL or is otherwise in charge of creating the protocol. 
   QWaylandWindow in the native API has some public code for this already. Exposing that object would be best.
5. Blurs, Window Animations and Shadows
   KDE has a set of bespoke protocols for providing blur regions to the compostior along with custom shadows. A wl_surface handle is used as there's no other concept of winId.
   This wouldn't belong in Qt
6. Screen recording
   A KDE specific API for screen recording uses the wl_output object to know which screen to use in screencasting. 
7. Attaching global menus
   Our QPlatformTheme uses the wl_surface to attach a global menu to a  specific window using a KDE specific protocol. Arguably this could move to the QPA directly. There's an awkward split there.
8. QX11Info / QXcbWindowFunctions
   Looking through the KDE code for QX11Info yeilded too many results to mention, close to 1000 hits.
   Looking through the methods we do not have any uses for: appDpiX and Y. We also don't use any of the event peeking API.   We do extensively use appRootWindow repeatedly.