I'd like to second this but personally I think this is an area that could do with a much more generalized solution, rather than only one specific feature. Being able to have global shortcuts be conditional is a massive thing that, IMO, is missing. For instance you may not want a shortcut like alt+tab, meta+tab, etc. to be active when you're in a game window, so being able to say "only activate if I'm not in a fullscreen application" or "only activate if I'm not focussed on a window with this title" would be massively helpful. The global shortcuts system is incredibly useful but it's also quite limited in a lot of ways unfortunately. 

I imagine many of these restrictions are due to Wayland's security model and, while admirable in intent, it unfortunately means that a lot of logic is handled internally and thus can't be modified easily by the user. 

If I had to guess at the best "solution" to this that doesn't involve completely redoing the entire system, it might be enough to extend the existing window-rules system to be able to do things like alter global shortcuts, run a script when an application is focussed, run a script when an application is unfocussed, etc. The window rules system isn't super intuitive, but it's definitely learnable by the average user with a little time and it'd allow a good bit more flexibility. Strictly speaking even if only 4 new window rule behaviours were added, "activate shortcut when window opens", "activate shorcut when window closes", "activate shortcut when window is focussed" and "activate shortcut when window is closed" then all of this behaviour would be possible if someone wrote a script that altered ".config/kglobalshortcutsrc" and had shortcuts to run that script. (in practice you would probably want other rules to make things way eaiser, but I think that'd be a MVP that allows for context-dependent behaviour that's user-defined)

(In reply to BulletproofBears from comment #1)
> I'd like to second this but personally I think this is an area that could do
> with a much more generalized solution, rather than only one specific
> feature. 

Thanks for sharing this design proposal! Given the difference in scope and the age of the original report, a better place to discuss your proposal will be in the Visual Design Group chatroom, because this isn't really a discrete feature request . As such it would make more sense to discuss it in a group setting where existing design choices and constraints that may not be immediately obvious can be explained, and we can go over which elements of this proposal might make sense to integrate.

Check out https://community.kde.org/Get_Involved/Design.
Thanks for understanding!

(In reply to Alexander Nestorov from comment #0)
> IMHO there should be a global KMix shortcut that would let you
> increase/decrease the volume of the application that has the focus. That way
> I could increase/decrease the volume on a per-app basis, with my keyboard,
> instead of having to deal with the mouse, KMix's GUI, etc...

Is this something you are still interested in? If so, plesae set the Status to "Confirmed". Thanks!

🐛🧹 ⚠️ This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information, then set the bug status to REPORTED. If there is no change for at least 30 days, it will be automatically closed as RESOLVED WORKSFORME.

For more information about our bug triaging procedures, please read https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging.

Thank you for helping us make KDE software even better for everyone!

🐛🧹 This bug has been in NEEDSINFO status with no change for at least 30 days. Closing as RESOLVED WORKSFORME.