This can be made possible by adding a new field in filters defined in .cient files. Something like:

gsettings-id=org.gnome.Empathy.call


which tell MC about a GSetting schema path to search for boolean keys (say, "filter1_enabled", "filter2_enabled" and so on for all filters) which let MC know the user's intention to use that filter/accept such a connection dynamically and connect to that gsetting's "changed::<key-name>" signal to dynamically decide to emit "UpdateCapabilities" for the registered client handlers.

Then the user just has to change the gsetting to enable/disable the use of a particular feature of his client and MC will update it's advertisement of that capability to the user's contacts! :)

A little tweaking of the specs will be needed.

A use case of this feature would be:

Right now its possible for a client to display the capabilities of tp-cilents he has installed on his computer but he cannot fully utilize this power to prevent him from launching an application before displaying the capabilities of that application since he would not be in position to stop advertisement of that capability unless he uninstalls the application.

If what I propose is implemented, a client would not need to start an application explicitly to show capabilities provided by that application (like empathy-call or glchess) to his contacts. All he would need is to set a setting 
"advertise chess playing capability to contacts whenever connected" to be checked and quit the app. MC will automatically launch the app. when a channel request of the advertised channel type comes up.

If the handler is already launched, when an incoming channel is approved, it will handle it. When it's not then MC (and approver which will be avtivatable by MC) are already alive to invoke it as needed on demand. No need to keep handler loaded for featuring capabilities or anticipating channel reqests.

If a capability of a handler is disabled by user, there will be no incoming channel requests for it in the first place. Even if they are (by some buggy client), MC will not know the name of that handler capable of handling it and will not pass it in the list of "PossibleHandlers" to any approver which is capable of approving similar channels.

See also bug #21318 and https://bugzilla.gnome.org/show_bug.cgi?id=576376

yeah, and thanks for support.
I am looking into it and preparing a non-trivial test case for adding this brand new cool feature.

Created attachment 72530 [details] [review]
This patch should solve the issue

> Subject: [PATCH] Allow-clients-to-control-their-capabilities-from-being-always-advertised

Git-commit-messages-don't-conventionally-have-words-chained-together-like-this.

-        if (space == NULL || space[1] == '\0' || space[2] != '\0')
+        if (space == NULL || !(space[1] != '\0' && space[2] != '\0'))

Sorry, I don't see how this does what it says in the Subject. It looks as though you're fixing (or at least changing) some sort of parsing bug: which strings are now accepted which weren't before, or which strings were accepted before but aren't any more?

(In reply to comment #1)
> This can be made possible by [...]
> a GSetting schema path to search for boolean keys (say,
> "filter1_enabled", "filter2_enabled" and so on for all filters)

I don't think we want Telepathy to depend on GSettings in this way: Telepathy is not GNOME-specific, and all account settings currently live on Telepathy Account objects where they can be manipulated over D-Bus. I would like that to continue if at all possible.

> If what I propose is implemented, a client would not need to
> start an application explicitly to show capabilities provided
> by that application (like empathy-call or glchess) to his contacts.
...
> No need to keep handler loaded for featuring capabilities or
> anticipating channel reqests.

This is already meant to be true; if the application is bus-activatable (has a D-Bus .service file), Mission Control will advertise its capabilities. If you don't want Mission Control to bus-activate it to ask it for its capabilities, you also have to provide a .client file containing a cache of those capabilities.

If our parsing of .client files is incorrect, then it might interfere with what I just described. If so, please explain what's wrong in your patch commit message and we can fix it :-)

> a new field in filters defined in .cient files

There is a slightly subtle design point about .client files which you might not be aware of: they are meant to be a pure cache. If an application lacks a .client file, or if Mission Control just "feels like it", it is able to get all the same information from that Client over D-Bus via the Client, Handler etc. interfaces: that's why all the fields in the .client file are defined and documented by the corresponding D-Bus properties in telepathy-spec.

(If necessary this could be dealt with by having an array D-Bus property that is defined to have the same number of elements as HandlerChannelFilter, in the same order.)

> If a capability of a handler is disabled by user, there will be
> no incoming channel requests for it in the first place. Even if
> they are (by some buggy client), MC will not know the name of
> that handler capable of handling it and will not pass it in the
> list of "PossibleHandlers" to any approver which is capable of
> approving similar channels.

This is a missing feature. I would be happy to review a patch that implements it, but I would prefer it to be done using a D-Bus property on the Account as suggested in Bug #21318, rather than (effectively) including all of GSettings in the Telepathy spec.

I would also prefer this to be thought of in terms of giving Mission Control information, rather than hiding information: it shouldn't be "Mission Control doesn't know the Handler has capability X", but rather "Mission Control knows that the Handler has capability X, but also knows that the user wants to ignore it, so it doesn't take it into account when selecting the PossibleHandlers".

One of the issues that needs to be settled in order to do that is the scope of the D-Bus property, for which we need to look at its use cases. Does it need to contain whole channel classes, or would it be sufficient to act on channel types? Do the channel classes need to match exactly, or do we use subset matching?

For "no VoIP", it's enough to be able to knock out the entire Call and StreamedMedia channel types.

For "no Tubes", we could either knock out the D-Bus and Stream tube channel types (although this raises the possibility that we add "datagram tubes" later and suddenly need a way to suppress those too), or knock out individual tube services (e.g. chess), or have some as-yet-undesigned way to knock out the general concept of Tubes ("everything with interface Chan.I.Tube" maybe?) - which one we want depends what use cases you have in mind.

I'm also not sure whether what you want here is "prevent Empathy from handling VoIP" or "prevent *anyone* from handling VoIP", or possibly even "prevent my contacts from being able to find out that I have a VoIP client, however hard they try". Which is it?

Do you think this setting should be per-account or global? What would the UI for it look like?  Which application provides the UI for it, and do individual Handlers need to be able to tell that UI about new channel classes that it would be meaningful to block?

> If a capability of a handler is disabled by user, there will be
> no incoming channel requests for it in the first place. Even if
> they are (by some buggy client)

Slight technical correction here: the client doesn't necessarily even have to be buggy.

In XMPP Jingle, there is an implementation detail that it is difficult to make a VoIP call to someone whose capabilities you don't know, because you don't know which of the four incompatible dialects of Jingle they understand: you have to choose one of those dialects and hope they do.

Now that "real Jingle" is standardized and increasingly widespread, it would be nice to have the ability to make a speculative VoIP call to an "offline" contact in the hope that they are actually just invisible, and might answer anyway.

In SIP, there are no capabilities (and, in the feature-set we implement, no presence): you just have to assume that everyone does support VoIP (and is currently online), try calling them, and see what happens.

(In reply to comment #6)
> "Mission
> Control knows that the Handler has capability X, but also knows that the
> user wants to ignore it, so it doesn't take it into account when selecting
> the PossibleHandlers".

It is technically possible for an Approver to return a Handler that was not offered to it; Mission Control will try to comply. Should this mechanism make Mission Control reject attempts to HandleWith(the forbidden Handler)? (I think it probably should.)

> Does it
> need to contain whole channel classes, or would it be sufficient to act on
> channel types?

Another possibility would be for it to act on Handlers, or to have a hybrid approach: a list of forbidden Handlers, and a list of forbidden channel types. If an application wants to support being "partially enabled", it just has to act as more than one Handler (either several executables, like Empathy and KDE-Telepathy, or a single executable with several bus names and TpBaseClient objects).

Here is a straw-man UI which could work with the hybrid approach:

    Enabled features

    [x] Receive voice and video calls      # i.e. Call channels
    [x] Receive incoming file transfers

    Enabled applications

    [x] GNOME Chess                        # Client would need a new map,
    [ ] Quake III Arena                    # { language => translated name },
    [ ] Remote desktop viewer              # and other metadata like Icon
    [x] AbiCollab (AbiWord)
    [x] My.UnfinishedClient

We could have a special case for Call and FT, or just drop the hybrid approach and list "Empathy voice/video calls" and "Empathy file transfers" in the list of enabled applications.

Handlers would need a way to say "it doesn't make any sense to disable me", which would be used by, for instance, Empathy's Auth and Text handlers (Auth is a behind-the-scenes thing, and in practice IM protocols always assume that everyone can receive Text).

Would we want to control outgoing (local-user-requested) channels too?

Thanks for your attention on this bug.

(In reply to comment #6)

> 
> -        if (space == NULL || space[1] == '\0' || space[2] != '\0')
> +        if (space == NULL || !(space[1] != '\0' && space[2] != '\0'))
> 
> Sorry, I don't see how this does what it says in the Subject. It looks as
> though you're fixing (or at least changing) some sort of parsing bug: which
> strings are now accepted which weren't before, or which strings were
> accepted before but aren't any more?
> 

Comment #5 was a BASIC patch on MC to begin with.
A few more patches are lining up in order to have this problem solved which include fixing telepathy-gabble connection manager to do the decion making about when to emit ContactCapabilitiesChanged (which is out of scope of this bug).

For easy tracing the following steps are in order:

 - https://bugzilla.gnome.org/show_bug.cgi?id=576376
   to enable Empathy users control when empathy-call can be used.
 - Split empathy-call as a separate process independent of empathy (https://bugzilla.gnome.org/show_bug.cgi?id=691773)
 - patch tp-gabble to incorporate the changes.


> (In reply to comment #1)
> > This can be made possible by [...]
> > a GSetting schema path to search for boolean keys (say,
> > "filter1_enabled", "filter2_enabled" and so on for all filters)
> 
> I don't think we want Telepathy to depend on GSettings in this way:
> Telepathy is not GNOME-specific, and all account settings currently live on
> Telepathy Account objects where they can be manipulated over D-Bus. I would
> like that to continue if at all possible.

Since the subject of this bug is telepathy handler clients, I don't want to bring per account settings pulled in here. It should be sufficient if I deploy a handler-channel-filter in empathy, like this:

 18 [org.freedesktop.Telepathy.Client.Handler.HandlerChannelFilter 3]
 19 org.freedesktop.Telepathy.Channel.ChannelType s=org.freedesktop.Telepathy.Channel.Type.DBusTube
 20 org.freedesktop.Telepathy.Channel.TargetHandleType u=1
 21 org.gnome.GSettings.schema s=org.gnome.Empathy.call

> > Subject: [PATCH] Allow-clients-to-control-their-capabilities-from-being-always-advertised
> 
> Git-commit-messages-don't-conventionally-have-words-chained-together-like-
> this.

> If our parsing of .client files is incorrect, then it might interfere with
> what I just described. If so, please explain what's wrong in your patch
> commit message and we can fix it :-)

My mistake. I have renamed commit message from
"Allow-clients-to-control-their-capabilities-from-being-always-advertised" to be 
"Correct which filters should be passed to CMs"

> 
> > a new field in filters defined in .cient files
> 
> There is a slightly subtle design point about .client files which you might
> not be aware of: they are meant to be a pure cache. If an application lacks
> a .client file, or if Mission Control just "feels like it", it is able to
> get all the same information from that Client over D-Bus via the Client,
> Handler etc. interfaces: that's why all the fields in the .client file are
> defined and documented by the corresponding D-Bus properties in
> telepathy-spec.
> 
> (If necessary this could be dealt with by having an array D-Bus property
> that is defined to have the same number of elements as HandlerChannelFilter,
> in the same order.)

Thanks, this was bothering me much. I need to look how to define it in the specs..

> 
> > If a capability of a handler is disabled by user, there will be
> > no incoming channel requests for it in the first place. Even if
> > they are (by some buggy client), MC will not know the name of
> > that handler capable of handling it and will not pass it in the
> > list of "PossibleHandlers" to any approver which is capable of
> > approving similar channels.
> 
> This is a missing feature. I would be happy to review a patch that
> implements it, but I would prefer it to be done using a D-Bus property on
> the Account as suggested in Bug #21318, rather than (effectively) including
> all of GSettings in the Telepathy spec.

I do not understand it very clearly. Since I am not dealing with account specific filters but creating handler switches, I am unable to see how Bug #21318 comes to help.


> 
> I would also prefer this to be thought of in terms of giving Mission Control
> information, rather than hiding information: it shouldn't be "Mission
> Control doesn't know the Handler has capability X", but rather "Mission
> Control knows that the Handler has capability X, but also knows that the
> user wants to ignore it, so it doesn't take it into account when selecting
> the PossibleHandlers".
> 
> One of the issues that needs to be settled in order to do that is the scope
> of the D-Bus property, for which we need to look at its use cases. Does it
> need to contain whole channel classes, or would it be sufficient to act on
> channel types? Do the channel classes need to match exactly, or do we use
> subset matching?

It needs to contain whole channel classes.
We also need subset matching for reading "advertise-capability" key from the gschema given in .client (and as DBus property too, like you say).

> 
> I'm also not sure whether what you want here is "prevent Empathy from
> handling VoIP" or "prevent *anyone* from handling VoIP", or possibly even
> "prevent my contacts from being able to find out that I have a VoIP client,
> however hard they try". Which is it?

The third one i.e. prevent my contacts from being able to find out that I have a VoIP client, however hard they might try. This is the premise.

> 
> Do you think this setting should be per-account or global? What would the UI
> for it look like?  Which application provides the UI for it, and do
> individual Handlers need to be able to tell that UI about new channel
> classes that it would be meaningful to block?

global and not account specific.

(In reply to comment #7)
> > If a capability of a handlier is disabled by user, there will be
> > no incoming channel requests for it in the first place. Even if
> > they are (by some buggy client)
> 
> Slight technical correction here: the client doesn't necessarily even have
> to be buggy.
> 
> In XMPP Jingle, there is an implementation detail that it is difficult to
> make a VoIP call to someone whose capabilities you don't know, because you
> don't know which of the four incompatible dialects of Jingle they
> understand: you have to choose one of those dialects and hope they do.
> 
> Now that "real Jingle" is standardized and increasingly widespread, it would
> be nice to have the ability to make a speculative VoIP call to an "offline"
> contact in the hope that they are actually just invisible, and might answer
> anyway.
> 
> In SIP, there are no capabilities (and, in the feature-set we implement, no
> presence): you just have to assume that everyone does support VoIP (and is
> currently online), try calling them, and see what happens.

This bug shouldn't interfere with any of those services, hopefully.


(In reply to comment #8)
> (In reply to comment #6)
> > "Mission
> > Control knows that the Handler has capability X, but also knows that the
> > user wants to ignore it, so it doesn't take it into account when selecting
> > the PossibleHandlers".
> 
> It is technically possible for an Approver to return a Handler that was not
> offered to it; Mission Control will try to comply. Should this mechanism
> make Mission Control reject attempts to HandleWith(the forbidden Handler)?
> (I think it probably should.)
> 
> > Does it
> > need to contain whole channel classes, or would it be sufficient to act on
> > channel types?
> 
> Another possibility would be for it to act on Handlers, or to have a hybrid
> approach: a list of forbidden Handlers, and a list of forbidden channel
> types. If an application wants to support being "partially enabled", it just
> has to act as more than one Handler (either several executables, like
> Empathy and KDE-Telepathy, or a single executable with several bus names and
> TpBaseClient objects).
> 
> Here is a straw-man UI which could work with the hybrid approach:
> 
>     Enabled features
> 
>     [x] Receive voice and video calls      # i.e. Call channels
>     [x] Receive incoming file transfers
>

Ok, none of these yet. I will create new bugs that should be spawn to track these spin-offs.

Sorry, I shouldn't have got into implementation details like GSettings before I asked you to describe what you want more precisely, without the distraction of whether particular implementation things mattered:

(In reply to comment #2)
> A use case of this feature would be:
> 
> Right now its possible for a client to display the capabilities of
> tp-cilents he has installed on his computer but he cannot fully utilize this
> power to prevent him from launching an application before displaying the
> capabilities of that application since he would not be in position to stop
> advertisement of that capability unless he uninstalls the application.

Sorry, that's not a use-case.

"I want to have call support installed, but have a switch that, when off, makes my Telepathy setup indistinguishable from one that doesn't support calls" is one possible use-case. Is that what you're asking for? If not, what *are* you asking for, in similar terms?

If that's what you're looking for, do you mean all audio/video calls, or do you mean VoIP (XMPP/SIP/...) specifically, i.e. not counting cellular calls if running on an N9 or something?

Imagine you have GNOME, Empathy, KDE and KDE-Telepathy installed. Which application provides UI to toggle this feature? Is it desirable for Empathy's call support and KDE-Telepathy's call support to be controlled together, or separately, or do you not mind either way?

Are you interested in similar use-cases for Tubes applications ("I want to have Vinagre installed, but I don't want my contacts to know that they can use 'share my desktop' with me") or do you not care about those one way or another?

What would the UI for these features look like? Please sketch out an ASCII-art preferences tab or something.

I *think* I can see ways to implement several possible versions of this in an easier and more Telepathy-ish way than what you've suggested, but I'm trying hard not to describe it until I've confirmed exactly what it is you want :-)

(In reply to comment #10)
> Sorry, I shouldn't have got into implementation details like GSettings
> before I asked you to describe what you want more precisely, without the
> distraction of whether particular implementation things mattered:
> 
> (In reply to comment #2)
> > A use case of this feature would be:
> > 
> > Right now its possible for a client to display the capabilities of
> > tp-cilents he has installed on his computer but he cannot fully utilize this
> > power to prevent him from launching an application before displaying the
> > capabilities of that application since he would not be in position to stop
> > advertisement of that capability unless he uninstalls the application.
> 
> Sorry, that's not a use-case.
> 
> "I want to have call support installed, but have a switch that, when off,
> makes my Telepathy setup indistinguishable from one that doesn't support
> calls" is one possible use-case. Is that what you're asking for?

You got this right. Exactly what I want.


> 
> If that's what you're looking for, do you mean all audio/video calls, or do
> you mean VoIP (XMPP/SIP/...) specifically, i.e. not counting cellular calls
> if running on an N9 or something?

I just meant to have VoIP call advertisement controlled

> 
> Imagine you have GNOME, Empathy, KDE and KDE-Telepathy installed. Which
> application provides UI to toggle this feature? Is it desirable for
> Empathy's call support and KDE-Telepathy's call support to be controlled
> together, or separately, or do you not mind either way?

I'd prefer each application to have its own way to control its functionality. That's more intutive to the end user.


> 
> Are you interested in similar use-cases for Tubes applications ("I want to
> have Vinagre installed, but I don't want my contacts to know that they can
> use 'share my desktop' with me") or do you not care about those one way or
> another?
> 

I care about extending this functionality into Vinagre but we'll cross the bridge when we come to it.


> What would the UI for these features look like? Please sketch out an
> ASCII-art preferences tab or something.

Similar to the one you described: 
    Enabled features

    [x] Receive voice and video calls      # i.e. Call channels
    [x] Receive incoming file transfers

looks good way to go.

> 
> I *think* I can see ways to implement several possible versions of this in
> an easier and more Telepathy-ish way than what you've suggested, but I'm
> trying hard not to describe it until I've confirmed exactly what it is you
> want :-)

I hope you understand what I want now.

(In reply to comment #9)
> Since the subject of this bug is telepathy handler clients, I don't want to
> bring per account settings pulled in here. It should be sufficient if I
> deploy a handler-channel-filter in empathy, like this:
> 
>  18 [org.freedesktop.Telepathy.Client.Handler.HandlerChannelFilter 3]
>  19 org.freedesktop.Telepathy.Channel.ChannelType
> s=org.freedesktop.Telepathy.Channel.Type.DBusTube
>  20 org.freedesktop.Telepathy.Channel.TargetHandleType u=1
>  21 org.gnome.GSettings.schema s=org.gnome.Empathy.call

I meant 
org.freedesktop.Telepathy.Channel.ChannelType s=org.freedesktop.Telepathy.Channel.Type.Call1
here.

(In reply to comment #11)
> > "I want to have call support installed, but have a switch that, when off,
> > makes my Telepathy setup indistinguishable from one that doesn't support
> > calls" is one possible use-case. Is that what you're asking for?
> 
> You got this right. Exactly what I want.

OK, that's useful, and is consistent with the design I had in mind.

> > If that's what you're looking for, do you mean all audio/video calls, or do
> > you mean VoIP (XMPP/SIP/...) specifically, i.e. not counting cellular calls
> > if running on an N9 or something?
> 
> I just meant to have VoIP call advertisement controlled

This is considerably more difficult, because all calls in Telepathy deliberately look "basically the same".

> > Imagine you have GNOME, Empathy, KDE and KDE-Telepathy installed. Which
> > application provides UI to toggle this feature? Is it desirable for
> > Empathy's call support and KDE-Telepathy's call support to be controlled
> > together, or separately, or do you not mind either way?
> 
> I'd prefer each application to have its own way to control its
> functionality. That's more intutive to the end user.

Apart from the bit about VoIP vs. cellular, that's relatively easy, and can even be made to work for other "features" than VoIP. I don't think we need anything as elaborate as matching channel classes: we can just have some way to enable or disable an entire Client at a time.

For Empathy in its current state (where the Call handler is separate anyway), we can just have a list of Handlers to ignore, stored by MC and available as a property on either each Account, the AccountManager or the ChannelDispatcher. Something like this:

    property IgnoredHandlers: read-only array of string
        A list of Handlers to be ignored. Ignoring a Handler has three
        effects:

        * the ChannelDispatcher behaves as though it doesn't exist
          when calling UpdateCapabilities and the legacy
          method AdvertiseCapabilities;

        * the ChannelDispatcher behaves as though it doesn't exist when
          determining the list of possible handlers;

        * the ChannelDispatcher replies to HandleWith(that Handler) with
          an error.

    method SetIgnoreHandler(string client, boolean ignore) -> nothing
        If ignore is true, add the given client to IgnoredHandlers.
        Otherwise, remove it from IgnoredHandlers.

(Or perhaps we should use a stronger word than "ignore", like "disable" or "avoid".)

Here is some Python-like pseudocode for how I imagine this would work:

    # disable calls
    >>> cd.SetIgnoreHandler('org.freedesktop.Telepathy.Client.Empathy.Call',
            True)
    # see whether calls are disabled
    >>> cd.Properties.Get('...', 'IgnoredHandlers')
    ['org.freedesktop.Telepathy.Client.Empathy.Call',
     'org.freedesktop.Telepathy.Client.Vinagre']
    # re-enable calls
    >>> cd.SetIgnoreHandler('org.freedesktop.Telepathy.Client.Empathy.Call',
            False)
    >>> cd.Properties.Get('...', 'IgnoredHandlers')
    ['org.freedesktop.Telepathy.Client.Vinagre']

Empathy could have a configuration option:

    [x] enable audio/video calling

whose value corresponds to whether ...Empathy.Call is present in IgnoredHandlers or not; when clicked, this would call SetIgnoreHandler.

If you have both Empathy and KDE-Telepathy installed, audio/video calling would only be disabled if both Empathy.Call and KDE-Telepathy's equivalent were in the IgnoredHandlers list. I think that's what makes sense for the UI you suggest.

If we want to allow Vinagre to be disabled later, that works too - just add it to the IgnoredHandlers (as shown in the pseudocode above).

If a particular Client has more than one HandlerChannelFilter, they'll all be enabled or disabled together; but if you want finer-grained control, a Client with more than one HandlerChannelFilter can always be replaced by a process with "more than one head" (multiple Client names, each with their own HandlerChannelFilter, which can be controlled individually). Older versions of Empathy worked like this.

Here are some things that might require a bit more thought:

Is it important to distinguish between VoIP and cellular calls? If so,
we'll have to think about how to achieve that. My inclination is to defer
that until (much) later.

Are there ever going to be any clients we would want to install
disabled-by-default? (Perhaps some of the things in gnome-games?)
If so, then we'd have to do something more like this:

      property Handler.EnableByDefault: read-only boolean
          If True, this Handler is enabled by default. In older
          Handler implementations where this property is not present,
          it MUST be assumed to be True.

      property ChannelDispatcher.EnabledHandlers: a{sb}
          If { client: True } appears in this map, that client is enabled.
          If { client: False } appears in this map, that client is disabled.
          If a client is not a key in this map, that client is enabled
          or disabled according to its EnableByDefault property.

      method ChannelDispatcher.SetHandlerEnabled(s: client, b: enabled)
          -> nothing

      method ChannelDispatcher.ResetHandlerEnabled(s: client)
          -> boolean: now_enabled
          Remove that client from EnabledHandlers, returning it to its
          default state. Return its EnableByDefault property.

This is still fairly simple, and seems a lot easier to document than matching channel classes. I think my preferred solution is this one: it adds a significant amount of flexibility without adding much complexity.

If we want to make this per-account later, the design with EnabledHandlers doesn't rule that out: each Account could have its own EnabledHandlers property, with the precedence being Account > ChannelDispatcher > default.

I specifically do not want the Telepathy spec to depend on GSettings; the way you configure "global" Telepathy things, or Telepathy accounts, should be to call D-Bus methods on the AccountManager, ChannelDispatcher or Account. If Mission Control wants to use GSettings to store the EnabledHandlers, that's fine, but it should be private to MC (although personally I'd be inclined to use a GKeyFile in ~/.config).

Created attachment 73447 [details] [review]
Add interface for maintaining a list of disabled handlers

Patch to add a new interface for maintaining a list of forbidden handlers on the channel dispatcher

(In reply to comment #13)
> ...
> I specifically do not want the Telepathy spec to depend on GSettings; the
> way you configure "global" Telepathy things, or Telepathy accounts, should
> be to call D-Bus methods on the AccountManager, ChannelDispatcher or
> Account. If Mission Control wants to use GSettings to store the
> EnabledHandlers, that's fine, but it should be private to MC (although
> personally I'd be inclined to use a GKeyFile in ~/.config).

Thanks for clearing things. Yes, I can make things work without GSettings too. I don't know why that didn't occour to me earlier. The KeyFile in that case would contain the list of DisabledHadlers alone. Working on it.

It's getting too complex for me and I am not currently working on it. It would be great if someone finds time to fix this issue in MC5. Thanks in advance.

-- 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-mission-control/issues/64.