[Telepathy] Presence API in gnome-session

[Jon McCann]

Hey,

----- "Robert McQueen" <robert.mcqueen at collabora.co.uk> wrote:

> Frederic Peters wrote:
> > Hello Telepathy Hackers; hello Jon;
> 
> Hi Frederic, Jon,
> 
> > A D-Bus Presence API has just been commited to gnome-session,
> >  
> http://svn.gnome.org/viewvc/gnome-session?view=revision&revision=5192
> >  
> http://svn.gnome.org/svn/gnome-session/trunk/gnome-session/org.gnome.SessionManager.Presence.xml
> > 
> > It will be used by the user switch applet (now part of gdm),
> >   http://svn.gnome.org/viewvc/gdm?view=revision&revision=6659
> 
> Cool. Although I'd slim the interface down into two properties you
> can
> access with GetAll/Get on the D-Bus properties interface, and just
> have
> one set method and change signal. Tracking the status and message
> separately seems needless and will just double up signals/method
> calls
> for almost all users.

I've exposed the properties and remove the getters from the interface now.  I'm not convinced that we should combine the status and status text methods and signals however.  I would also like to add another type of status text that is application scoped (where the current one is global).  The app scoped one could be used by rhythmbox, totem, etc to add "Playing Novelty" or similar.  Probably would have an API much like the inhibit api.

> > It thought you Empathy/Telepathy guys could discuss (with Jon) how
> it
> > could fit with your needs, and how it could match your Presence
> API.
> 
> Sure, it should be pretty easy for Empathy or Mission Control to just
> track this and update your IM presence. One concern is the enum type,
> it
> seems a little patchy compared to what Telepathy uses to classify
> presence:
> http://telepathy.freedesktop.org/spec.html#type-Connection_Presence_Type

Right, it wasn't meant to try to replace the statuses that communication clients use.

> Obviously you can ignore unknown and error, but the idle vs away/xa
> thing worries me. Idleness is kind of orthogonal. I guess you /could/
> read idle as away, but people can go away with a certain reason (out
> to
> lunch, at the movies, whatever) which is more more meaningful than
> mere
> idleness. I'd use idleness to automatically set away (with no
> message)
> and promote away to extended away, but I'd call the enum members AWAY
> and XA, and allow the user to set both busy and away with messages as
> they're different things.
> 

Yeah, this is precisely why I chose idle instead of away.  Idle is automatically set and the user won't have the ability to set it directly apart from locking the screen.  It is basically the same as what many clients call extended away.

We'll see how it goes.  Will likely have to make some changes once we start patching applications to use this.

Thanks for the comments.

Jon