GNOME Bugzilla – Bug 595742
Widget type that gtk_info_bar_get_action_area() returns is not documented
Last modified: 2018-02-10 04:40:21 UTC
The documentation doesn't say which GtkWidget gtk_info_bar_get_action_area() returns, so one has to dig in the source to find out that it's actually a GtkVButtonBox if one wants to modify container settings.
Created attachment 143593 [details] [review] Document content/ action areas as #GtkBox I think it would be good to document all action/ content areas as #GtkBox, that is of GtkDialog and GtkInfoBar. I would refrain from documenting the exact type in case there's a need to use a different subclass, and using GtkBox API is presumably good enough for the usual case.
Created attachment 143594 [details] [review] Use "content_area" in GtkDialog buildable On a related matter, I think the buildable of GtkDialog should also use "content_area" instead of vbox. If you don't mind me attaching this here as well, this is a patch adding the name, while keeping "vbox" for compatibility.
In my particular usecase, I wanted to place a minimum size close button into the GtkInfoBar. The button should only consist of a small x, without relief, like it is often done in tabs and seach bars. I didn't manage to get the button below a certain size until I realized that the container was a GtkButtonBox which has a minimum-child-size setting (well, and even then, I had problems, but that's bug #595741). So, for me, the documentation as GtkBox wouldn't have been helpful either. To modify container settings in a meaningful way, it would at least need to be documented as a GtkButtonBox.
Why don't you let it size based on the label like it's done everywhere else? Or do you have a locale specific size you want to set on the button?
There is no text display on the button. It should just be a small close icon, taking as little space as possible, being as un-obtrusive as possible. Examples of what I am trying to do are the close-buttons on the individual tabs of gedit or gnome-terminal.
Ah, so your button can become much too large. In that case I think it would make sense to provide properties that override the style properties in the same way the old function. Resurrecting the old function is probably not the best idea since it doesn't differentiate between width and height.
Yes, that would indeed be a very nice solution.
We're moving to gitlab! As part of this move, we are closing bugs that haven't seen activity in more than 5 years. If this issue is still imporant to you and still relevant with GTK+ 3.22 or master, please consider creating a gitlab issue for it.