reaching inputs

[godbout]

i think kV is doing pretty well once it reached an input. in text inputs that support the macOS Accessibility you can have real Vim motions, in text inputs that don't we can impersonate some Vim motions through key remapping. in non-text inputs you can move around using the natural Vim motions you're used too.

but sometimes you first need to reach those inputs. for some apps Alfred is enough. for some others you may need to fiddle around with the mouse.

some apps are dedicated to handle this, like Shortcat and Vimac. i like Shortcat coz it's fast, and rather than having to wait for some letters to show up that you need to read and decipher, you can just type naturally and get what you want. but it's outdated and doesn't work with Electron shit apps. Vimac is great too, but a bit slow to my taste. and having to decipher the letters brings more friction.

so i'm wondering. should this be included in kV? should this be another app? or should i go back to sleep.

[godbout]

also i like apps that are small, clean, and do one and one thing very, very well. i'm a bit reluctant to add this to kV if that means adding a lot of options.

[zmre]

Thanks for the long reply: yes, you're absolutely right about capital HJKL and their uses so no worries there. I've seen them mapped in non-standard ways to switch between tabs and navigate history in, for example, browser plugins, which is why I was trying it.

I have Vimac going right now. Not as snappy as I would like, but it definitely helps a lot. If you're building something similar: I also like the scroll area functionality, but would like to be able to target which scroll area.

Regarding the video where I saw the focus hints jump up: https://youtu.be/f8XRcu00GIA?t=80

Regarding the fn button: I haven't found a place where it works or is needed yet, but there are a lot of times when I wish I could use fn-j to map to the down arrow so I don't have to take my hands off the home keys. I might not be in vim normal mode at those times though. Could you make this work generally?

[godbout]

I've seen them mapped in non-standard ways to switch between tabs and navigate history in, for example, browser plugins, which is why I was trying it.

ok, i would have more to say but i'm not really sure i get correctly what you mean. so just in case, from your sentence above, maybe what you're trying to achieve is this?

1. remap keys within macOS itself
   

2. use the passthrough option in kindaVim
   

like this you could be in kV Normal Mode, press shift cmd H (or option H or something with either cmd or option in it) and macOS would pick it up. i do it all the time to change tabs, move my windows around, etc.
passthroughs are done with cmd or option, not control or shift because those keys are keys that Vim uses for its moves.

I have Vimac going right now. Not as snappy as I would like, but it definitely helps a lot. If you're building something similar: I also like the scroll area functionality, but would like to be able to target which scroll area.

Regarding the video where I saw the focus hints jump up: https://youtu.be/f8XRcu00GIA?t=80

ah, you're right 😅️ that was one of the early video yeah. mistake. also i actually don't use Vimac anymore because i'm having the same issue as you, way too slow. Shortcat is faster (but the issue with Shortcat is that it hasn't been updated in a while, and crashes quite often. but the dev is back to working on it.)

Regarding the fn button: I haven't found a place where it works or is needed yet, but there are a lot of times when I wish I could use fn-j to map to the down arrow so I don't have to take my hands off the home keys. I might not be in vim normal mode at those times though. Could you make this work generally?

fn-j in kV Normal Mode is always gonna be translated by the down key. and macOS will act like if you pressed that down key, even if you're in Normal Mode.

if you mean remapping this while in Insert Mode (like, the normal macOS), that's gonna be out of scope also. kV brings Vim moves when you're in Vim mode. what you need then is a key remapper. there's many tools for this, like Hammerspoon and Karabiner-Elements. with those you can remap anything you want under macOS. those tools are specialized for this.

[godbout]

@zmre i think in the coming weeks/months i'll have some very early build of the app running. i'm gonna start working on it because mainly i need it badly :D it'll be a paid app like kV, probably same price model, but like kV, it'll start with a free beta (well, in that case alpha) that will always be available. will ping you when i release.

[clouedoc]

@godbout I want a ping too! I wanted to switch between inputs but couldn't

[godbout]

@clouedoc it's coming along: https://twitter.com/wooshyapp
but not sure when. kV is the priority. and i'm not sure about betas. i may start directly with a license when i have something that works ok, and let users decide if they want more (although, i already have a good roadmap for it!)

[godbout]

sending something now.

[godbout]

ScreenFlow.mp4

[clouedoc]

Elliot would definitely have used kV

[clouedoc]

Elliot would definitely have used kV

[jannis-baum]

This is everything I've ever wanted for macOS🥹 Is this already released or are you planning on releasing it for kV?

[godbout]

alpha started a few days ago!

https://wooshy.app
https://www.youtube.com/channel/UCFi6Z79gzGDdgw9fuEg7g4w
https://github.com/godbout/Wooshy.docs

[godbout]

@zmre see the links above, maybe this will fit better than kV for what you were mentioning in your first post.

[zmre]

Been using whooshy for a few days now. Not natural to reach for it yet, but slowly figuring out when it's useful and I like it. Adding ways to figure out the names of targets without words will be good -- but maybe not on hover but rather a nearby label?

The one thing that trips me up regularly: I look in one place and want to jump right to it, hit the hot key, but it turns out my foreground app is something else. So I exit out of the whooshy prompt and fumble around with cmd-tab or raycast to get to the proper window and then re-trigger whooshy. I know you have an alfred workflow for this (and raycast more or less does the trick), but it's a lot of extra steps when I really just want to jump directly somewhere.

As a suggestion, would it be possible to have a keystroke that allows me to expand the searched targets beyond the current app? I'd imagine it something like this: I hit cmd-shift-space and start typing my target. I realize I'm in an idiot and my search was contrained to a different window than the one I was looking at. I hit a hotkey or add a special character to my search (let's say "#" for argument's sake, but I don't really care): then the search expands across all visible windows on all screens and highlights the hits so I can get where I want. That would be tremendous.

The other suggestion I have so far -- and this one is much lower priority -- is a way to avoid tabbing through results. Most of the time I can search so I have zero or minimal tabbing, but a few times I've had to repeatedly bang on tab or ctrl-n to get where I want and when that happens I wish for the label overlays of other tools. I'd envision maybe typing my search and then hitting, let's say, ctrl-enter or cmd-enter and then instead of choosing the first option, it labels the selections and lets me one or two letter type to direct jump where I want to go.

I'm already impressed by the speed and so far it seems stable. A big improvement over Vimac. I only just noticed that the Vimac author is putting forward a new tool called Homerow, which I haven't tried. But looking at that reminded me of a feature of Vimac that I did sometimes use, which was the ability to scroll various scrollable windows using the keyboard. I use vi browser plugins so that I can already do this in browsers where I most often scroll already, so not a huge need, but it did come in handy at times. So maybe a third suggestion there. I know you can drop into kindaVim and use j/k as up/down substitutes. Maybe that's good enough? Or maybe it would be nice to be able to select the scroll area when there are a few. For example, I usually have Slack open and have a scroll area for channels as well as for messages and that's an app where I often have to break out the mouse.

Anyway, great work, Whooshy is already pretty great and I haven't hit any bugs as yet that I've noticed.

[godbout]

Adding ways to figure out the names of targets without words will be good -- but maybe not on hover but rather a nearby label?

theory sounds good, practice i doubt so. your screen is gonna be a mess. pollution everywhere.

the idea with the hover is not to be used once for each item eternally. once you know for example that reaching your list of accounts on Twitter is account, then you got it. next time you type acc and voilà 😎️

but still discussable. but i'm gonna answer the rest first, because it's gonna be related.

I realize I'm in an idiot

we've all been there ☹️

As a suggestion, would it be possible to have a keystroke that allows me to expand the searched targets beyond the current app? I'd imagine it something like this: I hit cmd-shift-space and start typing my target. I realize I'm in an idiot and my search was contrained to a different window than the one I was looking at. I hit a hotkey or add a special character to my search (let's say "#" for argument's sake, but I don't really care): then the search expands across all visible windows on all screens and highlights the hits so I can get where I want. That would be tremendous.

it's in the ROADMAP: https://github.com/godbout/Wooshy.docs#maybe
although 10% of probability that this will happen, at the time of writing (of the ROADMAP). since then i played a bit with it. i'd rate the probability at 1% now.

again, theory sounds good, but when you start getting your hands dirty, well, you see it's really dirty. what would need to be done—AT LEAST—is:

1. grab all visible windows. the API is expensive, but it's possible
2. grab ALL THE UI ELEMENTS of ALL VISIBLE WINDOWS. hmm hmm. Wooshy is fast now, for several reasons, one being not grabbing ALL THE UI ELEMENTS of ALL VISIBLE WINDOWS.
3. once you have ALL THE UI ELEMENTS of ALL VISIBLE WINDOWS, you need to intersect all the windows lol. like you don't want to have hints for stuff that are hidden behind other windows. or do you? maybe actually you want a list of everything, not just the front window? (i'm thinking as i'm typing here.) if that's the case, a list of everything, yeah wrong project. there's something that may interest you though, see a bit later. edit: and if this is really what you want, imagine having a list of everything from every visible window. then when you activate a result, you will need this window to go upfront. so probably in the list you'll need to see which target belongs to which window etc. that seems to be like a MASSIVE FRICTION. like you're gonna spend time trying to decipher results before entering return. is there a possibility that you're thinking of what you're thinking now because you use full screen split or something similar?

I'd envision maybe typing my search and then hitting, let's say, ctrl-enter or cmd-enter and then

hmm. someone hasn't read the Manual 😅️ https://github.com/godbout/Wooshy.docs#click

The other suggestion I have so far -- and this one is much lower priority -- is a way to avoid tabbing through results. Most of the time I can search so I have zero or minimal tabbing, but a few times I've had to repeatedly bang on tab or ctrl-n to get where I want and when that happens I wish for the label overlays of other tools. I'd envision maybe typing my search and then hitting, let's say, ctrl-enter or cmd-enter and then instead of choosing the first option, it labels the selections and lets me one or two letter type to direct jump where I want to go.

so i'm gonna go for it again, have you read the Manual? you can add a narrower to your search term. most of the time you'll end up with very few targets left. also you can reach the last one, first one, middle of the lists, etc, etc with the macOS standard keyboard shortcuts that you would expect. EVEN BETTER, if you're still a kV user, you can enter Normal Mode and use jk, G, gg, CTRL-U, etc, etc. (add Wooshy to the Key Mapping Family.) it's really, really fun :D

for the labelling/list of results, i'm thinking that what may better suit you is Shortcat. Vimac/Homerow does the letters hints, Wooshy does the typing, Shortcat does both. the philosophy is a bit different. Wooshy is for people who like to type and type fast. a big point of Wooshy also is to take as little screen estate as possible. you just wanna see your targets and reach them.

I'm already impressed by the speed and so far it seems stable. A big improvement over Vimac. I only just noticed that the Vimac author is putting forward a new tool called Homerow, which I haven't tried.

i bought a license of Homerow. it's a great app. although if you have used Vimac, it's mostly the same, but faster.

But looking at that reminded me of a feature of Vimac that I did sometimes use, which was the ability to scroll various scrollable windows using the keyboard. I use vi browser plugins so that I can already do this in browsers where I most often scroll already, so not a huge need, but it did come in handy at times. So maybe a third suggestion there. I know you can drop into kindaVim and use j/k as up/down substitutes. Maybe that's good enough? Or maybe it would be nice to be able to select the scroll area when there are a few. For example, I usually have Slack open and have a scroll area for channels as well as for messages and that's an app where I often have to break out the mouse.

yes. i have this in my internal ROADMAP of stuff to explore:

i wasn't planning to do it soon but i've been on Ventura for maybe one or two weeks and hell it's gonna be needed yeah. many places not accessible by keyboard anymore. need a mouse or trackpad. really shit. iOS style. anyways. i thought about it for a while, and the current conclusions would be: 1) not part of Wooshy 2) may be a part of kV, like you said. may need better handling of scroll areas etc like it's done currently for Safari. like you can do jk, G, gg, CTR-D, etc. that may require Wooshy to ping the scroll areas, which would be fine. it doesn't now because it's useless 3) if not in kV, probably a free, open source small app that just does this. i like and dislike this idea at the same time. i like it because i like my areas of responsibilities separated. Wooshy is not about this. kV can, it makes sense, which is why i would like to have it there. but a separate open source free app sounds good too. what i DONT LIKE about it is having another global keyboard shortcut. i really don't want this. so yeah, that's the current state of affairs.

Anyway, great work, Whooshy is already pretty great and I haven't hit any bugs as yet that I've noticed.

then you're not using multiple monitors LOL

[zmre]

Oh I've definitely read the manual. I see now that suggesting ctrl-enter was bad. I haven't had cause to right click on a target as yet.

To your other solution: typing more to find the target isn't always the solution for me. For example, I've used Wooshy to select tabs in my browser. Sometimes the tab titles only show me the first two or three characters -- like of the subject of a gmail email or something -- and I just don't know what to type next. Sometimes I only see the icons and have basically nothing to go on. That's when the overlay shortcut approach is better. I don't really want a ton of overlays by default, but there are cases when it would be well worth it.

Regarding expanding to all visible UI elements: I get that can be a lot. Of course would only want visible elements. Would want it filtered. Again, I wouldn't want that to be the default mode, but something I could jump to if it might be quicker than exiting out of Wooshy, switching apps, and then reentering Wooshy and retyping.

I haven't used Shortcat, primarily because the website was down for months -- since you first mentioned it anyway. I do like the idea of typing to narrow targets though. Looking for the best of both worlds.

I'm definitely using multiple monitors. I guess I sometimes don't see the input box when I'm on the external monitor, but I generally don't look for that box. The search still works fine and I move to fast to bother looking at what Wooshy thinks I typed anyway.

On the scrolling thing: the bigger part of the ask is a way to put focus on a specific scroll area. Not sure the best way to do this, but windows frequently have multiple scroll areas. That's true right now as I type in an input box on Github. I don't have a great way to switch scroll areas right now so my scrolling (with arrows or j/k or whatever) moves to the right place.

[godbout]

Oh I've definitely read the manual. I see now that suggesting ctrl-enter was bad. I haven't had cause to right click on a target as yet.

phew. glad i didn't write RTFM 😂️

To your other solution: typing more to find the target isn't always the solution for me. For example, I've used Wooshy to select tabs in my browser. Sometimes the tab titles only show me the first two or three characters -- like of the subject of a gmail email or something -- and I just don't know what to type next. Sometimes I only see the icons and have basically nothing to go on. That's when the overlay shortcut approach is better. I don't really want a ton of overlays by default, but there are cases when it would be well worth it.

hmm but what if you knew the metadata for those icons? i guess you're referring to some same icons that you would keep using most of the time right?

Regarding expanding to all visible UI elements: I get that can be a lot. Of course would only want visible elements. Would want it filtered. Again, I wouldn't want that to be the default mode, but something I could jump to if it might be quicker than exiting out of Wooshy, switching apps, and then reentering Wooshy and retyping.

still, to only show the visible UI elements, you have to first get all of them, and intersect. huge amount of power. gonna slow down things by a lot. i get that this wouldn't be the common case, like you would start without this, and activate if needed. personally if something like your scenario happens, yes, i use Alfred and switch window with the Wooshy: Window to the Foreground! (sometimes i wish i hadn't called it this way... long to type) and then blast with Wooshy again. in my case i'm ok with this. it's pretty case. but i get that it's some extra keys. not saying no, just thinking out loud and digesting.

I haven't used Shortcat, primarily because the website was down for months -- since you first mentioned it anyway. I do like the idea of typing to narrow targets though. Looking for the best of both worlds.

the new Shortcat comes with both typing, and the hints. i think it's slower tho. may be worth having a look.

I'm definitely using multiple monitors. I guess I sometimes don't see the input box when I'm on the external monitor, but I generally don't look for that box. The search still works fine and I move to fast to bother looking at what Wooshy thinks I typed anyway.

yeah, that's kind of the spirit :D no looking, just typing and enter.

On the scrolling thing: the bigger part of the ask is a way to put focus on a specific scroll area. Not sure the best way to do this, but windows frequently have multiple scroll areas. That's true right now as I type in an input box on Github. I don't have a great way to switch scroll areas right now so my scrolling (with arrows or j/k or whatever) moves to the right place.

my first thought would be to have something in Wooshy that only targets the scroll area. maybe typing "scroll" or something? then you can navigate on those different areas, and choose one. then you use kV to move around. that's hypothetical for now. but i like this idea.

[godbout]

my first thought would be to have something in Wooshy that only targets the scroll area. maybe typing "scroll" or something? then you can navigate on those different areas, and choose one. then you use kV to move around. that's hypothetical for now. but i like this idea.

had a go at it. doesn't work, at least with the new Ventura UI/UX system. need something done especially for that. not sure yet where it'll land: Wooshy, kV, or a separate thing.