You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Instead, you get a runtime NotImplementedWarning (that's also part of a realllly long line of text) followed by a TypeError. 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() and toga.window.Window.as_image().
In a slightly different way, toga.widgets.ImageView.as_image() is also affected.
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
Operating System: pop os 22.04
Python version: 3.10.14
Software versions:
Briefcase: 0.3.19
Toga: 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:
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 None is a valid input throughout the system.
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: