[Development] Reduce usage of Qt private API

[Vlad Zahorodnii]

On 9/23/25 5:59 PM, Tor Arne Vestbø wrote:
>
>
>> On 23 Sep 2025, at 16:48, Vlad Zahorodnii <vlad.zahorodnii at kde.org> 
>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20250923/69fd8b94/attachment.htm>