You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
In some installs, opening the main window may take an abnormal time in some circumstances. On my KDE Plasma session on Debian 13, the delay is between 1 and 2 s even on a fresh install.
To Reproduce
Ensure that the “Close When Unfocused“ general preference is enabled.
Open the main window
Indirectly close the main window, by unfocusing it. Several methods can achieve this, notably:
clicking in another application
pressing the Windows key (if that is set to open Kickoff or another application launcher).
Reopen the main window directly¹
Opening the tray menu does not trigger, and invoking “Show/hide main window” or "Show main window under mouse cursor" via the tray menu does not reproduce.
¹: Direct ways to open the main window are:
pressing a global keyboard shortcut for either “Show/hide main window” or "Show main window under mouse cursor"
clicking the tray icon
$ copyq show;
Expected behavior
The main window opens instantly.
Actual behavior
The main window displays after at least 1 s, but less than 2 s (probably "exactly" 1 s, but this is non-trivial to time, as $ copyq show; returns before the window displays).
Additional context
When this bug happens, I can reproduce it tens (presumably as many as I wish) of times in a row by simply clicking the tray icon, again, again and again. A direct opening of the main window reproduces if and only² if more than 2 conditions are met:
❓The install is affected.
Out of 2 CopyQ installs on Debian 13 I tested, only 1 PC is affected (see above info). Both use KDE Plasma.
None of the 2 CopyQ installs (1 on 15.0, the other on 16.0.0) on Windows 11 I tested reproduces.
The main window was indirectly closed (see above) at least once in the current execution of CopyQ.
The last time the main window was closed was either via unfocusing or via a primary click on the system tray icon.
The set of defects underlying this scenario certainly intersects with the set of those underlying issue The main window opens with a delay after a while #2877.
When this happens, nothing is journaled to CopyQ logs. When a delayed display occurs, the 2 errors mentioned in ticket #3632 are logged to the systemd journal. However, these must be red herring, as they are logged whether the display is delayed or not. systemd journals nothing more during reproduction.
²: I only experienced this on an install which I mostly “use” to debug CopyQ. The affected PC is the one I use the least, only a few hours per year. I only used that install for a few hours and it will take a while to validate if the above description stands the test of time or if it turns out insufficiently accurate and complete to represent this bug's subtlety.
License
This report (including all messages and attachments I add to it) is offered under the terms of CC0 1.0. This excludes the screencast, which was created by cmvizitiu.
Describe the bug
In some installs, opening the main window may take an abnormal time in some circumstances. On my KDE Plasma session on Debian 13, the delay is between 1 and 2 s even on a fresh install.
To Reproduce
Opening the tray menu does not trigger, and invoking “Show/hide main window” or "Show main window under mouse cursor" via the tray menu does not reproduce.
¹: Direct ways to open the main window are:
$ copyq show;Expected behavior
The main window opens instantly.
Actual behavior
The main window displays after at least 1 s, but less than 2 s (probably "exactly" 1 s, but this is non-trivial to time, as
$ copyq show;returns before the window displays).Screencast
https://github.com/user-attachments/assets/257f33e3-3516-42cf-9a86-60934e288a91 depicts a bug similar to this one, but probably not identical. Note that the screencast’s audio is in Opus format, which Firefox does not support. Chromium and VLC do.
Version, OS and Environment
CopyQ 16.0.0
Arch: x86_64-little_endian-lp64
Audio: miniaudio 0.11.25
Compiler: GCC
DISPLAY: :0
KGuiAddons: 6.27.0
KNotifications: 6.27.0
KStatusNotifierItem: 6.27.0
OS: Debian GNU/Linux 13 (trixie)
QCA: 2.3.10
Qt: 6.11.1
QtKeychain: 0.15.0
XDG_CURRENT_DESKTOP: KDE
XDG_SESSION_DESKTOP: KDE
XDG_SESSION_TYPE: x11
has-audio: 1
has-encryption: 1
has-global-shortcuts: 1
has-keychain: 1
has-mouse-selection: 1
Additional context
When this bug happens, I can reproduce it tens (presumably as many as I wish) of times in a row by simply clicking the tray icon, again, again and again. A direct opening of the main window reproduces if and only² if more than 2 conditions are met:
The set of defects underlying this scenario certainly intersects with the set of those underlying issue The main window opens with a delay after a while #2877.
When this happens, nothing is journaled to CopyQ logs. When a delayed display occurs, the 2 errors mentioned in ticket #3632 are logged to the
systemdjournal. However, these must be red herring, as they are logged whether the display is delayed or not.systemdjournals nothing more during reproduction.²: I only experienced this on an install which I mostly “use” to debug CopyQ. The affected PC is the one I use the least, only a few hours per year. I only used that install for a few hours and it will take a while to validate if the above description stands the test of time or if it turns out insufficiently accurate and complete to represent this bug's subtlety.
License
This report (including all messages and attachments I add to it) is offered under the terms of CC0 1.0. This excludes the screencast, which was created by cmvizitiu.