On a default installation of Zenned, qt5 is only used for VLC 3. VLC 4 (in
development) supports qt6.

hplip only supports qt5, not qt6.

Neither vlc or hplip care about plasma decorations, so plasma supporting
qt5 don't affect them.

The rest of common non-kde qt apps use qt6, like q4wine.

All my own software was ported to pure qt6 on 04-2024. For instance it no
longer depends on plasma frameworks.

My opinion is that all applications that aren't basic to the desktop shall
not depend on anything desktop specific. And if any library is useful
outside of that it must commit to long-term API stability, preferably
forever.

Krita seems the one lagging, kdendlive already uses qt6.

On Wed, Jan 7, 2026 at 11:15 AM Sune Vuorela <[email protected]> wrote:

> On 2026-01-07, David Redondo <[email protected]> wrote:
> > Happy new year everyone.
> >
> > To properly integrate  and support Qt5 applications  Plasma ships a
> bunch of plugins that
> > still build against Qt5. These are:
> >
> > - Qt5 builds of our styles (Breeze and Oxygen) - same code base for Qt5
> and Qt6
> > - Qt5 version of the QPT plugin plasma-integration, separate Qt5 code
> > - kwayland-integration which is needed for KF5 windowsystem, Qt5-only
> >
> > Qt5 CI is in the process of being sunset, see:
> https://invent.kde.org/sysadmin/repo-metadata/-/work_items/36
> > I also get the impression that distros are looking to phase out Qt5,
> however I have no feel about how many
> > Qt5 applications are still out there in the wild.
> >
> > We need to decide what to do with these right now. I see:
> > - Keep them around but without CI coverage? (my least favourite option
> for obvious reasons)
> > - drop them for Plasma 6.7 and tell distros if they need them build them
> from the 6.6 tar ball
> > - keep them and have some CI setup where we build them against a KF5
> stack from distro packages (if possible)
>
> I think it is too early to consider dropping it. Applications that
> aren't ours move slowly. And we even have 'great apps' that aren't fully
> release-ready-ported yet (okteta and krita at least) - and for many 3rd
> parties it might be even worse.
>
> I do think your option 3 makes quite much sense.
>
> /Sune
>
>

Reply via email to