Track and visualize time spent per task

[eOvic]

Track and visualize time spent per task

Adds the ability to name the task you're working on during a pomodoro and see how that time breaks down in the statistics.

• Timer view: a task button to set the current task, with recently-used suggestions.

• Stats: a "Tasks" breakdown (time per task, with share bars) on the day, week, and month pages, plus a per-pomodoro "History" list on the day page.

• Storage: database schema v4 adds a task name to pomodoro time-blocks and stats entries; migration is additive and existing history is preserved. Unit tests updated for the migration and task tracking.

[eOvic]

This merge request solves this issue: #734

[kamilprusko]

Thank you for spending time on this and contributing.

It needs more work, but primarily it needs a proper design phase. Decisions like storing task names as strings and tying a single task name to the whole time-block would be hard to change later...

My feedback for the current implementation:

• current-task in gsettings - it should be stored in database. During SessionManager.restore it should restore last selected task. If task is assigned to a pomodoro block, it should restore values for all blocks.

• SessionManager.current_task setter. The this.save.begin (); there is just wrong. It should mark the time-block as changed, it will trigger the save without double calls.

• storing current_task as string is not future proof. If it were an object it could make editing easier, store completed timestamp, store source_id (if imported), be linked to tags...

• StatsManager - in my opinion it should be stored as a separate category "task", with source_id pointing to TaskEntry model/table. It would allow to track time multiple tasks for a single time-block. It may need rethinking - we only care about total duration for a task per day, which lead me to think that we could create entries directly in "aggregatedstats" table. We need to account that long tasks need to be split at "midnight" (4 AM) to appropriate "buckets".

• TaskBreakdown - I would prefer if fetching was done in StatsPage.fetch_entries / fetch_aggregated_entries, then process_aggregated_entry / process_entry should populate/update a list model. The displaying widget would receive the model as input. This way updates would be propagated to all widgets in "real-time".

• Try not to do database operations in widgets that display data. I strive for MVVM architecture - at least move database operations to view widget (StatsPage).

• StatsDayPage.queue_update_lists with 500ms timeout - you're adding extra fetching/processing on top of the current one. With StatsManager.entry-saved / entry-deleted signals it's doable without extra fetching (in the current state).

• There is no task selection in compact mode

• There is no task management in dbus-services.vala and no plan for implementing this in GNOME Shell extension

• Long tasks names get ellipsized - not good when reviewing tasks on monthly stats. When we hit MAX_TASK_NAME_LENGTH there's hardly any visual feedback - copy and pasting may end up with unexpected behaviour. 100 character limit feel too restrictive.

• this.task_entry.input_hints = Gtk.InputHints.NO_SPELLCHECK; ?

• TaskButton a lot of code is in vala. Some of it should be offloaded to .ui

• CREATE INDEX "stats-date-task" ON "stats" ("date", "task") WHERE "task" != ''; - nowhere you query by task, seems this index is not used

• just one unit test test_track_time_block__task, no tests for SessionManager.current_task

Screenshots for anyone else viewing this PR:

I suggest to stop work for now and prepare mockups first on how the time-tracking / task-list should work. Let's keep the discussion about the design in #734