After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 594535 - No accesor for GtkStatusbar->label and ->frame
No accesor for GtkStatusbar->label and ->frame
Status: RESOLVED OBSOLETE
Product: gtk+
Classification: Platform
Component: Widget: Other
2.22.x
Other All
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
: 470476 (view as bug list)
Depends on:
Blocks: 594053 595791 597610
 
 
Reported: 2009-09-08 18:06 UTC by Javier Jardón (IRC: jjardon)
Modified: 2018-05-02 14:48 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Implement gtk_statusbar_get_message_area (2.63 KB, patch)
2009-09-11 12:47 UTC, Christian Dywan
none Details | Review
Standalone test case (3.95 KB, text/plain)
2009-09-11 12:50 UTC, Christian Dywan
  Details
Implement gtk_statusbar_get_message_area #2 (2.56 KB, patch)
2009-11-12 15:08 UTC, Christian Dywan
needs-work Details | Review
Implement gtk_statusbar_get_message_area #3 (4.80 KB, patch)
2009-11-12 16:48 UTC, Christian Dywan
committed Details | Review

Description Javier Jardón (IRC: jjardon) 2009-09-08 18:06:48 UTC
It looks like GtkStatusbar->label and GtkStatusbar->frame don't have an accessor.  Is this intentional?
Comment 1 Christian Dywan 2009-09-09 11:37:41 UTC
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.
Comment 2 Bastien Nocera 2009-09-09 11:40:55 UTC
The use cases is showing the "buffering" progressbar in Totem's status bar in place of a message.
Comment 3 Christian Dywan 2009-09-09 11:57:28 UTC
Can you provide a small test case showing how the progressbar is used? Why can't you use a normally packed widget?
Comment 4 Bastien Nocera 2009-09-09 15:04:32 UTC
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
Comment 5 Christian Dywan 2009-09-11 12:47:24 UTC
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".
Comment 6 Christian Dywan 2009-09-11 12:50:31 UTC
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.
Comment 7 Matthias Clasen 2009-09-11 17:12:08 UTC
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.
Comment 8 Christian Persch 2009-09-29 21:20:14 UTC
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.
Comment 9 Christian Dywan 2009-09-30 11:54:09 UTC
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.
Comment 10 Christian Dywan 2009-10-13 11:05:30 UTC
*** Bug 470476 has been marked as a duplicate of this bug. ***
Comment 11 Matthias Clasen 2009-11-11 18:48:07 UTC
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.
Comment 12 Christian Dywan 2009-11-12 15:08:59 UTC
Created attachment 147583 [details] [review]
Implement gtk_statusbar_get_message_area #2

Fixed a warning and bumped the Since tag.
Comment 13 Matthias Clasen 2009-11-12 16:06:40 UTC
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
Comment 14 Christian Dywan 2009-11-12 16:48:52 UTC
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 15 Matthias Clasen 2009-11-12 16:53:30 UTC
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.
Comment 16 Christian Dywan 2009-11-12 18:02:38 UTC
Pushed to master.
Comment 17 Javier Jardón (IRC: jjardon) 2009-11-12 18:05:59 UTC
Comment on attachment 147592 [details] [review]
Implement gtk_statusbar_get_message_area #3

commit 0bc668056449e5a3502eef9d3cfdc3b6e5f201b9
Comment 18 Christian Persch 2009-11-16 17:06:10 UTC
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.
Comment 19 Christian Persch 2009-11-16 19:24:34 UTC
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 :)
Comment 20 Matthias Clasen 2009-11-23 05:11:37 UTC
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.
Comment 21 Vinicius Depizzol 2009-11-23 11:19:58 UTC
Could someone attach a screenshot with these different spacing properties?

Thank you very much.
Comment 22 Christian Persch 2009-11-23 16:10:53 UTC
Re-opening so this doesn't get lost.
Comment 23 Sven Herzberg 2009-11-24 13:47:17 UTC
(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?
Comment 24 Timothy Arceri 2013-10-14 06:49:12 UTC
Did this make it into GTK+3? Is this bug still relevant?
Comment 25 Daniel Boles 2017-10-09 13:27:01 UTC
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).
Comment 26 GNOME Infrastructure Team 2018-05-02 14:48:55 UTC
-- 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.