feat(kde-neon-6): lxqt and kvantum theme support

[Kyuyrii]

I'm trying to add the use of lxqt-support content snaps, but I don't quite understand how Snapcraft works. Could you check if I made the correct modification, and if not, what needs to be done?

Closes #5904

[bepri]

Hey @Kyuyrii, thanks! You definitely are on the right track, I would say.

If you haven't yet, have a look at our contributing guidelines, there's probably some useful information in there for you.

Additionally, could you update the tests at tests/unit/extensions/test_kde_neon_6.py to assert this new behavior?

[Kyuyrii]

If you haven't yet, have a look at our contributing guidelines, there's probably some useful information in there for you.

I saw that it requires signing the CLA, but since I can't do that, could someone merge the change for me?

This was done when I helped improve the creation of .desktop files and Steam Snap icons.

[lengau]

Thanks for doing this!

This mostly LGTM, but I think this would mean that all snaps that use this would get the lxqt/kvantum themes as well, even if the user doesn't use them. That's not necessarily a problem, but I wonder whether there's a way to avoid that.

[bepri]

Why can't you sign the CLA, exactly? I don't believe we are allowed to merge this otherwise, sadly.

[Kyuyrii]

Thanks for doing this!

This mostly LGTM, but I think this would mean that all snaps that use this would get the lxqt/kvantum themes as well, even if the user doesn't use them. That's not necessarily a problem, but I wonder whether there's a way to avoid that.

The lxqt-plugin and Kvantum will only be used if the distro, DE, or user defines that it should be used.

This is the case with Lubuntu, which uses LXQT, so it uses the lxqt-plugin, and Lubuntu comes with Kvantum pre-installed and activated.

The lxqt-support Snaps are tiny; when using “snap info lxqt-support-core24,” the size reported is 4MB.

[Kyuyrii]

Why can't you sign the CLA, exactly? I don't believe we are allowed to merge this otherwise, sadly.

This had been done on Steam Snap, so we assumed it wouldn't be a problem.

I had opened this pull request: canonical/steam-snap#449

And to merge it, this other pull request was opened: canonical/steam-snap#451

[bepri]

I confirmed that we cannot accept your contribution without the CLA being signed as-is. If you're unable or unwilling to contribute it, we unfortunately can't proceed with this PR.

[Kyuyrii]

I confirmed that we cannot accept your contribution without the CLA being signed as-is. If you're unable or unwilling to contribute it, we unfortunately can't proceed with this PR.

But if someone else opens a pull request with the same modification, the contribution will not be mine.

[bepri]

Unfortunately, that is not the case. From a legal point of view, it's still your code, just copied by you. For what it is worth, the CLA does not strip you of ownership when contributing to Canonical projects - you continue to own it even after merging.

[Kyuyrii]

That's a bit strange, code isn't the same as art, lots of things will be the same or practically the same even if they're made by different people.

If that code is under the GPL3 license, shouldn't its use be free?

[steinbro]

That's a bit strange, code isn't the same as art, lots of things will be the same or practically the same even if they're made by different people.

You're right, and anyone is welcome to independently reimplement your contribution. But simply copying your contribution into a new PR wouldn't be independent.

If that code is under the GPL3 license, shouldn't its use be free?

It's free for other users to use and modify, yes. But the CLA covers additional rights that are important for distributors of GPL-licensed software like Canonical.

You might find the CLA FAQ helpful: https://canonical.com/legal/contributors/faq

[Kyuyrii]

You're right, and anyone is welcome to independently reimplement your contribution. But simply copying your contribution into a new PR wouldn't be independent.

This was done with Steam Snap...

So the situation is quite strange. Will there be any problems involving Steam Snap?

canonical/steam-snap#449
canonical/steam-snap#451

[steinbro]

This was done with Steam Snap...

So the situation is quite strange. Will there be any problems involving Steam Snap?

I personally don't know what policies apply to steam-snap, seeing as there's no license in the repo and IIRC the client it's packaging is closed source.

In any case, signing the CLA once should cover all applicable Canonical repositories, which does include snapcraft. And it applies to the author, whether or not they're also the committer.

[Kyuyrii]

I signed the CLA, what do I need to do now?

[lengau]

Thanks for siging the CLA @Kyuyrii! My change suggestion caused a lint/test failure, so if you could update to take care of those we should be fine from my side.

[Kyuyrii]

Thanks for siging the CLA @Kyuyrii! My change suggestion caused a lint/test failure, so if you could update to take care of those we should be fine from my side.

I'm a little confused, what should I do?

[bepri]

I signed the CLA, what do I need to do now?

We should be good to go now, thanks :)

Now we're back to the review. The failing linter runs should be fixable by just running make setup followed by make format and make lint. Have a look at the failing tests under the "fast tests" workflow as those are directly related to your changes and should be pretty straightforward to solve. The "minimum dependencies" workflow is the same set of failing tests it seems, so I'd ignore it. The "spread tests" failing workflow are flaky failures being addressed in #5899, so once again I'd ignore those.

Finally, could you update this spread task file to check for the presence of the lxqt content snap? If you can think of any other ways to verify that your additions worked, go ahead and please add them to that file as well.

[Kyuyrii]

I added lxqt-support-core22 and lxqt-support-core24 to the files I found.

[Kyuyrii]

Is there anything else I need to do?

[lengau]

@Kyuyrii could you fix the linting issues we're seeing from ruff and pyright? Other than that, when @bepri gets back online on Monday he'll be able to do a final review. TIA!

[bepri]

Thanks for your contribution, @Kyuyrii!