New install of CopyQ not importing of clipboard content: not linking with Wayland clipboard?

[cpsyctc2]

Describe the bug
Cannot get CopyQ to import from clipboard

To Reproduce
My main laptop died yesterday. It was running Ubuntu 22.04, latest state and I'm not sure what version of CopyQ (but would have been latest based on daily updates of all packages and using the Ubuntu ppa. I have installed CopyQ 9.0.0~noble from the ppa on my fallback machine which is running Ubuntu 24.04.1 LTS and imported a fairly recent exported cpq file. That seems to have gone fine, i.e. I can see all the tabs and content but I cannot get CopyQ to import from the clipboard.

Expected behavior
I expect the latest cut or copy to go into the clipboard in CopyQ and be pasteable from there. Not happening. Single press on the CopyQ icon in the status bar always shows "Clipboard: " and opening CopyQ just shows the old contents of the imported clipboard tab. I think the clue is that the old clipboard tab is now "clipboard (1)" and there is a new clipboard tab at the top of tab list named "clipboard" but this stays resolutely empty .

Screenshots
Not sure these would say more than the above.

Version, OS and Environment
CopyQ Clipboard Manager 9.0.0~noble
Qt: 5.15.13
KNotifications: 5.115.0
Compiler: GCC
Arch: x86_64-little_endian-lp64
OS: Ubuntu 24.04.1 LTS

Additional context
Aha

CopyQ Warning [2024-09-20 10:18:44.843] : [default] QtWarning: Activating Wayland clipboard took 5000 ms
CopyQ ERROR [2024-09-20 10:18:44.849] : [default] QtCritical: Failed to activate Wayland clipboard
CopyQ ERROR [2024-09-20 10:20:06.090] : Null data in clipboard
CopyQ ERROR [2024-09-20 10:20:56.172] : Null data in clipboard

Something I need to do to get Wayland cooperating with CopyQ

P.S. CopyQ has been, for heaven knows how many years now, my #1 utility. Has saved probably months of my work life. Thank you!

[robertstrom]

See my post below CopyQ on Pop!_OS 2024 - Wayland. It has a lot of information on my struggles / findings of trying to get CopyQ working on a Wayland desktop environment.

NOTE: no one on the CopyQ team has responded to it in any way. Not sure if they are ignoring posts about Wayland or what.

I feel the same way about CopyQ. I have been using a clipboard manager since the mid to late 1990's (Clipmate on Windows). I still use that program on my main Windows systems because it has years and years (literally decades) of saved clips but CopyQ is my go to for Linux and macOS and I use it on test Windows systems. I even donate to / support the project monetarily.

This Wayland thing seems to really be throwing a number of programs a huge curve ball.

Flameshot, my go to screenshot program has similar issues when you attempt to run on a system using the Wayland Display Manager.

I have tried the workarounds listed here - https://copyq.readthedocs.io/en/latest/known-issues.html - but that did not work for me. I finally was able to get CopyQ working on the Pop!_OS 24.04 Alpha but I don't believe that the solution will help those not running the Pop!_OS operating system. I got a hint from a Pop!_OS support person. The hint was to add this to the /etc/environment file

COSMIC_DATA_CONTROL_ENABLED=1

This is pretty specific to the Cosmic desktop (which is using Wayland). I was also only able to get CopyQ to work if I used the Flatpak install version. It tried with the current .deb version and that did not work. What's really strange about that is that the Pop!_OS support person said that they were using the .deb install.

Even though I have it working there are still issues.

• Auto start is not working even though I set the value manually (the Auto start check box does not even exist in the GUI) using this command flatpak run com.github.hluk.copyq config autostart true and I checked that it was set to true using this command flatpak run com.github.hluk.copyq config | grep -i auto
• The program will not store the size and location as I have come to expect. It always opens up in the same place (not the last place where you placed it) and the same size (not the last size that you set it to). I expect that CopyQ would store these values after clicking the X or exiting the program. It does on non-Wayland systems
• I have installed the backup on exit script and that it not working for me
• I cannot get shortcuts to work - in particular the one to Show the window
• I'm sure that there are other issues, but those are what I know about for sure right now

This is also obviously / definitely not just a Pop!_OS 24.04 Alpha issue. I have installed some other Linux distros that run Wayland and CopyQ does not work on them either. Example:

I installed Zorin Educational into a QEMU virtual machine. This is the output of the command inxi --system --graphics --width 80

rstrom@zorin-educational:~$ inxi --system --graphics --width 80
System:
  Host: zorin-educational Kernel: 6.8.0-45-generic x86_64 bits: 64
    Desktop: GNOME 43.9 Distro: Zorin OS 17.2
Graphics:
  Device-1: Red Hat Virtio GPU driver: virtio-pci v: 1
  Display: wayland server: X.Org v: 1.22.1.1 with: Xwayland v: 22.1.1
    compositor: gnome-shell driver: X: loaded: modesetting unloaded: fbdev,vesa
    gpu: virtio-pci resolution: 1920x1080~60Hz
  OpenGL: renderer: llvmpipe (LLVM 15.0.7 256 bits)
    v: 4.5 Mesa 23.2.1-1ubuntu3.1~22.04.2

I can install CopyQ and it runs but it does zero copying and pasting. I have currently installed the Flatpak version. I have not yet tested the .deb version with the workaround. One issue with the Flatpak version is that I have no idea how to configure CopyQ to auto start or to start with the specific parameters mentioned in the workaround. I am not a fan of Flatpaks or Snaps.

On the Zorin install I see the same error as you do when I run CopyQ using the command line flatpak run com.github.hluk.copyq

rstrom@zorin-educational:~$ flatpak run com.github.hluk.copyq 
Warning: [default] QtWarning: QSocketNotifier: Can only be used with threads started with QThread
Warning: [qt.qpa.qgnomeplatform] QtWarning: Could not find color scheme  ""
Warning: [default] QtWarning: Activating Wayland clipboard took 5000 ms
ERROR: [default] QtCritical: Failed to activate Wayland clipboard

But while typing this I decided to try something. On Zorin, with the Flatpak version installed I tried using the command in the CopyQ Known Issues documentation linked above env QT_QPA_PLATFORM=xcb copyq and that did not work. I really did not expect it to. But then I tried a combination of that command and the Flatpak command to start CopyQ

env QT_QPA_PLATFORM=xcb flatpak run com.github.hluk.copyq

This command started CopyQ and copy and paste is working in the Zorin Flatpak installation. I will test with the .deb version later.

Summary ... Wayland is a royal PITA. It appears to be the future path forward but there are still so many issues. I am not a developer but ... Why are these so hard to get working?

HTH,

Robert

[cpsyctc2]

Hm. Totally agree about Wayland. Oddly enough it caused me nasty headaches when my last laptop arrived (the one that just died and caused some of this mess). That was Wayland and the then nVidia drivers for the machine. For months it also meant that many things only run at a usable pace if I turned off hardware acceleration. That was with the then new Ubuntu (22.04). I am now very jaundiced about Ubuntu and certainly about Wayland. Utterly bizarrely, I now have CopyQ running fine (OK on about 2 minutes testing) on one machine running U24 and not on the other and nothing I do seems to get the copying from the clipboard to work on the latter machine. I need to turn to other things for a few days so will let this stew for now. Many thanks for the very detailed update and let's hope whatever is causing all this gets sorted. Very best, Chris

[robertstrom]

So after playing with the Flatpak install on the Zorin VM I uninstalled the Flatpak CopyQ install (and told it to delete everything, not just the program) and installed the .deb version of CopyQ (the latest version 9) that was downloaded from the CopyQ GitHub site and it is just working! Crazy, crazy!! The backup on exit even worked. Still cannot get shortcuts to work (the one that is the most important - Show / Hide in particular). Some of the other items that I listed above as not working are not working, but not all.

The inconsistencies of what works and what does not are infuriating. It seems that Wayland implementations are not standardized on the various distros. Acckkkkkkkkkk!!!

Hopefully CopyQ developers are looking at these Wayland issues. If they are looking for testers I am game. I have CopyQ working fine on my main computers and have test systems that I can use to test various new builds.

[hluk]

Autostart is not supported in the Flatpak app itself. It needs to be configured in the desktop environment: #2517 (comment)

The program will not store the size and location as I have come to expect. It always opens up in the same place (not the last place where you placed it) and the same size (not the last size that you set it to).

This is interesting. At least in KDE and Sway window manager, the app can set window size at least. Generally, setting window positions on Wayland is not supported. There could a protocol to set window geometry supported by some Wayland compositors because e.g. krunner can position itself at top of the screen - but it does not get keyboard focus 🤦. But using these protocols is somewhat difficult to implement. I would prefer to wait until Qt itself supports it ...if ever. 😢

I somehow got used to all the Wayland issues and keep run the app in Sway window manager. From my POV, the annoying issues are:

• the windows open in the middle of the screen - not a big deal since at least the size can be set
• pasting does not work by just activating the item from CopyQ - need to do additional Ctrl+V
• global shortcuts need to be configured in the desktop environment itself

The inconsistencies of what works and what does not are infuriating. It seems that Wayland implementations are not standardized on the various distros.

Yeah, this is very annoying. For example, latest Gnome versions do not support access to the clipboard in inactive applications (this makes clipboard managers unusable). In other Wayland compositors there is a protocol to work around this (used by CopyQ), but it is not great.

[robertstrom]

So is there anything being done to standardize Wayland and to provide the capabilities of the likes of password managers and screenshot programs the access that they need? In macOS you have the ability to allow programs access to what they need to access. You are prompted and then need to specifically allow them (many times you need to authenticate with your credentials to do so). There needs to be a simple standardized method of doing this. It seems insane that this is something that the Wayland project has not worked out.

@hluk - It seems that your CopyQ is probably one of the most popular programs affected by these issues. Have you had any communication with the Wayland project about this?

[hluk]

So is there anything being done to standardize Wayland and to provide the capabilities of the likes of password managers and screenshot programs the access that they need?

The only thing that I can think of are the protocols: https://gitlab.freedesktop.org/wayland/wayland-protocols

The problem is that compositors/desktop-environments implement them inconsistently.

BTW, I tried using KWayland library to see it can set window position (specific protocol must be supported by the compositor), but could not get it working (at least on Sway).

In macOS you have the ability to allow programs access to what they need to access. You are prompted and then need to specifically allow them (many times you need to authenticate with your credentials to do so).

Yes, I would like that. If an app wants to access clipboard, ask me for a permission (once). I'm not sure how well it can be implemented since on Linux the apps are not signed, and I think there might be no safe way to identify a running app.

Have you had any communication with the Wayland project about this?

Nope, I haven't talked to anyone in the Wayland project.

[cpsyctc2]

As ever, so grateful to @hluk for this and for CopyQ. I am out of my depth with those technical details but if I can help with any debugging information I am more than happy to try. I may be of use as I am in the odd situation of having CopyQ working fine on one recently rebuilt Ubuntu 24.04.1 LTS where copyq -v reports:

CopyQ Clipboard Manager 7.1.0
Qt: 5.15.12
KNotifications: 5.115.0
Compiler: GCC
Arch: x86_64-little_endian-lp64
OS: Ubuntu 24.04.1 LTS

I do see warnings in the CopyQ log on that machine, mostly repeats of this:

Warning [2024-09-26 20:24:17.695] <Server-7747>: [default] QtWarning: �[31mQVariantMap DBusMenuExporterDBus::getProperties(int, const QStringList&) const�[0m: Condition failed: action

However, I have totally failed to get it to work on another machine also built recently (a week earlier than this one) also with Ubuntu 24.04.1 LTS. No installation I tried on that machine allows transfer of the clipboard contents to CopyQ. For the moment I have abandoned the fight with that machine as it's a fallback machine so I can (currently) live without CopyQ on it.

I run updates daily on both machines but still sometimes see differences between the OS or gnome on the two machines which baffle me and they do have different hardware (both Intel CPUs). I think I have purged all vestiges of CopyQ from the "bad" machine and am happy to try anything that might be helpful on that machine. Just tell me what to do if you think this might help! Very best both (and all), Chris

[hluk]

I do see warnings in the CopyQ log on that machine

That warning seems to be related to a DBus service running in the system (or possibly not running or misbehaving) or perhaps some problems with the Wayland protocols.

---

I think the easiest solution to work around most problems on Wayland is to set QT_QPA_PLATFORM=xcb environment variable when starting the app:

copyq exit  # close any running instance first
env QT_QPA_PLATFORM=xcb copyq --start-server

This will use some X11 compatibility layer (XWayland).

[cpsyctc2]

Been a bit overloaded with work, back again. I'm 99% sure I tried that on the machine where CopyQ fails to liaise with the clipboard and it made no difference but I am 1% sure. Before I start experimenting again, can you (@hluk) tell me which route to reinstall CopyQ on the machine you would prefer me to use from a debugging/exploring point of view. I am guessing it would be to put the /etc/apt pointer to your repository and then install with apt update and apt install copyq but I thought I should check. TIA, Chris

[hluk]

Installation instructions are in the documentation: https://copyq.readthedocs.io/en/latest/installation.html

I don't really have any other pointers how to resolve the Wayland issues.

[cpsyctc2]

I really appreciate, as ever, all your time on this. I can confirm that, with a clean install from the repository (as per docs!) and using
copyq exit # close any running instance first
env QT_QPA_PLATFORM=xcb copyq --start-server
CopyQ is now up and running on the other machine with import from and export to the clipboard there. Hooray!

Many thanks again, Chris

[hluk]

Glad it works now. I will close this since there is no action I can take now.