Using Windows UI to silence notifications results in an error in the error handling process (`toasted/toast.py > _handle_toast_failed`)
Exception ignored in: <function Toast._create_future_toast_event.<locals>.<lambda> at 0x000001CFF4C08E00>
Traceback (most recent call last):
File "C:\Users\olliv\AppData\Local\Programs\Python\Python312\Lib\site-packages\toasted\toast.py", line 767, in <lambda>
future.set_result, getattr(self, method_name)(sender, event_args)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Users\olliv\AppData\Local\Programs\Python\Python312\Lib\site-packages\toasted\toast.py", line 864, in _handle_toast_failed
"Toast failed with error code: " + args.error_code.value
To reproduce, press the 3 dots at top right of the notification and press the "Silence future notifications from... " button on a toast produced by toasted - now any future toasts (which will fail) prints above message in the console.
If I may make a feature request related to this, it would be cool if there was a function that let you check if toasts can be sent at all from a particular APP_ID (eg due to the user intentionally disabling notifications from the program).
There is a Toast.can_send_from_app_id property but it only allows checking for the currently set app ID, but I can happily convert it to a function to allow checking for any given app ID. 👍
I'm just still not sure about if app ID's should be per toast or globally (since it is set per Python process) so not every function does accept arbitrary app IDs yet.
Ah I didnt know about this property.
I'm just still not sure about if app ID's should be per toast or globally (since it is set per Python process) so not every function does accept arbitrary app IDs yet.
I think APP_ID on a per toast basis is good :)
If you want to make the API more comfortable to work with, you could also make providing APP_ID optional and add a global APP_ID that toasts will default to if no APP_ID is provided.