https://bugs.kde.org/show_bug.cgi?id=514631
--- Comment #1 from Scott <[email protected]> --- Here's what Gemini AI told me about this: The behavior you're seeing is a documented architectural issue in the Windows port. The Technical Root Cause Okular relies on KDBusService (a KDE wrapper for D-Bus) to handle single-instance logic. Here is how it's designed to work: 1. When you launch Okular with --unique, it tries to register a "well-known name" on the D-Bus session bus. 2. If the name is already taken, it sends the file path to the existing instance via D-Bus and exits. 3. The Windows Problem: On Linux, D-Bus is a system standard. On Windows, Okular has to bundle a minimal D-Bus daemon. Because of how the Windows port is packaged, the second instance often fails to connect to the "bus" created by the first instance, or the daemon is simply not compiled to allow session-wide discovery in the same way. Can it be fixed? The logic to handle this is in Okular's shell/main.cpp. To fix it for Windows, the code would likely need to be modified to use a native Windows mechanism (like a Named Pipe, MailSlot, or a Hidden Window with WM_COPYDATA) instead of D-Bus when running on Q_OS_WIN. Currently, the source code shows that if D-Bus fails or is unavailable, Okular just falls back to being a "normal" application, which results in a new window. Summary: Yes, Okular's code would need a Windows-specific patch to handle single-instance discovery without a functioning D-Bus daemon. There is no configuration setting or registry hack that can bridge this gap because the inter-process communication (IPC) channel itself is broken on the Windows port. -- You are receiving this mail because: You are the assignee for the bug.
