Tray context menu breaks input, requiring mouse click to restore

[nick87720z]

This problem affects all gui, including tray icon.

After tray context menu is opened, it will close by click outside, but all following mouse and keyboard input is ignored. For keyboard - impossible to change focus or input to text fields, for mouse - heh, even cursor doesn't change between text/pointer forms when moved in/out of text entry field.

To restore input, mouse click by any button is required at any gui part. Scroll events (mouse buttons 4/5) don't work just like keyboard.

Edit (landed to enter early): after input is restored, keyboard focus change is still broken, although after some magick clicks sequence it is ok too. Tried live version as well, besides recent release.

[rncbc]

may I ask what desktop environment is that ? is it Gnome or is it on top to Wayland ? if so, please rid yourself in relying on the system-tray icon (and menu) on those systems: it doesn't work well if at all. sorry :)

[nick87720z]

Yes, it is xfce, with xfce4-panel's systray implementation. Got same problem with qsynth, but e.g. clementine and keepassxc are not affected.

[nick87720z]

I got it fixed for self with change, which in fact just reverts commits 93905827ca103b37ca0c88343a695bcc7f52244f and 503bd2089af81f63f8e46d0e51947c265f7ae9c6, although I did not touch header yet (not removed QMenu m_menu).

Another way - probably, to find better place for m_menu.hide(). My wild guess - doing it from QMenu::aboutToShow signal handler is pointless, as menu is probably not shown yet (it is about_to_show).

Looks like those two commits are related to version 0.4.6. Latest packaged version in gentoo is 0.4.5, probably due to this bug. What was before those two commits?

Edit: in PR #63

[rncbc]

a2d0415 might have nailed it

please test && tell thanks a lot cheers

[nick87720z]

Oops, text below should go here, not to #64

Here it is. I tried example on top of qsystray example from qt reference. Just removed everything irrelevant (though left icon hide/show option), added dialog context handler, showing same menu as assigned to systray, and additionally tested, how menu changes are handled by systray. Both xfce and mate panels are ok. I only need yet to get to other pc with xfce. qt-tray-menu-dynamic.zip

In my example is one menu object, assigned to systray. For window context menu same systray-dedicated menu object is exec'ed, no need to create new.

Edit: also I tested, how actions are added/removed from existing menu.

[nick87720z]

I tested my test with plasma5 (I meaned it, not xfce). All ok, but if tray icon is disabled and then again enabled, tray menu is empty. Not case for both xfce/mate trays. And not case for qjackctl - it doesn't show icon before restart.

About qjackctl - tray menu doesn't appear if icon is hidden. I'm not sure, is it different for plasma5, but at least I did not have such problem with my test.

Edit: qjackctl icon doesn't appear if enabled before restart, but program behaves as if it is enabled, and hides window if closed, without shutdown.

Edit2: More exactly, I have qjackctl starting with hidden main window. First time menu will be opened anyway, even if window is hidden. But next - only with visible window (with recent refactoring).

[nick87720z]

I could reproduce new systray menu bug in minimal test by inventing menu generation way as used in qjackctl - i.e. binding both main window anad systray context requests to callback that refills menu, owned by window, and exec it. The only difference in my case, I did not subclass systray to add signal for that, instead calling contextMenu() right from systray activated() handler. In my test menu stops to appear from systray even if window is not hidden (but still appears from dialog window), but also appearing at least once even from systray. qt-tray-menu-dynamic-2.zip

Btw, previous zip-ball is really rar - I switched format in wrong place (file selection type filter instead of archive type).

[nick87720z]

At recent commit problem disappeared, thanks.