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

[Maxim Cournoyer <maxim.cournoyer@gmail.com>]

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