Bug 206724 - volume control shortcuts not working when kmix applet is open
Summary: volume control shortcuts not working when kmix applet is open
Status: RESOLVED INTENTIONAL
Alias: None
Product: kmix
Classification: Applications
Component: general (show other bugs)
Version: 3.7
Platform: openSUSE Linux
: NOR normal
Target Milestone: ---
Assignee: Christian Esken
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-09-08 10:34 UTC by Ruchir Brahmbhatt
Modified: 2020-10-04 10:23 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ruchir Brahmbhatt 2009-09-08 10:34:35 UTC
Version:           3.5 (using KDE 4.3.1)
Installed from:    SuSE RPMs

Steps to reproduce:
1. Click kmix icon in systray.
2. Push volume up/down keys on laptop.

Expected results:
Volume should be changed.

Actual results:
No effect

More info:
When main mixer window is opened by clicking mixer button in volume control applet, in that case it works but when volume control applet is open, volume doesn't change on key press.
Comment 1 Ruchir Brahmbhatt 2009-12-06 14:50:46 UTC
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
Comment 2 Christian Esken 2010-05-19 17:36:46 UTC
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.
Comment 3 Ruchir Brahmbhatt 2010-10-16 14:49:43 UTC
Reproducible in kde 4.5.2
Comment 4 Christian Esken 2012-10-04 00:50:06 UTC
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.
Comment 5 rockonthemoonfm 2013-02-20 13:59:25 UTC
I notice this bug still in KDE 4.10. I do not use pulseaudio.
Comment 6 rockonthemoonfm 2013-07-11 12:44:17 UTC
bug CONFIRMED for 4.11 beta2.

eagerly waiting for a plasma kmix systray applet..
Comment 7 Christian Esken 2014-08-12 10:27:03 UTC
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.
Comment 8 Christian Esken 2014-08-12 11:07:50 UTC
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.
Comment 9 Christian Esken 2014-08-12 11:15:24 UTC
(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.
Comment 10 Christian Esken 2014-08-12 12:43:48 UTC
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();
Comment 11 Christian Esken 2014-08-12 21:13:22 UTC
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
Comment 12 Christian Esken 2014-08-12 21:18:56 UTC
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.
Comment 13 Jonathan Marten 2020-10-04 10:23:40 UTC
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