[Telepathy] Requestotron use-cases, part 2

[Dafydd Harries]

Ar 30/04/2008 am 22:44, ysgrifennodd 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.

Can't we write loggers purely in terms of message filters? E.g. to log text
messages, I think you just need to watch Sent and Received signals. I don't
think channel handling need enter into it.

-- 
Dafydd