![]() For that last part note that I connected TravisCI to Github, so build logs are public, and thus you can see exactly how the app is built from source. Also it could differ from the actual release. All the source code is visible here on Github, though I understand that few people have time to actually check it. That one is easily confirmed using an app like Little Snitch. There is no telemetry or any network call from the app. That means I worked hard on the app size, consumption of the user resources (CPU, mem, battery, etc), and user privacy. I have no intention of making any money out of it, and have a very conscious goal of being as non-intrusive as possible. On the general topic of security/trust: you can never know if you don't reverse-engineer the app, what the app is truly doing, however, I can still try to convince you of my intent, for what that is worth: I'm doing this app out of wanting to empower others. Personally I think all the value-proposition of AltTab is in its windows thumbnails, but there have been other suggestions to add a preference to hide thumbnails to only show app icon, and/or titles, so that could be combined with the degraded mode here and do a 2-in-1. We could imagine a degraded mode where there are no thumbnails if the permission is off. Without it, AltTab wouldn't be able to display thumbnails of other windows. This is why it requires the new Catalina permission called Screen Recording. Another thing it does is display screenshots/thumbnails of these windows in its own UI. It queries state of the windows of other apps, and can manipulate them (i.e. Hey I appreciate you raising concerns regarding the strong permission requirements of AltTab.ĪltTab is, from an OS API standpoint, an accessibility app like a screen-reader is. It is not the best onboarding UX, but it is cheap to implement for now. The user would then relaunch AltTab, and get prompted to give permission, as on the initial start. For now I'll just observe the checkbox, and if someone removes it, it will simply quit AltTab, so we avoid the terrible behavior described in #269 for cheap. It would take a lot of code and complexity I think to make it that flexible. If you uncheck the permission, and the app suddently stops tracking things because it is unable to, then the model is going to be broken. The app currently make a model in memory of the state of apps and window around it. ![]() The codebase is really is not easy to refactor to handle dynamically stopping/starting listening to these events. ![]() However I realized that this also impact subscribing to process and window accessibility events. ![]() I observed the Accessibility permission checkbox state, and based on that I start/stop listening to keyboard events. I started implementing Accessibility permission observing in: ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |