Subject: Displaying qt applications on wayland using qtwayland is complicated

From: Morgan Smith <[email-masked]>
Date: Thu, 24 Aug 2023 13:48:04 -0400

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).