[Development] Reduce usage of Qt private API
Jan Grulich
jgrulich at redhat.com
Thu Sep 25 12:04:38 CEST 2025
Hi,
út 23. 9. 2025 v 17:32 odesílatel Tor Arne Vestbø via Development <
development at qt-project.org> napsal:
>
>
> On 23 Sep 2025, at 17:20, Vlad Zahorodnii <vlad.zahorodnii at kde.org> wrote:
>
> On 9/23/25 5:59 PM, Tor Arne Vestbø wrote:
>
>
> 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. :)
>
> Great! If you want to argue the latter case, then that includes the normal
> process of justifying use-cases and discussing API design that comes with
> adding/exposing new APIs in Qt :) If that’s seen as too disruptive or
> laborious, then the former solution is probably the best.
>
>From the packagers perspective the solution doesn't matter as the outcome
will be in both cases less work/rebuilds. Having this sorted out on the Qt
side would mean not having to deal with porting from one API to another,
which will be the case when things move to a KDE module exposing these
APIs, but on the other hand the majority of the packages we rebuild are KDE
packages. Few non-KDE packages will remain, but there will already be
considerably less rebuilds than now.
If the consensus is to go with a KDE wrapper then I'm fine with it and can
help with porting apps to the new API, we just need to figure out what APIs
to expose and where to put it.
Regards,
Jan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20250925/b58f9bfc/attachment.htm>
More information about the Development
mailing list