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