Nain57 / Smart-AutoClicker

An open-source auto clicker on images for Android
GNU General Public License v3.0
2.02k stars 359 forks source link

Scenarios Folders/Categories #529

Open bluespheal opened 3 weeks ago

bluespheal commented 3 weeks ago

Describe the feature

I would love to be able to make folders or categories to place Scenarios in, to better organize them.

Describe the usage

I often find the Scenario menu to be a bit cluttered, adding folders or categories in which you can put in Scenarios would help with the clutter, as well as better organize your scenarios, either by type or app where they are being used in. I'd would also like the ability to manually order elements inside the Scenarios Menu.

Is it a duplicate?

ValerieLehane commented 1 week ago

A foreword: Pardon my ADHD. When I get to thinking about interface flows and back-end operations and all that, all topics get connected into this singular continuum because they are all at least somewhat related, but for other people, it can look like a bunch of tangents that never weave back into the main thread. Flow-of-consciousness is the only way that I can initially write, and I'm just trying to share ideas while I'm able, not write a draft and then go back and clean it up and run out of steam and end up throwing it all away. Hopefully, the following makes as much sense to others as it does to me, and doesn't bother anyone.

I have had this same thought. The scenarios currently are ordered alphabetically (or, by character index within the character set, more specifically), so to work around the inconvenience somewhat, you can prefix their names with numbers and special characters, but there's no substitute for having them in collapsible/expandable lists, or nestable, breadcrumb-navigable folders like in many file managers.

Where it really starts to suck is when trying to copy visible conditions from other scenarios. You end up with so many duplicates, and the list of conditions ends up truncated. I think that scenarios having sub-scenarios, so that it's easier to organize control flow when designing a scenario, would be great. Then, for copying conditions, we could have an easier time of it if we could, rather than navigate a list of every condition known to the application, instead select from a list of scenarios, with their sub-scenarios nested a level beneath them. Each scenario could be presented as an atlas of image thumbnails representing the conditions available within the scenario, so that we have a quick, compact visual reference to help us find what we're looking for.

Additionally or alternatively, depending on the alignment of the stars and author/maintainer whims, I also suggest a solution to the visual condition duplication problem. For each visual condition, when it is created, rather than being saved within Klik'rs app data for that specific scenario, save it within a sort of visual condition database, with its own (universally?) unique identifier (or let the condition name given by the user be used, if unique, or used as a prefix to the internal identifier if not unique, and/or compare the colliding non-uniquely-named condition images and, if they are exactly the same, discard the newer image and create a reference instead). Then, within the context of copying conditions from other scenarios, where all visual conditions are listed, there need not be any duplicates shown. When a condition is copied, rather than creating a full duplicate, it can instead exist as a reference to the original, with any later altered data attached to the database entry belonging to that reference. This can be how two conditions based on the same image can use the same image file and not duplicate it on disk, but also have their own unique data about the image (metadata, I guess) and how it is to be used, ie the match percentage for fuzzy comparison, the boolean for whether detection is based on presence or non-presence, the detection mode (exact position, screen region, whole screen, and any relevant coordinates for those). The image file can be kept on disk in the condition database until there are no more scenarios referencing it, at which point the image will be purged. To deal with restoring/importing previously exported scenarios where the images used by the scenario have been purged (or, such as in the case of migration to a new device or sharing scenarios with a friend, the images never will have existed in the first place), images should continue to be saved in the export process, but the import process should check with the created UID (or UUID?) for the image, and/or the user-specified condition name, and/or perform exact comparison of the images themselves in order to determine if a matching image already exists, and if a matching image already exists, create a reference instead of a new entry in the image database.

I'd also love to be able to directly export condition images, so that I can open or edit them externaly, and crop them tightly in order to reduce the comparison work that must be done, then reimport them to overwrite the original condition, hopefully resulting in better responsiveness/performance. Klik'r would need to take into account the change in dimensions and match up where the original and altered images are the same in order to update the screen position data for all references that need it.

Finally, after that, I would like to be able to provide image masks, so that instead of comparing to rectangular areas only, we can provide a black and white (or black or white) image to specify which pixels within the image to compare and which to disregard. The use case for this is that, often, an application may have stylized graphical buttons with interior regions that have some degree of transparency. Maybe the numeral "7" is on a button, and the button itself rests above a backdrop that may change at any time, so to deal with this, instead of setting the fuzzy comparison percentage as high as you can, where the maximum setting of 20% may never be enough or may result in false positives (or potentially both), depending on how chaotic the background is, you can keep a low percentage and provide an image mask, in the form of a rectangle the size of the visual condition it is meant to be used with, where all black pixels mark regions to ignore during comparison, and all white pixel mark regions that are valid for comparison.

If anybody (particularly Nain57) likes any of this, feel free to go ahead and use the ideas, make issues/tickets, etc.