bug#65508: Displaying qt applications on wayland using qtwayland is complicated

bug#65508: Displaying qt applications on wayland using qtwayland is complicated

[Morgan Smith]

Hello guix!

Before I get into the actual bug I'm trying to report, I have to bring up 2
other complications.

1. qtwayland@6 currently doesn't build due a test failure.  So in this bug I'm
either using "--without-tests=qtwayland" on the command line or
"((options->transformation '((without-tests . "qtwayland"))) qtwayland)" in
manifests.

2. The way we deal with multiple package versions in a profile is really weird.
"guix shell package@1 package@2" works as expected (both versions available).
"guix install package@1 package@2" silently installs only the newer one.
Putting package@1 and package@2 in a manifest yields: "error: profile contains
conflicting entries for package"


OK with that out of the way, onto my actual bug report:

I use wayland.  I also use some qt applications.  For a qt application to
display on wayland it either needs the qtwayland plugin available, or it can
use some x11 fallback thingy.  The qtwayland plugin is the way I'd like my qt
applications to render.

Some applications include qtwayland in their inputs like okular and work fine
out of the box.  Most applications (like openscad and jami) do not.

This is fine because we can simply install qtwayland into our profile.  Not
everyone uses wayland so this actually seems like the appropriate thing to do.
Unfortunately, openscad uses qtwayland@5 and jami uses qtwayland@6.  Due to the
above explained complication, I cannot simply install both into my profile.

We could make qtwayland@5 and qtwayland@6 into two completely different
packages and that would solve my problem.  Doing "guix shell qtwayland@5
qtwayland@6 qtbase" (jami wants qtbase for some reason), allows me to run both
openscad and jami.  So clearly qtwayland@5 and qtwayland@6 don't interfere with
each other.

Of course the more user friendly option would be to simply add the appropriate
qtwayland to the inputs of a package using the qt-build-system.  Or maybe even
make it propagated from qtbase somehow?

guix size qtwayland@5 = 1203.1 MiB
guix size qtbase@5 = 1171.5 MiB

guix size qtwayland@6 = 1271.7 MiB
guix size qtbase@6 = 1190.2 MiB

Well if I understand how "guix size" works, then adding qtwayland would only
add 30 or 80 MiB, which in my opinion isn't a lot.  My vote is on just adding
qtwayland to all wayland packages (at the cost of a full qt rebuild).

bug#65508: Displaying qt applications on wayland using qtwayland is complicated

[Josselin Poiret via Bug reports for GNU Guix]

[-- Attachment #1: Type: text/plain, Size: 383 bytes --]

Hi Morgan,

Morgan Smith <Morgan.J.Smith@outlook.com> writes:

> Well if I understand how "guix size" works, then adding qtwayland would only
> add 30 or 80 MiB, which in my opinion isn't a lot.  My vote is on just adding
> qtwayland to all wayland packages (at the cost of a full qt rebuild).

Just dropping by to say that I agree with this!

Best,
-- 
Josselin Poiret

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 682 bytes --]

bug#65508: Displaying qt applications on wayland using qtwayland is complicated

[Maxim Cournoyer]

Hi,

Morgan Smith <Morgan.J.Smith@outlook.com> writes:

> Hello guix!
>
> Before I get into the actual bug I'm trying to report, I have to bring up 2
> other complications.
>
> 1. qtwayland@6 currently doesn't build due a test failure.  So in this bug I'm
> either using "--without-tests=qtwayland" on the command line or
> "((options->transformation '((without-tests . "qtwayland"))) qtwayland)" in
> manifests.
>
> 2. The way we deal with multiple package versions in a profile is really weird.
> "guix shell package@1 package@2" works as expected (both versions available).
> "guix install package@1 package@2" silently installs only the newer one.
> Putting package@1 and package@2 in a manifest yields: "error: profile contains
> conflicting entries for package"
>
>
> OK with that out of the way, onto my actual bug report:
>
> I use wayland.  I also use some qt applications.  For a qt application to
> display on wayland it either needs the qtwayland plugin available, or it can
> use some x11 fallback thingy.  The qtwayland plugin is the way I'd like my qt
> applications to render.
>
> Some applications include qtwayland in their inputs like okular and work fine
> out of the box.  Most applications (like openscad and jami) do not.
>
> This is fine because we can simply install qtwayland into our profile.  Not
> everyone uses wayland so this actually seems like the appropriate thing to do.
> Unfortunately, openscad uses qtwayland@5 and jami uses qtwayland@6.  Due to the
> above explained complication, I cannot simply install both into my profile.
>
> We could make qtwayland@5 and qtwayland@6 into two completely different
> packages and that would solve my problem.  Doing "guix shell qtwayland@5
> qtwayland@6 qtbase" (jami wants qtbase for some reason), allows me to run both
> openscad and jami.  So clearly qtwayland@5 and qtwayland@6 don't interfere with
> each other.
>
> Of course the more user friendly option would be to simply add the appropriate
> qtwayland to the inputs of a package using the qt-build-system.  Or maybe even
> make it propagated from qtbase somehow?
>
> guix size qtwayland@5 = 1203.1 MiB
> guix size qtbase@5 = 1171.5 MiB
>
> guix size qtwayland@6 = 1271.7 MiB
> guix size qtbase@6 = 1190.2 MiB

This size is a bit misleading for Qt 6, which recently regressed by
referencing Python, bloating it's size by about 100 MiB, IIRC (now fixed
on the telephony-team branch).  Since qtwayland correctly works as a
plugin when installed to a user profile, it seems we should leave it
that way, but I agree we should fix the uses cases of installing
multiple versions of the same package in the same profile.

-- 
Thanks,
Maxim