Any plan to add a scroll mode?

[haveanicedavid]

Not sure whether to ask this in here or kV. Basically, I’m still using vimac / homerow — exclusively for its ‘scroll’ toggle button (wooshy for search).

While I know kV has basic features possible in normal mode, i’m curious whether you have any plans to tackle scrolling behavior in your quest for the perfect Mac setup for VI users :D

[godbout]

Not sure whether to ask this in here or kV.

i've been wondering the exact same thing 😂️

i’m curious whether you have any plans to tackle scrolling behavior in your quest for the perfect Mac setup for VI users :D

absolutely. i thought i had it in the ROADMAP but no. but that makes sense now. it's because i was not sure yet where this would belong. Wooshy? kV? another (small, free, open source) app?

my first idea was that it belonged to kV. what we could do with Wooshy is target scroll areas. currently they are filtered out from the Targets because it makes no sense to click on them. so the great idea was you target with Wooshy through maybe a special search term, then once you're on the scroll area you use kV jk, G/gg, CTRL-D/U etc. i actually had a go at it yesterday! here's the result:

https://user-images.githubusercontent.com/121373/183302259-2729f218-92aa-425d-9b23-5d93b65dddc8.mp4

so as you can see it's shit. kV scrolls the menu items on the left rather than the scroll area. also, i was planning the scroll for after v1, but Ventura is full of stuff where the keyboard can't be used anymore and you need a mouse or trackpad. mega iOS style, so the scrolling feature is now becoming more urgent.

but i'm still not sure how and where. i do not like having to have another new keyboard shortcut for another functionality. too many of them. and is this really a part of Wooshy? i don't know. so i'm still digesting. but yes, scrolling will have to be done, definitely. have a nice day, vid.

[haveanicedavid]

yes, scrolling will have to be done 🙌

have a nice day, vid. … nice 😄

Thanks again for all your work. Both are huge upgrades to my workflow

[godbout]

can't be sure about Wooshy yet, but probably when you set up a new Mac and kV is not installed you're gonna feel it hard 😂️

[godbout]

FWIW, there's now a new dedicated app for the scrolling from the creator of Vimac/Homerow: https://twitter.com/dexterleng/status/1563493043293995011 maybe that helps?

still in the plans here. still not sure where it belongs (kV, Wooshy, separate). but it's a big piece so i'll be more clear once i grab that "project".

[haveanicedavid]

OOoh this actually works great! Thanks for sharing

[godbout]

yep. whatever makes people's lives better!

[godbout]

@haveanicedavid care to have a look? https://github.com/godbout/Wooshy.docs/discussions/69

gathering the brains. not about the scroll (yet), but somehow related to the "ecosystem". thanks!

[jannis-baum]

Have you considered making Normal mode kV (smooth) scroll on hjkl whenever the focus is not on text input for the accessibility strategy? Before discovering Wooshy I used Vimari, a Safari extension that tries to provide Vim keybindings, and I liked their scrolling with Normal mode hjkl.

[godbout]

Have you considered making Normal mode kV (smooth) scroll on hjkl whenever the focus is not on text input for the accessibility strategy? Before discovering Wooshy I used Vimari, a Safari extension that tries to provide Vim keybindings, and I liked their scrolling with Normal mode hjkl.

yeah i was using Vimari too.

so here's the thing: i did try. i thought: ok, i'm gonna target the scroll areas with Wooshy, and scroll etc. with kV (hjkl CTRL-U/D/B/F G gg). but it didn't work. i tried at least three times.

BUT now you're giving me a 💡️ what doesn't work is probably the key remapping. what i have to do instead is similar to how i handle differences between TextFields, TextAreas, and other inputs. if it's a scroll area, i have to ditch key remapping completely and send scroll events instead!

i'm thinking about this now because i started exploring creating a separate app and that's what i would have to do anyways. but your question just put me back into kV, and actually my brain is connecting both now. which is fantastic! if i could add this to kV that's solve the issue of finding where to add this feature. mix of Wooshy to target, and kV to move. at least to me, that'll be the perfect way, coz i use kV a lot already to scroll web pages.

[jannis-baum]

what i have to do instead is similar to how i handle differences between TextFields, TextAreas, and other inputs. if it's a scroll area, i have to ditch key remapping completely and send scroll events instead!

Yes! that's what I was thinking.

at least to me, that'll be the perfect way, coz i use kV a lot already to scroll web pages.

Same! let me know in case you want me to open an issue for it in kV :)

[godbout]

hmm but now thinking about it again ( 😅️ ) i think the main issue is that a scroll area is not really "reachable". like you can't click it. if i target a scroll area with Wooshy and go click, it clicks the child of the scroll area. which means we're not going to be able to target it with Wooshy, and move with kV. but i don't think we can also "grab" it with kV naturally, if that makes sense. even a web page, it's a web area, not a scroll area. although the web area is within a scroll area. like you can have a text area within a scroll area. hmm. so i'm still not sure it's possible. but i'll have to investigate again, from another direction now.

[jannis-baum]

Just some thoughts, not sure if this helps:

So as far as I understand the issue now (in accessibility strategy):

1. we don't want to always have hjkl scroll because they are arrow keys for text input and
2. we always know whether the focused element is text input,
3. hence we could have hjkl behave as arrow keys in text input and as scrolling everywhere else,
4. which leaves us with the one issue: If text input is already focussed, we often times can't get out of the text input to scroll. For example there is no way for me to unfocus this GitHub comment field without clicking, i.e. I'm stuck with hjkl as arrow keys.

Is all of that correct?

If it is, then the question seems to be "How can we unfocus a text input?". Is that possible through the AX API? Could you make escape for example unfocus the text input? Or, if "unfocussing" isn't a thing, give focus to some well defined parent like the first parent that is a scroll view, or whatever element would be the first focus responder if the window was given focus? (the latter might not make sense because the first responder could be text input again)

[godbout]

@jannis-baum i think your points are correct yes.

and your solutions are definitely worth exploring. one way would be to unfocus yes, although i think from my past experience it's hard to get a consistent experience (like the parent thing. even more for web pages and Electron shits, it's the wild wild west.). maybe a combination to force the scrolling? a bit like i do now with CTRL-U/D and fn? i personally use that a lot. not sure. just some thoughts. i'll have to focus (hehe) on this later.

[jannis-baum]

maybe a combination to force the scrolling? a bit like i do now with CTRL-U/D and fn?

Forced scrolling with another key seems like a good bridging solution until there is something better. My personal issue with ctrl-u/d is that it scrolls way too far for my taste since I usually like to read close to the center of the screen. Something between jk/arrow key scrolling and ctrl-u/d is what I would want🙈

[godbout]

My personal issue with ctrl-u/d is that it scrolls way too far for my taste since I usually like to read close to the center of the screen. Something between jk/arrow key scrolling and ctrl-u/d is what I would want🙈

yeah there's no other scrolling available through keyboard shortcuts than those ones (and jk), so that needs to custom thing. hence the other app, or some complete new system in kV/Ws.

[godbout]

bumping this for myself. The Inspector is gonna come soon, so Wooshy will go into v1, i guess in the couple of weeks/month. the three main things i wanna work on after v1 are:

1. The Input not stealing focus, so that we can target those new shit popovers all over macOS
2. different flavor of fuzzy matching/search (smartcase etc.)
3. THE SCROLL SHIT. that's gonna be very needed in Ventura

just sending a heads up, because i think for the SCROLL SHIT there's many different ways to do it, and i'm still not sure which one is best (special search term in Wooshy? external small app with new hotkey? etc.)

will probably open/pin an issue/discussion when it's time to do the work.

[godbout]

https://github.com/godbout/Wooshy.docs/issues/80

[godbout]

@haveanicedavid https://scrolla.app/releases/Scrolla.zip

[haveanicedavid]

@godbout 🙌 🙌 downloading now! Thank you, as always

[haveanicedavid]

OMG I’ve used for 30 seconds and am already in love - it’s exactly what I wanted!

[godbout]

@godbout 🙌 🙌 downloading now! Thank you, as always

no. thank you for your nickname that never fails to make me -> 🤣️

[godbout]

OMG I’ve used for 30 seconds and am already in love - it’s exactly what I wanted!

GREAT. still a very early alpha. the AXEngine will be fine tuned to grab more stuff (like it doesn't work well in Finder now for example), probably some more configuration available. blah blah blah. i have ideas.

[godbout]

closing.

new repo for the scrolling: https://github.com/godbout/Scrolla.docs