Closed Julianoe closed 10 months ago
Hi there! As you're new to this repo, please make sure you've used an appropriate issue template and searched for duplicates (it helps us focus on actual development!). We'd also like to suggest that you read our contribution guidelines and our code of conduct. Thanks a bunch for opening your first issue! 🙏
I could contribute a change to the FAQ to reflect that the exclude/ignore feature is an ongoing discussion and link to the forum and n°1 issue maybe?
"case" is the standard wording I've found across apps. Here's the Firefox "search in page" for example:
This is the first time I've heard someone confuse it with "switch-case", probably only happens to devs. I don't think we're going to change this.
I could contribute a change to the FAQ to reflect that the exclude/ignore feature is an ongoing discussion and link to the forum and n°1 issue maybe?
The analysis-stage exclude/ignore is a trivial PR I think (unlike collection-time exclude/ignore/redact as in #1). You could add some text to the docs mentioning this, but I feel like it too small a future-feature to mention, might as well spend the time adding the feature, if you have the time and ability.
VS Code also uses "Match Case". While "Ignore case" doesn't seem particularly confusing (context: American English native speaker), perhaps "Case insensitive" would be more intuitive, or you could reverse the behavior, and use "Case sensitive" or "Match case".
"Case insensitive" also maps more directly to this being a regex, as it's just the i
flag, where i
stands for "insensitive".
Not saying that it does not mean the typographic case. But that in that context, I had no means to understand it was one or the other. The docs did not return any result for "ignore case" so I could not check the meaning of this option there.
All the examples of UI that I know that allow search do the reverse: defaults to case insensitive, giving option to "match case". What @mrienstra suggests would make the confusion I experienced impossible, I think.
Just giving you my feedback after a few days using the software ¯_(ツ)_/¯
probably only happens to devs.
is the software not mainly used by devs?
All the examples of UI that I know that allow search do the reverse: defaults to case insensitive, giving option to "match case"
We want to encourage people to write case-sensitive rules as they are more precise and help avoid false positives, thus the default.
probably only happens to devs.
is the software not mainly used by devs?
That's a fair point :sweat_smile:
perhaps "Case insensitive" would be more intuitive ... "Case insensitive" also maps more directly to this being a regex, as it's just the i flag, where i stands for "insensitive".
I'm okay with "Case insensitive" and can see how that removes some room for confusion. Does that sound good @mrienstra @Julianoe?
If anyone wants the PR credits, feel free to do the honors: https://github.com/ActivityWatch/aw-webui/blob/d2fa858812b1d4cf57ab9f3d70e736a505260067/src/components/CategoryEditModal.vue#L22
@Julianoe, you've got first dibs on the PR! If you're not interested, I'll do it. :)
We want to encourage people to write case-sensitive rules
I get that and I agree with you on the wording.
Just proposed a pull request with the small patch.
Merged 🎉
As of the main definition of the word case it is to designate a situation. Furthermore in many programming languages a "case" is use to talk about one of an entry of a certain type of feature (switch).
Anyways, I think it could increase the readability of the software to adjust the wording. I had to dig through users .json rulesets to understand what case meant... and dig through documentation, issues and forum to finally understand that ActivityWatch does not provide a way of ignoring/excluding specific tabs/windows