Bug 206724

Reproducible in 3.6 alpha2.
Qt: 4.6.0
KDE: 4.3.80 (KDE 4.3.80 (KDE 4.4 Beta1)) "release 9"
KMix: 3.6-alpha2

This could get very complicated. Popups "swallow" all keystrokes, even global keys. I would have to "forward" those keystrokes to the "appropriate" Object. 

Quite likely tough, and I won't promise to tackle this soon. Any help is appreciated here.

Reproducible in kde 4.5.2

Work notice: Interestingly I do not receive ANY key presses when the popup is there (at least xev does not report any). I could try to install an eventFilter() in the ViewDockAreaPopup and see what I receive there.

I notice this bug still in KDE 4.10. I do not use pulseaudio.

bug CONFIRMED for 4.11 beta2.

eagerly waiting for a plasma kmix systray applet..

We are getting closer. I found the following in the documentation of void QWidget::keyPressEvent() :

The default implementation closes popup widgets if the user presses Esc. Otherwise the event is ignored, so that the widget's parent can interpret it.

So key presses are passed to the "parent", but there is no parent, so KMix simply does not see ANY key presses.

And also:

A widget must call setFocusPolicy() to accept focus initially and have focus in order to receive a key press event.

If you reimplement this handler, it is very important that you call the base class implementation if you do not act upon the key.

I have tried now a lot:

	setFocusPolicy(Qt::StrongFocus);
	setFocus(Qt::TabFocusReason);
	releaseKeyboard();
        focusNextChild();

But whatever I do, I do not receive keyboard events from Qt. The best I could do with lots of hacks is to get the keyboard events after a mouse-click in the popup. But the solution is not what is requested and also so hacky that I do likely will not try to pursue on that road. Likely this bug will be closed with a WONTFIX because it looks impossible to do.

(In reply to josephk from comment #6)
> bug CONFIRMED for 4.11 beta2.
> 
> eagerly waiting for a plasma kmix systray applet..

@josephk You should not eagerly wait for it, as there is nobody working on it and no plans to do so.
OK, this is not entirely true. There is work on https://git.reviewboard.kde.org/r/112208/ , but I am not yet sure whether Diego Casella considers it ready.

Continuing documentation what I tried:

Implement the following "event handlers", but they do not show any signs of key presses:
    keyPressEvent()
    x11Event()
    eventFilter()

	setFocusPolicy(Qt::StrongFocus);
	mainWindowButton->setFocusPolicy(Qt::StrongFocus);
	setFocus(Qt::TabFocusReason);
	releaseKeyboard();
        focusNextChild();

Git commit 2bd1c4cb5d8689c2be9a6761ee5e647afcd5c1fe by Christian Esken.
Committed on 12/08/2014 at 21:13.
Pushed by esken into branch 'master'.

Lazy intialziation for MatchAllForSoundMenu, to avoid a static
initializer ordering problem in the next commits.
Also document what was tried to fix bug 206724.

M  +32   -3    gui/viewdockareapopup.cpp
M  +1    -1    gui/viewdockareapopup.h

http://commits.kde.org/kmix/2bd1c4cb5d8689c2be9a6761ee5e647afcd5c1fe

Unfortunately I do not see any way to get this fixed. Thus I will not fix it.

As a side note, I personally do not see this as too relevant, as there is usually no need to click the tray icon if you want to use the keyboard. Just use the volume shortcuts that are present on nearly every keyboard nowadays. Should you disagree, then please find a way too fix it and let me know for integrating a fix.

Git commit 1658f1585b0a8dc292a583db11e74ca1c2bf0dbe by Jonathan Marten.
Committed on 04/10/2020 at 10:13.
Pushed by marten into branch 'master'.

Handle key events on the system tray popup volume control

It may not have been possible before, but with current Qt5 it seems
to be possible if the focus is set appropriately.  Since the popup
is enclosed in a menu all keystrokes are received, so the global
volume/mute shortcuts also need to be recognised and handled.

M  +99   -23   gui/viewdockareapopup.cpp
M  +6    -3    gui/viewdockareapopup.h

https://invent.kde.org/multimedia/kmix/commit/1658f1585b0a8dc292a583db11e74ca1c2bf0dbe