On 08/02/12 14:00, David Edmundson wrote:
> Currently (mostly thanks to a lack of delegateChannel in TpQt) this
> plasmoid purely an observer with our main handler running in a window
> elsewhere.
...
> So in short; in this particular case is it ok for an observer to ack
> messages? I think it is, but I don't want to go against the spec,
> particularly something in capital letters.
> If not how does Gnome-Shell handle this?
It's a Handler, and so is Empathy, and the Shell delegates the channel
to Empathy when necessary. Sorry, I think you do want delegation support
in telepathy-qt - patches welcome if it isn't implemented already! (If
in doubt, base it on what telepathy-glib does, which has been verified
to work in Shell.)
When you double-click a contact in the Empathy contact list, Empathy
calls EnsureChannel with the
org.freedesktop.Telepathy.ChannelRequest.DelegateToPreferredHandler=TRUE
hint, and itself as the PreferredHandler; if the Shell happens to be
handling a channel to that contact already, it gets HandleChannels
re-invoked, notices the hint and responds by delegating the channel to
Empathy. If nobody is handling the channel (i.e. it's new), it's Empathy
that gets HandleChannels called on it, in which case it does not try to
delegate the channel to itself :-)
When you double-click a conversation bubble in Shell, Shell also
delegates the channel to Empathy, this time without a request from Empathy.
When we discussed this in the context of GNOME Shell, we came to the
conclusion that having more than one Handler, and having the active
Handler for the Channel follow where the user should be looking if they
want to keep up with it, was sufficiently useful to pay the (complexity)
price of DelegateChannel.
For instance, one thing that you get by having exactly one Handler at a
time, which acknowledges the messages, is that either Empathy or Shell
notifies you (makes a sound or gives the window manager an attention
request or pops up a bubble or whatever) when there's a new incoming
message, but never both.
(This approach also means that Empathy doesn't necessarily get run at
all, for quick conversations done entirely in gnome-shell.)
Not acknowledging messages unless you're a Handler has (at least) two
functions; I think there may have been more that I've forgotten.
The main one is that it avoids Observers missing messages. An Observer
like telepathy-logger is expected to connect to signals, download state,
*then* reply to ObserveChannels. HandleChannels isn't called until all
Observers have done this; so if you don't start acknowledging until you
have had HandleChannels called on you, you're guaranteed not to delete
any messages before the logger has seen them (unless it's unreasonably
slow and MC gave up waiting for it, in which case, get a better logger).
If you start acknowledging straight away in an Observer, there's no
guarantee that you won't ack a message before the logger (another,
equal, Observer) has had a chance to record it, and it'll be lost forever.
A secondary function is that it avoids getting errors back from
AcknowledgeMessages when you give a message ID that someone else already
acknowledged, and having to try again, acknowledging messages one-by-one
and ignoring the errors, in order to ack them all!
> We were using this acknowledged message system as a way to keep track
> of the "unread messages" in both the main chat handler and the
> plasmoid and show/remove the correct notifications in the two places.
That's entirely reasonable... but it might turn out to be a lot simpler
to say that whoever is currently the active Handler (for a given
Channel) is expected to notify about it.
S
_______________________________________________
telepathy mailing list
telepathy@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/telepathy
