Graphical interface for backends

Should this eventually allow multiple backends to be operating simultaneously?

If so, then all the task-related GUI stuff will have to be changed to show what backend a task is associated with, so the user can control which tasks go where.

Maybe at first it is better to choose just one backend at a time?

What do you think of this mockup (backend_manger_mockup.png)?
It's very similar to the plugins one (<in a Steve Ballmer voice> consistency,consistency,consistency), except that the preference button has been moved up, as in the plugin manager I find it not immediate to understand that the preference is for the plugin, due to its position.

It should have everything Ploum said in the backends email.

Luca > That's exactly how I imagine it but it misses :
- an "default backend (catch remaining tasks)" option
- backend specific option (for twitter/launchpad, it would be login/pass for instance)

Backend specific options should be handled by the backend via the "preferences" button.

I don't catch why we need a "default backend". If a backend catches all tasks, it's a default backend (and surely need at least one backend that catches every task).

Right now I'm thinking that you mean that a backend has exclusive possession of the tasks tagged with his tag. But that doesn't make much sense, since a user could want to give multiple tags to a task that are saved in different backends.

Luca > that's indeed what I've written in my mail. A task could be part of differents backends. But you don't necessarily want all your tasks in one backend. So I believe that there should be a way to just "catch all tasks that do not belong to a backend yet".

thanks. That makes sense.

Attached is a sketch of an alternate idea I described in a list to the GTG-users list. It is a GTKTreeView with one row per tag and one column per backend. [R], [W] and [RW] are icons with obvious meanings...the user can click on some of them to change them. Others are disabled/empty.

A side note: some things, like Hamster integration and notification area features, are "plugins" and can never really be considered "backends". Therefore there will always be a need for a UI to enable/disable plugins and do some configuration of simple options for each plugin. This is also a common (familiar to users) pattern from other software.

I think all backends (besides the default one) should be provided by "plugins" that the user can enable and disable in the same way. If there are options *specific to one backend only* (e.g. the URL(s) of Bugzilla instance(s) from which to pull bugs), then those should be configured in the same way as plugin options.

On the other hand, the user should not have to view many tabs/pages with identical controls to set options *common to all backends*. Hence an interface that gives the user a complete overview.

(waiting on #336605)

I believe that the "classical" approach would be more consistent :

http://static.arstechnica.com/ubuntu1004a3/account-manager.png

But I like the idea of exploring new way of interaction too.

merge requested.