-
Notifications
You must be signed in to change notification settings - Fork 0
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
Type a prefix for performing types of clicks (e.g. right click, double-click) #57
Comments
yeah, i'm not a big fan of modifiers either, but because it's standard and follows macOS habits i've added them at first. i prefer typing also à la Homerow, but i haven't found yet a natural way of dealing with this. i don't want to have an overly complicated manual for Wooshy. it should feel quite natural without having to think too much. like if you want to target links you type "links". straight from brain to results. so yes, i want to add something through typing, but i need time and focus to digest a proper idea. thinking out loud here: your double space sounds nice. people should already be used to type double spaces on iOS for example. but typing this, thinking that some people may have the double space being replaced by a |
For sure and I bet some people even prefer the modifiers. I used mods with Shortcat and was skeptical of Homerow's method, but I ended up liking it.
If you use single space, then I think you would need to disallow spaces for matching words. For example, if they type
This can totally work, though. It would look like this:
LaunchBar (an alternative to Alfred) works similar to this. It uses |
Also, if you end up adding the feature, maybe the best option is to let the user to define the delimiter. Perhaps start with a sensible default, but offer tweaking tucked away in an "Advanced" tab under preferences? |
in practice is that working smoothly? i can't avoid feeling that this requires extra cognition to think about the first letters of each word. personally that has never worked for me. i'm way faster just typing "read the d" than "rtd" (just typing "rtd" right now i made a mistake. i didn't with "read the d"). also, personally, i tend to avoid stuff that would build bad (or at least not useful) habits. like typing "read the d" is useful. it trains me to type something i'll use in a lot of places. but "rtd" doesn't. which is why Wooshy started without even any fuzzy matching at all. apart from this, how would you distinguish roles then? like in your examples?
or then we need a different system for the UI elements roles? then you'll need a 96 pages PDF to understand the complicated system to match your stuff. argh no thanks. so, i'm not sure. i have several feedback about "better" ways to type, but they are mostly all seeing their own point of view, and it crumbles as soon as i add some basic cases that will just not work, bring Targets pollution, etc.
yeah i know LaunchBar and i'm aware of their fuzzy matching, it's just again that it doesn't match how i work.
i try to avoid giving options, unless when it's clearly necessary. i like to do apps that "Just Work" and need minimal config. that being said, i could have a "Fuzzy Matching" option like i did with The Input, and you could choose "À la Alfred", "Like LaunchBar", etc. this would be acceptable. but probably not before v1. |
Interesting. I'd find typing "read the d" cumbersome and I'd prefer to type less. (Edit: cumbersome in the context of typing to click hundreds of things a day). Thinking
Again, this is probably owing to everyone being different but I don't find the UI roles helpful. They can actually be a hindrance. You have a lot of experience with UI elements and their accessibility roles. I can only guess at some ( like I bet button is one). There have been times where I get a match that I don't want and I have no clue why. I reverse engineered one to be "Labeled" something. For my experience, it just added a match that I had to tab through. I suspect many people that use the app won't know roles either.
Again, different strokes. The reason I like fuzzy matching so much is that it's more dynamic. A good fuzzy match could match "Read the Documentation" with:
|
my bad. that was a very bad example 😅️ was just to show you don't need to type the whole thing. for
hmm. interesting. the roles are supposed to be self-explanatory. i don't really know them myself, i just type what comes to my mind: button, link, checkbox, radio, tab, etc. what happened with your "labeled" is not because of a role, it's because Wooshy doesn't only match what you see on the screen, but all the metadata behind. currently the only way to see this is to use the Accessibility Inspector that comes with Xcode. at a later stage there'll be something integrated to Wooshy (the reason why it's in alpha now is because it's missing this feature) where you'll be able to see all the terms that will match your Target.
seems at least a few people do. for checkboxes and tabs at least. personally i use the link all the time.
ok. i think that will come then as a "preset" at a later stage, yes. thanks for the idea. |
actually do you mind opening a new issue regarding this? this is different from the right click etc. through typing. thanks! |
That'll be cool.
Will do! |
funny, i'm coming back here to say that i think it may be nice if we add a new narrower at the end, like |
I tried Homerow.app's method for performing different types of clicks (e.g typing a prefix before the hint like
r
for a right click) and I prefer it over modifiers now. It'd be great if a similar option could be added to Wooshy someday.It'd need to work a little differently. Perhaps a convenient separator (like
;
or,
ordouble space
) to indicate type of click:r;button
orr,button
orr _ _ button
would perform a right clickAnd maybe the ability to do a prefix or suffix:
d;button
orbutton;d
would perform a double clickThe text was updated successfully, but these errors were encountered: