feat: more categorization and support for select_keys#286
feat: more categorization and support for select_keys#286iloveitaly wants to merge 2 commits intoActivityWatch:masterfrom
Conversation
Codecov ReportBase: 25.05% // Head: 25.40% // Increases project coverage by
Additional details and impacted files@@ Coverage Diff @@
## master #286 +/- ##
==========================================
+ Coverage 25.05% 25.40% +0.35%
==========================================
Files 27 27
Lines 1489 1496 +7
Branches 240 247 +7
==========================================
+ Hits 373 380 +7
Misses 1086 1086
Partials 30 30
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report at Codecov. |
19378fe to
ec49a1d
Compare
|
@ErikBjare friendly reminder on this PR :) Before I fix the last failing test, I want to make sure this is the sort of thing you'd be ok merging in. |
| { | ||
| name: ['Work', 'Programming'], | ||
| rule: { type: 'regex', select_keys: ['url'], regex: 'github.com' }, | ||
| data: { color: COLOR_SUPER_GREEN }, | ||
| }, |
There was a problem hiding this comment.
Does having several category rules with the same name work correctly in the web UI? (editing etc)
Seems redundant to specify data several times (how would collisions/differences be handled?).
There was a problem hiding this comment.
It does seem to work from my testing!
There was a problem hiding this comment.
This rule will only work in those cases where there is a url set on events at all (only on macOS), which makes me not want this as a default rule (esp with the "hidden" select_keys specifier).
I think it will be very confusing to users which would expect this to work, given it's a default, but for most users it won't (and without a select_keys UI, it would be a mystery why it doesn't work if they were to e.g. edit it).
| data: { color: '#F80' }, | ||
| data: { color: COLOR_RED }, |
There was a problem hiding this comment.
Was orange, now red (intentional/improvement?)
There was a problem hiding this comment.
| data: { color: '#F80' }, | |
| data: { color: COLOR_RED }, | |
| data: { color: COLOR_ORANGE }, |
| data: { color: '#F33' }, | ||
| data: { color: COLOR_RED }, |
There was a problem hiding this comment.
Was a dimmer/desaturated red, now a darker/saturated red. Worse contrast with the black text.
src/util/classes.ts
Outdated
| data: { color: '#FCC400' }, | ||
| data: { color: COLOR_RED }, |
src/util/classes.ts
Outdated
| regex: 'Spotify|Deezer|Amazon Music', | ||
| ignore_case: true, | ||
| }, | ||
| data: { color: '#A8FC00' }, |
There was a problem hiding this comment.
Can this color be lifted out into a constant too?
src/util/classes.ts
Outdated
| const COLOR_GREEN = '#96cd39', | ||
| COLOR_SUPER_GREEN = '#54e346', | ||
| COLOR_UNCAT = '#CCC', | ||
| COLOR_ORANGE_GREEN = '#f5ff65', |
There was a problem hiding this comment.
Maybe rename/change this slightly to a yellow?
9a4ec7b to
9fe3fe0
Compare
|
@ErikBjare Finally getting back to this, take another look and let me know what you think! |
ErikBjare
left a comment
There was a problem hiding this comment.
Just a couple minor things and I'll merge :)
| name: ['Work', 'Writing'], | ||
| rule: { | ||
| type: 'regex', | ||
| select_keys: ['app'], |
There was a problem hiding this comment.
So this is set, but there is no way to change it in the UI?
All select_keys should probably be removed from the default categories until the UI supports it.
There was a problem hiding this comment.
Yes, that's right.
You can't set them via the UI, but you can import a config file which contains them. I think we should add select_keys to the default config since you can 'export, modify, import' and to mutate these keys and it makes it more explicit how we are deciding which app is in use.
There was a problem hiding this comment.
But that's very confusing for the user. They have no indication there is even a select_keys for those categories, right? (unless they export and inspect)
I really don't want to add this specifier to the default rules without:
- UI support for it
- More thorough testing of these new "multi-rule" categories in the UI.
- What happens in the UI if a category with multiple rules has children?
- What happens when you rename a category with multiple rules? Or assign it to a different parent?
- What happens to
colorkeys when you have multiple rules? - Ideally, a category with multiple rules should be listed only once in the category tree, with an indication that there are multiple rules for this one category (without listing it as two seperate categories, since that's likely to get confusing).
src/util/classes.ts
Outdated
| // https://colorhunt.co/palette/4802 | ||
| const COLOR_GREEN = '#96cd39', | ||
| COLOR_SUPER_GREEN = '#54e346', | ||
| COLOR_BRIGHT_GREEN = '#A8FC00', | ||
| COLOR_UNCAT = '#CCC', | ||
| COLOR_SLIGHTLY_YELLOW = '#f5ff65', | ||
| COLOR_ORANGE = '#ffba47', | ||
| COLOR_RED = '#ff5b44'; |
There was a problem hiding this comment.
Please revert these to previous colors (but good to keep them as constants!)
fa77b08 to
5073642
Compare
|
@ErikBjare finally fixed this. Collapsed the commits & rebased. Hopefully this is what we need to get this in! |
ErikBjare
left a comment
There was a problem hiding this comment.
Was hoping to merge this but I still find the hidden-from-user select_keys behavior problematic.
I really want to see a UI for it before I feel okay with adding the selector to the default categories, as I otherwise think users will be very confused.
The "multi-rule" categories also make me uneasy, as I didn't design for it so I would want to review/test this much more thoroughly before I feel confident merging it (see comments for specifics).
To support multi-rule categories like this without causing trouble, I think it'd be best if we allowed the rule property to be a array of rules. Instead of having several categories with the same name implicitly be the same (troublesome with the data property, renaming, parents, etc).
All these color changes are also very hard to review. I generally don't want them changed. I tried to leave comments where I found differences, but I'm sure I didn't spot them all.
If you want, we can strip the select_keys and merge this now (so we get the color constants etc.), or we can leave this open if you want to give the UI part a shot.
| { | ||
| name: ['Work', 'Programming'], | ||
| rule: { type: 'regex', select_keys: ['url'], regex: 'github.com' }, | ||
| data: { color: COLOR_SUPER_GREEN }, | ||
| }, |
There was a problem hiding this comment.
This rule will only work in those cases where there is a url set on events at all (only on macOS), which makes me not want this as a default rule (esp with the "hidden" select_keys specifier).
I think it will be very confusing to users which would expect this to work, given it's a default, but for most users it won't (and without a select_keys UI, it would be a mystery why it doesn't work if they were to e.g. edit it).
| }, | ||
| { | ||
| name: ['Work', 'General'], | ||
| rule: { | ||
| type: 'regex', | ||
| regex: 'Preview|Finder|Todoist|1Password|Soulver|System Preferences|VNC Viewer|Streaks', | ||
| select_keys: ['app'], | ||
| }, | ||
| data: { color: COLOR_SLIGHTLY_YELLOW }, |
There was a problem hiding this comment.
| }, | |
| { | |
| name: ['Work', 'General'], | |
| rule: { | |
| type: 'regex', | |
| regex: 'Preview|Finder|Todoist|1Password|Soulver|System Preferences|VNC Viewer|Streaks', | |
| select_keys: ['app'], | |
| }, | |
| data: { color: COLOR_SLIGHTLY_YELLOW }, |
Sorry, but I don't like this as a default category. It's too broad to be generally useful, imo. Better to leave underspecified stuff like this up to the user (or if one would keep it, it would belong better in the parent category 'Work', such that child-categories can override).
| regex: | ||
| 'Messenger|Messages|Discord|Telegram|Signal|WhatsApp|Rambox|Slack|Riot|Element|Discord|Textual|Nheko|Texts', | ||
| }, | ||
| data: { color: COLOR_ORANGE }, |
There was a problem hiding this comment.
Why override the #9FF comms color with something very different?
| data: { color: COLOR_ORANGE }, |
| { | ||
| name: ['Comms', 'Email'], | ||
| rule: { type: 'regex', regex: 'Gmail|Thunderbird|mutt|alpine' }, | ||
| data: { color: COLOR_ORANGE }, |
There was a problem hiding this comment.
Same as above.
| data: { color: COLOR_ORANGE }, |
| { | ||
| name: ['Comms', 'Meetings'], | ||
| rule: { type: 'regex', regex: 'Zoom|Calendar|Cron' }, | ||
| data: { color: COLOR_SLIGHTLY_YELLOW }, |
There was a problem hiding this comment.
| data: { color: COLOR_SLIGHTLY_YELLOW }, |
| return _.maxBy(categories, c => c.name.length); | ||
| } | ||
|
|
||
| // TODO this is only used colorize the categories, all categorization is done on the backend |
There was a problem hiding this comment.
| // TODO this is only used colorize the categories, all categorization is done on the backend | |
| // NOTE: this is only used to colorize the categories, all actual categorization is done on the backend |
| name: ['Work', 'Writing'], | ||
| rule: { | ||
| type: 'regex', | ||
| select_keys: ['app'], |
There was a problem hiding this comment.
But that's very confusing for the user. They have no indication there is even a select_keys for those categories, right? (unless they export and inspect)
I really don't want to add this specifier to the default rules without:
- UI support for it
- More thorough testing of these new "multi-rule" categories in the UI.
- What happens in the UI if a category with multiple rules has children?
- What happens when you rename a category with multiple rules? Or assign it to a different parent?
- What happens to
colorkeys when you have multiple rules? - Ideally, a category with multiple rules should be listed only once in the category tree, with an indication that there are multiple rules for this one category (without listing it as two seperate categories, since that's likely to get confusing).
| COLOR_YELLOW = '#FCC400', | ||
| COLOR_SLIGHTLY_YELLOW = '#f5ff65', | ||
| COLOR_ORANGE = '#ffba47', | ||
| COLOR_RED = '#F80'; |
There was a problem hiding this comment.
Red is orange now? Previous red was #F33.
| COLOR_RED = '#F80'; | |
| COLOR_RED = '#F33'; |
| name: ['Work'], | ||
| rule: { type: 'regex', regex: 'Google Docs|libreoffice|ReText' }, | ||
| data: { color: '#0F0' }, |
There was a problem hiding this comment.
Better to keep this parent-category explicit imo. Even if without a rule, such that children inherit color and don't need to be set explicitly for each child.
| data: { color: '#F80' }, | ||
| data: { color: COLOR_RED }, |
There was a problem hiding this comment.
| data: { color: '#F80' }, | |
| data: { color: COLOR_RED }, | |
| data: { color: COLOR_ORANGE }, |
|
Makes sense! I don't have any additional time to spend on this, so someone else will have to take this up to get it across the finish line. |
|
bump |
|
Closing out in favor of the simplier #495 |

Similar to this PR (and as discussed here this contains a additional app categorizations.
Some additional changes:
select_keysto the rule. This is helpful for matching on the domain name of an event.