On Mon, Jul 13, 2009 at 11: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'll do what I can :) > > 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. > Unless it's got a tag that goes to a different backend, right? > 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. > IIUC, after it's created, you can still delete it from your other backends (your default read/write backend?) -- is this right? > 4) consequently, an export backend only copy tasks to something external > and do not care anymore about them. > Can you give an example for this? > 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'm not 100% sure I follow. Just to confirm, you're saying: - tags mean something in the context of my life - backends are strongly associated with a tag - therefore backends mean something in the context of my life And then something about not forgetting that I don't quite get :) > 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 ! > It definitely sounds very cool. I can think of a couple of things that would help me understand this better The first is a sentence or two answering the question "Why backends?". I think I've got a rough idea, but it's often good to have these things written down. The second would be a quick sketch of the Python interface for a backend. > Roads ? Where we are going, we don't need roads ! > :-D Apologies if these questions have been answered elsewhere. jml _______________________________________________ Mailing list: https://launchpad.net/~gtg-user Post to : [email protected] Unsubscribe : https://launchpad.net/~gtg-user More help : https://help.launchpad.net/ListHelp
