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
--
Development mailing list
[email protected]
https://lists.qt-project.org/listinfo/development
