Bug 212837 - Title bar per-application volume buttons
Summary: Title bar per-application volume buttons
Status: RESOLVED INTENTIONAL
Alias: None
Product: kwin
Classification: Plasma
Component: general (show other bugs)
Version: 4.3.2
Platform: unspecified Unspecified
: NOR wishlist
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-11-03 01:23 UTC by KDE Brainstorm Submissions
Modified: 2009-11-03 08:56 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments
Mockup (72.83 KB, image/jpeg)
2009-11-03 01:24 UTC, KDE Brainstorm Submissions
Details

Note You need to log in before you can comment on or make changes to this bug.
Description KDE Brainstorm Submissions 2009-11-03 01:23:52 UTC
Version:            (using KDE 4.3.2)
Installed from:    I Don't Know

My idea is similar to idea 41951 (http://forum.kde.org/brainstorm.php#idea41951), but with a different presentation method.

In windows per-application volume settings are controlled from the volume settings. The KDE equivalent would be putting these settings in kMix like idea 41951. I would however prefer to have per-application volume controls close by (as I often mute single applications), and I think the title bar of an application would be the ideal place to put it.

See attachment for mockup

Additionaly it would be nice if this button would automatically hide/be grayed out if an application doesn't use sound.

Advantages:
+ Volume controls right where you need them
+ It's easy to see when an application is muted. In windows I often forget I muted my web browser and afterwards I'm wondering why there's no sound
+ Not much clutter if the auto-hide of the button is implemented

Disadvantages:
- Yet another button on the title bar, but it could be hidden by users who don't want it (much like the "show on all desktops" button which I find less useful than this)



This feature request was originally submitted through KDE Brainstorm, and has been submitted to Bugzilla due to popular demand. Original idea: http://forum.kde.org/brainstorm.php?mode=idea&i=82868
Comment 1 KDE Brainstorm Submissions 2009-11-03 01:24:11 UTC
Created attachment 38044 [details]
Mockup
Comment 2 Martin Flöser 2009-11-03 08:56:39 UTC
I'm sorry to say, but this wish cannot be implemented. That has various reasons:
 * kwin handles windows, not applications. An application may have none, one or more windows. In general kwin does not know which window belongs to which application. There is an optional field in the EMWH specification which tells kwin which process belongs to a window. We cannot rely on this optional information.
 * Sound is handled per application basis, having it in the window would make it look like a per window basis. Just imagine you are in the test sound configuration dialog in Amarok. What should be muted? The main application or just the test sound? Another example: two firefox windows each running a youtube video and you want to mute one to listen to the other. You would expect that one get's muted and not both.
 * Getting the mixer in the titlebar would require ugly hacks like XEmbedd. It is very unlikely that we would again start using XEmbedd after getting rid of it in the systray.
 * How should kwin know the volume level? The applications would have to expose an interface (e.g. DBus) so it would only work for applications which provide this information. While this can easily be added to all KDE application, other applications like Firefox or Skype won't be adjusted.
 * We try to remove clutter from the titlebar. This would add clutter
 * Controlling audio is the task of the application. If the application is not providing an easy to use volume then it is an application bug and has to be fixed in the application. Kwin does not work around application bugs
 * Adding this would require as to add many more "features" to the titlebar.
 * Compiz is using our titlebars. We would "force" them to implement it as well.

So alltogether this may be a nice idea but it is definately not the task of the window manager. Let's keep kwin being a window and compositing manager. Application tasks belong to the application. Sorry that I close this wishlist but it's the most honest thing I can do: we would not implement this feature and probably reject patches adding this feature.