-
-
Notifications
You must be signed in to change notification settings - Fork 108
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: more categorization and support for select_keys #286
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It does seem to work from my testing!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Was orange, now red (intentional/improvement?)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 }, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Was yellow, now red.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
src/util/classes.ts
Outdated
}, | ||
{ | ||
name: ['Media', 'Music'], | ||
rule: { | ||
type: 'regex', | ||
regex: 'Spotify|Deezer', | ||
regex: 'Spotify|Deezer|Amazon Music', | ||
ignore_case: true, | ||
}, | ||
data: { color: '#A8FC00' }, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can this color be lifted out into a constant too?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe rename/change this slightly to a yellow?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed.
9a4ec7b
to
9fe3fe0
Compare
@ErikBjare Finally getting back to this, take another look and let me know what you think! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
color
keys 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please revert these to previous colors (but good to keep them as constants!)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reverted!
fa77b08
to
5073642
Compare
@ErikBjare finally fixed this. Collapsed the commits & rebased. Hopefully this is what we need to get this in! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
}, | |
{ | |
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
data: { color: COLOR_SLIGHTLY_YELLOW }, |
@@ -197,6 +268,7 @@ function pickDeepest(categories: Category[]) { | |||
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
// 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
color
keys 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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_keys
to the rule. This is helpful for matching on the domain name of an event.