Bug 250355

Summary: Volume control with system tray icon does not work when application is minimized or loses focus
Product: [Applications] juk Reporter: Brian <blist>
Component: generalAssignee: Scott Wheeler <wheeler>
Status: RESOLVED FIXED    
Severity: normal CC: mpyne
Priority: NOR    
Version First Reported In: 3.5 (KDE 4.5)   
Target Milestone: ---   
Platform: Unlisted Binaries   
OS: Linux   
Latest Commit: https://commits.kde.org/juk/e2012e79359854f0ad73769bd02f092e44f40cf4 Version Fixed/Implemented In: 18.08.3
Sentry Crash Report:

Description Brian 2010-09-06 13:20:13 UTC 
Version:           3.5 (KDE 4.5) (using KDE 4.5.0) 
OS:                Linux

Shift-mousewheel over the system tray icon is supposed to change the volume level in Juk.  When the application is maximized and has focus, this work correctly.  When the application loses focus or is minimized to the system tray, this function does not work. Instead, shift-mousewheel gives the same behavior as mousewheel; the next song in the playlist is selected.

Reproducible: Always

Steps to Reproduce:
Start Juk
Minimize to system tray
While holding Shift, roll mousewheel over the system tray icon

Actual Results:  
Song changes to next song in playlist

Expected Results:  
Volume level should change

Specifically, I am on version 4.5.1 of PCLinuxOS.

This problem has been confirmed by multiple PCLOS users.

It has been reported that the behavior under PCLOS-gnome is as expected but I can not confirm.
Comment 1 Michael Pyne 2010-09-06 17:55:49 UTC 
Perhaps a systray bug? In KDE Platform 4.5 JuK doesn't actually control the systray icon message handling.

The problem seems to be that Qt's QCoreApplication::keyboardModifiers() method only reflects events that make it to the JuK input queue. Pressing Shift when JuK is not already focused means the Qt library in the JuK process doesn't know that Shift is being held down.

I need to find a way to reflect the actual position of Shift instead of the indicated-by-Qt position.
Comment 2 Brian 2010-09-06 23:37:45 UTC 
Perhaps a short term workaround would be to make the systray behavior a user option?  For me, volume control is more frequently relevant than changing songs, particularly since a right click on the icon can get me playlist control but does not get me volume control
Comment 3 Michael Pyne 2018-10-20 02:52:34 UTC 
Git commit e2012e79359854f0ad73769bd02f092e44f40cf4 by Michael Pyne.
Committed on 20/10/2018 at 02:40.
Pushed by mpyne into branch 'Applications/18.08'.

systray: Make SHIFT+Mousewheel change the volume, not the song.

This fixes a bug that recently hit its 8 year anniversary. :(

The big issue was that there was no easy way to tell which keyboard
modifiers were set for the systray since Qt's event loop didn't actually
receive the keyboard events.

There's a separate function you can call, queryKeyboardModifiers, which
makes a specific query to the desktop, and works even if Qt event loop
didn't receive keyboard events. This fixes the bug here, and hopefully
for everyone else.

In fixing the bug I noticed that we can set out-of-bounds volumes due to
lack of checking, so I fixed that too.
FIXED-IN:18.08.3

M  +5    -2    playermanager.cpp
M  +1    -1    systemtray.cpp

https://commits.kde.org/juk/e2012e79359854f0ad73769bd02f092e44f40cf4