-
-
Notifications
You must be signed in to change notification settings - Fork 669
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
Allow creating images from raw image sources #2263
Merged
Merged
Changes from 4 commits
Commits
Show all changes
10 commits
Select commit
Hold shift + click to select a range
9732208
Add the ability to create a toga Image from the internal platform ima…
freakboy3742 ef6185a
Add a testbed test of creating images from raw.
freakboy3742 7ffe38f
Add changenote.
freakboy3742 218fadb
Document the raw image API.
freakboy3742 cf43936
Correct the raw type declaration for GTK.
freakboy3742 b0600a6
Rework type declarations for Image to allow for native types.
freakboy3742 1d2cea7
Revert to a simple Any type annotation.
freakboy3742 a1b0f47
Restore 88 char word wrap.
freakboy3742 472b1c6
Corrected capitalization of image.
freakboy3742 d606b95
Use a documented TypeAlias for image source data.
freakboy3742 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
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 @@ | ||
Images can now be created from the native platform representation of an image, without needing to be transformed to bytes. |
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
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
Oops, something went wrong.
Oops, something went wrong.
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.
@rmartin16 If you're looking for a hard-mode typing challenge: How should the type annotation on
src
be modified to allow for this? It's a type on a class that, by definition, is platform specific, and won't exist in the environment where toga-core is being built, tested, or documented.The only solution I can think of is to add
UIImage | NSImage | GdkBitmap | ...
but that won't be correct - you can't use a UIImage unless you're on iOS.Any ideas?
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 this might be possible....but it, perhaps, starts to verge on the ridiculous....
For instance, here's where I got to before I, more or less, gave up:
I'm not sure if mypy technically considers this strategy above part of their larger type narrowing support, but it helps accommodate the runtime environment.
That said, for this to really make mypy happy, it'll require other changes in Toga...notably, replacing the star imports in the platform-specific Toga code to explicitly import these native library classes....and we'll also need typing stubs for, at least, PyGObject.
BUT...this has major consequences for building docs. On my Linux machine, it tries to interpret the definition of
ImageSrcT
for Linux but cannot findtoga_gtk
; I can installtoga_gtk
to build the docs....but then the build blows up withRuntimeError
s aboutDISPLAY
env var. Maybe Sphinx has some buried support for effectively ignoring certain symbols...and that could serve as some type of resolution here.At any rate, the
src
argument feels like a good candidate forAny
where the documentation fills in the details.P.S. - type checkers and IDEs are still likely to resolve the type of
src
toAny
even with all these accommodations if Pillow isn't installed. And if we just add these platform-specific image classes, such asGdkPixbuf.Pixbuf
, then the type will always beAny
because it would be impossible to resolve all the types in theUnion
on any one system.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.
That was broadly my initial thought as well - except that it falls down on iOS/Android (which will never be installed in the local environment where sys.platform will find it), and on custom backends, and in the Sphinx builds you mention later.
Woof... good luck with that endeavour... I like yaks as much as the next person, but autogeneration of types from GI bindings is a yak to far for me :-)
Is there any advantage to specifying the type at all in this case? What (if any) benefit exists to an explicit
Any
over "no type declaration"? Cosmetically, "Any" reads to me as "You can use literally anything", which isn't true (at least, not in spirit). This is a case where I think I'd prefer to say nothing, and force the reader to actually read words, rather than provide something explicitly too broad as an automated description.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 it depends on your goals.
As far as typing is concerned, an untyped argument will be resolved as
Any
...so, in that regard, addingAny
or not in this case is functionally the same.However, the absence of a type can mean different things. It could mean this function hasn't been evaluated for typing; this would be useful when gradually typing a code base and using mypy's functionality to ignore untyped functions and methods. Although, as you mention, if someone takes
Any
seriously, then they will be especially misled on what this argument can accept.That said, given this is part of the API surface, I think it will be useful to ensure it has a type assigned....so, we can know the type has been assessed.
So, thinking a bit out of the box perhaps, you could create a
NewType
calledImageDataT
that's just assigned toAny
. In that way, it's an indication a specific type is being requested....it just isn't expressed in Python types.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.
Replacing all the specific Image classes with an
ImageT
that maps toAny
seems like a decent option that is going to render well as documentation, and won't be intractable from a mypy perspective. I'll go with that.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.
Additionally, fwiw, using
NewType
wouldn't really work either....since it would, in fact, require users to explicitly cast the image data asImageType
which wouldn't be a great experience at all.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.
Ugh... fine, I guess we'll just go with
Any
in the union then... le sigh...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.
The docs still look quite cluttered with everything in the union. Can we just make ImageType an alias for Any, and then describe all the options in its docstring?
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.
See the discussion above - that's where I started, and it looks awful; it renders in Sphinx as
NewType("Image", Any)
, with the sphinx link to "NewType" being to the Python docs. AFAIK, it's not possible to provide documentation for the type itself (which would be the ideal situation).I'm open to other suggestions, but putting
Any
in the union is the only version I could find that mollifies mypy/PyCharm and doesn't read like a train wreck.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.
Since a union that contains Any no longer provides any type-checking safety, and there are so many things in the union that it isn't very good documentation either, my suggestion was to just replace the whole union with Any, and rely on the documentation text to explain what's accepted.
Ideally we would do this with an alias, but if Sphinx doesn't work with that, we can use Any directly, and put the documentation in its own section on the Image page with incoming links from all the relevant places.