Bug 19589

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.