GNOME Bugzilla – Bug 719936
GtkFontButton: Make sure the dialog isn't destroyed on delete-event
Last modified: 2014-09-29 02:09:57 UTC
I initially thought to fix this by always keeping font_filter and friends around after building the dialog and resetting them on the dialog once it gets rebuilt (on button clicked). But then I realized that font_filter_data gets freed by the destroy notify when the dialog is destroyed so I think this solution of trying to keep the dialog alive will have to do. I can't think of any other way for the dialog to be destroyed except getting a pointer to the dialog (using gtk_window_list_toplevels() or similar) and calling gtk_widget_destroy() on it. But in this case I think you get what you deserve.
Created attachment 263626 [details] [review] GtkFontButton: Make sure the dialog isn't destroyed on delete-event The remaining code assumes that the dialog doesn't get destroyed, but it actually does on delete-event. In particular, the filter function and the preview text are lost as soon as the dialog is created and thus when we create a new dialog we don't have those properties to set on it anymore.
is this really a big concern though ? with csd decorations, the font chooser dialog doesn't have a close button, just cancel+select, so the user already has to be quite determined to really delete the window.
Both Escape and Alt+F4 still result in a delete-event though. Note that the issue that made me look into this was that the gtk_font_chooser_set_filter_func() API was only working for the first time that button was clicked.
Review of attachment 263626 [details] [review]: Sure
Attachment 263626 [details] pushed as d05730d - GtkFontButton: Make sure the dialog isn't destroyed on delete-event