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 536969 - Status bar widget and line on the top border.
Status bar widget and line on the top border.
Status: RESOLVED OBSOLETE
Product: gtk+
Classification: Platform
Component: .General
2.12.x
Other All
: Normal enhancement
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2008-06-06 11:51 UTC by Andrea Antolini
Modified: 2013-04-27 22:13 UTC
See Also:
GNOME target: ---
GNOME version: Unversioned Enhancement


Attachments
Visual description of the issue (129.27 KB, image/png)
2008-06-06 11:53 UTC, Andrea Antolini
  Details
Fix (6.58 KB, patch)
2009-07-23 12:48 UTC, Jaroslav Šmíd
none Details | Review
I don't think so, space for resize grip is reserved only when there is resize grip. See the screenshot with patched GTK (24.95 KB, image/png)
2009-08-11 11:48 UTC, Jaroslav Šmíd
  Details

Description Andrea Antolini 2008-06-06 11:51:38 UTC
Current  GTK+ statusbar widget, draw a line on the top edge of the status bar.. it's not dependant to the gkt theme engines, even if with some of them, "issue" is less evident. 

I think that the scope of this line is to separate status bar from other widget present in the window (eg. a treeview or text widgets)  but in some cases the widgets are attached and an unaesthetic effect appear (at least for me)

Probably this was present since a lot of time also in previous gtk+ libs..

I think status bar should look better if it's have a flat design without any border arount statusbar fields..

a lot of GTK+ apps draw the status bar with this top line (I've attached a screenshot)

Tnx Andra
Comment 1 Andrea Antolini 2008-06-06 11:53:33 UTC
Created attachment 112270 [details]
Visual description of the issue
Comment 2 Benjamin Berg 2008-06-06 18:02:41 UTC
Are you looking for the GtkStatusbar::shadow-type style property? If you set it to GTK_SHADOW_NONE, then nothing will be drawn around the statusbar.
Comment 3 Andrea Antolini 2008-06-06 20:51:19 UTC
Wow!.. it works :).. not for all gtk2 engines but with most of them (clearlooks, mist, thinice)  it works... Others gtk2 engines like murrine seems ignore this setting but as workaround I added also this code in the .gtkrc file of my preferred murrine gtk2 theme

style "theme-statusbar" = "theme-default"
{
 engine "clearlooks"
  {
  }
}
class "theme-statusbar" style "theme-default"

regards 
Andrea

Comment 4 Jaroslav Šmíd 2009-07-23 12:48:40 UTC
Created attachment 139071 [details] [review]
Fix

I think we could have better statusbar. This patch will disable the shadow around the frame in the statusbar and will draw it itself in expose_event handler. This will fix issues that application attaching other widgets (like midori, gimp, file-roller and others) to statusbar will not end up with ugly bluring resize grip when resizing the window and the top line will be all over the allocation width of the statusbar.
It keeps binary compatibility so applications won't break :-) Some themes will be uneffected by this, but perhaps some badly written themes not respecting GTK_SHADOW_NONE for the frame and drawing it anyway will draw the frame of the GtkFrame embeded in the StatusBar. But it is theme's problem and should not affect your decision to accept this patch - it will eventually lead to better user experience :-)
Comment 5 Matthias Clasen 2009-07-24 16:51:43 UTC
No comment on the drawing changes yet, but your patch changes things to unconditionally reserve space for the resize grip, which will cause children to not use the full space even if there is not resize grip. Thats not a good change.
Comment 6 Jaroslav Šmíd 2009-08-11 11:48:40 UTC
Created attachment 140424 [details]
I don't think so, space for resize grip is reserved only when there is resize grip. See the screenshot with patched GTK
Comment 7 Jaroslav Šmíd 2009-08-11 11:54:30 UTC
But perhaps there should be condition in size_request to add (currently hardcoded in GTK, which is bad) 18 pixels to width and height set to MAX(height,18) if there is resize grip.