wxGUI/history: Add time period branching to history browser tree

[lindakarlovska]

This PR adds a new node level to the history browser tree which is the part of the new History tab dealing with command history management.

It adds five nodes which are then populated by commands:
Today, Yesterday, This week, Older than week and Missing info.

The hierarchy is as follows:

Missing info is a special node used for situations when history log is in the plain text format (in this case we do not have any info when the command was run).

[petrasovaa]

I like the idea of using today, yesterday etc, but I would still group them by day, so I wouldn't use 'older than week', because then everything will eventually end up there. Maybe something like 'April 22 (today)', 'April 21 (yesterday)', 'April 20 (this week)' April 5 (this month)' and use years of it's not this year: 'December 21, 2023'. Look at how Github shows commits (see commits tab in a PR), but this can get complicated, so maybe a simpler solution would be better.

[lindakarlovska]

I like the idea of using today, yesterday etc, but I would still group them by day, so I wouldn't use 'older than week', because then everything will eventually end up there. Maybe something like 'April 22 (today)', 'April 21 (yesterday)', 'April 20 (this week)' April 5 (this month)' and use years of it's not this year: 'December 21, 2023'. Look at how Github shows commits (see commits tab in a PR), but this can get complicated, so maybe a simpler solution would be better.

I can try to do it.. First, I did it similarly as you suggested - particularly Today, Yesterday, April 2024, March 2024, February 2024 etc. But your solution is more systematic as the grouping is always by the day. The reason why your and the original suggestion are more complex is that the node number is not fixed. Then there is a bit problem with sorting time nodes because the Today node has to be at the very top but at the same time, the Missing Info node has to be at the very bottom. When the number of nodes is fixed - it is easy, we can assign the number and sort them according to their numbers but when not, then it should be sorted based on time. Unfortunately, the Missing info node does not have any time info. So, the easiest thing how to solve it that came to my mind is to artificially assign some time from deep history to it.. I will try to implement it and we can then edit it.

[wenzeslaus]

I can see how this can be useful.

Also: "Missing info" sounds like something one needs to fix (that it is a problem). Perhaps use "No time stamp" or "No time info" instead (which seems to simply state there is no such information). But maybe others perceive this the opposite way?

[petrasovaa]

I like the idea of using today, yesterday etc, but I would still group them by day, so I wouldn't use 'older than week', because then everything will eventually end up there. Maybe something like 'April 22 (today)', 'April 21 (yesterday)', 'April 20 (this week)' April 5 (this month)' and use years of it's not this year: 'December 21, 2023'. Look at how Github shows commits (see commits tab in a PR), but this can get complicated, so maybe a simpler solution would be better.

I can try to do it.. First, I did it similarly as you suggested - particularly Today, Yesterday, April 2024, March 2024, February 2024 etc. But your solution is more systematic as the grouping is always by the day. The reason why your and the original suggestion are more complex is that the node number is not fixed. Then there is a bit problem with sorting time nodes because the Today node has to be at the very top but at the same time, the Missing Info node has to be at the very bottom. When the number of nodes is fixed - it is easy, we can assign the number and sort them according to their numbers but when not, then it should be sorted based on time. Unfortunately, the Missing info node does not have any time info. So, the easiest thing how to solve it that came to my mind is to artificially assign some time from deep history to it.. I will try to implement it and we can then edit it.

I think using an old date is a good approach.

[lindakarlovska]

I like the idea of using today, yesterday etc, but I would still group them by day, so I wouldn't use 'older than week', because then everything will eventually end up there. Maybe something like 'April 22 (today)', 'April 21 (yesterday)', 'April 20 (this week)' April 5 (this month)' and use years of it's not this year: 'December 21, 2023'. Look at how Github shows commits (see commits tab in a PR), but this can get complicated, so maybe a simpler solution would be better.

I can try to do it.. First, I did it similarly as you suggested - particularly Today, Yesterday, April 2024, March 2024, February 2024 etc. But your solution is more systematic as the grouping is always by the day. The reason why your and the original suggestion are more complex is that the node number is not fixed. Then there is a bit problem with sorting time nodes because the Today node has to be at the very top but at the same time, the Missing Info node has to be at the very bottom. When the number of nodes is fixed - it is easy, we can assign the number and sort them according to their numbers but when not, then it should be sorted based on time. Unfortunately, the Missing info node does not have any time info. So, the easiest thing how to solve it that came to my mind is to artificially assign some time from deep history to it.. I will try to implement it and we can then edit it.

I think using an old date is a good approach.

I implemented it using day grouping according to your suggestion @petrasovaa . I think it looks good. (This week, Today, Yesterday) seems to me very useful for quick orientation, so I would keep it. Maybe I would remove (this month) label as it is clear that the month is the current one? And replace it by 'December 21, 2023' format?

[lindakarlovska]

I like the idea of using today, yesterday etc, but I would still group them by day, so I wouldn't use 'older than week', because then everything will eventually end up there. Maybe something like 'April 22 (today)', 'April 21 (yesterday)', 'April 20 (this week)' April 5 (this month)' and use years of it's not this year: 'December 21, 2023'. Look at how Github shows commits (see commits tab in a PR), but this can get complicated, so maybe a simpler solution would be better.

I can try to do it.. First, I did it similarly as you suggested - particularly Today, Yesterday, April 2024, March 2024, February 2024 etc. But your solution is more systematic as the grouping is always by the day. The reason why your and the original suggestion are more complex is that the node number is not fixed. Then there is a bit problem with sorting time nodes because the Today node has to be at the very top but at the same time, the Missing Info node has to be at the very bottom. When the number of nodes is fixed - it is easy, we can assign the number and sort them according to their numbers but when not, then it should be sorted based on time. Unfortunately, the Missing info node does not have any time info. So, the easiest thing how to solve it that came to my mind is to artificially assign some time from deep history to it.. I will try to implement it and we can then edit it.

I think using an old date is a good approach.

I implemented it using day grouping according to your suggestion. I think it looks good. (This week, Today, Yesterday) seems to me very useful for quick orientation, so I would keep it. Maybe I would remove (this month) label as it is clear that the month is the current one? And replace it by 'December 21, 2023' format?

The current look after implementation:

[petrasovaa]

I realized the ordering of commands - most recent first - would be probably better, since the day nodes are ordered like that as well, what do you think @lindakladivova ?

[lindakarlovska]

I realized the ordering of commands - most recent first - would be probably better, since the day nodes are ordered like that as well, what do you think @lindakladivova ?

Yes, seems better. I will create PR for after merging open ones.