haha this has strong ps1 vibes

@ladyada If we can get a color wheel into ColorConverter/OnDiskBitmap, maybe we upgrade to a PS2 vibe?

https://cdn.discordapp.com/attachments/682423270083002468/821526384677617704/video0.mov

ya gotta have it make the crash bandicoot sfx 😂

Argh! I pushed the wrong branch last night.

This commit has the version with the following removed:

• "unselected" function
• color_wheel animation.

Ok, I updated the docstrings and excess print statements and repushed. Sorry for the confusion on this! Thanks for your support and patience on this one.

Thinking about this a bit more I think it will be better to refactor the animation into a subclass “AnimatedIcon”. There is a lot of baggage that will be unnecessary if someone wants a simple icon.

I’ll give it another shot at reorganizing it.

I refactored this into a subclass of IconWidget called IconAnimated. This way IconWidget can be used without the overhead of the animation buffers.

The IconAnimated subclass has an initialization function IconAnimated.init_class where the display and other parameters are passed to initialize the bitmap and palette buffers.

Important: The init_class function must be called before any IconAnimated are instanced.

Only one icon can be animated at a time. So, all IconAnimated instances share this same zoom bitmap and palette buffers that are stored in the Class variables. This buffer is used to prevent memory segmentation and memory allocation failures that can be induced by repeated instancing and del of large bitmaps.

The demo version of the touch_deck using IconAnimated is located in this gist.

@kmatch98 I like the way you refactored this into a subclass. Nice way to add functionality for those that want it, but allow those that don't to skip it.

I'm working on testing this out and I'm getting this error when I attempt to do the class initialization:

Traceback (most recent call last):
  File "code.py", line 20, in <module>
TypeError: function missing required positional argument #3

My line 20 is this initialization call:

IconAnimated(display=display, max_scale=1.5, max_size=(80,80), max_color_depth=256)

I'm not sure if I've ever used init_class before, perhaps I am misunderstanding how that works?

Thanks for the great catch on the documentation, that was a big one. I updated and it's ready for your further review. Thanks again for checking this out and helping improve it to where it is now.

I think that we may have some trouble with anochored positioning in IconWidget. While working on setting up a test for this I placed a single IconAnimated with anchored positioning and noticed that the touch_boundary first two items do get updated to the new location on the screen. Which then makes the adjustments done inside of the overridden contains method unnecessarily shift the position back toward the origin.

If I position it with x and y the touch boundary does not get updated and therefore the contains point does register correctly.

I think this also affects the main branch, but it's ok to discuss here since it will need to be merged into this PR too.

I think the issue can be setting touch_boundary in local coordinates. Then when the contains method is called to check the touches, the IconWidget.contains() method updates the coordinates to local coordinates before sending to Control.contains() which operations on local coordinates.

Right now the current definition of touch_boundary uses display coordinates for the upper left corner:

        self.touch_boundary = (
            self.x,
            self.y,
            image.width,
            image.height + _label.bounding_box[3],
        )

I think this should be updated to only local coordinates:

        self.touch_boundary = (
            0, # local coordinates
            0, # local coordinates
            image.width,
            image.height + _label.bounding_box[3],
        )

I'll push a PR on this and you can evaluate. Here is the PR: #24

This IconAnimated subclass references the IconWidget superclass for setting the touch_boundary, so the PR mentioned above should solve it for this subclass also.

So, this PR should be ok for touch_boundary. Yay for inheritance!

I just realized I missed this issue: #18 (review)

I should be able to give this one a try again tonight. My last few attempts led into finding issues unrelated to this PR with imageload and IconWidget.

I did manage to get a test in last night of the IconAnimated but the animation was looking odd to me. Like the animated image got layered on top of the "real" image but the "real" image wasn't hidden, so during the animation both were visible, albeit with the top one mostly obstructing the bottom one.

I want to reset my libraries and CircuitPython version to make sure I have a clean environment for testing. I am somewhat suspicious because I've been testing out various different PRs in the core, imageload, and FeatherWing libraries with it. Some of my libraries are modified from their current state. Need to get back to a clean slate.

I updated this to better handle possible error conditions, including when the init_class settings cannot accommodate the requested icon graphics, including requiring that indexed BMP files are required.

Also, I modified the input parameter names to clarify the difference between the Class variables and the Instance variables. Please note that the key instance inputs have changed to scale and angle.
The class IconAnimated.init_class inputs have changed to max_icon_size to differentiate from max_size (the Group's max number of elements).

I also added an example simpletest along with the "play" button icon.

Here are some other icon files:
icons.zip

The truecolor file should trigger a warning that the animation is cancelled.