Having subcategories really be subcategories (partitions) of the parent category

Features
#1

For example, if I have a Programming category and two children Emacs and Vim.
Emacs has as children Java and C++ and the same applies to Vim.

Programming could have a regex for filtering all events as it is a “root” category.
Then, the Emacs category could have a regex to filter the events of the Programming category to only take Emacs windows into account (regex: Emacs).
The same could be done for Vim (regex: vim).
The events that are not taken by the Emacs category nor the Vim one stay as Programming.

What this gives us is very precise statistics and near-zero conflict between children of different categories. For example in this case, if I edit a java file with emacs, it will go to:
Programming -> Emacs -> Java
If I edit a java file with vim, it will go to:
Programming -> Vim -> Java
no conflicts and it’s really easy!

If I edit a file using Sublime, it will go to:
Programming
If I edit a file using Emacs which is not java nor c++, it will just go to:
Programming -> Emacs

I think this is a way simpler solution than the current one. This could be optional to not trouble the people that don’t want this feature, but I think this could be a sane default for categories in ActivityWatch.
I hope this was clear enough to get the point across :wink:

Priority of categorizing rules
#2

Sorry, but I don’t understand. Doesn’t it already work like that today?

If I have a category “Programming” which contains the regex “GitHub” and a subcategory with the name and regex “ActivityWatch” and I go to the GitHub ActivityWatch page it will prefer the “ActivityWatch” subcategory even though it matches both because it’s a level deeper. Since it’s a subcategory the time spent will be included in both however if you look at the sunburst visualization.

If it does not work like that there is some bug because that’s how it’s supposed to work at least. Or maybe I’m misunderstanding?

#3

What is in place today is a “choose the deepest” approach, but the parent category does not filter the actual child activities.
In the example you have given, if I go to an ActivityWatch page without GitHub in it, it would still match the child even tho the parent does not match the page to begin with.
So this page will appear under Programming -> ActivityWatch even tho it shouldn’t be in Programming to begin with.
The parent does not filter the children’s tasks, only the regex of the child is taken into account.
It is possible that it was not the way it was supposed to behave however, so it might be a bug.

#4

Ah, I see what you mean.

If you would want it to work that way you could just add “GitHub.*ActivityWatch” to your regex rule, you wouldn’t need to change the whole way the querying works. The issue would however if it’s longer than that, for example if you have parent category “GitHub|Vim|WireShark” with subcategories “Project1|Project2|Project3” it would get out of hand quite quickly with insane regexes.

It’s not really an issue no matter what solution you use (“choose the deepest” or “require match of parent”) both ways can achieve the same things. I think the discussion should rather be “which one makes the most sense by default and is it worth switching?”.

It would also be possible for a parent category to maybe have a checkbox for each rule which is something like “Require sub-categories to match rule of this category”. Maybe that’s the best solution?

#5

yes! this would be indeed the best solution to put a checkbox as to not confuse people who utilize the first method right now!
It would seem logical to make it a default as it makes it intuitive in my opinion, but this is just my opinion, more point of views are needed.