GNOME Bugzilla – Bug 594535
No accesor for GtkStatusbar->label and ->frame
Last modified: 2018-05-02 14:48:55 UTC
It looks like GtkStatusbar->label and GtkStatusbar->frame don't have an accessor. Is this intentional?
Those are internal widgets. Using them directly is not a good idea and basically undefined. Please check your use cases before asking for missing accessors.
The use cases is showing the "buffering" progressbar in Totem's status bar in place of a message.
Can you provide a small test case showing how the progressbar is used? Why can't you use a normally packed widget?
Packed widgets will pack to the right of the status bar, not in place of the status messages. The code removing the current label and adding a vbox with the label and progressbar is at: http://git.gnome.org/cgit/totem/tree/src/totem-statusbar.c#n67
Created attachment 142976 [details] [review] Implement gtk_statusbar_get_message_area What about providing a box in the statusbar, that can be accessed via gtk_statusbar_get_message_area, and you can pack your widgets in there. That lets you avoid the surgery. It's not exactly the same, though, that is the label isn't changed the way does. Maybe a property would help here, such as "expand-label" and "ellipsize-label".
Created attachment 142977 [details] Standalone test case For reference, this test case contains an adapted version of Totem's statusbar packing. Depending on an #ifdef in the code it uses the proposed new function.
I don't really see why any of this is necessary... the statusbar is an hbox, so you have full access to all its children.
The point is that we want to replace the statusbar's label with a hbox containing that label. One needs to do this, because if you just pack the extra widgets into the statusbar itself the frame won't extend all around all children. See bug 372452. However I think you're right; we can do the same widget surgery without extra accessors. statusbar->frame is the first child of the statusbar (as GtkContainer), and the label is the child of that frame (as GtkBin). So the new API isn't strictly necessary; however it's still a nice addition to have a hbox there so one doesn't _need_ to do that widget surgery.
The question is what is going to happen if GtkStatusbar code ever changes. Then the surgery will blow up for good. That is incidentally one of the motivations for the sealing.
*** Bug 470476 has been marked as a duplicate of this bug. ***
I guess the message area idea is actually somewhat nice. While the statusbar _is_ an hbox, you really want to add your stuff inside the frame... so I guess I'll give that a hesitant +1.
Created attachment 147583 [details] [review] Implement gtk_statusbar_get_message_area #2 Fixed a warning and bumped the Since tag.
I guess we should have gtkbuilder support for adding children to the message area. Ie implement GtkBuildable, and in add_child, check for type == message-area
Created attachment 147592 [details] [review] Implement gtk_statusbar_get_message_area #3 Updated, with GtkBuildable implementation. I think it should be message_area with an underscore, as GtkDialog also uses an underscore. (No idea if it matters or if it's just style as with Glib signals)
Comment on attachment 147592 [details] [review] Implement gtk_statusbar_get_message_area #3 You are right, we seem to be using _ throughout for these names. Patch looks good.
Pushed to master.
Comment on attachment 147592 [details] [review] Implement gtk_statusbar_get_message_area #3 commit 0bc668056449e5a3502eef9d3cfdc3b6e5f201b9
Just a tiny nit: why was the weird value 4 chosen for the hbox's spacing? I'd have expected maybe 0 (let the API user set his own spacing if necessary), or possibly 6 or 12 or 18 (not sure which one is most likely HIG-correct), but certainly not 4.
Also, this patch does break the widget surgery as currently done by e.g. epiphany, aisleriot, totem, ...: Gtk-CRITICAL **: gtk_container_remove: assertion `GTK_IS_TOOLBAR (container) || widget->parent == GTK_WIDGET (container)' failed Gtk-CRITICAL **: gtk_box_pack: assertion `child->parent == NULL' failed Gtk-WARNING **: Attempting to add a widget with type GtkHBox to a GtkFrame, but as a GtkBin subclass a GtkFrame can only contain one widget at a time; it already contains a widget of type GtkHBox They assume that the label is the direct child of the frame, which doesn't hold anymore. Of course, you may say they get what they deserve for messing with the internals of the statusbar :)
Lets pick a better value for the spacing. I honestly didn't pay attention to that... someone with sufficient hig interpretation skills needs to divine the appropriate value, I'd say. As for the breaking surgery, not sure we can do much about it. Of course, contrived workarounds like only inserting the box when get_message_area is called, but thats probably worse than some temporary breakage. We should add a release note about this, though.
Could someone attach a screenshot with these different spacing properties? Thank you very much.
Re-opening so this doesn't get lost.
(In reply to comment #8) > The point is that we want to replace the statusbar's label with a hbox > containing that label. One needs to do this, because if you just pack the extra > widgets into the statusbar itself the frame won't extend all around all > children. See bug 372452. > > However I think you're right; we can do the same widget surgery without extra > accessors. statusbar->frame is the first child of the statusbar (as > GtkContainer), and the label is the child of that frame (as GtkBin). > > So the new API isn't strictly necessary; however it's still a nice addition to > have a hbox there so one doesn't _need_ to do that widget surgery. I used to pack frames into the status bar (and sync the style properties of the status bar to the frame's border type) and pack my stuff into the new frame. Will this be a use case that will also be covered by the new function? This whole "let's add more content to statusbar" issue has seen lots of solutions. Will this new function be the _best practice_ for this issue?
Did this make it into GTK+3? Is this bug still relevant?
Yes, get_message_area() is in GTK+ 3, but the issues raised in Comments 18~20 still appear to be relevant. The whole concept of setting spacing and margins and etc in .ui files or other code is broken anyway; that should be the province of themes only, now that they have almost all the tools needed (except border-spacing in GTK+ 3, sadly).
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gtk/issues/324.