GNOME Bugzilla – Bug 758776
GtkMessageDialog: be able to fill and expand its content
Last modified: 2018-04-15 00:31:27 UTC
GtkMessageDialog permits to add custom content in the message_area. But that content cannot currently fill and expand the available space in the case when a GtkMessageDialog is resizable (it is not by default). The use case is for example the close confirmation dialog in gedit, when there is a list of unsaved documents in a GtkScrolledWindow. The dialog is set to be resizable to be able to see the whole list of documents. It is possible to poke at GtkMessageDialog internals, by walking through the message_area parents and repack them by calling gtk_box_set_child_packing() with expand=true and fill=true. But it's a hack and could get broken over time. So see the attached patch, I think it's a safe change.
Created attachment 316443 [details] [review] GtkMessageDialog: be able to fill and expand its content 'message_area' is contained in 'box' which is contained in 'dialog-vbox1'. 'box' is the horizontal box that can also contain an image on the left. But 'box' was packed with expand=0 and fill=0. In the case where a GtkMessageDialog is set to be resizable (it is not by default), it was not possible to fill the dialog with the message_area content. So change the 'box' packing to expand=1 and fill=1. When the dialog is not resizable, it doesn't change anything. And when the dialog is resizable, the content can now fill the available space.
After more thinking, it's possible to add the custom content to the content_area instead of the message_area. The content_area is expandable. But it's a little less convenient when using a GtkMessageDialog. Also, I'm not 100% sure that the above patch would create regressions or not. I guess that since the GtkMessageDialog is not resizable by default, it doesn't change anything since it allocates the natural size, and the natural size doesn't change depending on whether a widget is packed with expand=1 and fill=1. But in the case where applications call gtk_window_set_resizable(true), there may be unexpected regressions.
It's indeed less convenient to add custom content to the content_area instead of the message_area, because (at least in gedit) we need to change the spacing and set the same margins. The margins can get out of sync over time. So for example, code like this is currently needed: > content_area = gtk_dialog_get_content_area (dialog); > gtk_box_set_spacing (GTK_BOX (content_area), 12); > > gtk_widget_set_margin_start (custom_content, 30); > gtk_widget_set_margin_end (custom_content, 30); > gtk_widget_set_margin_bottom (custom_content, 12); > gtk_box_pack_start (GTK_BOX (content_area), custom_content, TRUE, TRUE, 0);
well, message dialogs are not meant for custom content.
Currently in gedit, the close confirmation dialog is a GtkDialog subclass that tries to mimic the style of GtkMessageDialog. The git history shows that it needed to be adapted several times to keep it in sync with GtkMessageDialog. And with GTK+ master the style is broken again. And to mimic GtkMessageDialog, gtk_dialog_get_action_area() is needed, which is deprecated. > well, message dialogs are not meant for custom content. Why gtk_message_dialog_get_message_area() exists, then? For GtkMessageDialog, there is also gtk_dialog_get_content_area() of course, since GtkMessageDialog *is a* GtkDialog.
We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.
As announced a while ago, we are migrating to gitlab, and bugs that haven't seen activity in the last year or so will be not be migrated, but closed out in bugzilla. If this bug is still relevant to you, you can open a new issue describing the symptoms and how to reproduce it with gtk 3.22.x or master in gitlab: https://gitlab.gnome.org/GNOME/gtk/issues/new