← Back to team overview

gtg-user team mailing list archive

Anticipating 0.2 release

 

Hello everybody,

As you might know, GTG community is going quite well with a lot of nice
contribution.

Segphault contributed a nice DBus interface and a review on Ars Technica :
http://arstechnica.com/open-source/news/2009/07/getting-things-done-with-linux-todo-list-programs.ars

We are present on the French wikipedia :
http://fr.wikipedia.org/wiki/Getting_Things_Gnome
(but afaik, not on any other. Mom, look, my name is on a wikipedia page !)


It's then time to prepare 0.2. Official 0.2 bug list is here
https://bugs.edge.launchpad.net/gtg/+milestone/0.2 but can be changed at
any time.

My vision is the following :

Major 0.2 goal :
- support for multiple backends

0.2 optionnal goals are :
- merge Paulo SoC and its plugin system
- Bertrand's major treeview refactorisation
- Merging as many community branches as possible. Request merge as often
as possible.



Regarding multiple backends support, it's a large piece of work that also
requires a whole lot of UI design. Here's my vision of this feature.


1) there are three types of backend. read/write, import and export.

2) one read/write backend will be the default backend. It means that any
new created task will go in that backend.

3) An import backend is only a feed for your task list. Periodically
imported task are then added to your r/w backends. Conceptual example :
reading an rss feed and adding a new task in your list for each new item
in the feed. There's no synchronisation. Once the task is created, it's
created, even if the entry is later removed from the rss feed.

4) consequently, an export backend only copy tasks to something external
and do not care anymore about them.

5) To know in which backend a task should go, we use… tags !
So it means that you have a default backend : localxml
And say that you add another r/w backend : onlinexml

you can then choose in the backend preference that onlinexml is linked to
@not_work and @personnal

When creating a task, the task is added to localxml. When you add the tag
@personnal, the task is added to onlinexml instead (and removed from
locaxml I guess).

As you might guess, it means that the same task could be in more than one
backend. If we have a "one title == one task" rule, it's not a problem.

I really like the idea of linking backend to tag as it means that backend
now have a material meaning. You will not forget to put a task in one
backend because you already used a tag on it.

I think it worths discussing this as it will probably be the most
important feature of GTG. But as soon as we have that, the future will be
open to nearly everything !

Roads ? Where we are going, we don't need roads !





Follow ups