-
-
Notifications
You must be signed in to change notification settings - Fork 19
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
Deprecate style.copy(applicator); rework style/applicator setting mechanism #224
Merged
Merged
Changes from 17 commits
Commits
Show all changes
20 commits
Select commit
Hold shift + click to select a range
412e059
Delay assigning applicator until after setting properties on copied s…
HalfWhitt e45ff86
Added changenote
HalfWhitt 9226673
Deprecated copy(applicator), style and applicator are now properties
HalfWhitt 6967d43
Added tests for deprecations
HalfWhitt a628751
More comprehensive deprecation test
HalfWhitt 9951cf7
Put intrinsic and layout assignments in style property
HalfWhitt 68959a9
restore decorator name -- from a bit of refactoring I undid
HalfWhitt a8b6b6e
de-icked warning, put reapply logic in BaseStyle._applicator setter, …
HalfWhitt 7850926
moved comment to the right place
HalfWhitt 426a29d
Fixed deprecated copy test
HalfWhitt 2bd31a0
Note: changed changenotes
HalfWhitt 8cb132d
Proofreading
HalfWhitt c12e4f5
Reverted style default None arg, and removed logic checking for None …
HalfWhitt 132cf85
Tweaked doc string and mentioned self.node reference
HalfWhitt 415c531
One more check for unready node
HalfWhitt 5799f1c
One more wording fix...
HalfWhitt 6d55698
Update change note to match code changes
HalfWhitt 3084327
Apply suggested changenote tweak
HalfWhitt 603adbc
Moved comment about assigning new style to a separate bugfix changenote
HalfWhitt fb33dc1
Raise instance/subclass
HalfWhitt File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1 @@ | ||
An applicator, once assigned to a node, now receives a reference to its node (as self.node). |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1 @@ | ||
Supplying an applicator to BaseStyle.copy() has been deprecated. If you need to manually assign an applicator to a style, do it separately, after the copy. (In normal usage, though, assigning an applicator to a style is handled automatically when styles and/or applicators are assigned to nodes.) | ||
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1 @@ | ||
The mechanisms for assigning styles and applicators to nodes, and applying styles, have been reworked. A node will now attempt to apply its style as soon as it is assigned an applicator; this means you should wait to do so until a node is sufficiently initialized to apply its style. To accomodate uses that currently do not follow this order, any exceptions resulting from a failed style application are caught, and a runtime warning is issued. In a future version, this will be an exception. (Assiging a new style will also trigger a reapply, as long as the applicator is already present.) | ||
HalfWhitt marked this conversation as resolved.
Show resolved
Hide resolved
|
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,29 @@ | ||
import sys | ||
from dataclasses import dataclass | ||
from unittest.mock import Mock | ||
|
||
if sys.version_info < (3, 10): | ||
_DATACLASS_KWARGS = {"init": False} | ||
else: | ||
_DATACLASS_KWARGS = {"kw_only": True} | ||
|
||
|
||
def prep_style_class(cls): | ||
"""Decorator to apply dataclass and mock apply.""" | ||
return mock_attr("apply")(dataclass(**_DATACLASS_KWARGS)(cls)) | ||
|
||
|
||
def mock_attr(attr): | ||
"""Mock an arbitrary attribute of a class.""" | ||
|
||
def returned_decorator(cls): | ||
orig_init = cls.__init__ | ||
|
||
def __init__(self, *args, **kwargs): | ||
setattr(self, attr, Mock()) | ||
orig_init(self, *args, **kwargs) | ||
|
||
cls.__init__ = __init__ | ||
return cls | ||
|
||
return returned_decorator |
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure the "normal usage" comment here is correct... or at least, it's open to a misleading intepretation. I think the interesting feature here is more that "when a new style is assigned to a node, any existing applicator on the node will be use for the new style" - which is more of a bug fix (see beeware/toga#2305), and independent of "applicator argument to copy deprecated". My inclination is to drop the "normal usage" comment here, and add a separate bug fix entry for being able to assign a new complete style to a node (which will also inherit any previous node applicator)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm, fair enough. I was just thinking in terms of Toga specifically, I think — and a Toga user should probably never encounter this anyway. And thank you for linking that issue! Didn't realize it was already being tracked.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Removed the parenthetical, added separate bugfix changenote, and edited that issue into the initial comment for the PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, right. Had momentary amnesia about what you said about whether or not to mark this as fixing it. I think it makes sense... Toga only requires Travertino of at least 0.3.0, right? So as soon as this is included in a released version, it's available to current version of Toga. With the caveat that current installations aren't going to be magically auto-updated, of course...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suppose it boils down to a sort of false positive question. Once Travertino 0.3.1 or 0.4.0 or whatever is released with this patch, it is entirely possible to have an installation of Toga 0.4.8 in which the bug is fixed / feature is added. And any new installation of it presumably will, unless the user specifically pins Travertino 0.3.0 as part of the install.
But it won't be guaranteed to be fixed on existing installations, unless the user updates Travertino, or until they update to the next version of Toga, which can require the newer version of Travertino.
I'm still inclined to think this counts, but as someone without much experience in project management conventions, it's not a hill I'd argue on if you disagree.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with your analysis - this PR will fix both bugs in Toga... but in a way that causes warnings in Toga. The catch will be how we release this in a way that minimises disruption to users. If existing Toga users are going to get a thousand warnings when they upgrade Travertino, we may need to do a near parallel release to make sure there's a clear way to avoid the warning.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that sounds like the way to go.
Pack.font
) and Restructure widget initialization toga#2937, but don't merge them yetThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's definitely one approach; the downside being that it will be difficult to avoid some users getting the warnings from Travertino.
The other possible approach would be something like:
That all hinges on (1) being possible; but if it is, this approach would give a little breathing room between the Toga release and the Travertino release, so the chances of people getting stuck in the middle zone is lessened. It also gives a little more space for (3) and (5) to be completed - and ironically, the longer they take to implement, the less the impact of the Travertino change will be.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, that makes sense! I had assumed # 1 would be ungainly, but I tried it out just now and what do you know, it's totally doable.