Dev discussion on Qt6 support

[tsujan]

Porting to Qt6 is straightforward for components like libfm-qt, pcmanfm-qt, lximage-qt, qterminal, etc. However, apart from KF6, it seems to me that we have a fundamental problem to solve.

We have two Qt5 plugins provided by libqtxdg and lxqt-qtplugin. They add support for icon engine and platform theme. Also, libfm-qt provides the file dialog through lxqt-qtplugin. Qt5 apps will be around for a long time. Do we want to stop supporting Qt5 by porting libqtxdg and lxqt-qtplugin to Qt6? Or will we support compilation against Qt 5.15 too?

Qt doc explains how to mix Qt5 and Qt6 here: https://doc.qt.io/qt-6/cmake-qt5-and-qt6-compatibility.html. I've used it in two projects of mine for supporting Qt < 5.15 too but it's easier with Qt 5.15. Will we proceed in that direction?

Another approach, which may be cleaner, is forget about Qt5 and tell people to install the components of 1.0.0 for it. But lxqt-build-tools doesn't differentiate between Qt versions, in the sense that, for example, it installs files into /usr/share/cmake/lxqt-build-tools/modules, not in /usr/share/cmake/lxqt-build-tools/qt5-modules.

@luis-pereira, @palinek, @yan12125, all devs?

EDIT: It turned out that Qt6 port is not straightforward for qterminal but, of course, it could (and should) be done.

[luis-pereira]

We have two Qt5 plugins provided by libqtxdg and lxqt-qtplugin. They add support for icon engine and platform theme. Also, libfm-qt provides the file dialog through lxqt-qtplugin. Qt5 apps will be around for a long time. Do we want to stop supporting Qt5 by porting libqtxdg and lxqt-qtplugin to Qt6? Or will we support compilation against Qt 5.15 too?

I have no educated guess about Qt5 life expectancy. Will it be maintained ?

Qt doc explains how to mix Qt5 and Qt6 here: https://doc.qt.io/qt-6/cmake-qt5-and-qt6-compatibility.html. I've used it in two projects of mine for supporting Qt < 5.15 too but it's easier with Qt 5.15. Will we proceed in that direction?

The doc talks about the CMake stuff. But the real burden "might" be maintaining the sources for both Qt5 and Qt6. Do we have the manpower to do that ? Right now, I don't think so.

Another approach, which may be cleaner, is forget about Qt5 and tell people to install the components of 1.0.0 for it. But lxqt-build-tools doesn't differentiate between Qt versions, in the sense that, for example, it installs files into /usr/share/cmake/lxqt-build-tools/modules, not in /usr/share/cmake/lxqt-build-tools/qt5-modules.

That can be changed.
Not thinking about the technical details this would be the best solution in the long run, IMO.

[tsujan]

I have no educated guess about Qt5 life expectancy. Will it be maintained ?

It's LTS; so, it'll be around for a long time. It won't matter if most Qt apps (not just LXQt's) are ported to Qt6, but we don't know when that will happen.

But the real burden "might" be maintaining the sources for both Qt5 and Qt6

Yes. For now, it's easy, but later it might get complex and you're right about the manpower.

Not thinking about the technical details this would be the best solution in the long run, IMO.

I agree but, sadly, lxqt-build-tools isn't our only problem.

Perhaps, we'll have no choice other than forgetting about Qt5 when porting LXQt to Qt6. Or we could wait to see what KDE will do.

[luis-pereira]

It's LTS; so, it'll be around for a long time. It won't matter if most Qt apps (not just LXQt's) are ported to Qt6, but we don't know when that will happen.

Only time will say it. Qt4 was supposed to be used for an extended period and it was quickly "abandoned".

I agree but, sadly, lxqt-build-tools isn't our only problem.

Perhaps, we'll have no choice other than forgetting about Qt5 when porting LXQt to Qt6. Or we could wait to see what KDE will do.

We need KF6. At that point we can make a more informed choice.

[yan12125]

I didn't find a clear statement about whether KF6 will support Qt5 or not. However, some discussions show that Qt5 is still relevant. For example, https://phabricator.kde.org/T14233 talks about supporting both Qt5 and Qt6 in extra-cmake-modules.

[yan12125]

+1 for forgetting about Qt5. Sometimes keeping sources compatible with both Qt5 and Qt6 can be messy (tons of #if preprocessors), tricky and time-consuming. The situation will be better if we have working CI to test all active projects against Qt5 and Qt6, but that's another long story (#1644)

[tsujan]

+1 for forgetting about Qt5

I agree. For a single program, supporting both versions might be feasible; for LXQt, it would be impossible in practice.

The question remains as to when we should start. Certainly, not now, because of KF6. I think we'll get our answer from the KDE team.

[stefonarch]

And there will be always LXQt 1.0 or maybe even 1.1 for qt5 distributions

[yan12125]

Assuming we're going to drop Qt5 in newer LXQt versions, do we support co-installation of an older lxqt-qtplugin (for Qt5 apps) along with the latest lxqt-qtplugin (for LXQt itself and other Qt6 apps)? Here "support" only means installed files do not conflict. Bugs in older lxqt-qtplugin will not be actively addressed. Personally I prefer to do so, as Qt5 apps will last in foreseeable future, and keeping theming and file dialogs for those apps is a nice feature.

To achieve that, some installed filenames should be changed. For example, libfm-qt currently installs /usr/lib/libfm-qt.so, which should be changed to allow co-installation of an older libfm-qt with the latest one.

[tsujan]

I started to make a complete Qt6 port of libfm-qt, without any conflict with its Qt5 version. Will make a "wip-qt6" branch for it and another one for pcmanfm-qt after porting pcmanfm-qt (which should be in conflict with its Qt5 version) and doing some tests.

[stefonarch]

Since Qt6 apps started to appear in Arch and Manjaro, and because I hate Qt's default look, to make Qt6 follow LXQt's Qt style and icon theme

I'm quite ignorant, tested qt6ct for strawberry and qbittorent and it looks working, at least for font and dark/light palette a similar look can be achieved.
Is there a downside using QT_QPA_PLATFORMTHEME=qt6ct ?

[tsujan]

tested qt6ct for strawberry and qbittorent and it looks working

Yes, it works but I prefer a purely LXQt solution. LXQt icon engine is more advanced than what qt6ct provides.

Is there a downside using QT_QPA_PLATFORMTHEME=qt6ct ?

For now, I don't think there's any problem. But, when LXQt's Qt6 plugins are installed, it'll override them and you'll need to remove it.

[tsujan]

You can't have this with Qt6 qbittorent + qt6ct :P

I'll ask you to test them after making "wip-qt6" branches.

[stefonarch]

Nope, I can't --yet ;)

[tsujan]

Dear devs,

I might make a "wip-qt6" branch for libqtxdg too, but if you do it before me, please note that, in xdgiconloader.cpp and xdgiconloader_p.h, apart from the obvious changes that are needed by Qt6:

1. QVector can be changed to QList — they're unified and QVector is just an alias.
2. XdgIconLoaderEngine needs 4 additional overrides, namely, iconName(), isNull(), scaledPixmap() and availableSizes().
3. Because of 2, XdgIconLoaderEngine::entryForSize() needs an extra argument at its start, namely, const QThemeIconInfo &info.

Without 2 (which requires 3), some icons wouldn't be shown correctly or at all.

EDIT: I made https://github.com/lxqt/libqtxdg/tree/wip_qt6

[yan12125]

Nice tips on differences between Qt 5/6! Mind to collect them on LXQt wiki? QTextCodec mentioned in #2139 (reply in thread) may be worth a note as well.

[tsujan]

@stefonarch and...

If you want to test LXQt's Qt6 plugins, first unset QT_QPA_PLATFORMTHEME (@stefonarch, you'd set it to qt6ct). Then you could use the following "wip_qt6" branches:

https://github.com/lxqt/libqtxdg/tree/wip_qt6

https://github.com/lxqt/libfm-qt/tree/wip_qt6

https://github.com/lxqt/lxqt-qtplugin/tree/wip_qt6

The order of compilation and installation should be libqtxdg → libfm-qt → lxqt-qtplugin. If you make installable packages, don't forget to set their names to libqt6xdg, libfm-qt6 and lxqt-qt6plugin, respectively, for them not to override the Qt5 packages.

The only thing that's excluded temporarily is qtxdg-mat (belonging to libqtxdg), because it's incompatible with the Qt5 version. When a complete Qt6 port is started in LXQt, I'll add it again.

No setting is needed to change for Qt6; Qt6 apps will follow Qt5 settings.

[tsujan]

AUR packages are "unofficial" and almost any kind of package is fine.

Very good.

Probably lxqt-build-tools-qt6-git, libqt6xdg-git...

I think they are good; only lxqt-qtplugin-qt6-git could be lxqt-qt6plugin-git.

If you encounter any problem, please tell me to rebase the branches.

[stefonarch]

BTW: shouldn't this discussion be moved from Q&A to "general"?

[tsujan]

BTW: shouldn't this discussion be moved from Q&A to "general"?

Yes. It was started as a question but is for planning now.

[yan12125]

lxqt/lxqt-build-tools#77 renamed the CMake module from lxqt-build-tools to lxqt2-build-tools, while other components (libqtxdg, libfm-qt, lxqt-qtplugin) still use find_package(lxqt-build-tools ...) in their CMakeLists.txt files. Should other components be updated to use lxqt2-build-tools instead?

[tsujan]

Should other components be updated to use lxqt2-build-tools instead?

Yes, they should. Thanks!

I'll check lxqt/lxqt-build-tools#77 soon; will tell you here.

[stefonarch]

ls /usr/lib/qt6/plugins/styles
libqt6ct-style.so

echo $QT_STYLE_OVERRIDE
[empty]

I disinstalled qt6ct and now there is no file. For Kvantum: it didn't work, same palette as before whit kvantum widget style.

[tsujan]

For the widget styles: Only "windows" is applied

It shows that LXQt's Qt6 plugin works fine for you.

The styles list you see in LXQt Appearance Configuration is for Qt5. When lxqt-config is ported to Qt6, you'll see the Qt6 styles.

If you tell me how to find my issue to compile kvantum against qt6

You didn't install it. It's as simple as this:

mkdir build && cd build
cmake .. -DENABLE_QT5=OFF
make
sudo make install

A single file /usr/lib/qt6/plugins/styles/libkvantum.so will be installed. Nothing more is needed.

However, you don't need it for testing LXQt's Qt6 plugin because you already tested it with Windows theme.

[stefonarch]

A single file /usr/lib/qt6/plugins/styles/libkvantum.so will be installed. Nothing more is needed.

it's not different to my previous compile with more options...:

....
[100%] Built target kvantum
Install the project...
-- Install configuration: "Release"
-- Installing: /usr/lib/qt/plugins/styles/libkvantum.so
-- Up-to-date: /usr/share/color-schemes/Kvantum.colors

[tsujan]

-- Installing: /usr/lib/qt/plugins/styles/libkvantum.so

That's Qt5 plugin ;) I can't guess where the problem is. The build folder may not be clean before compilation, or Kvantum's version may be old, or…

Anyway, I'm sure that LXQt's Qt6 plugiin works fine for you (because of Windows style).

[stefonarch]

It's not about the testing - it just bothers me that it's not working. Folder was/is a fresh clone

[tsujan]

It's not about the testing - it just bothers me that it's not working. Folder was/is a fresh clone

Sorry, I have no idea. Tested 4 times and even made a package; the style plugin went to /usr/lib/qt6/plugins/styles/.

[tsujan]

Also, added iconName(), isNull(), scaledPixmap() and availableSizes() to iconinfo_p.h in https://github.com/lxqt/libfm-qt/tree/wip_qt6.

[tsujan]

The Qt6 port won't be possible for LXQt 1.1.0 in April, because of KF6. Even if a stable version of KF6 is released before April, we won't have time.

But, we still need to do something for qtxdg-mat before April, so that, when Qt6 port is done, the user could install both libqtxdg and libqt6xdg.

[tsujan]

... but a major change in a point release is kind of unexpected.

Yes, but if we port to Qt6 in 1.2.0, it'll be understandable.

I see in telegram and twitter that the info: "release in the second half of april" was spreading.

Didn't I say? ;) Happy to hear that people have got used to regular releases!

Anyway, I'm keeping up with preparing....

I'll open a Discussion page for the announcement and other things soon.

[yan12125]

Yeah, this release is much better than previous ones in terms of visibility. That also means more efforts, thank you all!

[yan12125]

Yes, but if we port to Qt6 in 1.2.0, it'll be understandable.

That's a good idea if the reason is mentioned clearly in release notes. By the way, I guess keeping 1.1.1 slightly distant from 1.1.0 (ex: at least two or three weeks after 1.1.0) reduces the possibility for mistaking it as a minor and unimportant bug fix.

[yan12125]

I think the only missing PR is adding qtxdg-tools as a dependency of lxqt-session. I can make it today or tomorrow.

Here it is: lxqt/lxqt-session#428. The wiki https://github.com/lxqt/lxqt/wiki/Building-from-source#compiling can be updated after all related pull requests are merged.

[tsujan]

That's a good idea if the reason is mentioned clearly in release notes.

Yes, release notes should reflect the important changes in a way that's understandable to the average user.

...reduces the possibility for mistaking it as a minor and unimportant bug fix.

Right. As a matter of fact, point releases are reserved for critical fixes, although this one won't be just about a fix.

[tsujan]

Apparently, KDE has no rush about Qt6: https://community.kde.org/Schedules/Plasma_6.

More and more apps are being compiled against Qt6. While our Qt6 plugins are almost ready, we need KF6 for important components like lxqt-panel. Are we stuck, because of KF6?

[tsujan]

Another suggestion, which I explain by using lxqt-panel as an example:

• We make lxqt-panel depend on LXQt 1.1.0 for now, so that its compilation gives an error against a higher version. (Is that possible?)
• We start porting libqtxdg, lxqt-qtplugin and libfm-qt to Qt6. Their PRs are almost ready.
• In LXQt 1.2.0, we'll have double versions of libqtxdg, lxqt-qtplugin and libfm-qt: the old Qt5 and the new Qt6 versions.
• We continue porting other components that can be ported to Qt6.

[yan12125]

a Qt5-based lxqt-panel couldn't be compiled with it because lxqt-panel needs liblxqt, which needs libqtxdg, which is needed by lxqt-qtplugin.

Your next comment is the most likely solution. After libqtxdg switches to Qt 6, liblxqt and lxqt-panel will use libqtxdg 1.1.0, the last Qt 5 version.

Can't we internalize it?

Do you mean copying relevant files into lxqt-qtplugin repo? libdbusmenu-qt5 is used by both lxqt-qtplugin and lxqt-panel. I prefer to keep it as a standalone library than having two copies.

Do we want lots of version checks and perhaps separate source files for Qt5 and Qt6?

As you may have read in other places, I prefer not. We don't have CI for most components to verify compatibility against multiple versions. I assume Qt 5 support will soon be broken, like what we've seen for earlier Qt 5 versions. I 'm too lazy to setup complicated CI, either. Anyway, I'm open to different opinions.

its compilation gives an error against a higher version. (Is that possible?)

Maybe not not needed. Let's assume libqtxdg has moved to Qt 6 while liblxqt has not. In that case, liblxqt wants libqt5xdg, while newer libqtxdg only provides libqt6xdg. As a result, liblxqt only compiles with older libqtxdg. The case for other components should be similar.

[tsujan]

I prefer to keep it as a standalone library than having two copies.

I meant exactly that :) Internalizing into LXQt — I know, "Internalizing" wasn't a good word.

So, if I've correctly understood your comment, you agree that we start the Qt6 port, by porting those components that don't depend on KF6 and leaving the others to depend on LXQt 1.1.0.

The only thing that still isn't clear to me is libdbusmenu-qt6. Arch has it, by applying a patch — and that's very good — but we can't expect it from other distros.

[yan12125]

I meant exactly that :)

Nice :)

you agree that we start the Qt6 port, by porting those components that don't depend on KF6 and leaving the others to depend on LXQt 1.1.0.

Yep!

but we can't expect it from other distros

Yeah that's a good question. Here is yet another idea: how about copying libdbusmenu-qt files into an existing LXQt library (ex: liblxqt)? Then we can apply bug fixes without worrying about Linux/BSD/... distributions.

[tsujan]

Here is yet another idea: how about copying libdbusmenu-qt files into an existing LXQt library (ex: liblxqt)?

That's a very good idea!

[tsujan]

@palinek, @luis-pereira, all devs:
Your thoughts on copying libdbusmenu-qt into liblxqt?

EDIT: libdbusmenu-qt and KF6 are the obstacles. We can't do anything about the latter other than waiting.

[palinek]

As said in KDE's phabricator thread, the library consists of import & export logic. We are using the exporting part in lxqt-qtplugin, but we don't need to for Qt6 as Qt6 can handle it by itself (based on the KDE thread). The importing part is used in statusnotifier plugin.
If we want to maintain the library, we probably should use the KDE's lib (https://github.com/KDE/plasma-workspace/tree/master/libdbusmenuqt) as a base and make it standalone library.

[luis-pereira]

I'm Ok with maintaining our libdbusmenu-qt library if necessary.
To liblxqt, I'm not so fan of that. libdbusmenu-qt is a library on it's own. It's better to leave that way, IMO.

[yan12125]

we don't need to for Qt6 as Qt6 can handle it by itself

Qt 5 already has the exporting feature, but there are some minor bugs. I have once tried patching lxqt-qtplugin to use Qt 5 instead of libdbusmenu-qt (https://github.com/lxqt/lxqt-qtplugin/tree/qt-sni), and the result is not quite satisfying. I'm not sure if some bugs are fixed with Qt 6 or not.

It's better to leave that way, IMO.

Yeah I prefer that, too. Nevertheless, there is a concern for Linux/BSD/... distros: #2139 (reply in thread)

[tsujan]

My crystal ball warns me: "If you don't make a decision soon, LXQt 1.2.0 will be in Qt5 and users might kill you."

[stefonarch]

Just recompiled the 3 wip_qt6 branches on a clean manjaro install and I see that the qt6 applications take the kwantum theme set with kvantum manager, although widget style is set to "breeze". Restarted session, changed widget style for and back, nothing.
EDIT: turns out is has to be a setting in my home somewhere....
EDIT2: nothing found, temp solution: remove kvantum

[tsujan]

Ha ha. Kvantum takes over ;)

Breeze doesn't have a Qt6 version. The only Qt6 styles that I know of are currently Fusion and Kvantum. Of course, that should change soon but, apparently, KDE devs don't have any rush in porting KDE to Qt6.

EDIT: I'm talking about stable versions.

[tsujan]

although widget style is set to "breeze".

LXQt Appearance Configuration is still in Qt5; so, it only sees Qt5 styles. If lxqt-config was also ported to Qt6, it would only see Fusion and Kvantum.

[stefonarch]

Yes, I forgot to test fusion ;)

[RokeJulianLockhart]

I suggest that you merely support qt6. I see no reason to burden maintainers and developers with support for qt5, and removal of support for it shall incentivize developers of qt5 packages to replace qt5 with 6.

[tsujan]

There will be no burden. Qt5 will be forgotten with the Qt6 ports, but users could install some Qt5 libraries alongside Qt6 ones to support Qt5 apps (as they can already install WIP Qt6 branches for Qt6 support). Here, we discussed how to separate those libraries and reached a conclusion.

[RokeJulianLockhart]

Was your solution renaming certain libraries to allow simultaneous installation of older and newer ones? I'd say that that creates additional problems, because older software that interacts with those libraries won't receive the features afforded by newer versions. However, I suppose that stability is more important.

It's similar to the difference between vanity and versioned hyperlinks for software-installation.

[tsujan]

LXQt doesn't have LTS. Old versions are considered "dead". However, some "dead" libraries will be useful for a while with Qt5 →Q6. For example, Qt5 LXQt file dialog could be used by Qt5 apps when the port is finished. The user will be free to install those "dead" libraries or not.

Anyway, the fundamental problems have been solved. We're waiting for KDE devs, because of KF6.

[tsujan]

A small note:

As with Qt5, https://github.com/lxqt/libqtxdg/tree/wip_qt6 may also need to be recompiled after Qt6 upgrades. For example, Arch's upgrade to qt6-base 6.4.0-1 requires that (otherwise, crashes in Qt6-based LXQt file dialog will be imminent).

[stefonarch]

Atm I didn't experience any crash.
Will those wip_qt6 branches be released in 1.2 ?

[tsujan]

Will those wip_qt6 branches be released in 1.2 ?

Waiting for lxqt/lxqt-build-tools#77 and making the branches be based on it.

[stefonarch]

So yes?I think it's good to ship (appearance and filedialog) support for the qt6 apps.

[tsujan]

We can't release them yet because they aren't separate source packages but future patches.

However, distros like Arch could make Qt6 packages out of them, once lxqt/lxqt-build-tools#77 is ready and the other patches are based on it.

I really hope that LXQt 1.3.0 will be in Qt6 as far as possible, even if KDE isn't ready for Qt6. Let's make that our goal!

[stefonarch]

KDE's timeline: https://www.phoronix.com/news/Plasma-5.27-Last-5-Release

[tsujan]

LXQt 1.2.0 has been released. Let's make the next release, 1.3.0, be based on Qt6!

[tsujan]

I haven't compared libdbusmenu-qt with Plasma's libdbusmenuqt yet, but I think @palinek's suggestion may be the best way to go for Qt6.

@yan12125, what do you think?

@palinek, how difficult is it? Are fundamental changes needed for a Qt6 port?

And if it can be done without a serious hassle, how should we rename it for LXQt?

[yan12125]

OK, Telegram devs port only the library but not tests. Here is a WIP with tests: https://github.com/lxqt/libdbusmenu-qt/tree/wip_qt6

[tsujan]

@yan12125

Thanks a lot!

I think we can merge https://github.com/lxqt/libdbusmenu-qt/tree/wip_qt6, rename it as libdbusmenu-lxqt and start to clean up its code.

[yan12125]

I renamed it. I prefer to keep the Qt 6 branch until it works, though.

[tsujan]

I renamed it.

Thanks!

I prefer to keep the Qt 6 branch until it works, though.

OK.

IMHO, we could remove the support for < Qt6 because we already use libdbusmenu-qt for Qt5. If so, the Qt6 branch will be the only branch.

[yan12125]

we could remove the support for < Qt6

Fine with me.

[tsujan]

I added the Qt6 port of pcmanfm-qt: lxqt/pcmanfm-qt#1726

Please make sure you have the latest libfm-qt6 from lxqt/libfm-qt#778 before compiling it — I made a change to it minutes ago.

[tsujan]

Also added the Qt6 port of lximage-qt: lxqt/lximage-qt#600

[yan12125]

More AUR packages!

https://aur.archlinux.org/packages/lximage-qt6-git
https://aur.archlinux.org/packages/pcmanfm-qt6-git

[yan12125]

Submitting pull requests to https://github.com/lxqt/libdbusmenu-lxqt is not straightforward as the default base repo is https://github.com/desktop-app/libdbusmenu-qt, and GitHub does not support changing the default base repo yet [1], so I submitted a GitHub support ticket to detach https://github.com/lxqt/libdbusmenu-lxqt (making it a root repo instead of a fork).

By the way, I've also enabled issues for that repo.

[1] community/community#11729

[tsujan]

@yan12125
Thanks! I thought the source should be copied to another repository for fork detachment.

I encountered the problem in PR making and solved it by manual editing of the PR address.

BTW, would you take a look at lxqt/libdbusmenu-lxqt#2? lxqt-qtplugin can be compiled well with it.

[yan12125]

And it's now detached. GitHub support team is again as fast as thunder!

BTW, would you take a look at lxqt/libdbusmenu-lxqt#2? lxqt-qtplugin can be compiled well with it.

Sure, I took a brief look.

[tsujan]

@yan12125
What's the state of QTerminal regarding Qt6? Could you make draft PRs for Qt6 ports of qtermwidget and qterminal?

[yan12125]

The PR for qtermwidget lxqt/qtermwidget#468 needs many fixes. I don't have time for qterminal either.

[tsujan]

Making new PRs may be easier — I'm not sure though; haven't looked into it recently.

[yan12125]

yeah probably; it still needs some time

[stefonarch]

Looking at layer-shell-qt again atm the situation is somehow acceptable only for lxqt-notificationd, made a draft wip PR here.

Using the same approach for lxqt-panel and lxqt-runner those are the results.

Working: position, exclusive zone, layer, exclusion from appswitcher and taskmanager

Issues (showstoppers):

• Most widgets and menus are fullscreen (volume slider, calendar, settings and so on).
• All Qt applications launched from menu, quicklaunch or runner are fullscreen on all workspaces, without decorations and don't take cltr+Q

[tsujan]

Most widgets and menus are fullscreen

It's a known issue; see #10 (comment). With Qt5, nothing can be done. With Qt ≥ 6.6, the devs of layer-shell-qt are working on it.

[yan12125]

I give it a try with Projects (a new GitHub feature), and it looks good for providing an overview: Qt 6 support

[tsujan]

With the new (harmless) compilation warnings of Qt 6.6, and for avoiding version checks, it seems better to me if the minimum required version of Qt is bumped to 6.6 after the November release. Most probably, LXQt 1.5.0 could be in Qt6, and Qt 6.6 will be in all up-to-date distros until then.

[tsujan]

Dear LXQt members,

This is just a suggestion; change it if you know of a better way:

I suggest that we wait a few weeks or so (maybe a month) to see if point releases for components of LXQt 1.4.0 are needed, and then, after rebasing the current Qt6 branches (except for qterminal and qtermwidget, which aren't ready), merge them. I've been using the Qt6 branches for a long time to make sure that they have no problem.

If you agree, please don't add PRs for the Qt5 components that have working Qt6 branches. My reason for asking this is that we won't release a Qt5-based LXQt anymore. The required PRs could be made against the Qt6-based components.

Of course, components like lxqt-panel can wait until stable releases of their Qt6 dependencies appear — PRs against their current masters can be made and merged.

[tsimonq2]

@Conan-Kudo From my recollection, the original intent here was to release a 2.0 with both Wayland and Qt 6 support. It may be a while; for Lubuntu I've started cherry picking good, tested patches and documenting these so users know not to expect upstream support for them yet.

[tsimonq2]

Furthermore, Lubuntu 24.04 LTS will be Qt 5 and X11, and 24.10 will be Qt 6 and Wayland, no matter how premature. That should tell you something about when our efforts will be increased in this direction. :)

[tsujan]

Any chance we'll get LXQt 1.5 with Qt6+KF6 support this month?

No. LXQ is released twice a year in November and April.

And, as it has been mentioned several times, LXQt has no special relation to any distro. What happens in Lubuntu is the responsibility of its maintainers.

[Conan-Kudo]

What about a release candidate next month with a final release in April?

[tsujan]

As mentioned in the November release note, even the April release might be delayed. A complete port needs time, our active manpower is always limited, and a half-baked release isn't an option.

Anyway, for a long time, there have been several Qt6 branches, updated constantly and tested (I'm using them, although they need another update and some changes — Qps and lxqt-archiver will be added soon), but they don't include the components that need KF6. The port of QTerminal isn't decided either (with or without legacy encodings).

[Conan-Kudo]

Hey folks, downstream in Fedora, we've just integrated KDE Plasma 6 into Rawhide for the upcoming Fedora 40 release. Unfortunately, we noticed that we accidentally broke LXQt because we have a Qt6/KF6 KScreen instead of a Qt5/KF5 version. Is this addressed in the Qt 6 version of LXQt? And would it be possible to get a release soon with Qt 6 based LXQt so we can pull this down into Fedora?

cc: @aleasto @travier

[yan12125]

To fix the issue, lxqt-config needs a Qt 6 port, and I didn't find a work-in-progress as of writing.

@tsujan I assume the Qt 6 port will not be complete when KDE Plasma 6 is out? If not, I will need to make KF5 kscreen and KF6 kscreen to co-exist on Arch Linux, like what Fedora has done.

[tsujan]

I will need to make KF5 kscreen and KF6 kscreen to co-exist on Arch Linux

Yes, they need to coexist for a while; otherwise, people will have to remove LXQt.

I assume the Qt 6 port will not be complete when KDE Plasma 6 is out?

@gfgit and @stefonarch have started to port the components that can't coexist with their Qt5 counterparts. I'll join them after KF6 comes to Manjaro.

What about QTerminal?

[yan12125]

Yes, they need to coexist for a while; otherwise, people will have to remove LXQt.

Got it. I will check how to achieve co-existence before starting other Qt6-related works, as Arch Linux users will be affected soon when KDE Plasma 6 arrives.

@gfgit and @stefonarch have started to port the components that can't coexist with their Qt5 counterparts. I'll join them after KF6 comes to Manjaro.

Yes, I noticed many news pull requests in Qt 6 support. Thank you all very much!

What about QTerminal?

It seems existing pull requests are not in a good shape. It may take me one or two weekends to cleanup and finish them.

[tsujan]

... as Arch Linux users will be affected soon when KDE Plasma 6 arrives.

Arch's upgrades of last months gave me the impression that Arch had already done it, by changing the names of many Qt5-based packages.

[yan12125]

The primary KDE matainer at Arch has put awesome efforts on making lots of KDE 5 packages co-installable with upcoming KDE 6. I just need to add one more package for KF5 lbkscreen.

The progress is now tracked at https://archlinux.org/todo/plasma-6/

[isf63]

Just curious -- how is Qt6's performance and system usage compared to Qt5? After all, LXQt will be using Qt6 and is a lightweight DE.

On Arch qt5-base is 63.22 MiB and qt6-base is 56.19 MiB -- that's a promising sign that Qt6 is more lightweight, but that probably doesn't mean much as a whole.

[tsujan]

Qt6 is as resource-friendly as Qt5. Apart from fixes, it includes several cleanups too. Also, it's better with Wayland.

It isn't like GTK ;)

[tsujan]

It may be worth adding that Qt6 is a little faster than Qt5 in processing strings. Although that may not be tangible with LXQt apps, I feel it is with apps like FeatherPad.

[stefonarch]

Stumbled upon this, not quite new though:

Every release has a killer feature. Qt 6.6 features the opposite - staying alive. This blog post describes work to make Qt clients more robust and seemlessly migrate between compositors, providing resistance against compositor crashes and more.

http://blog.davidedmundson.co.uk/blog/qt6_wayland_robustness/

EDIT: I tested in the VM, doesn't look like it would work,back to login screen.

[tsujan]

I haven't felt a need for that. Instead Qt6 needs a really working layer-shell, as GTK has had it for a long time.

[tsujan]

The porting will be started soon, in ~2 days, mostly for components that could be installed in parallel with Qt5 ones.

After that, the porting will continue for the other components, thanks to @gfgit, @stefonarch and contributors who have been working on them.

However, in the case of components that cannot be installed in parallel with their Qt5 counterparts, we might need to wait until all of them are ready and only then merge their PRs together. Because, otherwise, the current Qt5 components won't work and git users might have a hard time.

[stefonarch]

git users might have a hard time.

It's good to be cautious, but it looks as there are no issues with running a mixed Qt5/6 LXQt.
I'm using all draft PRs together with Qt5 version for session, runner and powermanagement.

[tsujan]

but it looks as there are no issues with running a mixed Qt5/6 LXQt

Only as long as the second type of PRs aren't merged until all of them are ready. Suppose that we merge lxqt/liblxqt#337. Then, for example, Qps won't work anymore. IMHO, we shouldn't torture git users ;)

[tsujan]

Just wanted to say that the Qt6 port is mostly done now. There remain a few components, among which lxqt-config and qterminal are the most important. I'm waiting for some stable "K" components to come into Manajaro testing in order to port lxqt-config. Also, a serious problem in lxqt-panel's notification area should be solved (haven't looked into it yet).

Simultaneously, full Wayland compatibility has been achieved for some components, thanks to the Qt6-based layer-shell-qt.

[Chiitoo]

Getting close indeed!

Many thanks to everyone involved. I wish I had the time and energy to help!

I did at least start getting the Gentoo "live" (git) packages in order, but mixing those with the Qt 5 packages would take quite a bit more energy that I don't have, so will have to wait for pretty much all of it to be there until I'll push them out.

[tsujan]

but mixing those with the Qt 5 packages would take quite a bit more energy

Yes. I should have added that, except for a few packages, the port is mostly inside WIP PRs, not even in git. Testing those PRs isn't straightforward at all. So, git users have to wait.

[stefonarch]

From my point of view all qt6-ports could be merged now with lxqt-config done too, to allow more users testing. I see only the issue in the panel's worlclock and did quite heavy testing of all components now. Only archiver and screengrab are missing, beside qterminal.

[tsujan]

Yes, it'll be good if more users could test them as soon as possible. But please wait for only one or two days. I want to read all PRs quickly; will merge them if I find no problem.

[stefonarch]

Aren't the AUR PKGBUILDs for libqtxdg-git, lxqt-qtplugin-git and lxqt-build-tools-git to update as they use qt6 and don't conflict with the qt5 release at the moment and can coexist @yan12125 ?

_pkgname=libqtxdg
pkgname=$_pkgname-git
pkgver=3.3.0.3.g7f32cc7
....
depends=("qt5-base" "qt5-svg")
makedepends=("git" "cmake" "qt5-tools" "lxqt-build-tools-git")
checkdepends=("xorg-server-xvfb")
provides=("$_pkgname=$pkgver")
conflicts=("$_pkgname-qt5-git" "$_pkgname")

[yan12125]

I haven't had time to start Qt 6 migration for AUR packages. The progress will be tracked in https://gitlab.com/yan12125/aur/-/issues/42

[tsujan]

Update:

The Qt6 port is finished in git, except for QTerminal, whose port is in progress (complications have been encountered regarding QTextCodec).

I think the next release could be made on time. if QTerminal isn't ready before Apr 15, its Qt6 port could be released as soon as it's ready and tested. Delaying the release for a few weeks (but not more) will also be possible.

[yan12125]

I think LXQt 2.0 is stable enough after recent point releases [1]? I'm considering moving Arch packages from testing to stable.

lxqt/lxqt-panel#2053 is also good to have. I cherry-picked the fix into the Arch package, anyway.

[1] https://lxqt-project.org/release/2024/05/04/Point-Releases-of-several-components/

[tsujan]

Official Arch Linux packages are expected to have high quality

How can a package that had high quality before suddenly lose its quality? Arch already contains packages for very old apps that haven't been developed for years. This is only about supporting Qt5 by renaming 4 packages that existed before.

[yan12125]

How can a package that had high quality before suddenly lose its quality? Arch already contains packages for very old apps that haven't been developed for years.

Criteria are becoming stricter and stricter. If older packages cannot meet new criteria (ex: new compiler options for security hardening), they may be dropped to AUR.

Anyway, I uploaded two remaining packages to AUR.
https://aur.archlinux.org/packages/libfm-qt5
https://aur.archlinux.org/packages/lxqt-qt5plugin

[tsujan]

Thanks for adding them, and also for the explanation.

I hope Arch won't become like Debian. I remember that, several years ago, Debian didn't apply two patches (one for cairo and the other for Qt) that almost all other major distros applied. That created a hassle for many users: they had to apply them themselves with every update, just because of a Debian formality.

[yan12125]

I hope Arch won't become like Debian.

I believe that will not be the case in the forseeable future. From my experience, Arch Linux is on the direction that lowers the barrier of contributions. For example, introduction of merge requests for packages, allowing Package Maintainers (formerly called Trusted Users) to access the [extra] repo, etc.

In this case, the main issue is my limited spare time. As cybersecurity threats are more and more severe nowadays, most (all?) serious Linux distribution are encouraging better security for packages. With this trend, I cannot guarantee high quality for all my packages if I maintain many, and thus I prefer to keep the number of my packages low.

[tsujan]

Arch Linux is on the direction that lowers the barrier of contributions

That's good news :)

In this case, the main issue is my limited spare time.

I understand.