Show Main Window hotkey opens File menu

[LaserMoai]

This makes looking up words with it less convenient.

GoldenDict 1.5.0RC2
Arch Linux w/ Xfce

[hsantanna]

Confirmed.

Tested with hotkey "Ctrl+alt+c+c".

The main window will open with the File menu opened too.

GoldenDict 1.5.0-RC2
Chakra Linux / KDE Plasma 5.8.4

[ghost]

Confirmed, in another Arch (Fluxbox) with GoldenDict 1.5.0RC2 and Qt 5.7.1.

[kyawthusoe45]

Confirmed, Arch KDE.

[kyawthusoe45]

This is specific to Arch, may be.

[MichailBachtin]

Anyway to get this to work on Windows7?

There should be an option to open the main window with a highlight + hot-key search.
The main window has the "found in dictionaries" list on the right, which makes it easier to choose quickly a specific source after the search.

Alternatively, is there an option to include the "Found in Dictionaries" sidebar to the popup window?

One or the other would be a great option!

[LaserMoai]

@MichailBachtin Why on Earth would you post this here especially if you've already made a #802 ticket for this? This achieves nothing but confusion.

[usermjs]

A workaround for this issue is to uncheck the menu bar under the View menu.

[kyawthusoe45]

@usermjs
You don't say.

[LaserMoai]

That is a great contribution compared to sarcasm that is 2 months late.

[Dan-cer]

I have this issue on one of my computers, both running latest Ubuntu 18.10. Same preferences at both of them, one is working well, the other is showing file menu when it opens for translate-results.

the workaround from usermjs is fine to solve this until it is fixed.

[vedgy]

I disabled the workaround responsible for this bug in this branch. I haven't created a pull request based on this branch because it causes a regression.
If you want to help fix this bug in goldendict master, please read the commit message in my branch, then test the described scenarios in builds based on this branch and on goldendict master.

I suspect that the bug and the regression caused by my fix could depend on window manager focus settings, but I haven't tested this. If you find such dependencies, please describe them in comments.
If no simple configuration adjustment eliminates the regression, then the X11 code might have to be fixed instead of disabled. Alternatively, a different focus grabbing workaround could be implemented.

Note: my system is the Xfce edition of Manjaro (stable branch with latest updates, which is not far behind Arch Linux).

[vedgy]

The disabled X11 workaround makes the system believe that the user manually clicked on the top-left pixel of the main Goldendict window. This hack steals focus from other applications reliably, but it also performs this click at the position belonging to the File menu in the default KDE Plasma style.

Without the X11 workaround, when KDE's Focus stealing prevention level is set to Low (which is the default) or higher, launching a second Goldendict instance doesn't give focus to the already running instance unless it is hidden into system tray or minimized. I tried hiding, then showing the main window, and it works, but makes the window flicker, so isn't a proper solution. Suggesting Goldendict users to set their focus stealing prevention level to None also doesn't seem right.

As an alternative to the X11 hack, I tried to find a proper way to activate and focus the first instance of Goldendict when the second instance is launched. Freedesktop.org's window manager specification suggests that the secondary instance should activate the primary one instead of sending a message to it (as Goldendict does now):

the Window Manager may be e.g. more likely to obey the request if it will mean transferring focus from one active window to another

This seems to be a proper cross-platform approach. Microsoft recommends the same here:

The easiest way is simply to have the second instance make the call to SetForegroundWindow. The second program has permission to take the foreground because you just launched it. And if a program can take the foreground, it can also give it away, in this case, by setting the first program as the foreground window.

Unfortunately I couldn't find such activation mechanism in Qt API. QtSingleApplication implements a simple message-based activation mechanism, similar to what Goldendict does now.

The KDE way

I tested KDE's systemsettings5 unique/single application: launching a second instance of it activates and focuses the primary instance with any focus stealing prevention level. KDBusAddons documentation states:

In Unique mode, only one instance of this application can ever run. The first instance of the application registers with D-Bus without the PID, and any attempt to run the application again will cause the activateRequested() signal to be emitted in the already-running instance; the duplicate instance will then quit.

KDBusService::activateRequested()'s documentation recommends the primary instance to call KWindowSystem::forceActiveWindow() in the slot connected to this signal. Goldendict can not use this implementation directly because it does not depend on KDE Frameworks. But perhaps it could implement it with direct XCB calls in KWindowSystem's way. This kind of implementation probably does not belong to application-level code though, so I hope there is a more appropriate way to implement primary instance activation.

Any ideas?

[vedgy]

KWin requires applications that want to get focus properly to depend on KIO (a tier 3 KDE framework with complex dependencies) or to implement X11 startup notifications support, which is not particularly easy. See comments to my KWin bug report. So most apps do neither and don't get focus in Plasma unless focus stealing prevention level is set to None. Goldendict does get focus with levels lower than High thanks to the workaround, which causes this File menu bug. A conclusion: Goldendict users will have to stick with the hiding-main-menu workaround until a proper implementation becomes easier or a volunteer implements startup notifications support the hard way.

[drgibbon]

I also have this problem on KDE Plasma 5.183, Qt 5.13.2 (Slackware -current). I'm running the latest version of goldendict from git 6ca112b797e70774d252b3635d41b4c5d38ea9dd.

[dontdieych]

Confirmed, Manjaro, Plasma 5.19

goldendict 1.5.0RC2-9
hunspell 1.7.0-3
libxtst 1.2.3-4
libzip 1.6.1-2
libao 1.2.2-3
qt5-webkit 5.212.0alpha4-6
qt5-svg 5.15.0-1
qt5-x11extras 5.15.0-1
qt5-tools 5.15.0-2
phonon-qt5 4.11.1-2
ffmpeg 2:4.2.4-1
plasma-desktop 5.19.3-1

[Knusper]

Unfortunately I don't understand much of the above, but I have the same issue on debian buster, but the workaround with disabling the menu bar works for me.

[rr-info]

The disabled X11 workaround makes the system believe that the user manually clicked on the top-left pixel of the main Goldendict window. This hack steals focus from other applications reliably, but it also performs this click at the position belonging to the File menu in the default KDE Plasma style.

Any ideas?

Several:

1. Emulate the same click but 40 pixels below (1x40) that point
2. Emulate a click in the middle of the window's title (is that even possible?)
3. Use an entirely separate program to launch the main window.
4. Add a configuration option (which disables this feature)
5. move the menu somewhere else? I know it's not easy at all. If the menu starts 2 pixles from the left, then why not?

Regarding your post:

1. Thank you! you did a really thorough and difficult research. I know how hard it is.
2. You mentions test build. Are there any pre-compiled binaries I could use?

[vedgy]

Comments on the ideas:

1. That could easily trigger some other unwanted action in a different Qt style.
2. The current code uses coordinates x=1, y=1, and the click ends up in the main menu. So if emulating a click on the window's title (higher) is possible, it would likely have to be implemented differently. And it could still cause trouble, e.g. when there is no window title in a Qt style.
3. Not sure what you mean by a "separate program". If another program is launched, it would still have to pass X11 startup notification info to the primary GoldenDict instance. If you mean restarting GoldenDict, that would be rather slow, inefficient and lose the current app state.
4. This can be done as a workaround. The simplest approach to implement is via an environment variable. Would this be good enough for a workaround?
5. This is another workaround, and is already possible for each user: pick a different window style in system settings to add a couple of pixels margin to the top or to the left of the main menu. There is such margin by default in most window managers. Doing this in GoldenDict's code is probably not easy and risky, considering the number of different window managers.

No, I don't compile binaries. If you build GoldenDict from source, you can merge the referenced branch and compile with it.

[zhea55]

@LaserMoai

I fixed this problem.

Simplily click view -> MenuBar, uncheck it.

[herberteuler]

I am on KDE. I found another solution to this issue was to switch to the Fusion application style.

[xiaoyifang]

I think this is a regression from #235

[vedgy]

I think this is a regression from #235

The fix for #235 actually limited the workaround that causes this issue, so it is not responsible for this regression. Apparently window styles that placed the main menu at position (1, 1) weren't popular 9 years ago, so no one noticed the issue back then.

I think that requiring users to apply the workaround of hiding the menu bar is preferable to not giving the activated GoldenDict window focus. So until someone implements proper startup notification support, this bug will remain open.