Created attachment 238938 [details] [review]
provider: Add GoaProvider:get_features() to list supported features

The GoaProvider:get_features() virtual method will be the basis for
filtering providers by functionality to e.g. be able to show only
accounts and providers that provide IM services when requesting the
creation of a chat account from Empathy.

Review of attachment 238938 [details] [review]:

Do we still need a separate GoaProviderGroup and the get_group vfunc? Can't we merge those two or replace one with other?

We can add another flag for "branded" providers, and for the normal control-center UI we can use it to arrange the providers into separate categories as we do now. When we show the UI within the context of an application then we can use CHAT or DOCUMENTS to filter out only the providers that we want.

(In reply to comment #2)
> Do we still need a separate GoaProviderGroup and the get_group vfunc? Can't we
> merge those two or replace one with other?
> 
> We can add another flag for "branded" providers, and for the normal
> control-center UI we can use it to arrange the providers into separate
> categories as we do now. When we show the UI within the context of an
> application then we can use CHAT or DOCUMENTS to filter out only the providers
> that we want.

What about providers providing multiple features, which category do we choose?

We could either require that only branded providers can return multiple features or repeat each non-branded multiple-feature provider under the appropriate category, your call.

I don't know what Allan or Jon has in mind ...

I have been abusing BRANDED for even generic things like ownCloud because it offers multiple features and hence multiple integration points. So, I figured that it is ok to highlight them.

So in the normal c-c UI, we can show any provider that has the BRANDED flag (irrespective of whether they have PHOTO, DOCUMENTS, CHAT, CALENDAR too) in the first page, and then the remaining MAIL, CHAT, CALENDAR, TICKETING, etc in the next page.

For the application context UI, we can get rid of these pages / categorization and just list out all the providers offering a particular feature. So that way Empathy users will not be bothered with IMAP/SMTP or CalDAV crap.

(Ofcourse there are edge cases like Facebook which is BRANDED even though it only offers CHAT)

Created attachment 238975 [details] [review]
provider: Add GoaProvider:get_features() to list supported features

This also deprecates goa_provider_get_provider_group() to be replaced by
goa_provider_get_provider_features().

I've deprecated _get_provider_group() and done a simple conversion of g-c-c to _get_provider_features() in bug #695885. I've not done any change to how accounts are shown though, I'd rather see if the UI needs to be streamlined once the functionality is in place.

Review of attachment 238975 [details] [review]:

Thanks for the patch. Mostly looks good to me.

::: src/goabackend/goabackend.h
@@ +30,2 @@
 #define __GOA_BACKEND_INSIDE_GOA_BACKEND_H__
+#include <goabackend/goabackendenumtypes.h>

This isn't really needed for this patch, right? Could you please split it off into a separate patch? Just a minor nitpick.

(In reply to comment #6)
> accounts are shown though, I'd rather see if the UI needs to be streamlined
> once the functionality is in place.

That is fine.

It should be possible to autogenerate the show_accounts UI for non-generic providers. We'll see. It is not a blocker for these patches in my opinion.

Created attachment 239229 [details] [review]
backend: Export the enumeration type definitions

Export the GType definition for the GoaProviderGroup enumeration to
be able to box it inside GValue, etc.

Created attachment 239230 [details] [review]
provider: Add GoaProvider:get_features() to list supported features

Split the enum header fix.

Thanks for the patches.