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

List:       kde-devel
Subject:    Re: a desktop wide "presence state" handling
From:       Anarky <anarky () ifrance ! com>
Date:       2006-12-21 12:09:26
Message-ID: 200612211309.27321.anarky () ifrance ! com
[Download RAW message or body]

 Tobias Hunger wrote :
> Decibel does manage your real time communication accounts (IM, VoIP, etc.)
> and has a presence state for all of the accounts it knows about. So far it
> does not have a global presence: It should be possible to bring up accounts
> independent of each other. It is trivial to extend Decibel with some applet
> that does update the presence information of all accounts at once though.
>
> > I've also read somewhere that an idea of Phonon was to allow to lower the
> > volume of your music when an entering VoIP call comes in.
>
> It should be easy to wire this up using the Decibel framework: Decibel's
> daemon (Houston) can detect incoming connection attempts and will trigger
> actions based on the type of the connection.

Yeah, as a user, I think that's something that should be done.
BTW, kopete already does that for all the account it handles. Of course it's 
still limited to one app and Houston would allow to wire all applications.
An interesting and not too hard step to go I think. So if I can help for that, 
let me know.

> Triggering screensavers, etc. is out of scope of Decibel.
>
> I see two approaches to get on from here:
>
> * Have Houston (Decibel service Daemon) raise a signal whenever a presence
> state changes.  We would not need a presence service then. You could argue
> 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. 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.
>
> > I would also be happy if someone else is interested by this project and
> > wants to help, give advice, etc ...
>
> It would be nice if we could discuss this some more. We definitely need to
> work out how to work together.

Nice to hear that.
As I said somewhere else on the thread, I'll be away for a couple of weeks 
(talking about presence status ...).
But I'll contact you on IRC as soon as I'm back.

> I for one think having categories is overdoing it a bit: Presence is a
> pretty straight forward concept which should have a *simple* implementation
> or many users will just not bother with it.

I completely agree with you on that point, things should be as simple as 
possible.

But I think categories are just there, whether we want them or not.
Let me explain my point :

If we don't have a category concept in the daemon that handles presence status 
(Houston or another), then this daemon will export the status as it knows it 
(offline/away/busy/free/...) and every app will have to deal with that.
For IM, that would be quite easy, but what about multimedia apps ?
Does the user want to stop music when he is busy ? it depends on the user.
So if he's not happy with the default setting, he will just have to change the 
config of every multimedia app.

What I propose is to have a mapping in two steps.
information --> global status
There are a lot of information sources that can be used to know the user 
presence status, this part is about gathering all the information and 
extracting the interesting part : the global status.
then, global status --> category specific status
Each category of app will have a different set of possible reactions, and each 
user will want different reactions to be triggered for a specific global 
status. This would allow to have only one place to configure it.

Let me talk about a new use case, not one I imagined, but one that someone 
just told me about on IRC.
His hdd are very noisy, so he wants them no to be used when he's asleep.
The applications that are using his disks are beagle and kmail.
What would he do?

Just add a new global status "asleep", and choose when this status is active 
(between 11pm and 10am, only if there wasn't a user input for more than 15min 
let's say) That's the information --> global status part.
Then he would add a category "noisy apps" with two possible state "started" 
and "not started".
He would set the "started" state as default and would link the "not started" 
state to the "asleep" global status. That's the global status --> category 
specific status part.

That may seem a bit overkill as you say, but I think it's the better way to do 
that.
I would like to hear your opinion about that. Perhaps IRC is the place for 
this kind of discussions.

> I am not overly fond of your categories: They allow to have one central
> place to set up reactions to presence state (which is nice), but limits
> what you can do, too. If there is no category for something, then you are
> stuck.

Yes you're right. My answer to that is to allow the user to add categories, 
but it may not be ideal.

> 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? 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...

Perhaps you're right. It would be interesting to have the opinion of usability 
people.
My whole point was the complete opposite, that it would be interesting to 
configure the things one time and for all somewhere in kcontrol so that if 
you start using another music player, you don't have to configure this again.
Then, perhaps the solution is to have a central configuration, but to allow 
applications to change the part of the config that's related to them, best of 
both worlds in a way ...

> Best Regards,
> Tobias

I'd like to really thank you, it's really interesting to stop thinking in your 
corner and start comparing your ideas with someone else.

Regard,

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

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