KDE and Ubuntu SoundMenu

Fri May 28 18:59:55 BST 2010

let the cross posting begin! ;)

On May 27, 2010, Harald Sitter wrote:
> At the recently held KDE Multimedia + Edu sprint in Switzerland we came to
> discuss the new concept of a soundmenu, as described at [1].

it's excellent to hear that the dev sprint is paying off, as they always seem 
to do! :)

> [1] https://wiki.kubuntu.org/SoundMenu

personally, i think the idea is a fine one. it essentially merges the Now 
Playing applet with the sound control application (kmix, in the case of KDE).

the details of what features to support for the audio app, i'll leave up to 
the audio app devs (e.g. amarok, et al), but from the Plasma perspective:

one thing that jumps out at me about this page is that it goes into a lot of 
detail about visual design. this is fine for a specific final implementation 
(e.g. a gnome-panel applet or a Plasmoid), but it would be helpful to us as 
implementors / adopters if such visual design information was separated from 
representation and mechanics (such as the dbus API parts) and if the 
visualization details were further divided into "expectations audio players 
can rely on" (such as having play/pause, next and prev controls, and with no 
assertion that they are buttons ..) and implementation specific notes such as 
font faces and sizes or that the play/pause control is a button with a 
specific icon.

this will allow us to:

* implement the mechanism separately and ensure cross-environment compliance 
by having a clearly defined target to work towards to be able to test against

* provide a UI that meets the set of contracted requirements audio players 
require

* be flexible in implementation specific representation without having to 
compromise spec compliance

* be able to continue to adapt our visual design over the coming years without 
feeling compelled to revise or abandon the functional aspects of the spec

i like the idea of using Status Notifiers paired with mpris for this as it 
obviates the need for too much new specification and application 
implementation. it also increases the odds of adoption, while providing a "for 
free" fallback: when there isn't a sound menu implementation around, then the 
system tray icon (or however the status notifier is being visualized), the 
status notifier can be shown.

this does have an interesting implication for the status notifier spec, 
however: we will need some extra information about the notifier to decide what 
to do with it. essentially, we will require the ability to go from "here is a 
notifier item" to "and it has an mpris interface, and we have a sound menu, so 
integrate it into the sound menu instead".

one (perhaps overly simplistic?) idea would be to add an optional "extra 
hints" mapping to the status notifier spec. this would be used to transport 
things like "mpris" => "org.mpris.amarok", as well as similar future 
expansions of visualization handling based on hints. status notifier items 
would not be required to provide any such hints, and visualizations would be 
free to do with them as they would like to. we would need to keep a catalog of 
well-known keys (e.g. "mpris") in the spec, however, to ensure consistency. 
thoughts?

on the KDE implementation side: we already have DataEngines for both status 
notifier items and mpris (part of the "now playing" engine) that ship as part 
of the default KDE Plasma workspace bundle. what would be needed is:

* writing a Plasmoid that combines the current kmix notifier item (basically, 
the volume controller and a sensible context menu) with elements from the Now 
Playing Plasmoid. kmix's full mixer window could remain a stand alone app 
called from the plasmoid when needed. an alternative would be to take the Now 
Playing Plasmoid and add audio level controls to it, esentially turning it 
into the "Sound Menu". 

* add te resulting Plasmoid to the default system tray Plasmoid set (along 
with Battery, Notifications, etc); this is a one-liner, so is more of a detail 
than anything else.

is there anyone in Amarok, Ayatana, Kubuntu, $OTHER_PROJECT_COMMUNITY who 
would be willing to step up and take on the work to realize the Plasmoid? that 
would greatly help ensure adoption. the Plasma team would be happy to support 
the effort, so you wouldn't be "all on your own", but we're already fairly 
strapped for manpower with what is already on our plates (what's new, right? 
:)

p.s. can we please stop calling status notifiers "app indicators" in technical 
documentation? (as opposed to user communication or marketing, which is rather 
separate.) we already have a name for them that makes perfect sense for 
technical reasons, and it would be nice to keep technical discussion 
consistent and clear to maximize effectivity.

p.p.s. since when were "app indicators" an invention of Ted Gould? nothing 
against Ted himself and certainly the work on app indicators has improved what 
it is built on, but unless the goal is to continue to create social strain and 
channel conflict (and i can't imagine that it is), Canonical and its community 
may do well to consider how both attribution and downstream code forks are 
handled. it's an ongoing issue that creates bariers which are unecessary, 
unhelpful and avoidable .. and which i personally run into too often. (a 
polite way of saying: "You all are helping create problems that I end up 
having to deal with." ;)

before anyone gets defensive about it, i understand it's likely often 
completely unintentional or even a result of "pragmatism forced our hand". and 
please understand that i'm just a messenger here, observing what is quite 
evidently a common result in the broader F/OSS community due to how things are 
currently (and historically) handled.

as a concrete and constructive suggestion, saying things like, "We would like 
to provide a unified music player experience on the Ubuntu platform therefore 
we strongly urge application developers to follow this spec." gives the 
impression that the idea is that app devs should be targetting Ubuntu and 
meshing with Ubuntu as the target platform, with the underlying implication of 
"who cares about anything else f/oss out there". (those are very Redmonian or 
Cupertonian sorts of lines, so the innevitable reactions are to be expected 
... ) maybe something like, ""We would like to provide a unified music player 
experience in Ubuntu, and therefore we strongly urge the F/OSS desktop 
community to embrace this spec so that we can achieve that goal." would help 
us all get closer to the shared goals we have quicker and with less gnashing 
of teeth.

that may seem like "twiddling the words", but as someone who has been somewhat 
successful in helping achieve adoption of a number of shared technologies over 
the years (as well as having failed at times!), i can only say that it really 
matters. whether it "should" or not is pretty irrelevant; that's like arguing 
whether or not gravity is a good idea since it gets in the way of humanity's 
dream of flying. ;) it is how it is, it's not worth trying to "fix" since we 
can work with it quite effectively.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : https://lists.ubuntu.com/archives/kubuntu-devel/attachments/20100528/1cc18e47/attachment.pgp 