-
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
Does not support switching between multiple scrolling areas in Electron programs #16
Comments
yeah, that's because Electron apps are fake apps. they don't use any native elements and they usually don't set their AX properly, so Scrolla can't detect scrollable areas, or areas with scrollbars. maybe try the Scrolla any app in particular? i can have a look how they've built the AX. thanks. |
1password 8 |
ah. the heretic 1Password 8. i miss 1Password 7. yeah 1P8 is an Electron UI now. they don't define AXScrollAreas. everything is just a group. it's shit. what you can always do tho, even if it's not that good i know, is activate Scrolla, and position the cursor over what you wanna scroll, and use the |
I'm also in this boat, but with Slack. It's Electron and has two main scroll areas. Scrolla works great for me in many places, but in Slack it's frustrating that I can't scroll the list of channels. I was curious to see if Chrome/Brave had different behavior and it's the same there -- different scroll areas like slack in the browser don't show up. As a final point of related curiosity, I tried loading up slack in the browser in Safari and found the same thing -- Scrolla just detects the main window. But it might be easier to figure out ways to work with scroll areas in the browsers and that learning might just lift over to apply to Electron. Hope that helps. |
do you have any example of an Electron app where Scrolla works great?
yes, same, because the web content is not using native elements. so the only "scrollable area" that you're having is the whole window. |
currently the only idea i can come up with is what i've described in a comment above: move the mouse to where you wanna scroll, and scroll. but also the current issue is that when you activate Scrolla, it moves the cursor in the middle of the detected area. one thing could be to not do that in certain cases, and then use Wooshy to move the mouse around. see below. does that make sense? ScreenFlow.mp4 |
Alas, no. I try to avoid electron apps, but it seems I have more than I realized. Signal, Kopia, Discord, Slack, Spotify, Dropbox, Boxy SVG, and a couple of others. I tried a sampling of these to see if scrolla was able to detect different scroll areas on any of them and no luck. It does work on the main scroll area, just not sidebars and such, as you likely expect.
Yeah, it's interesting that it works fine to manually move the mouse cursor over the correct area of the window after first invoking scrolla and then it works. So it seems like a way to move the cursor around could help with this. I'm not sure about using wooshy for this purpose, but maybe. What if on holding a modifier (option?) the scrolla area got divided up into a grid with labels and hitting a label would move the mouse to the center of that grid item? Another workaround would be to use Mouse Keys, I guess. But it's pretty awful. The mouse moves slowly, the keys to move it are funky, it overtakes j and k, and the way to toggle on or off is hitting option five times, which is a drag. Perhaps though you could have mouse keys like functionality, again when holding a modifier (option?) while scrolla is activated and then vim movements to move the cursor around? It would be a drag to be moving the cursor, I think, and I'm not sure I wouldn't just reach for the damn trackpad at that point, so this might not be a great idea. Then again, if you could use vim keys like |
yep. i would have been surprised if it had worked in any Electron app.
yeah basically from my research the only API available is just to send scroll event to macOS, so basically it does a mouse wheel right under the mouse cursor. there's no API to like scroll scrollbars available around the screen. Scrolla detecting the Scroll Areas is to place the cursor so that you have nothing else to do rather than just using the Vim moves to scroll.
unfortunately that sounds like a whole other project to me.
again, sounds like another project. i think at this point i'd rather use Wooshy with |
Well fundamentally scrolls is moving the cursor so the idea of using vim keys to control that quickly doesn't seem that far outside of the purview to me. I like the idea of using w, b, and other keys to jump the cursor around to where it's needed. But if I could activate wooshy while scrolla was active to move the cursor then scroll the area under it, that could work fine too. |
hmm. yeah. i could add Vim moves for moving the cursor within the current selection. you'd never need it for native apps, but that would help for web browsers and Electron apps. nice idea, thanks. that requires quite some heavy changes in Scrolla's architecture, so it'll take a bit of time. |
is it actually better than the cursor can be moved within the detected area (scroll areas for native apps, whole window for Electron/browsers), or the whole screen? |
I think the active window would be the most useful. Thinking about the
browser and use cases like that.
…On Fri, Apr 14, 2023 at 9:35 PM G. ***@***.***> wrote:
is it actually better than the cursor can be moved within the detected
area (scroll areas for native apps, whole window for Electron/browsers), or
the whole screen?
—
Reply to this email directly, view it on GitHub
<#16 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAARQ37UXRG5DGZYE6FTLCTXBIJQRANCNFSM6AAAAAAWJGN37I>
.
You are receiving this because you commented.Message ID: <godbout/Scrolla.
***@***.***>
|
I have tried Scrolla, and I've given up with because of Slack. It does not detect the mouse in scrollable areas. In the end I've used keyboard maestro to jump the cursor to areas of the screen and trigger a mouse scroll even with JK keys. It's not as polished as scrolla, but at least it gets the job done. |
what i'm thinking about for shit apps like Slack that are fucking lazy with Accessibility is split them in 9 areas. you press 0 to 9 to move the cursor to an area. then you can use Scrolla's moves. the next step would be if you press numbers quickly then you keep splitting down the current area. that would allow you to basically move the mouse anywhere. how does that sound? thanks for the comment btw. i had this in the back of my mind but you helped bringing it back on the surface 😂️ |
i'm actually thinking about doing it in Scroll Areas detected. else it seems it'll be very messy. why having Scrolla detecting the Scroll Areas if you can have a "manual way", which is worse, but still helping for shit apps? so my idea now is that every Scrolla Area is divided in a grid of 9 cells, accessible with numbers. then it moves the mouse there. in case of browsers/Electron shits/apps which no Scroll Area, then the whole window get the treatment. |
So a few thoughts here:
I think with apps like Slack, I'd probably figure out the "addresses" of the areas I wanted to scroll pretty quickly. The annoying thing there is that it could change depending on, for example, whether slack is on my giant external monitor or my built-in laptop display. I'm thinking where the middle of the "4" region is no longer the sidebar if Slack is maximized or on a big screen vs. a small one. I think that behavior could end up being more consistent if the mouse cheated toward the window edges by default after a first number is pressed. I'll try to explain although I should probably just draw a picture. If we imagine a window broken up into three rows and three columns and the selection of one of those squares putting the cursor in the middle, it would be effectively the same as typing Now instead, what if To summarize: 👍 to the number addressable region idea so long as current behavior is basically preserved and that's sort of a backup approach. And suggestion for cheating the placement in each region to produce results that I think will more often work with one number pressed rather than sometimes having to hit two numbers. And a request to consider some sort visual feedback showing the region or the mouse location even if just for a flash (so the overlay doesn't obscure whatever's in the box). |
yes. this would just be an "add-on" for shit apps. the rest will stay the same.
maybe i'm used to the numbers coz American keyboard and typing IPs frequently? 🤔️ felt a comfortable idea to me. anyways this mixed up with the idea to have configurable mapping means those keys would be configurable too.
my first idea is no. you press Scrolla's hotkey, Scrolla puts the cursor in the middle of the current Scrolla Area detected (windows if shit app), then you press the keys to move the cursor around. my feel would be that you'd quickly get used to it. like quickly you would "know" where the cursor will go if you press a key. brains are pretty good at visualizing stuff (i'm making this up).
yes. i've been pondering using my App Catalog to also detect which app is focused and use that to place the cursor, but as you said it's gonna depend on too many things i think. window's width and height are one thing, but then there's resolution, etc. so it seems extra complicated.
yep. been also thinking about this. most Scrollable Areas should be on the far left and far right. surely there's gonna be exceptions tho. but i think the only way now to see if this is gonna be applicable in reality is to start coding and using it. going this way makes me think again also about using Vim moves to place the cursor around instead of numbers... i think i now need to digest all this and really start developing and seeing how it feels.
yeah i'm afraid also it's gonna be super personal. like would you rather press a number and have the app "decide" where's the best position. or would you rather be in control and certain about where the cursor will be when you press a number? solution one would only be great if Scrolla gets it 100% right, i think.
thank you! very helpful. excited about digging into this. visual feedback tho let's see. i like my minimalism. trying hard not to get my apps to look like this: 😂️😂️😂️ |
For visual feedback: I was thinking just briefly after a selection. My cursor hides when I'm not using it and I don't think it appears when moved programmatically. Regarding the certainty in where the cursor is placed, I think you'd have that with the 11, 22, etc scheme but could press a second number yourself to get it elsewhere. But agree it may not be necessary and only testing will really tell. Vim keys are also potentially interesting but I think you'd need to support a bunch. Could I |
what tool you're using to hide it?
|
starting the development on this. |
ok i know i've said this once already, but had to move all my servers and upgrade sites and apps framework and shit and also had to make a bit of money, BUT DEV HAS RESTARTED ON THAT FEATURE!!! |
Does not support switching between multiple scrolling areas in Electron programs
The text was updated successfully, but these errors were encountered: