godbout / Wooshy.docs

it's like Alfred but for the UI
https://wooshy.app
221 stars 0 forks source link

not working on Basecamp 3 #104

Closed kandros closed 1 year ago

kandros commented 1 year ago

Not working in the macos Basecamp App

It does work in the web version

godbout commented 1 year ago

thanks. will check.

godbout commented 1 year ago

so your point is that it doesn't work in the macOS app AND the web version?

kandros commented 1 year ago

so your point is that it doesn't work in the macOS app AND the web version?

It work on web ✅ Don’t work on macOS app ❌

godbout commented 1 year ago

👌🏼 grazie!

godbout commented 1 year ago

actually everything was clear from your first post 😂 for whatever reason i had read it does NOT work in the web version. will add the macOS app support for next release. planning it for in a few days.

kandros commented 1 year ago

Thanks you, for curiosity what makes an app work vs another? Haven’t had the time to investigate how the app works but it’s really interesting

godbout commented 1 year ago

Thanks you, for curiosity what makes an app work vs another? Haven’t had the time to investigate how the app works but it’s really interesting

ok. ready for the novel? 😅️

native apps have Accessibility abilities right out of the box. this is because Apple does this well, and care (i assume). for those apps nothing has to be done, and when apps like Wooshy or kV are trying to make use of the Accessibility APIs to grab the data they need to do their work, everything is available, and available fast. but now there's apps (non-native) that don't enable the Accessibility abilities by default. the reason is they suck. they're slow af and enabling the Accessibility is gonna use half the ram of your computer. so they disable it by default.

for those apps that don't enable the Accessibility abilities by default, Wooshy needs to force them to enable it. there's several ways to go about this:

  1. Wooshy could blast any app, regardless whether they need their Accessibility support to be enforced or not. advantages: easy and lazy for the developer. should work for most apps. disadvantages: massive amount of useless resources used on users' computers. plus it's gonna break some apps, usually those who deal with windows management. (the world of Accessibility is complicated. different apps respond to different treatments. some like Spotify even need two different treatments to work. etc. etc. for your own sanity i recommend not digging into this 😂️)
  2. Wooshy could let users define some apps in the Preferences/Settings themselves. like if an app doesn't work, users could drop it in some category for example (although it's more complicated than that. different apps require different treatments... which would mostly make not much sense to end users. it's technical shit), and therefore Wooshy would blast the Accessibility for those apps. advantages: lazy for the developer. users have control over which app works and doesn't work. no need to wait for a new release. disadvantages: users have to bother with this. have to learn more than necessary. AX is complicated stuff.
  3. Wooshy holds a list of app, and knows exactly what to do with each app to enable the Accessibility for them. advantages: this is fine-tuned and uses the least amount of resources possible, because I know the technical reasons of what is supposed to happen behind the scenes. also, users don't have to know or think about anything. they use the app, and that's it. i'm responsible for making the whole thing smooth, not them. disadvantages: users may need to wait for a new release to have some apps working.

so as you're aware, i've went with point 3. the main reason is: i already hold an App Catalog for my other app, kindaVim. kindaVim is way more complex, and when a user reports that kV doesn't work with an app, i need to investigate way more deeply. then i add the app to the App Catalog. overtime, the App Catalog grows, and becomes better and better. every new app added is a new solid brick added to both kV and Wooshy. so overtime, apps support gets better.

when someone reports Wooshy not working on an app, i just don't add that app to "Wooshy". what i do is i investigate how the app reacts with kindaVim. then once the investigation is finished, i add the app to the App Catalog, and the app is now supported for both kV and Wooshy (and actually Scrolla too).

hope that makes sense!

godbout commented 1 year ago

but now there's apps (non-native) that don't enable the Accessibility abilities by default. the reason is they suck. they're slow af and enabling the Accessibility is gonna use half the ram of your computer. so they disable it by default.

those are mostly Electron apps, web browsers, and some other few apps that use their own shit frameworks (like Java based. respect no macOS standard at all. not just AX but also standard keyboard shortcuts lol cry).

disadvantages: users may need to wait for a new release to have some apps working.

i am (usually. got some electricity problems in the last few days 😅️) very responsive. like i answer people daily, and i release very often. even more when it's about an app support.

kandros commented 1 year ago

Thanks a lot for the details 🙏

godbout commented 1 year ago

Ws4 coming in a few hours, with Basecamp 3 support ✌️

godbout commented 1 year ago

added in v4: https://github.com/godbout/Wooshy.docs/releases/tag/4

kandros commented 1 year ago

working like a charm thank you, I'll try other products soon