gtg-user team mailing list archive

[Bertrand Rousseau <bertrand.rousseau@xxxxxxxxx>]

On Mon, Jul 13, 2009 at 3:32 PM, Lionel Dricot<ploum@xxxxxxxxx> wrote:
> 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.
>

I think the treeview refactoring might not be optional: since it is
actually related to data structures, it should be completed ASAP.
Developing new backends that will have to be converted to upgraded
data structure will certainly bring a lot of pain. I plan to complete
this refactoring soon (I kinda hope it will be done this month)

>
> 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.

It's a nice idea, I agree. We should give us some test examples to see
if some corner cases arise. Obviously we should also have a way to say
that every task should be copied to a backend, with no specific tag
related.

> 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 !
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~gtg-user
> Post to     : gtg-user@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~gtg-user
> More help   : https://help.launchpad.net/ListHelp
>



-- 
Bertrand Rousseau
Place communale 1, 1450 Chastre, Belgium
e-mail : bertrand.rousseau@xxxxxxxxx
tel : +32 485 96 69 86