Bug 32979

Summary:	Add extensions to allow accounts to be hidden from the main AccountManager interface
Product:	Telepathy	Reporter:	Will Thompson <will>
Component:	mission-control	Assignee:	Telepathy bugs list <telepathy-bugs>
Status:	RESOLVED FIXED	QA Contact:	Telepathy bugs list <telepathy-bugs>
Severity:	normal
Priority:	medium	CC:	vivek
Version:	git master	Keywords:	patch
Hardware:	Other
OS:	All
Whiteboard:	review+
i915 platform:		i915 features:

Description Will Thompson 2011-01-10 11:50:08 UTC

I have been working on an extension for Mission Control to allow certain accounts to be hidden from the main AccountManager interface. The use-case is building services on top of IM protocols, using accounts which are not actually intended for human consumption. Rather than requiring every UI to do special work to avoid showing the account to the user, we simply do not list the account in AM.ValidAccounts, shunting it off to AM.Interface.Hidden.ValidHiddenAccounts. In all other respects the account behaves normally. See http://people.freedesktop.org/~wjt/telepathy-spec-hidden/spec/Account_Manager_Interface_Hidden.html and http://people.freedesktop.org/~wjt/telepathy-spec-hidden/spec/Account_Interface_Hidden.html for the proposed D-Bus API. (I haven't polished these very far, hence my not proposing them for merge to the Telepathy spec just yet.

Anyway! I have an implementation of this in Mission Control. The branch is actually rather big, so I've split it into four and a half distinct chunks, all built atop one another.

'miscellaneous-cleanup' <http://git.collabora.co.uk/?p=user/wjt/telepathy-mission-control-wjt.git;a=shortlog;h=refs/heads/miscellaneous-cleanup> does some preliminary cleanup on the test suite and a couple of debug messages.

'hidden-for-keyfiles' <http://git.collabora.co.uk/?p=user/wjt/telepathy-mission-control-wjt.git;a=shortlog;h=refs/heads/hidden-for-keyfiles> implements the above interfaces, with no special handling in the storage backends. So they'll work fine for accounts backed by a keyfile, but they don't work for accounts-glib-backed accounts.

'accounts-glib-cleanup' <http://git.collabora.co.uk/?p=user/wjt/telepathy-mission-control-wjt.git;a=shortlog;h=refs/heads/accounts-glib-cleanup> does some preliminary refactoring of the accounts-glib backend, fixes a couple of bugs and does a little clean-up.

'hidden-for-accounts-glib' <http://git.collabora.co.uk/?p=user/wjt/telepathy-mission-control-wjt.git;a=shortlog;h=refs/heads/hidden-for-accounts-glib> adds a subclass of the standard accounts-glib backend which looks for accounts of the 'HiddenIM' service type and marks them as hidden.

I am somewhat sceptical of the merits of including the latter in stock MC. Currently it has to be in-tree due to bug 32914, which I have begun to fix (hence the half-branch I mentioned above).

 24 files changed, 1033 insertions(+), 374 deletions(-)

I'm in danger of losing all the good karma I earned by deleting MinimumPresence. :'(

Comment 1 Will Thompson 2011-01-11 08:53:17 UTC

I've updated the hidden backend to be conditionally compiled, and to set a different name and description to that of its parent class.

Comment 2 Vivek Dasmohapatra 2011-01-13 09:08:45 UTC

Minor quibble: The interface alread has Hidden in its name,
and only deals with hidden accounts, so I think it would be
better not to have "Hidden" also in the properties and methods:

ie:

  Blah.Hidden.ValidAccounts

rather than:

  Blah.Hidden.ValidHiddenAccounts

Admittedly a very minor point: Other than that, looks fine.

Comment 3 Will Thompson 2011-01-14 02:29:59 UTC

(In reply to comment #2)
> Minor quibble: The interface alread has Hidden in its name,
> and only deals with hidden accounts, so I think it would be
> better not to have "Hidden" also in the properties and methods:
> 
> ie:
> 
>   Blah.Hidden.ValidAccounts
> 
> rather than:
> 
>   Blah.Hidden.ValidHiddenAccounts
> 
> Admittedly a very minor point: Other than that, looks fine.

This is to work around a dbus-glib bug. The signal names need to be unique across all interfaces implemented by an object. So AM.I.Hidden.HiddenAccountValidityChanged can't be called AM.I.Hidden.AccountValidityChanged, because this conflicts with AM.AccountValidityChanged.

(It works by objects emitting corresponding GObject signals; unfortunately the names dbus-glib expects are based only on the signal name, not on the interface too.)

It makes me unhappy too! The properties only have stupid redundant names for consistency, so I could rename those, depending on whether brevity in property names is worth the inconsistency.

Comment 4 Simon McVittie 2011-01-14 03:31:00 UTC

(In reply to comment #3)
> This is to work around a dbus-glib bug. The signal names need to be unique
> across all interfaces implemented by an object.

Methods should usually also be unique across all interfaces, for ease of use with deficient bindings (dbus-python in this case). Properties I'm less sure about, but I'm sure there's some binding that gets this wrong too :-/

Comment 5 Vivek Dasmohapatra 2011-01-14 04:41:48 UTC

Eh, I wouldn't bother renaming then. Just shake your fist at dbus-glib and move on for now, I reckon.

Comment 6 Vivek Dasmohapatra 2011-01-19 09:59:40 UTC

Released in 5.7.2

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.