On Mon, Jul 13, 2009 at 3:32 PM, Lionel Dricot<[email protected]> 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 : [email protected] > Unsubscribe : https://launchpad.net/~gtg-user > More help : https://help.launchpad.net/ListHelp > -- Bertrand Rousseau Place communale 1, 1450 Chastre, Belgium e-mail : [email protected] tel : +32 485 96 69 86 _______________________________________________ Mailing list: https://launchpad.net/~gtg-user Post to : [email protected] Unsubscribe : https://launchpad.net/~gtg-user More help : https://help.launchpad.net/ListHelp
