== App Developer Week -- Integrating music applications with the Sound Menu -- ronoc -- Fri, Apr 15th, 2011 == {{{#!irc [19:00] right [19:00] hello folks [19:00] so the plan for this session is to discuss integrating with the sound menu === ChanServ changed the topic of #ubuntu-classroom to: Welcome to the Ubuntu Classroom - https://wiki.ubuntu.com/Classroom || Support in #ubuntu || Upcoming Schedule: http://is.gd/8rtIi || Questions in #ubuntu-classroom-chat || Event: Ubuntu App Developer Week - Current Session: Integrating music applications with the Sound Menu - Instructors: ronoc [19:01] Logs for this session will be available at http://irclogs.ubuntu.com/2011/04/15/%23ubuntu-classroom.html following the conclusion of the session. [19:01] firstly I would like to point out that early in the O cycle we will make available via libunity the ability to integrate with the menu [19:02] this will mean developers will not need to worry about mpris interfaces and will just need to use this api [19:02] Can I ask which of you here are interested in implementing a compliant player from scratch ? [19:03] right so nobody so far, for Maverick we used libindicate for registration with the menu [19:04] i reworked this during the natty cycle so as a compliant mpris interface was all that was needed to integrate with the menu [19:04] but there is abit more involved than just raising an mpris interface [19:05] mpt went to great lengths to define a preferred workflow with players and the menu so as players can optin or opt out of the menu through their own UI [19:05] more info on all of this can be found on the wiki (wiki.ubuntu.com/SoundMenu) [19:06] each player should allow the user to to have the option to opt in or opt out. The functionality behind all of this is in the indicator-sound's gsettings [19:06] again info on all of this can be found on that wiki page [19:07] also there is a mailing list which you should join if you are developer interested in this [19:07] * ronoc digs up the lp page [19:08] https://launchpad.net/~indicator-sound-developers [19:09] I use this to announce to devs about upcoming changes [19:09] I feel though after this cycle must of the architecture is settled [19:09] so no major changes planned for now [19:10] back to what I was saying previously, one of my main reasons for moving away from libindicate and using a strictly dbus registration mechanism [19:10] was to reduce / remove any i-s related dependency for clients [19:10] i-s = indicator-sound [19:11] clients = players = banshee, rhythmbox etc [19:11] by doing this it means that players like spotify work seemlessly without any i-s specific work by the spotify team [19:13] furthermore the change to use gsettings as a way of recording blacklisted applications or applications which have previously registered means that the menu dynamically updates when some change has been wrote to the i-s gsettings [19:13] this did happen before with the maverick version [19:13] any questions anyone [19:13] anything in particular you would like me to go through ? [19:14] ok, so for clients,the main thing is to raise an mpris interface with the desktop entry properly filled in [19:15] the mechanism works so as when an mpris interface appears on the bus the service attempts to load the desktop file defined on the root mpris interface for the client [19:15] if all is good , then the player is inserted in the menu [19:16] the mpris people have been very supportive in redefining the spec over the last year which has really made this all work nicely [19:17] whether you support the playlist interface or not is determined by the service at start up by querying the interfaces listed by your player [19:18] if the service finds a playlist interface then its exposes the relevant dbusmenu items [19:18] any questions anyone ? [19:19] we had a scrub bar at one point but it was removed due to design clutter which in retrospect was a good call by mpt [19:20] the back end for pulse has been totally refactored this cycle and pretty confident that it should work well now (before it was a bit of fudge due to time restrictions) [19:20] also this cycle I introduce the voip slider [19:21] next cycle we will do work which allows for the voip slider to be added for applications that are not just necessarily voip apps [19:21] so gnome-sound-recorder running will trigger the appearance of the voip slider [19:22] i have done the work for this in a branch but won't merge until the O cycle begins [19:22] what else ? [19:22] i feel though now ( a year down the road) [19:23] the code and the architecture of the i-s is pretty stable/completed [19:23] obviously new features require new code but as the spec stands I have all angles covered [19:23] is there anything people would like to see added ? [19:24] I suppose 7pm in Europe on Friday isn't the best idea [19:24] although there must be some Americans here full of beans [19:25] As I expressed earlier one of the main reasons for the reworking of the registration architecture was to allow players to easily integrate [19:26] there are still some players though that do not integrate [19:26] totem being one [19:26] which I have not got around to writing [19:26] nothing ubuntu specific is required anymore just a compliant mpris interface [19:27] !q any questions [19:28] * ronoc is getting the hang of using the classbot [19:29] * ronoc waits for some interaction [19:31] don't really know what else really needs to be covered ... [19:39] Any question guys, please ping me [19:42] * ronoc enjoy Richard Skelton's latest release on type [19:51] There are 10 minutes remaining in the current session. [19:56] There are 5 minutes remaining in the current session. [19:59] Ok folks all done here I think [19:59] Good weekend all [19:59] thanks ronoc [19:59] Cheer james_w [20:00] cheers even }}}