[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: a desktop wide "presence state" handling
From:       "Aaron J. Seigo" <aseigo () kde ! org>
Date:       2006-12-22 6:26:04
Message-ID: 200612212326.11786.aseigo () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Thursday 21 December 2006 3:07, Tobias Hunger wrote:
> * Have Houston (Decibel service Daemon) raise a signal whenever a presence
> state changes.  We would not need a presence service then. You could argue

in addition to a signal, it would of course also need to be queryable so 
applications that start up can find out what's going on =)

> that the presence in Decibel is tailored to communications settings
> (following the usuall offline/away/busy/free for chat pattern) which is
> more limited then what you are proposing.

it could be noted that most states are a sub-type of one of the four you 
listed. e.g. "i'm asleep" is a form of "i'm away" while "i'm on a phone call" 
is part of "i'm busy".

what would be interesting, from an app developer's pov, is to note is what 
kind of busy you are; e.g. if it's audio busy (e.g. a voip call) then perhaps 
music playing should automatically mute a bit at the moment of the presence 
change. if i'm busy with an irc query then my music can stay just as it is ;)

is this in decibel's current code base or future plans?

> As I said, Decibel has no "global  presence" so far, but this could be
> added. 
>
> * Have Houston grab the global presence state from someplace else. I was
> planning on having an applet to do just that, but this could be a presence
> service just as well.

having multiple locations / mechanisms for presence sounds very messy to me; 
if one app is handling communications presence and another is monitoring, 
say, physical presence .... how are they coordinated, sync'd, kept in a sane 
mutual state, etc? (add a third type of presence for more fun)

> Wouldn't it be simpler to have some existing service send a D-Bus signal
> with a IM-like presence state (maybe including a message) and have
> interested parties listen for that, "translating" the event as they see
> fit? 

makes the most sense to me as well. then each app can decide what's the most 
appropriate thing to do given its domain. listening for these changes needs 
to be made simple for the app developer, of course =)

> Muting can be done in the mixer then, stopping playback in the music 
> player, etc. I'd for one would find that more logical as a user. It is not
> really intuitive that I have to look in a presence configuration dialog to
> have my music not stop whenever I am idle for a while! I'd check the
> configuration of the music player first...

yep

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

Full time KDE developer sponsored by Trolltech (http://www.trolltech.com)

[Attachment #5 (application/pgp-signature)]

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<


[prev in list] [next in list] [prev in thread] [next in thread]