Taskwarrior support

[Armadill0]

On the harbour comments someone requested the possibility to save the data in a todo.txt formated file.

I just read the todo.txt format specifications: https://github.com/ginatrapani/todo.txt-cli/wiki/The-Todo.txt-Format

It seems the format is very simple. But because of the simple data structure of TaskList it won't be possible to support the complete todo.txt functionality. On the other hand I would say that this is not needed by an export function from the TaskList side. The data which could not be set in the export is priority, project and context.

The question is now, on which data basis should the export be generated? TaskList could generate one todo.txt file for each list, but is this really a good idea? TaskList could also export all tasks of all lists to one todo.txt file and mark each task with the list name as a project or something like that.

Let's discuss what the best solution would be.

[icaruseffect]

As i started this topic at the store here some ideas. The export should be more like a sync process. So the todo.txt should be synchroneous with the local database. This could become kind of difficult on external changes. On the other hand it could be an option to choose todo.txt as alternative backend. I would prefer the option, where all lists get synced to one todo.txt and the the individual list items get the @project mark. I will try to contribute to this functionality with some code. Cheers :)

[Armadill0]

I'm a bit concerned about the second local database. Do you really think that this makes sense?

The problem is: Sure with additional code and some code cleanup (completely deviding database from logic content in a MVC model) we could always update the todo.txt database. BUT: We could never update the SQLite database if the todo.txt database is changed outside TaskList. Hacking the database without running TaskList is no option for me.

A reading of the second database on startup and a syncing would be possible, but this will lead to a very complex code base, which is very difficult to extend.

And a single sided update process of the todo.txt database doesn't make sense for me, does it?

Currently it seems to me, that an export only function (maybe also on an automated basis, if there are changes made to the primary database are made) is the better way.

What do you think?

[icaruseffect]

In perspective of future integration of caldav(issue #2) it seems to be a logical step, to divide the backend in a settings db and a data db. So a re-factoring will be needed now or later anyways. The data db then can be accessed by an independent interface.

Actually we could handle the todo.txt format more or less as an database, just without SQL selectors and interface it via one of the many implementations of todo.sh, so we don't have to reinvent the wheel.

An export only function doesn't really make sense for me, because when i change it elsewhere, i also would like to re-import it. Thus i then have to clean my local database and import the external file. But in a short time perspective it would work. :)

An example for a really far progressed app for todo.txt list processing i would suggest a look at the codebase from simpletask[https://github.com/mpcjanssen/simpletask-android]. I had no time yet to do this, but maybe we could lend something from there.

So in summary: for short term a import+export with lokal purge would work, in longterm there should be a unified backend interface to work with the backends and clean up the code. Else there will be an import/export mess.

Maybe i made some logical errors here, what do you think?

[Armadill0]

Sure, the backend cleanup needs to be done in any case. Especially the task append things directly from the DB class has to be tidied up.

Additionally there should be a database class which handles all read/write operations to all activate databases. CalDAV will also be another database which should be supported.

Also the lists and tasks should be hold as objects to simplify the accesses to the data structure for adding/editing and deleting tasks and lists.

But honestly as I'm no real developer, only an admin, I'm not sure how to implement this the best way. :-)

All in all there's much work to do.

[icaruseffect]

Thats true. It's much work to do. I will have a first look over the source code and try to install the new SDK, which failed the last times. Then I will try to get an idea how the refactoring could look like.

Honestly I'm also just a student and my main programming language is python. But I have to (re)learn for one subject c++ & java anyways and till now it was not that difficult.

In this case I think the best implementation is that one, which works ;)

So do I get the idea right, that the local storage should be kept as an parallel db instance together with some new db instances for new protocols as caldav and todo.txt? In this case, maybe we can keep the internal sql db as an backup solution for (accidentally) deleted tasks/notes and update it with deleted & added items. That looks kind of useful and maybe limits the need of refactoring.

Do you have more thoughts or ideas on this?

[zodtm]

You could also have a look at taskwarrior ( http://taskwarrior.org/docs/ ) as it also uses a simple txt-file as storage. There is already a server for syncing and a mobile solution for android ( http://mirakel.azapps.de/ ). After using TaskList for a couple of days I think it would be the perfect fit to taskwarrior.

I would export just one textfile and map the lists in TaskList to contexts in taswarrior (@home, @work ...). That way one would get a nice view at the tasks for the current context in the home-screen.

Thanks a lot for this great app!

[icaruseffect]

Hmm, as I'm moving now to taskwarrior (more efficient and wider base) i will focus on this one. And as the formats are quite similar, it shouldn't be a problem to support both. My main problem now is, that my SailfishOS SDK hangs on install. I have to wait, until the jolla devel team comes up with a solution.

[icaruseffect]

@zodtm What exactly do you mean with mapping to contexts ? Do you mean, the widget on rhe homescreen should display instead of the current list a with an @ marked content?

[zodtm]

Sorry, the @ prefixes were a bit misleading. In taskwarrior-lingo they should be +

By mapping I mean that tags in taskwarrior should be mapped to lists in TaskList, since IMHO they are used for the same thing: separating a big list into smaller pieces.

Personally I use the tags in taskwarrior for the context (home, work, phone, errands, ...) and that is the same way I am using lists in TaskList. Therefore I really like the fature, that you can quickly switch lists from the homescreen widget. When I am at home I switch to the home-list, so that I can quickly see and add tasks about stuff I have to do at home. Same goes for work.

[zodtm]

About the backend: I haven't looked at TaskLists internals, but from using it I would think a taskwarrior-textfile should make a perfect backend.

I think that by using a textfile as a backend you could utilize existing sync solutions like vdirsyncer or even git (one could then clone the file and push/pull it to/from some other machines)

[icaruseffect]

I'm also thinking about a 'full backend switch' solution. This means that we somewhere in the settings have an option for choosing the backend. The downside would be, that we loose already created tasks. a plan would be: -create an export function -create an import function -make the backend exchangable by an plugin function I think this needs at least a conversion of the backend part to a class based structure with defined functions to access the DB. As i still have no answer from the jolla devel team about the SDK (well from the support team) I maybe can start next week with some coding

[Armadill0]

Ok, so many posts... Some words from my side now. :-)

1.) SQLite will persist as primary database in any way. Just to clarify this, as it sounded that you want to change this to a text file database with a taskwarrior layout.

2.) I'm currently not convinced that Taskwarrior can survive as a second database instead of an export format. Some thoughts on my guessed reasons:

• The Taskwarrior DB is already persistent in some way, compared to the TaskList SQLite DB, which is still only using it's first version. This could cause problems with the future development of TaskList if a feature is not possible to implement with the Taskwarrior DB.
• LocalStorage (the SQLite QTQuick module) has possibilities to upgrade databases, which is very helpful for further extensions of the TaskList database.
• SQLite is not a full SQL compatible database, BUT you have an abstraction layer where you can use many helpful SQL-Commands like subselects and JOINs, which are already in use for the new smart list features. I think this makes SQLite much more powerful and I have to do some research on the Taskwarrior database format, but I don't think it can compete with SQLite.
• SQLite is a fully supported feature by QTQuick, which is simple to use and you can rely on many years to the future. The Taskwarrior DB middleware has to be used from an external source or has to be written on our own (which I think is the worst way as I'm trying to avoid to implement own basic features).

There are many more things I could mention, but those are the most important. Please think of them, if you can manage to provide code for all those things. Especially the future extensions are very important. I, for myself, am not using Taskwarrior and I'm sure I would drop the Taskwarrior support soon again, if there is nobody who could help to implement the curent basic and future features.

3.) I don't want to prevent Taskwarrior as a second database, but I think currently it would be better to support it only as an export feature. Maybe there are other ways to keep Taskwarrior on your PCs and the TaskList database synchronized. One of my main goal is the CalDAV sync support. Can't Taskwarrior also be synchronized with CalDAV, so that we have a powerful sync backend, where we don't have to synchronize this on our own?

Just my 2 cents. ;-)

[Armadill0]

Closing this as there's no more activity.

Pull-requests with more export functionalities are always welcome. :wink:

[Armadill0]

As there are more and more people requesting the Taskwarrior support, let's see if we can find a solution for this.

[cintema]

I'd suggest a somewhat stripped down TW support, like just the possibility to either import or sync all tasks from taskd in one seperate TW-list. TW has just too many features, from which most of them are not really needed on a mobile.

[zodtm]

Hi @Armadill0 Thanks a lot for looking into that again. I would love to see TaskLists nice UI married to Taswarriors power and syncing abilities.

I agree with @cintema . Not every feature of TW makes sense on a mobile. IMHO the most important thing is to add tasks to the inbox (and have those synced). Since task has already been ported to sailfish [1] one could sync TaskList's sqlite to a TW-style txt-file and let task take care of the syncing. I personally would not mind doing the syncing "manually" using FingerTerm.

[1] https://together.jolla.com/question/91491/isnt-there-a-native-todotxt-or-taskwarrior-app/

[borghal]

I, too, would love to see the beautiful native TaskList combined with the universal, syncing Taskwarrior. Maybe an automated export/import to the task file? Maybe TaskList just needs a way to assign/check/import taskwarrior IDs to be able to sync databases?

[borghal]

oh, or just a function that clears the database on startup and imports taskwarrior data. Before shutdown the data is exported again. Does that make any sense? I'm not a programmer, just trying to add some ideas. Don't be offended by my ignorance :-)

[cintema]

Hi @all, I came across https://inthe.am/ which is a very useful sync server for taskwarrior clients. This site might suite very well for all those dedicated to taskwarrior AND GUI-Apps and it offers conversion of tw-tasks to several other protocols, such as RSS or iCal feeds but also to Mirakel, Trello or Pebble feeds (neither of which I know). I use it to convert tw-tasks to RSS and iCal and it seems to work. It can also be accessed through a RESTful API in JSON format (http://intheam.readthedocs.org/en/latest/api/task_format.html). This might also be an option for integration in taskwarrior...

[manglewit]

Thank-you for re-opening this feature request. I too would like to see some form of integration with taskwarrior if at all possible. Obviously, you need to scratch your own itch, but if your itches are in the same area of skin as taskwarrior integration, I'll be happier than at present.

Echoing borghal above, I'd humbly suggest writing (a) a filter that can merge-import from todo.txt and (b) some form of export format that taskwarrior can use to merge-import back. As a start, I would be happy to have a manual or semi-scriptable process. If it means plugging the phone via USB into the PC and moving a file across, that's fine by me. Personally, I like interim data files that can be inspected and edited to resolve problems, if necessary. Like borghal, please do not be offended by my glaring ignorance.

I make less use of TaskList than I should, but I still appreciate the effort you have gone to to write it and make it available. Thank-you.