Skip to content

Create getter/setter for font #42

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 13 commits into from
Closed

Conversation

kmatch98
Copy link
Contributor

The label class had the "font" exposed as a variable without an explicit getter/setter. This lead to unexpected results, such as only part of the label getting redrawn with the new font, and some of the old font remaining. That is, some of the characters would be using the "old" font and only the changed characters would use the "new" font. When changing the font with label.font=newFont, and calling for a text update, the drawing is only be updated for characters that were changed.

In this pull request, I am adding an explicit definition of getter and setter for the font. This added getter/setter causes the complete text string to be re-rendered from scratch. By setting self._text = '', then the call to self._update_text(old_text) will execute a full redraw of the text with the updated font.

@kmatch98
Copy link
Contributor Author

Please forgive me, as this is my first pull request for Adafruit libraries. I read through the learn guide, but it wasn't obvious to me how to overcome this error when creating the documentation. I Received the following error when creating the documents ("Sphinx"):

/home/runner/work/Adafruit_CircuitPython_Display_Text/Adafruit_CircuitPython_Display_Text/adafruit_display_text/label.py:docstring of adafruit_display_text.label:10:Unexpected indentation.

I'm unsure how to debug and eliminate this error message, so your suggestions and guidance will be helpful.

@ladyada
Copy link
Member

ladyada commented May 22, 2020

@kattni can help you get it passing next week :)

@ladyada ladyada requested a review from kattni May 22, 2020 15:08
@@ -50,7 +43,6 @@ class Label(displayio.Group):
properties will be the left edge of the bounding box, and in the center of a M
glyph (if its one line), or the (number of lines * linespacing + M)/2. That is,
it will try to have it be center-left as close as possible.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the issue might be caused by the removal of this blank line. This SO Q/A mentions the same error: https://stackoverflow.com/questions/45880348/how-to-remove-the-cause-of-an-unexpected-indentation-warning-when-generating-cod

Copy link
Contributor Author

@kmatch98 kmatch98 May 23, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the suggestion, I added this blank line back in and now pylint is throwing this error:
adafruit_display_text/label.py:46:0: C0303: Trailing whitespace (trailing-whitespace)

Sorry if this is simple stuff, but I'm totally unfamiliar with pylint or Sphinx, so I will appreciate your guidance.

Oh, and in the process of checking out these changes I fixed a calculation bug and added several other improvements to the getters/setters in another pull request. Let me know if you want me to cancel this PR and we can just focus on that one. Thanks for your patience with me on this!

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No worries. I am pretty new to sphinx and pylint myself. They can definitely be finicky.

I think the issue now is the empty line has a tab indention on it. Pylint wants it to be an empty newline with no tabs or spaces in it.

@kmatch98
Copy link
Contributor Author

Thanks to @FoamyGuy the checks now pass.

If desired, I can cancel this PR and focus on the other one that I created. It includes these changes (sorry for combining but I forgot to fork from the original source!): See PR # 43

Let me know how you recommend to proceed. Thanks for all your support!

@tannewt
Copy link
Member

tannewt commented May 26, 2020

Closing in favor of #43

@tannewt tannewt closed this May 26, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants