SoundMenu

Revision 1 as of 2011-04-18 12:52:43

Clear message

App Developer Week -- Integrating music applications with the Sound Menu -- ronoc -- Fri, Apr 15th, 2011

   1 [19:00] <ronoc> right
   2 [19:00] <ronoc> hello folks
   3 [19:00] <ronoc> so the plan for this session is to discuss integrating with the sound menu
   4 === 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
   5 [19:01] <ClassBot> Logs for this session will be available at http://irclogs.ubuntu.com/2011/04/15/%23ubuntu-classroom.html following the conclusion of the session.
   6 [19:01] <ronoc> 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
   7 [19:02] <ronoc> this will mean developers will not need to worry about mpris interfaces and will just need to use this api
   8 [19:02] <ronoc> Can I ask which of you here are interested in implementing a compliant player from scratch ?
   9 [19:03] <ronoc> right so nobody so far, for Maverick we used libindicate for registration with the menu
  10 [19:04] <ronoc> i reworked this during the natty cycle so as a compliant mpris interface was all that was needed to integrate with the menu
  11 [19:04] <ronoc> but there is abit more involved than just raising an mpris interface
  12 [19:05] <ronoc> 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
  13 [19:05] <ronoc> more info on all of this can be found on the wiki (wiki.ubuntu.com/SoundMenu)
  14 [19:06] <ronoc> 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
  15 [19:06] <ronoc> again info on all of this can be found on that wiki page
  16 [19:07] <ronoc> also there is a mailing list which you should join if you are developer interested in this
  17 [19:07]  * ronoc digs up the lp page
  18 [19:08] <ronoc> https://launchpad.net/~indicator-sound-developers
  19 [19:09] <ronoc> I use this to announce to devs about upcoming changes
  20 [19:09] <ronoc> I feel though after this cycle must of the architecture is settled
  21 [19:09] <ronoc> so no major changes planned for now
  22 [19:10] <ronoc> back to what I was saying previously, one of my main reasons for moving away from libindicate and using a strictly dbus registration mechanism
  23 [19:10] <ronoc> was to reduce / remove any i-s related dependency for clients
  24 [19:10] <ronoc> i-s = indicator-sound
  25 [19:11] <ronoc> clients = players = banshee, rhythmbox etc
  26 [19:11] <ronoc> by doing this it means that players like spotify work seemlessly without any i-s specific work by the spotify team
  27 [19:13] <ronoc> 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
  28 [19:13] <ronoc> this did happen before with the maverick version
  29 [19:13] <ronoc> any questions anyone
  30 [19:13] <ronoc> anything in particular you would like me to go through ?
  31 [19:14] <ronoc> ok, so for clients,the main thing is to raise an mpris interface with the desktop entry properly filled in
  32 [19:15] <ronoc> 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
  33 [19:15] <ronoc> if all is good , then the player is inserted in the menu
  34 [19:16] <ronoc> the mpris people have been very supportive in redefining the spec over the last year which has really made this all work nicely
  35 [19:17] <ronoc> whether you support the playlist interface or not is determined by the service at start up by querying the interfaces listed by your player
  36 [19:18] <ronoc> if the service finds a playlist interface then its exposes the relevant dbusmenu items
  37 [19:18] <ronoc> any questions anyone ?
  38 [19:19] <ronoc> 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
  39 [19:20] <ronoc> 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)
  40 [19:20] <ronoc> also this cycle I introduce the voip slider
  41 [19:21] <ronoc> next cycle we will do work which allows for the voip slider to be added for applications that are not just necessarily voip apps
  42 [19:21] <ronoc> so gnome-sound-recorder running will trigger the appearance of the voip slider
  43 [19:22] <ronoc> i have done the work for this in a branch but won't merge until the O cycle begins
  44 [19:22] <ronoc> what else ?
  45 [19:22] <ronoc> i feel though now ( a year down the road)
  46 [19:23] <ronoc> the code and the architecture of the i-s is pretty stable/completed
  47 [19:23] <ronoc> obviously new features require new code but as the spec stands I have all angles covered
  48 [19:23] <ronoc> is there anything people would like to see added ?
  49 [19:24] <ronoc> I suppose 7pm in Europe on Friday isn't the best idea
  50 [19:24] <ronoc> although there must be some Americans here full of beans
  51 [19:25] <ronoc> As I expressed earlier one of the main reasons for the reworking of the registration architecture was to allow players to easily integrate
  52 [19:26] <ronoc> there are still some players though that do not integrate
  53 [19:26] <ronoc> totem being one
  54 [19:26] <ronoc> which I have not got around to writing
  55 [19:26] <ronoc> nothing ubuntu specific is required anymore just a compliant mpris interface
  56 [19:27] <ronoc> !q any questions
  57 [19:28]  * ronoc is getting the hang of using the classbot
  58 [19:29]  * ronoc waits for some interaction
  59 [19:31] <ronoc> don't really know what else really needs to be covered ...
  60 [19:39] <ronoc> Any question guys, please ping me
  61 [19:42]  * ronoc enjoy Richard Skelton's latest release on type
  62 [19:51] <ClassBot> There are 10 minutes remaining in the current session.
  63 [19:56] <ClassBot> There are 5 minutes remaining in the current session.
  64 [19:59] <ronoc> Ok folks all done here I think
  65 [19:59] <ronoc> Good weekend all
  66 [19:59] <james_w> thanks ronoc
  67 [19:59] <ronoc> Cheer james_w
  68 [20:00] <ronoc> cheers even