On Thu, May 27, 2010 at 9:48 PM, Harald Sitter <sitter.har...@gmail.com> wrote: > Hello! > > At the recently held KDE Multimedia + Edu sprint in Switzerland we came to > discuss the new concept of a soundmenu, as described at [1]. > > The general consensus was that the present KDE MM developers do think the idea > of having a central place to control all sound related informations and > operations is a very good one, and something we could very well want to have > implemented upstream instead having a Kubuntu specific version. Especially > since this would also imply doing enhancements to existing specifications that > are already used in KDE software.
a great idea i think. > We are at this point however not sure that the same UI representation proposed > for Ubuntu should be applied as-is to KDE software. So it is very much desired > to get discussion going with regards to the API and how to implement it in KDE > software. i think the ui is almost secondary now, what we need is a good api and decide how the architecture will be. some immediate points i can think about are: - how this is positioned against statusnotifieritem? -do we need a multimedia category for it, since one of the things it will do is grouping multimedia related icons? - how it will use other protocols? - i suppose the media player control will use mpris - the mixer will use dbus over a mixer app? iirc kmix is being splitted in a client and server partr, right? so in brief, what more we need compared to a combination of StatusNotifierItem, Mpris abd a mixer interface? have they to be extended? what i really want to avoid is a brand new protocol just for that, that will just add complexity and slimmer chances of adoption (yes, i'm looking at the ubuntu messaging menu, i still think it can be done with some extension to StatusNotifierItem) Cheers, Marco Martin _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
