On Fri, May 28, 2010 at 7:59 PM, Aaron J. Seigo 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 _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel