-
-
Notifications
You must be signed in to change notification settings - Fork 666
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
Better error handling for capturing as an image #2673
Comments
The question for me is whether it's better to raise an error, or succeed, but with a dummy image and a log message. Raising an error is likely an "app exiting" behavior; but returning a screenshot that is the right size, but empty, with a clear log message that "screenshots aren't supported on Wayland" would at least allow an app to continue, and would require less safety checks (and typing updates) to ensure that |
This kind of error is likely to happen to end users who are running in an environment that the app developer hasn't tested. In that case, an exception is better, because it would bring up a crash dialog with the message. If we used a log message instead, it would be invisible to the user, so the app developer could only guess at the cause. Allowing the app to continue probably isn't useful in this case, because it can't do anything useful with an empty screenshot. If the app has other functions, then the user can just avoid the crash by not using the screenshot feature. |
Describe the bug
Failing to capture a screenshot can result in unexpected failure modes.
For instance, on Linux under Wayland, it is not possible to screenshot the entire screen:
Instead, you get a runtime
NotImplementedWarning
(that's also part of a realllly long line of text) followed by aTypeError
. This is because the screenshot API expects the backend to always return valid image data; in this case,None
is returned.This is also true of
toga.widgets.Canvas.as_image()
andtoga.window.Window.as_image()
.In a slightly different way,
toga.widgets.ImageView.as_image()
is also affected.Here, users can create an empty
ImageView
and end up with anAttributeError
if it doesn't actually contain an image.Steps to reproduce
Sample app:
Expected behavior
While some of these failure modes are user induced, others are quite subtle and may be entirely unknown to developers at build time. Toga could be more resilient to these failure modes and provide better error handling when they occur.
Screenshots
No response
Environment
0.3.19
0.4.6.dev52+g10608425a
Logs
No response
Additional context
On a side note, there are also likely to be interesting issues if you use these APIs while the window is not being shown. I think this may be getting a little in to particularly contrived failure modes, though.
The text was updated successfully, but these errors were encountered: