Hi, On Sat, Oct 8, 2011 at 12:11 PM, Ted Gould <t...@gould.cx> wrote: > So to be clear, you see GOA's configurability to be in setting up new > account groups, but new protocols. So I could add "Corp. Account" but > if my corp. uses a protocol that GNOME OS doesn't use otherwise, I > couldn't add this. Trying to understand what configurability you expect > in the future.
The way to look at GOA is that it's just one provider of accounts. As I said, GOA is by no means a substitute for having a separate way to configure an app for accounts - if it was, then GOA would be a choke point in this way: it just makes no sense to add protocol-support in both the app and in GOA to make things work - you end up with ugly dependencies between the app, libgoa and the running goa-daemon(8) instance. Which makes it really hard to get anything done. So just from a technical point of view the "I want to use GOA to configure everything" is a non-starter, I think. You should think of GOA as something that the app can optionally depend on to make using 'suites' of services (e.g. Google, Yahoo) just work in the sense that you logon once and then the auth token is used for all services, e.g. mail, chat, calendar etc. And no-one says that only GNOME apps (such as Evolution) can use this - no one is preventing e.g. Thunderbird from consuming the same kind of data. The other thing is that we do not want the UX in the Online Accounts preference pane to look like this http://people.freedesktop.org/~david/lots-of-account-types-that-i-don't-know-about.png Not that there's anything per-se wrong with that kind of UI in Empathy (the same way there's nothing wrong with all the Chrome you find in e.g. Gimp) - we just don't to expose the user to it if we can avoid it. The idea of Online Accounts has been from the start that this is something the user sees in either the OS installer or as part of some "Initial Setup" experience, see e.g. https://live.gnome.org/GnomeOS/Design/Whiteboards/InitialSetup So you ask about extending GOA and I've already explained a bit about that upthread. It's not that I'm 100% opposed to it, heck as I said we used to read config files, and double-plus-heck, the code is already using gio extension points, see http://developer.gnome.org/goa/unstable/GoaProvider.html#GOA-PROVIDER-EXTENSION-POINT-NAME:CAPS http://developer.gnome.org/goa/unstable/GoaProvider.html#goa-provider-get-for-provider-type we just don't read any GIO modules just yet. As I said upthread, the only reason this is so is basically because a) providing a stable API for extensions is expensive; and b) providing a stable config file format is also expensive; and c) it's too easy to abuse to create substandard UX in the Online Accounts preference pane. Well, where to go from here? a) and b) will clearly be non-issues around 3.4 or 3.6 as things stabilize [1]. It's more c) I'm concerned about. To resolve this we need to work with the designers to make sure that the UX can scale in the presence of many different account types. Either way, I don't get why you are so concerned about whether GOA can be extended. If you buy into the idea that apps will always need to have a separate panel for non-mainstream accounts then... then the app can provide the extension point and config-file merging from .d-directories. David [1] : note that we said the same about GVfs and GVfs backends are still private GNOME API 3 years later. Which turned out to not really be a problem even though everyone whined about it about the fact that there is no stable GVfs API. But it works really well for GVfs, heck we got all the interesting parts _in the GVfs tree_ instead of them being random 3rd party things seeing less testing. It's similar to how the Linux kernel works. _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list