Does not support switching between multiple scrolling areas in Electron programs about scrolla.docs HOT 19 OPEN

from scrolla.docs.

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 Extra Settings, the middle option about the scrollbars?

any app in particular? i can have a look how they've built the AX. thanks.

from scrolla.docs.

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 Extra Settings, the middle option about the scrollbars?

any app in particular? i can have a look how they've built the AX. thanks.

1password 8

from scrolla.docs.

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 jk etc. keys. that'll work, but yeah it's not idea. what Scrolla does is moving the cursor over scrollable area, and sending mouse events. but with webpages and Electron apps, everything is custom (and shit), so it's impossible to build something consistent. (some pages uses list, some groups, some other things, blah blah blah.)

from scrolla.docs.

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.

from scrolla.docs.

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.

do you have any example of an Electron app where Scrolla works great?
the issue with Electron apps is that nothing is standard. basically Electron provides a canvas where devs paint whatever the fuck they want. it's not integrated within the native OS technologies. my apps—Scrolla included—make use of very deep parts of macOS. Electron bypass all that. Scroll Areas are not defined as Scroll Areas, Scrollbars are not defined as Scrollbars. to handle Electron app you'd have to study each app, and build an independent Scrolla for each of them.

I was curious to see if Chrome/Brave had different behavior and it's the same there

yes, same, because the web content is not using native elements. so the only "scrollable area" that you're having is the whole window.

from scrolla.docs.

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?

from scrolla.docs.

do you have any example of an Electron app where Scrolla works great?

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.

what Scrolla does is moving the cursor over scrollable area, and sending mouse events.

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 ^ and $ and G and such and it jumped the cursor within the active window to the left side, right side, bottom, or whatever, that might not be too bad.

from scrolla.docs.

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.

yep. i would have been surprised if it had worked in any Electron app.

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.

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.

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?

unfortunately that sounds like a whole other project to me.

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 ^ and $ and G and such and it jumped the cursor within the active window to the left side, right side, bottom, or whatever, that might not be too bad.

again, sounds like another project. i think at this point i'd rather use Wooshy with shift command that will move the cursor to a location without clicking, and then use Scrolla (when it doesn't move back the cursor). but that would be a side-feature. the point of my apps is that they do a lot of the heavy work for you. like in the case of Scrolla, detecting Scrolla Areas and doing all it needs to do for you to be ready to scroll quickly and easily. does it succeed? that's debatable. because whether we like it or not, yes, there are a lot of Electron apps out there and that are used by a lot of people. the issue tho is that it's impossible to do something standard for those apps. personally i don't think i'm gonna use a grid, or labels a la Vimac/Homerow, so i'm definitely not gonna have the motivation to build this. even if Scrolla was a paid app. anyways, just thinking out loud and digesting. obviously there's something to be done for Scrolla to be usable on more apps (Electron), but i'm not sure what's the solution i want to go for yet.

from scrolla.docs.

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.

from scrolla.docs.

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.

from scrolla.docs.

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?

from scrolla.docs.

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.

from scrolla.docs.

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 😂️

from scrolla.docs.

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'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.

from scrolla.docs.

So a few thoughts here:

• I wouldn't want to see the existing behavior change (except for keys to move between detected areas). So in native Swift/Objective-C apps you have the one experience.
• I've been trying to think about numbers versus letters maybe with hinting (though I know you're not fond of label hints in similar apps), but I do think the numbers in a phone pad layout 1-9 is fairly intuitive. My brain knows that 9 is bottom right so though it might be annoying to hit 91 or something to get scrolla to the right spot (as that's two stretches and my fingers are really that lazy), I can't think of anything more intuitive than what you've proposed.
• In hitting an area will I see where the cursor is placed? Or a yellow box defining the area or roughly where the cursor is if not? I wouldn't like to be guessing and checking much, if possible.

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 X followed by 5. That second five in that sequence would be pointless given the default.

Now instead, what if 1 defaulted instead to 11 so it cheated to the top left corner of the top left square. And what if 2 defaulted effectively to 22? Maybe it would be worth testing to see if I'm right, but I suspect you'd get more ideal placements in more scenarios with less variability from window size. That's because scroll areas tend to be some largish main region with separate scroll areas around the sides. And I'd bet that in a scenario where you can't detect the scroll regions, a default starting assumption of 55 would work in 85% of cases (to make up a number that sounds impressive).

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).

from scrolla.docs.

• I wouldn't want to see the existing behavior change (except for keys to move between detected areas). So in native Swift/Objective-C apps you have the one experience.

yes. this would just be an "add-on" for shit apps. the rest will stay the same.

• I've been trying to think about numbers versus letters maybe with hinting (though I know you're not fond of label hints in similar apps), but I do think the numbers in a phone pad layout 1-9 is fairly intuitive. My brain knows that 9 is bottom right so though it might be annoying to hit 91 or something to get scrolla to the right spot (as that's two stretches and my fingers are really that lazy), I can't think of anything more intuitive than what you've proposed.

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.

• In hitting an area will I see where the cursor is placed? Or a yellow box defining the area or roughly where the cursor is if not? I wouldn't like to be guessing and checking much, if possible.

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).

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.

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.

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.

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.

Now instead, what if 1 defaulted instead to 11 so it cheated to the top left corner of the top left square. And what if 2 defaulted effectively to 22? Maybe it would be worth testing to see if I'm right, but I suspect you'd get more ideal placements in more scenarios with less variability from window size. That's because scroll areas tend to be some largish main region with separate scroll areas around the sides. And I'd bet that in a scenario where you can't detect the scroll regions, a default starting assumption of 55 would work in 85% of cases (to make up a number that sounds impressive).

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.

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).

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:

😂️😂️😂️

from scrolla.docs.

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 5j or use $, for example?

from scrolla.docs.

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.

what tool you're using to hide it?

Vim keys are also potentially interesting but I think you'd need to support a bunch. Could I 5j or use $, for example?

$ already sends you at the most right on a Scroll Area actually. 0 most left: https://github.com/godbout/Scrolla.docs?tab=readme-ov-file#scroll but maybe more to explore.

from scrolla.docs.