streamdeck-ui: Fedora 38 Install not able to launch application
Describe the bug Application wont launch when installed on Fedora 38 following the guide.
To Reproduce Steps to reproduce the behaviour:
- Fresh install of Fedora 38 workstation (both baremetal and VM)
- Install kernel-headers
- Follow “installing on fedora guide”
- when trying to launch
- Review console output
- See error
Traceback (most recent call last): File "/home/stephen/.local/bin/streamdeck", line 5, in <module> from streamdeck_ui.gui import start File "/home/stephen/.local/lib/python3.11/site-packages/streamdeck_ui/gui.py", line 17, in <module> from streamdeck_ui.api import StreamDeckServer File "/home/stephen/.local/lib/python3.11/site-packages/streamdeck_ui/api.py", line 8, in <module> from PIL.ImageQt import ImageQt ModuleNotFoundError: No module named 'PIL.ImageQt'
Expected behaviour Launch Streamdeck-ui
Operating system (please complete the following information)
- OS: Fedora 38 Workstation
- Desktop environment: GNOME
- Python version Python 3.11.3
Stream Deck Version Across the board as software issue. Can do any tests on Standard MK.2
Happy to help replication try different methods on bare metal and VM.
About this issue
- Original URL
- State: open
- Created a year ago
- Comments: 22 (2 by maintainers)
We have no errors and the GUI,streamdeck is running!
Regarding Docker/Moby/Podman/Containerd/Rkt/CRI-O/LXD and friends, containerization would be a great tool for this if this weren’t an app supposed to interact with X11 or Wayland. Containerization is awesome to isolate dependencies and communications, but the very thing you need is IPC (Inter-Process Communication) for window drawing, input injection, system tray interaction, direct USB access and all that.
It would have been slightly easier in the past when all you needed was X11 since it has a server-client model (over the network if desired), but today even if you’re running in X11 mode you’re already using a number of parts from the Wayland effort, which were specifically designed to not have the same constraints regarding performance and integration hurdles that the original X11 project had.
It’s not impossible to containerize this, but from someone which works professionally with containerization since 2013, believe me when I say that it would be a hell of a pain in the butt, and without the isolation benefits that you would usually want from a container.