KDE and Ubuntu SoundMenu

[Marco Martin]

On Fri, May 28, 2010 at 7:59 PM, Aaron J. Seigo <aseigo at kde.org> wrote:
> let the cross posting begin! ;)
> [...]
>
> 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?

I think what we need is extra keys that are dependant on the item
category, for instance a multimedia statusnotifier would have an mpris
path property, a communication one the unread message count and things
like that.
now i'm not sure how to make a clean api to rflect that, i think
adding those properties to all elements is not pretty.
one possibility would be to add a single type specific property that
would contain everything encoded in, like
"mpris=org.mpris.amarok;volume=30;whatever=foo" or instead exporting
the path of another object on dbus that would contain only the needed
properties

> 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

Helio's work on kmix splitting will be very useful there i think

> 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".

or, the core part of nowplaying could become a little workspace
library like libplasmaclock

> * 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?
> :)

exactly, it's something that we can't load ourselves with right now.
i would be glad to help tough

> 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." ;)

I think here they are referring to the messaging indicator.
but that particular piece is a quite unfortunate example of how not do
things, lack of communication caused a quite ugly duplication of
effort.
luckily, i think both communities came a long way since then, so i
hope we will be able to come up with something
-agreed among everybody at protocol level
-that uses existing technology as much as possible
-agreed between KDE and Kubuntu at ui level
-if The GNOME version will be different at UI level is just fine,
exploring different visual paradigms as long as it's on _the same
model and protocols_ is not a bad thing at all

I hope work on this could also  pose the basis on a future rework of
the messaging part in a way that can be agreed upon.

>
> 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.

yes, that form of communication concerns me too quite a bit, FOSS
community is too small already to afford such kind of divisions.

Cheers,
Marco Martin