[Telepathy] Requestotron use-cases, part 2

[Xavier Claessens]

Le mercredi 30 avril 2008 à 14:57 +0100, Simon McVittie a écrit :
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Wed, 30 Apr 2008 at 15:23:59 +0200, Frederic Peters wrote:
> > My special use case would be using Totem, enjoying a movie, and a
> > plugin that would get IM messages to its fullscreen window, possibly
> > just like a news ticker.  Then I would notice important messages,
> > pause the video, un-fullscreen it, click on the blinking empathy icon
> > and answer.
> 
> I think that's just a special case of the blinking Empathy icon, but I
> see your point that there should be some extensibility to the way in
> which you're notified of new channels/new events.
> 
> (My inclination would be to just use the Galago/fd.o notification spec,
> as implemented by libnotify - then this just becomes an implementation
> detail of the notification daemon, "make sure notification bubbles
> appear over the top of full-screen applications". Perhaps I'm
> over-simplifying, but on the other hand, my approach would ensure that
> IMs, gnome-power-manager "low battery" warnings, etc. all automatically
> gain the same functionality.)
> 
>     Simon

I think Frederic's idea makes sense. When a new Text channel arrives I
see many programs that could be interested:
 - The logger
 - Empathy's status icon
 - Totem if in fullscreen could display the new message like subtitle
over the movie to warn user. Note that it doesn't means other app don't
want the channel at the same time, if I have 2 displays connected I can
watch the movie on one and empathy's status icon could blink on the
other... I don't have 2 monitors so I'm not sure that's possible?
 - If contact list is a separate process that status icon it could want
the channel to blink the icon of the contact
 - the megaphone applet of the contact may be interested to do something
when receiving a message from that contact
 - chat UI obviously wants the channel too.

So here I see 5 processes that could want the incoming channel. Before
giving the channel to the chat UI one of the others (but not the logger)
need to get a user action.

I could agree that we don't really need a priority queue for handlers, 2
levels could be enough: logger+status-icon+totem+contact-list first and
when one of those says it's OK the chat UI starts. On the first level we
have many handlers and on the 2nd we have only one... that's the idea
behind NMC's filters VS Chandlers.

Xavier Claessens.