SUMMARY Windows 11 Home version 26.03.70, which is not in the bug report tool's pull-down. If I double-click on a PDF file in Windows Explorer it opens it in Okular but not in a new tab. It opens it in a new window. I have set Okular to "open in new tabs" is true. Opening files within Okular works correctly. Is there a way to set this up so it works or a way to change the windows functionality so it sends a parameter that works via a .bat file or something? STEPS TO REPRODUCE 1. Set your settings to open new files in new tabs. This is not the default. 2. Double click on a PDF file in Windows Explorer. OBSERVED RESULT Opened in a new Okular window. EXPECTED RESULT Opened in a new Tab in Okular SOFTWARE/OS VERSIONS Windows: 11
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.