QUESTION: Does the backup command / script work in a Wayland environment?

[robertstrom]

Describe the bug
Running the Flatpak version of CopyQ v9.1.0 with the Backup On Exit command added and enabled and the backups have never worked. I have enabled this and had it work on MANY other systems whether they be Linux, Mac, or Windows (mostly Linux) for years now. I am currently running the Alpha pre-release of Pop!_OS Cosmic (Alpha 3 right now - have been running since the initial Alpha version) using the Flatpak install of CopyQ (because I cannot get the deb version to work on Wayland ... did I ever mention how unhappy I am with Wayland?)

I believe that have found where the CopyQ data is located for the Flatpak install (not a big Flatpak or Snap fan either). Please confirm this.

./.var/app/com.github.hluk.copyq/config/copyq/

So if this is correct, I can certainly backup the files if necessary but it sure would be nice if the built-in backup on exit worked.

To Reproduce

Run CopyQ on Pop!_OS 24.04 Cosmic (which is running a Wayland DE)

Expected behavior
It would be great if the backup on exit worked

Screenshots

NONE

Version, OS and Environment

rstrom@pop-os:~/.var/app/com.github.hluk.copyq/config/copyq$ flatpak run com.github.hluk.copyq version
CopyQ Clipboard Manager 9.1.0
Qt: 6.7.3
KNotifications: 6.7.0
Compiler: GCC
Arch: x86_64-little_endian-lp64
OS: KDE Flatpak runtime

rstrom@pop-os:~/.var/app/com.github.hluk.copyq/config/copyq$ env
SHELL=/bin/bash
WINDOWID=0
COLORTERM=truecolor
GTK_IM_MODULE=ibus
COSMIC_PANEL_BACKGROUND=ThemeDefault
SSH_AUTH_SOCK=/tmp/ssh-AjOm0o3RjPt8/agent.3348
DRI_PRIME=pci-0000_00_02_0
XMODIFIERS=@im=ibus
SSH_AGENT_PID=3349
XDG_SEAT=seat0
PWD=/home/rstrom/.var/app/com.github.hluk.copyq/config/copyq
XDG_SESSION_DESKTOP=COSMIC
LOGNAME=rstrom
XDG_SESSION_TYPE=wayland
COSMIC_DATA_CONTROL_ENABLED=1
...
XDG_CURRENT_DESKTOP=COSMIC
WAYLAND_DISPLAY=wayland-1
CLUTTER_IM_MODULE=ibus
QT_QPA_PLATFORM=wayland;xcb
LESSCLOSE=/usr/bin/lesspipe %s %s
COSMIC_PANEL_SIZE=S
TERM=xterm-256color
COSMIC_PANEL_NAME=Dock
LESSOPEN=| /usr/bin/lesspipe %s
LIBVIRT_DEFAULT_URI=qemu:///system
USER=rstrom
DISPLAY=:1
SHLVL=1
MOZ_ENABLE_WAYLAND=1
QT_IM_MODULE=ibus
XDG_VTNR=1
XDG_SESSION_ID=4
COSMIC_PANEL_OUTPUT=eDP-1
PANEL_NOTIFICATIONS_FD=20
XDG_RUNTIME_DIR=/run/user/1000
COSMIC_PANEL_ANCHOR=Bottom
QT_AUTO_SCREEN_SCALE_FACTOR=1
XCURSOR_THEME=Cosmic
XDG_DATA_DIRS=/home/rstrom/.local/share/flatpak/exports/share:/var/lib/flatpak/exports/share:/usr/local/share:/usr/share
GDK_BACKEND=wayland,x11
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin
QT_ENABLE_HIGHDPI_SCALING=1
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus
RUST_BACKTRACE=1
ALACRITTY_WINDOW_ID=0
X_PRIVILEGED_WAYLAND_SOCKET=110

• OS (for example Windows 11, Ubuntu 22.04, macOS Sonoma 14.4)

rstrom@pop-os:~/.var/app/com.github.hluk.copyq/config/copyq$ cat /etc/os-release
NAME="Pop!_OS"
VERSION="24.04 LTS"
ID=pop
ID_LIKE="ubuntu debian"
PRETTY_NAME="Pop!_OS 24.04 LTS"
VERSION_ID="24.04"
HOME_URL="https://pop.system76.com"
SUPPORT_URL="https://support.system76.com"
BUG_REPORT_URL="https://github.com/pop-os/pop/issues"
PRIVACY_POLICY_URL="https://system76.com/privacy"
VERSION_CODENAME=noble
UBUNTU_CODENAME=noble
LOGO=distributor-logo-pop-os

• Desktop environment, window manager (if applicable)

rstrom@pop-os:~/.var/app/com.github.hluk.copyq/config/copyq$ printf 'Desktop: %s\nSession: %s\n' "$XDG_CURRENT_DESKTOP" "$GDMSESSION"
Desktop: COSMIC
Session:
rstrom@pop-os:~/.var/app/com.github.hluk.copyq/config/copyq$ env | grep -i wayland
XDG_SESSION_TYPE=wayland
WAYLAND_DISPLAY=wayland-1
QT_QPA_PLATFORM=wayland;xcb
MOZ_ENABLE_WAYLAND=1
GDK_BACKEND=wayland,x11
X_PRIVILEGED_WAYLAND_SOCKET=110

Additional context

[hluk]

The Backup On Exit command should normally work, but there are cases when the app is aborted if exiting the desktop environment, e.g. when there is no session manager.

I just checked on Sway (Wayland tiling compositor) and the backup is only created if I exit the application myself, but not when I exit sway itself. :(

I'm looking into writing alternative command to back up regularly.

[robertstrom]

I downloaded the Fedora 41 sway ISO and tried getting it up and running in a virtual machine this weekend. I got it installed but it did not want to behave in a VM.

I did get the Fedora 41 i3 ISO built into a VM and working so I am pretty confident that there was something weird with either the ISO build of the Fedora 41 sway or just running the sway DE in a VM.

I also implemented Kali 2024.3 with the i3 desktop in a VM this weekend and it is running beautifully ... and I have CopyQ working on it (have not checked the backups yet but I didn't think of it until now).

I like the idea of the regular backups!

Can you please validate that I have the info on the location of the CopyQ data files (posted above) when installed using Flatpak? This is one of the reasons that I am not a fan of either Flatpak or Snap.

[hluk]

Can you please validate that I have the info on the location of the CopyQ data files (posted above) when installed using Flatpak?

I'm not sure, but you can check the paths used by CopyQ with copyq info (e.g. run terminal or in Action dialog with "Store standard output" set to "text/plain"). Unfortunately, in case of Flatpak, I think it could show some "virtual" locations (mounted just for the app).