Repository navigation
Add overlay switcher for the currently loaded Smart scenario #848
Description
Describe the feature
When a Smart scenario is already loaded and paused, switching to a different scenario currently has a lot of friction if the user is inside the app they are automating.
Current flow:
- Leave or close the app being automated.
- Open Klick'r.
- Select another scenario.
- Grant screen recording permission again.
- Return to the app being automated.
The desired flow is much shorter:
- Pause the currently loaded Smart scenario and tap a Switch button on the floating overlay.
- Pick another Smart scenario from an overlay list.
Because screen recording permission was already granted for the currently loaded paused scenario, the app should be able to reuse the active media projection session when feasible instead of asking again.
Describe the usage
This is useful when working inside another app/game and needing to swap between several Smart scenarios without leaving that app. The switcher should stay in the overlay layer, not reopen the main scenario list Activity, so the automated app remains foreground.
One possible implementation is an overlay-native switcher:
- show a Switch button on the Smart floating menu only while detection is idle/paused and media projection is active
- open an overlay dialog/bottom sheet listing other Smart scenarios
- selecting a scenario changes the loaded scenario and keeps the existing screen recording session alive
- update the foreground notification and quick settings tile to reflect the selected scenario
Related
This is related to #493, but it is specifically about manual, user-driven switching from the floating overlay while a scenario is already loaded. It is not the same as an automation action that jumps from one scenario to another.
Is it a duplicate?
- There is no exact duplicate
Activity
Nain57 commentedon May 29, 2026
First of all, thank you for contributing to the project.
I did try the PR provided in #849 and i have to admit, i'm not really a fan of the solution. I definitly need to define some contribution rules in order to avoid developpers working on rejected code (and I'm really sorry about it).
Reworking/Ruling for Feature requests is in my roadmap for Klick'r 4.0.0 release (probably moving it to the Github Discussions).
For now, here are some basic rules (and of course, I'm open to discussion for any of those)
Unlike bugfixes, features changes can impact the whole app and the way users sees it. This is a huge challenge to keep the app as simple as possible while offering more and more features/flexibility to more advanced users. That's why I think changes made for a feature request must be discussed and approved first before starting the development.
Alongside the actual feature implementation, UI/UX must also be decided before developing (where do we add the interface to access the feature / how should it looks). This can be by prototyping, images of what it should looks like, even drawings, as long as we can understand how it will be once implemented in the app. For the developpers around here, yes this is a basically a Scrum ticket 😄.
If you needs icons for the app, please note that all icons are from the Material Icons (or slightly altered ones). You can find them all here: https://fonts.google.com/icons?icon=
That being said, i think I can start to explain why I'm not sure about your implementation:
The main menu is the main hub of the application and this is probably the thing the users sees the most. My main rule about it is to keep it as simple as possible. While I can understand the need for this switch, I don't think it belongs to the main menu.
My proposal as a solution for this would be to move the switch to the Klick'r notification. Currently, there is a button to open the app, which is mainly to help you change scenario more easily. We could change this button behaviour to open a scenario selection dialog instead of the app, allowing to skip the request for media detection.
What do you think ?
vibhor1102 commentedon May 29, 2026
I appreciate your view that it may not be fit for the general app's overall direction, especially around simplicity and minimalism.
I'd like to clarify that i worked this out as a solution for myeslf primarily, that i got codex to code for me in about 15 minutes. Not much thoughts or planning went into it. (I maintain a forked repository for personal use — that's the neat part about any OSS)
I also lack development experience myself, and mostly rely on Codex. So, I'd believe that you can take this vision to a better goal for the actual implementation. Notification idea might be a better permanent place for the actual app as well. You may also make other heavy modifications to the #849 PR, reserve it for future versions, or just close it and keep this issue open and work out a different solution. All up to you. My vision may not be as aligned with the long term interests of the application.vibhor1102 commentedon Jun 18, 2026
@Nain57 I have another idea. By default, maybe the scenario switcher could live in the notifications, and a separate setting from the Klick'r settings page is provided to change the location to overlay instead permanently? That'd satisfy my use case while keeping UI simpler for everyone.
Once you approve, i'll look closer into the feature, and aim to swap icons with Material UI icons, tighten the behaviours around its loading and open a new PR with a more appropriate solution to the same.