Review splitting and merging of activities

[ederag]

According to the help pages,

hamster/help/C/merge.page

Lines 11 to 14 in 8326504

	<app>Time Tracker</app> does its best to avoid overlaps in activities.
	If you create an activity in the middle of an existing activity, the former
	will be split into two. In other cases of overlapping, the previous entries
	will be shrunk.

This does not work this way now. (the end part is simply disregarded)
The relevant code is still there:

hamster/src/hamster/storage/db.py

Lines 454 to 456 in 8326504

	def __solve_overlaps(self, start_time, end_time):
	"""finds facts that happen in given interval and shifts them to
	make room for new fact

Need to investigate...

[GeraldJansen]

Hmm, works as documented when the activity being split is not the last of the day. For example, I inserted 3 entries, 1) "0900 1200 activity1", 2) "1400 activity2" (in progress) and 3) "1000 1100 last activity" and I ended up with:

[GeraldJansen]

Upon further testing, I find that it always works as advertised, but the documentation could be clearer. When you create a new activity whose start and end time both lie within the interval of an existing activity, the existing activity will be split in two. If you only specify a start time then the previous activity is simply truncated, not split.

[ederag]

interesting observation, useful, thanks !
Still, inserting an activity into an ongoing one fails.

[GeraldJansen]

Whether it fails or is a feature is a matter of opinion I suppose. Currently the behaviour is to truncate the ongoing activity at the start of the new activity, whether or not the new activity has an end time. It is done in __add_fact here.

[ederag]

In my opinion, it would more consistent to split the ongoing activity A in two, inserting the new B inside,
and leaving the last part ongoing (yielding A B A-ongoing).

Besides, trying to insert a B without any end-time yields two on-going activities,
instead of making A end when the ongoing B starts.

But that will have to wait, after 2.3 to the very least.

[GeraldJansen]

I agree about postponing this work.

Besides, trying to insert a B without any end-time yields two on-going activities, instead of making A end when the ongoing B starts.

I cannot replicate this behaviour. For me, ongoing activity A is terminated at the start-time of B, whether or not B has an end-time.

There seem to be a number of possible improvements, so maybe the title should be "Review splitting and merging of activities" or maybe we should create another issue to gather the ideas. Among them:

1. Avoid creating duplicate activities. Currently the logic is based on "<" and ">" operations on times rounded to minutes, and exact matches are ignored. This makes it possible to insert duplicate activities with the same start and end times. Perhaps the logic should use "<=" and ">=".

2. Add a light red background colour to make overlapping activities more evident in the overview window.

3. Add the possibility to merge adjacent identical activities, possibly adjusting start/end times to remove short gaps between them.

[ederag]

I cannot replicate this behaviour. For me, ongoing activity A is terminated at the start-time of B, whether or not B has an end-time.

Sorry for the noise, you are right. I was on an experimental branch. Removing the bug label.

I agree with your points, except perhaps

Add a light red background colour to make overlapping activities more evident in the overview window.

Currently it is impossible to create overlapping activities, which seems a good feature ?

[GeraldJansen]

Here's an example of overlapping activities that are not yet handled:

[src]$ ./hamster-cli track A 18:00 19:30 
[src]$ ./hamster-cli track B 17:50 19:40
[src]$ ./hamster-cli list
Start | End   | Duration | Activity     | Category
-----------------------------------------------------
17:50 | 19:40 | 1h 50min | B            | Unsorted
18:00 | 19:30 | 1h 30min | A            | Unsorted
-----------------------------------------------------
Unsorted: 3h 10min

[GeraldJansen]

Related issue #235