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 .
it's excellent to hear that the dev sprint is paying off, as they always seem
>  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
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
* 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.
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
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
kubuntu-devel mailing list
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel