[Development] Reduce usage of Qt private API

[Vlad Zahorodnii]

Hi,

On 9/23/25 3:51 PM, Tor Arne Vestbø via Development wrote:
> Hi Jan,
>
> Thanks for looking into the private API use!
>
> The “modern” version of qplatformnativeinterface.h is the public 
> QNativeInterface namespace and the various QFoo::nativeInterface<T>() 
> accessors, so we should transition the former to the latter.
>
> Similarly, the QX11Extras can find a new home in the QNativeInterfaces.
>
> However we should look at each API on a case by case basis, and not 
> just dump everything into e.g. the QGuiApplication native interface 
> (like https://codereview.qt-project.org/c/qt/qtbase/+/677957 currently 
> does). E.g. some of these APIs might have a more specific place in the 
> QScreen native interface.

In most cases, the QScreen part is irrelevant, keeping things such as 
appRootWindow() in QX11Application would produce a cleaner API and 
cleaner user code. Perhaps the QScreen arguments can be dropped and if 
somebody really needs that, they could add corresponding APIs in screen 
native interface API?

There's also an element of migration logistics. The code that we are 
talking about is legacy, we maintain it, but we don't want to make big 
rewrites or take more than necessary of our time from Wayland back to X. 
If the migration path could look something like s/QX11Info::/x11App->/g, 
that would be great.

> We should also limit the amount of trivial wrapper helpers we provide, 
> so these interfaces don’t blow up to a kitchen sink. If something can 
> be solved by having a small helper module in KDE, that uses hooks in 
> the native interface to e.g. get the underlying xcb_screen_t 
> or xcb_window_t, then that’s preferably to maintaining code in Qt if 
> in reality it's a 99% KDE use-case.
>
> So I think we have a plan, if someone is willing to work on it (thanks 
> Vlad!), and as long as we do it step by step and with some 
> considerations of the scope/use-cases :)
>
Regards,
Vlad