Currently, a client can look at a Connection's RequestableChannelClasses property to figure out what kinds of channels it can request. But this is not necessarily useful: * A CM might support channels with THT: Room, but that's not to say that there's a client installed that can handle them. So a contact list UI might look at RCC, see that rooms are available, and have a bunch of room-related UI which is actually useless because any channels that get created will be terminated with extreme prejudice by the dispatcher. * A client can see that Gabble supports 1-1 stream tubes, but that doesn't help it figure out what services to offer when you right-click a contact. It should be able to have a "Play Tic-Tac-Tube" option. This information is already present in the form of the union of all activatable and running clients' HandlerChannelFilter properties, applied to the CM's requestable channel classes. So maybe extra spec is unnecessary. There's also a localization issue here: every contact list needs to know what the human-readable description of service=tictactube is.
We could add this as a mutable, signallable property on the ChannelDispatcher?
*** Bug 25288 has been marked as a duplicate of this bug. ***
Bug #25288 has two similar proposals: ChannelDispatcher.GetPossibleHandlers(a{sv}: Properties) -> as Check whether a requested channel whose immutable properties were Properties could be handled. If so, return the expected ChannelDispatchOperation.PossibleHandlers property for such a channel; if not, return an empty list. | This is appropriate for UIs to check whether a suitable client for | a request is installed; for instance, Empathy could use it. The channel dispatcher SHOULD assume that { Requested => TRUE } is in the Properties, even if it's not specifically given. | This matters if you have a client that only handles outgoing | channels, like a Vino "share my desktop" request. and interface o.fd.T.ChannelDispatcher.Interface.PossibleHandlers method GetPossibleHandlers(a{sv}) -> as [... documented as before ...] Clients MAY cache the result of this method (or more practically, decisions based on the result of this method), and use HandlersChanged to detect when to update their caches. | For instance, the Empathy contact list has a "Share my desktop" | menu item, which is visible when a VNC tube handler such as Vino | is available. signal HandlersChanged() Emitted when the set of available handlers has changed. Clients that cache the results of GetPossibleHandlers SHOULD call that method again.
Danielle's branch implementing the former proposal from Comment #3: http://git.collabora.co.uk/?p=user/danni/telepathy-spec.git;a=commitdiff;h=52b75f4d9d1ad6307d3fca523e2aedb8819eb84d An Empathy bug blocked by this: https://bugzilla.gnome.org/show_bug.cgi?id=589224
I'd prefer the version with a change signal, because as Guillaume pointed out on the duplicate bug (which has more discussion): > Now that Vino is finally a proper channel handler I'd really like to have this > method. > Ideally I'd need a change signal as well so I can just cache the result instead > of making a D-Bus call each time the contact menu is open. To get the spec beyond a draft someone will need to implement it in MC. mck182 on #telepathy was interested in using this to detect an audio/video call handler (and so decide whether to allow outgoing audio/video calls) in KDE-Telepathy.
For the record, this blocks https://bugzilla.gnome.org/show_bug.cgi?id=589224
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/telepathy/telepathy-spec/issues/20.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.