Apps/Recipes/Todoist - GNOME Wiki!

Notes from todoist planning meetings

Present: Matthias, Ekta, Georges, Rohit

We met on May 4 to discuss what goa changes we need for todoist support in both gnome-recipes and gnome-todo.

Decisions:

We will try to share the code for talking to the todoist api, probably just as a copied file initially, not a shared library

Tasks:

Investigate if we can just link to libgoabackend, or if we need to add an add_provider api to libgoa
Investigate the current goa dbus interfaces - are they suitable as a portal, or do we need to define a separate portal interface
Clarify the behavior on app removal:
- Do we just hide the provider, or do we remove the account ?
- We could hide it and quietly remove it after some time (say, 2 weeks)
- Or we could ask the user what to do (annoying...)
Initially, we can do the same that gnome-calendar currently does, and bring up the goa panel for account setup UI. We just need to make it work in a sandbox... but this is a separate decision for gnome-todo and gnome-recipes - the UI does not have to be the same. Just the account should be shared

Later on (not part of the todoist work, need to be discussed with designers)

If we hide an account, the privacy panel could learn to purge it like temp files and history data
Per-app access control for account information in goa

Next meeting: Tuesday, May 9

Present: Matthias, Georges, Ekta, Rohit, Debarshi

Plan:

Keep todoist provider on the gnome-online-accounts side (together with all the other providers), since we don't want to inject code from a sandboxed app into a session service (as we'd have to do if the provider lived with the apps)
Add a 'hidden' or 'only-show-with-account' property to the provider api in gnome-online-accounts, and use that to hide the todoist provider initially
Apps don't link against libgoabackend, just libgoa
Add a ListProvider api to libgoa that lists all providers, including hidden ones like todoist
Add an AddAccount api to libgoa to set up an account for a provider
The ListProvider and AddAccount calls will go over dbus and be the 'goa portal', basically
Make the gnome-todo and gnome-recipes show a "Set up Todoist" button if the todoist provider is present (using ListProviders), and call AddAccount when clicked. If an account already exists, we want to just reuse it (may still need to call into goa to let the user opt-in to having the app use this account)
If it turns out to be a problem that the todoist provider is hidden until we set up an account from the application side and stays visible after the applications are uninstalled, we can add a desktop file marker like X-Goa-UsesTodoist=true, and show the provider in the goa panel as long as an app with that marker is installed

Present: Ekta, Georges, Matthias, Rohit

Revisited the plan from last time.

We discussed that ListProviders is probably not a hard requirement for our case (we can just hardcode "todoist", and deal with AddAccount returning an error if it is not available), but it is a good idea to have in general. One place where it is useful is to provide display data such as names and icons.
Division of labor:
- Rohit and Georges will draft the libgoa apis and docs, for review by Debarshi
- Ekta will continue to work on the todoist provider in libgoabackend
- Matthias will draft the portal api to sit in the middle and talk to designers about portal UI
Not assigned yet:
- adding a hidden property to GoaProvider in libgoabackend
- making the online accounts panel use it for filtering providers to display (Georges will probably do this)
- writing the portal implementation (Matthias will probably do this)
Next checkpoint: Friday, June 2

Open questions:

Providing objects on the bus and adding/removing interfaces at runtime does not fit well with the portal approach. To support change notification, this draft instead offers a global AccountsChanged signal - is that good enough ?
Since we are registering only a single 'GNOME' application with the online providers, there is no way to actually revoke access from individual applications. Is this a problem ?
Currently, EnsureCredentials() only has the data needed for Oauth2 - do we make this more general to cover other methods ?
No clear yet what to do about interfaces like org.gnome.OnlineAccounts.Calendar
If we expect GetAccounts to present a dialog where the user can select which accounts to make available to the application, that is somewhat incompatible with saying
- "call GetAccounts in response to AccountsChanged". GetAccounts() probably needs to be non-interactive for this to work.
On the goa side, we should have per-application permissions for this to make the most sense

Some quick sketches of how portal ui for this could look: get-or-add-accounts.png ensure-credentials.png

Even sketchier sketches for how the control-center might change: goa1.png goa2.png