On 9/23/25 5:59 PM, Tor Arne Vestbø wrote:
On 23 Sep 2025, at 16:48, Vlad Zahorodnii <[email protected]>
wrote:
On 9/23/25 3:51 PM, Tor Arne Vestbø via Development wrote:
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?
Let’s discuss details of this in the relevant review :)
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.
If you want the simple solution, then a module in KDE that exposes or
copies the private QX11Info class as public API would be the way to go
AFAICT. That would mean only that single KDE module needs a rebuild
from Jan for the private API use, right?
We may need to juggle some dependencies around due to the design of KF
(I haven't look at it in detail though), but yeah, that could work.
Still, it feels like something that Qt should help users with. :)
Regards,
Vlad
--
Development mailing list
[email protected]
https://lists.qt-project.org/listinfo/development
