New model classes, storage backend and user interface - on the way to 2.0!

[Manuel-Kehl]

Hello fellow developers ✌️

This is going to be one of the more important threads for collecting design and implementation concepts concerning the "new backend" which many planned future features, e.g. time tracking, depend on.

I have decided to represent the task as a subclass of Gtk.ListStore for now to provide a quick, yet fully functional result. However I never intended to solely rely on this approach. In fact I always had a set of "handcrafted model classes" in mind for a future version (>= 2.0), which we - hopefully - are about to reach during the next months 😉

General Idea

The Model Classes

One might want to store information about a task than its name and done status. Utilizing Todo.txt allowed for some meta info to be encoded in the string itself, but even that is somewhat limited. Therefore I propose the creation of a new model structure, consisting of a Task class that can contain as many extra attributes as necessary and the implementation of a TaskStore class that is not based on Gtk.ListStore.

It must however provide a function to represent (part of) its data by means of a Gtk.ListStore to communicate with the UI elements involved. Also signals emitted by Gtk.TreeView must be handled so that the underlying model is varied accordingly.

The GUI

The GUI has been designed to be simple and minimalist. Adding tons of new fields to the task object must not "bloat" the user interface. Thus I considered exposing by default only task name, priority and done status.

Additional information like associated projects or contexts might be displayed underneath a task's entry upon selection of the task. Following this approach one could also solve #60 by truncating overflowing text indicated by an ellipsis. The truncated text might then be expanded to a multi line view, once the task has been selected.

More advanced attributes could be accessed via a modal dialog, e.g. upon double clicking.

The Storage Backend

Todo.txt has served us very well and offers many possibilities that we have not even utilized so far. That being said it might not be the best option for making all the potential meta data persistent, as this would break Todo.txt's minimalist philosophy to a certain degree.

I suggest evaluating several persistence APIs that allow for storing our new model objects in JSON or XML format. Sqlite might also be an option if you can provide strong arguments - I simply prefer somewhat human-readable and parsable alternatives 😄

But I love Todo.txt! 😠 How am I supposed to sync with my phone now?!

So do I and be assured that I am not planning to drop Todo.txt support at all. It is simply not wise to use it as a main storage backend. I propose the implementation of a SynchronizationInterface class that handles exporting to and importing from various sources of which Todo.txt will be most easily implementable, as we already have the parsing code available. Following this approach we'd get the solution to #19 "for free".

Final Words

All the above matters are officially "open for discussion" now and I am excited about your opinions and engagement. Everyone is invited to comment on this issue and of course more than welcome to start implementing (hint: @JMoerman, @dardevelin, @voldyman, @fredmwangi et al. 😜 ) I propose a next-gen branch for all development in that regard.

I am currently in the middle of my bachelor's thesis so I might probably not be of much use during the next two months, but I wanted to publish my thoughts at this point, as @JMoerman has already indicated additions that would somewhat fall within this scope.

[JMoerman]

I think that it may be worth to add projects to the GUI as it may reduce clutter if done properly. (Displaying only task name, priority and done status, for the tasks themselves. Showing the existing projects elsewhere, allowing filtering of tasks.)

My experimental branch currently has a new todo.txt parser/writer and task class. It has some gee dependencies, but I can replace everything with native glib objects later on. It needs more work as I designed it without knowing what would be used later on and it probably can use some improvements in general.

[voldyman]

Do you want the different backends to be shipped as plugins or are they embedded in the program?

If we keep the back ends as shared libs, we only define an interface in the main program and the plugins must implement them, libs like libpeas or something simpler can be used.

The UI only needs a few things from the back end

• list of todos
• status of todos
• maybe a widget that is displayed in the dialogue (which is shown when the user clicks the item)
• a bunch of signals that represent certain actions

Hence make the backend loosely coupled with the UI so if in the future we change the UI the back ends are unaffected

disclaimer I typed this in a hurry

[JMoerman]

Here is a quick sketch of a possible implementation of projects:

If we are to support different back ends, it's of course important that we don't discard unsupported information. How would the different back ends be used: one or the other, separated, or kept in sync with each other?

[JMoerman]

Plugins now work properly.
I have to fix some code, tidy it up a bit and bring back missing stuff like the menu button etc...
When that's all done I'll push it to my wip branch. I would like some feedback when that's done.

https://youtu.be/UL84JZ_a5zI
(Plugin selection screen and back button are placeholders)

-edit: Some info about the current plugins: A plugin has complete freedom in regards to the first and last page (no direct access to TimerView though), this can cause plugins to function quite differently from each other. If plugins cant use their own specified widgets, some functionality will be impossible to implement in plugins. (And some things like reordering, may not make sense for some backends.) We need to find some balance between consistency and possible functionality.

[JMoerman]

I have been working on this: https://github.com/JMoerman/Go-For-It/tree/wip for a while, it isn't finished, but I would like to know your opinion on it.
It currently isn't possible to make a plugin for it that only implements a backend, but it shouldn't be hard to add that. (I want to support plugins that differ in more aspects than just backends.)

I split go for it into an application and a library to get it to work on Windows.

The functionality of the current version can be found in /plugins/classic (mostly a lazy copy paste port with a few extra fixes), which at this moments needs to be compiled and installed after installing the application and library.

I'm not sure if the extra namespaces GOFI.API and GOFI.Todo make much sense right now, I might remove them.

Edit: I also removed Gtk+ 3.0 < 3.10 support for now, it can be re added later.