Skip to content

progress: don't update responses that aren't there

Adam Williamson requested to merge adamw/zenity:missing-responses into master

zenity_progress_handle_stdin always tries to update these responses when progress seems to be done, but sometimes the responses aren't present at all. The cancel response is not present if no_cancel is true (that's when the CLI param --no-cancel is used), and the OK response is not present if auto_close is true (that's when --auto-close is used). We need to only update the responses when they're present. This solves a problem where zenity will print some errors then crash when --no-cancel or --auto-close (or both) are used, notably by Steam:

zenity[3319]: adw_message_dialog_set_response_enabled: assertion 'adw_message_dialog_has_response (self, response)' failed zenity[3319]: adw_message_dialog_set_response_enabled: assertion 'adw_message_dialog_has_response (self, response)' failed zenity[3319]: adw_message_dialog_set_response_enabled: assertion 'adw_message_dialog_has_response (self, response)' failed steam.desktop[3319]: ** steam.desktop[3319]: Zenity:ERROR:../src/util.c:465:zenity_util_gapp_quit: assertion failed: (GTK_IS_WINDOW (window)) steam.desktop[3319]: Bail out! Zenity:ERROR:../src/util.c:465:zenity_util_gapp_quit: assertion failed: (GTK_IS_WINDOW (window))

I don't know why this causes the parent to stop being a window, but...apparently it does. See:

https://bugzilla.redhat.com/show_bug.cgi?id=2177287

Signed-off-by: Adam Williamson awilliam@redhat.com

Merge request reports