Revert "Use wayland workaround from #958"

[slikie]

As discussed in #1193, running QT_QPA_PLATFORM=xcb on a launcher is not a sustainable solution.

As 90f2ccade6b8976aa0d5b080eeded9bcc7eb35d1 gets reverted, the behavior of the launcher changed, resulting unreliable launch behavior.

While running without it on wayland doesn't seem to crash anymore, I hope this workaround can be reverted.

[ManuelSchneid3r]

There are several problems without the xcb fallback. We cant just undo it. At least one of them is severe: Wayland does not allow windows to position itself. Have you run albert without the QT_QPA_PLATFORM=xcbenv var?

[slikie]

        Albert version: 0.21.0
            Build date: Jun 23 2023 17:40:06
            Qt version: 6.5.1
             Build ABI: x86_64-little_endian-lp64
  Arch (build/current): x86_64/x86_64
 Kernel (type/version): linux/6.3.7-zen1-1-zen
                    OS: Arch Linux
     OS (type/version): arch/unknown
 $QT_QPA_PLATFORMTHEME: qt5ct
         Platform name: wayland
                  Font: Sans Serif,9,-1,5,400,0,0,0,0,0,0,0,0,0,0,1
       Binary location: /usr/bin/albert
                  $PWD: /home/rt
                $SHELL: /bin/bash
                 $LANG: en_US.UTF-8
              Language: English
                Locale: en_US
     $XDG_SESSION_TYPE: wayland
  $XDG_CURRENT_DESKTOP: sway
      $DESKTOP_SESSION: sway
  $XDG_SESSION_DESKTOP: 
            Icon theme: hicolor

Yes I have been running it without xcb for some time. And I believe it should be desktop environment's side to handle window position, as the same way as albert toggle hotkey binding. I'm pretty sure that in KDE wayland there are window options to set position based on app_class and window name. Not really familiar with other options, what are the main desktop environments that are having issue?

[ManuelSchneid3r]

Yes I have been running it without xcb for some time.

so your window is in the top left corner?

[ManuelSchneid3r]

I'm pretty sure that in KDE wayland there are window options

I dare to say toolkit developer and their users think otherwise. windows and macos are a staightforward, linux is a pain. I dont have the time to apapt each and any API out there. I dont see the point in making things that complex. we have xlib, xcb, wayland, xdg-portals/flatpak, snaps, … now each compositor should have its own API 🤦‍♂️. Linux desktop is going to die if the community does not settle on a single desktop standard api.

what are the main desktop environments that are having issue?

all but "good" old X servers but even the xlib/xcb api is a pain when writing desktop abstractions. i agree there has to happen something but its a shame that we are going to have concurrent approaches instead of colaborative ones.

[ManuelSchneid3r]

Its not the time yet. Before we can remove the xserver emulation we (or rather Qt devs) have to properly use the wayland api. See #1261, we cant just drop it yet.