F42 Change Proposal: LXQt 2.1 (self-contained)

LXQt 2.1

:link: Summary

Wiki
Announced

Upgrade LXQt in Fedora to version 2.1.

:link: Owner

:link: Detailed Description

LXQt in Fedora will be upgraded to v2.1 and will default to Wayland, leveraging miriway by default for the Wayland experience.

More details on LXQt 2.1 are available from the upstream release announcement.

:link: Feedback

:link: Benefit to Fedora

Fedora includes the latest version of LXQt and one more desktop spin offering a Wayland-based experience.

:link: Scope

  • Proposal owners:

    • Upgrade all related LXQt packages
      • Incorporate pending upstream changes to support
        miriway as a Wayland compositor for LXQt
    • Adjust comps and live image to use Wayland by default
  • Other developers: N/A

  • Release engineering: #12455

  • Policies and guidelines: N/A (not needed for this Change)

  • Trademark approval: N/A (not needed for this Change)

  • Alignment with the Fedora Strategy: N/A

:link: Upgrade/compatibility impact

Users will be upgraded to LXQt 2.1, though no major configuration or user experience changes are expected.

:link: How To Test

Install using the spin, netinstall or DVD. Or upgrade from older release. Then users should be able to test by doing any daily work.

:link: User Experience

The user experience is not expected to change significantly with this upgrade.

:link: Dependencies

None outside of this Change.

:link: Contingency Plan

  • Contingency mechanism: Roll back the LXQt packages. It will require an Epoch bump.
  • Contingency deadline: Beta freeze
  • Blocks release? No.

:link: Documentation

N/A (not a System Wide Change)

:link: Release Notes

LXQt in Fedora has been upgraded to version 2.1 and now defaults to Wayland.

Last edited by @ngompa 2024-11-12T21:20:05Z

Last edited by @ngompa 2024-11-12T21:20:05Z

2 Likes

How do you feel about the proposal as written?

  • Strongly in favor
  • In favor, with reservations
  • Neutral
  • Opposed, but could be convinced
  • Strongly opposed
0 voters

If you are in favor but have reservations, or are opposed but something could change your mind, please explain in a reply.

We want everyone to be heard, but many posts repeating the same thing actually makes that harder. If you have something new to say, please say it. If, instead, you find someone has already covered what youโ€™d like to express, please simply give that post a :heart: instead of reiterating. You can even do this by email, by replying with the heart emoji or just โ€œ+1โ€. This will make long topics easier to follow.

Please note that this is an advisory โ€œstraw pollโ€ meant to gauge sentiment. It isnโ€™t a vote or a scientific survey. See About the Change Proposals category for more about the Change Process and moderation policy.

Added lxqt

Really cool! But why miriway?

Labwc, KWin, Wayfire, Hyprland, Sway, River and Niri

Are officially tested Wayland compositors for LXQt. They never mentioned miriway in any way.

Kwin is likely the best supported one (in Fedora), and the only one that supports a few features in the panel.

Labwc is very lightweight, RaspberryPi OS switched to it too, formerly used Wayfire.

I think it sounds more reasonable to bundle in ANY of those, and I think kwin would be the best option (if automatic installation of a ton more packages can be limited to the minimum)

What is so great about Mir? I found that miriway is the floating, miracle is the tiling variant of it.

Seems like it was designed to be part of a DE rather than used standalone, not that I know what difference this makes in practice.

They switched to labwc recently.

Itโ€™s pretty cool. A bit too buggy though, at least when I try it.

1 Like

There were a few reasons:

  • While I like KWin, the other members of the LXQt SIG were wary of pulling in KDE components because of the perception of โ€œbloatโ€. The technical argument that swayed me was that the KDE portal (which goes alongside KWin) doesnโ€™t really work outside of KDE Plasma without some significant work.
  • Most of these other window manager compositors are kind of a pain to integrate into a desktop environment.
  • The Mir team is interested in supporting an effort for a portal implementation that can integrate with desktops well without requiring every desktop to build one from scratch.

Miriway is designed to be the โ€œletโ€™s combine Mir with an existing desktopโ€ compositor, whereas most of these others do not have that as a goal. And the portal system is basically a requirement for functional Wayland environments these days, so the fact that the Mir team is interested in supporting that alongside the protocols-based approach that a lot of Wayland CLI tools use makes it a very appealing option.

It also helps that Mir has a much better ABI stability story than wlroots, which leads to less headaches overall.

1 Like

okay this explains a lot. didnt know that about KWin.

So miriway also does not have portals yet, but wants to implement them.

And all the others dont have generic GUI portals that work on different DEs??? didnt think of that

For some more details about this, I gave a talk (alongside Alan Griffiths from the Mir team) at the Ubuntu Summit about Miriway and demonstrated Fedora LXQt running on Miriway.

2 Likes

This change proposal has now been submitted to FESCo with ticket #3294 for voting.

To find out more, please visit our Changes Policy documentation.