This has grown out of https://bugzilla.gnome.org/show_bug.cgi?id=589224 If you're adding API anyway, you might as well ask the question you actually want to ask, rather than starting a speculative request and then cancelling it. Something like this: ChannelDispatcher.CouldHandleChannel(a{sv}: Properties) -> b [or as?] Check whether a requested channel whose immutable properties were Properties could be handled. Return TRUE if so. [Or: return the expected ChannelDispatchOperation.PossibleHandlers property for such a channel.] | 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.
Decided to call this method GetPossibleHandlers. Spec addition: http://git.collabora.co.uk/?p=user/danni/telepathy-spec.git;a=shortlog;h=refs/heads/get-possible-handlers
To clarify, my implementation returns an 'as' of well-known names like ChannelDispatchOperation.PossibleHandlers
tp:added should contain (or end with) UNRELEASED, so that our release procedure catches it and replaces it with the correct version - it would be incorrect to claim that this method was added in 0.18.0.1 when it isn't even in 0.19.3. I like the spec proposal, but to be merged, this needs a prototype implementation in a Mission Control branch. Wiring up the existing code to a G_GNUC_UNUSED function with the same signature that the D-Bus method would have would be a sufficient prototype, I think.
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.
(In reply to comment #4) > 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. That's an interesting point. Care to design a spec/implementation for that?
Thinking about it, one easy way to design this would be to assume the available clients will change infrequently, and use this sort of pattern: 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.
(In reply to comment #6) > Thinking about it, one easy way to design this would be to assume the available > clients will change infrequently, and use this sort of pattern: > > interface o.fd.T.ChannelDispatcher.Interface.PossibleHandlers > > method GetPossibleHandlers(a{sv}) -> as ... > signal HandlersChanged() This is, in fact, Bug #19589. *** This bug has been marked as a duplicate of bug 19589 ***
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.