Create a vertical ProgressBar Widget

[hugodahl]

• Move library file into directory for packaging
• Create a base class from the current widget for any common code or functionality between various widget implementations
• Add docstrings to the created base class

This PR will close #21

[kmatch98]

I tried running the code from progress_simpletest.py on a pyPortal and received this error. I'm not familiar with this notation on the line where it is causing this error, so I can't offer any suggestion on the root cause of the error. Maybe these are supposed to be comments?

code.py output:
Traceback (most recent call last):
  File "code.py", line 8, in <module>
  File "/lib/adafruit_progressbar/__init__.py", line 100
SyntaxError: invalid syntax

Here's where the error is occurring in the __init__.py file in the __init__ definition for the ProgressBarBase Class:

    _bitmap: displayio.Bitmap  # The bitmap used for the bar/value
    _position: (int, int)  # The (x,y) coordinates of the top-left corner
    _size: (int, int)  # The dimensions of the progress bar
    _palette: displayio.Palette(3)  # The palette to be used
    _progress: float  # The value to represent, between 0.0 and 100.0
    _border_thickness: int  # The thickness of the border around the control, in pixels
    _show_margin: bool  # Whether we should display a margin between the border and the value/bar
    # The minimum and maximum values we can represent
    _range: (int, int) or (float, float)

I commented out these statements, but then I got this error in progressbar.py. Maybe .fset is available in Blinka but not in CircuitPython on microcontrollers. Sorry I can't give any more insights as to what is going on, but let me know if you want me to do any more testing.

code.py output:
Progress: 0%
Traceback (most recent call last):
  File "code.py", line 32, in <module>
  File "/lib/adafruit_progressbar/progressbar.py", line 96, in progress
AttributeError: 'property' object has no attribute 'fset'

[hugodahl]

Thanks for those pieces of info @kmatch98. A lot of those issues are mainline "Pythonisms" that CP doesn't have or support. I'm kinda working my way through this project while also learning more Python than print("yay!"). So the changes are a mix of what I'm learning and figuring out, combined with what python.org and StackOverflow show, with a touch of PyCharm's input.

The latest changes should all be happy and run. However, I have some changes to make so that the bar can be displayed (currently filled with the alternate/background colour). From where I currently am, it shouldn't take too much more to get the refactor done and working. There are some other changes afterward that would be needed for quality-of-life, but I'll get to those in due time.

[FoamyGuy]

I tested this out today, it does run now for me. But I am getting some extra lines drawn on it, and it doesn't seem to "unfill" itself when the progress is set back down to 0

The structural changes to split this into a module are looking good to me now. I'm going to try tinkering some to see if there is a way we can make the original import statement work as well as the new ones so that we could possibly avoid having to change any existing progress bar using project code. But i'm unsure if it can actually be done.

Thank you for all of your work on this @hugodahl!

I will check out the new matrix portal example this week.

[hugodahl]

Thanks @FoamyGuy. The bars are current artifacts from the previous fill/clear methodology. I've got changes that should fix those, I just need to reimport them from my original "proof-of-concept" changes.

I've also added my current color-theory-ignorant-but-highly-visually-obvious blinka/PyGameDisplay example to make sure that we can test with some common code.

[hugodahl]

A few minor things that I observed:

1. Running on the pyportal, it doesn't know about the typing library. I'd suggest adding try/except in the three files:

try:
    from typing import Tuple, Union
except:
    pass

Done. Thanks for catching this!

2. For the horizontal bar (and might occur on vertical too), when it's set to 100% the bar doesn't quite go to the end.

This is intended behaviour, since there's both a border and a margin (both 1px on each side by default). If you set the margin_size to a value of 0, at the maximum value, it should be completely filled.

1. For a bar with max_value=100, if you set the value to 101 it causes some strange rendering since the bar is drawn over the outline. Also, if you set a value significantly > 100, it will crash because it is trying to write outside the bitmap. I'd suggest constraining the value to remain within the min/max values.

Somehow I managed to lose my assertions in the setter of progress and value that validated both the type (int or float) as well as the new value is within the minimum-maximum range for value, or 0-100 for progress. Fixed that.

1. The example is for the "old style" progress bar. It took me a minute to realize the parameters were different for the new style vertical/horizontal bar. Not sure exactly how to deal with this "old" vs. "new" transition, since it is a little confusing about which is the preferred usage. Should we gravitate the examples toward the "new" style?

The original examples, that is, all but the "displayio" one, will need to be updated with the new syntax. @FoamyGuy and I have gone over how we want to deal with the "legacy" class, which is why it still exists in this library. It's also why it has the "old" name of progressbar, and uses completely different parameters than the new HorizontalProgressBar and VerticalPRogressBar

I had thought, originally, of refactoring the progressbar class to enhance it with additional args, so that it could "do all the things", but that would have led down a very branch-heavy class depending on direction, orientation and such, and not immediately obvious as to "which way is this bar pointing".

Once these minor things get resolved, I think this is looking pretty good to me.

I agree. These are the final little details and polishing touches, which make the difference between "Yeah, it exists" and "Woo! It exists! Let's use this!"

[kmatch98]

Correction: It does go to 100, I was confused by the range(0,100) and was only setting it up to 99. Looks good!

[hugodahl]

This PR is ready for review. Again.

[hugodahl]

To merge, this may be something where we'd want to bump the version to 2.0 to indicate the significant changes included.

[jposada202020]

This is amazing you know how much I love your vertical progress bar!!! @hugodahl Welcome to the widget world :)

[hugodahl]

This is amazing you know how much I love your vertical progress bar!!! @hugodahl Welcome to the widget world :)

Thanks! It's taken me FAR longer than I expected or would have liked, but I did pick up a significant amount of Python in the process, which is where a lot of my time went. That and Pylint's duplicate code detection!

[FoamyGuy]

Thanks again for all of your work on this @hugodahl

I would suggest a few small tweaks but this is looking very close to me.

I think we should include a new example that makes use of the new HorizontalProgressBar and VerticalProgressBar classes more directly.

I used this one for testing them:

import time
import board
import displayio
from adafruit_progressbar.horizontalprogressbar import HorizontalProgressBar
from adafruit_progressbar.verticalprogressbar import VerticalProgressBar

# Make the display context
splash = displayio.Group(max_size=10)
board.DISPLAY.show(splash)

# set horizontal progress bar width and height relative to board's display
h_width = board.DISPLAY.width - 40
h_height = 30

v_width = 30
v_height = 140

h_x = 20
h_y = 20

v_x = 60
v_y = 70

# Create a new progress_bar objects at their x, y locations
progress_bar = HorizontalProgressBar((h_x, h_y), (h_width, h_height), 0, 100)
vert_progress_bar = VerticalProgressBar((v_x, v_y), (v_width, v_height), 0, 200)

# Append progress_bars to the splash group
splash.append(progress_bar)
splash.append(vert_progress_bar)

current_progress = 0.0
while True:
    # range end is exclusive so we need to use 1 bigger than max number that we want
    for current_progress in range(0, 101, 1):
        print("Progress: {}%".format(current_progress))
        progress_bar.value = current_progress
        vert_progress_bar.value = current_progress * 2
        time.sleep(0.01)
    time.sleep(0.3)
    # reset to empty
    progress_bar.value = 0
    vert_progress_bar.value = 0
    time.sleep(0.3)

It could serve as a good example script perhaps.

[FoamyGuy]

These changes are looking good to me.

I've tested all of the new example scripts successfully.

Thanks again for this awesome new functionality @hugodahl

[FoamyGuy]

When this gets merged and released we should bump the major version number since the new version uses slightly different importing syntax that is not backward compatible with previous versions. I can make a PR to update projects in the learn guide repo to use the new import syntax as well.

[kattni]

@FoamyGuy I wanted to make sure this didn't get missed. If you're going to put the PR into the Learn repo to fix the code there, I want to leave it to you to merge and release this. That way you can time it all together.

[FoamyGuy]

@kattni Yep, I'll get that PR in for the learn repo tonight and I will plan to merge this at the same time when that one goes in to change the learn projects to use the new import.