The filtereditor:
And the person sidebar filter:
3 Likes
Perhaps you could invert the label? This would work better as a more common English phrasing.
Make a “Case insensitive” checkbox. It would be selected by default – to avoid changing the current default behavior.
Or make it “Case sensitivity” which could be deselected by default.
A question about the added switch.
Does the “Case sensitive” work when “Use regular expressions” is NOT selected too?
No. You need to have the “Use regular expressions” selected.
It is not a problem except that both options must be selected if you want to use the sensitive case.
Expected that it would require RegEx.
Does it dim the Case sensitivity checkbox when RegEx is deselected?
It would be a misleading interface otherwise.
1 Like
I think this approach would be workable.
Note that the views for which case-sensitivity would most commonly be useful are probably Events & Notes.
In the Events view, it would presumably be offered in the existing “Events with ”.
In the Notes view, I guess it would be an option in “Notes containing ”.
In all views, I assume these would appear under the group “General filters” as at present.
It works for all fields in all views.
Here is an example if we have 3 persons named amarc, marc and Marcel
If you are looking for “marc”, you’ll get:
If you select the "Use regular expressions, you’ll get the same:
If you are looking for “^marc”, you’ll get:
Thank you, but tooltips typically go unseen. Some newbies have expressed surprise that they exist after months of using Gramps. GUI that requires drill-down for context makes behavior seem “quirky”.
I agree that it would be ugly interface to using contextual dimming or to deselect if RegEx was deselected.
This functionality uses mutually exclusive choices. So, how about 3 radio buttons instead?
No pattern matching (default)
Use Regular Expressions
Use case sensitive RegEx
Or future-proof it as a pop-up menu that would allow easy addition of alternate modes. As an example, a “developer” mode might allow matching handles rather than IDs
Pattern matching:
- None (default)
- Regular Expressions
- case sensitive RegEx
A menu label has the bonus of helping “Aunt Martha” understand that “Use Regular Expressions” is a form of pattern matching. (As opposed to some feature that makes Find results appear in a “colloquial” summary form rather than. As patently absurd as that sounds to a database developer, “colloquial idioms” would be a more common understanding of an “expression” for non-technical “regular” people.)
Instead of being constantly dissatisfied with this crappy operating system, use the OS for gramps which is linux. Everything will work like a charm.
I’m not in the least dissatisfied. Sorry that you have that impression.
But I am very much interested in infusing the project with more developers since “many hands make light work”. And since only a tiny percentage of the userbase becomes a contributor and only a fraction of that contributes code, I often talk about things which causes the project to lose users during the initial eval period. Once they become invested in the project, we have a better chance of converting them to volunteers.
Gramps needs UX/UI developers, statistical analysis people (particularly if we would like to see more DNA tools) & chart designers.
So if we can eliminate some of the minor things that turn off those people in the early stages, we stand a better chance of them becoming invested.
Unfortunately, those tend to be the nitpicky GUI things that irritate developers who prefer fixing big & truly functional things.
2 Likes
Yet another opinion…
Looking up Find options in a short list of four applications:
1 - no case sensitivity option (iTunes)
2 - “Match Case” as text label to enable case sensitivity (Thunderbird, Visual Studio Code)
1 - “Case sensitive” as text label to enable case sensitivity (Adobe Acrobat Reader)
While the current choice “case sensitivity” is close, either “Match Case” or “Case Sensitive” may be more commonly used.
Also agree that if an option isn’t applicable then it should be disabled, i.e. whatever the option is named for matching case should be selectable only if regex is selected.
@SNoiraud Great work putting this change together so quickly.
2 Likes
Interesting. I’ll try to do that. I hope it will be easy.
If it works, I’ll remove the tooltip.
3 Likes
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.