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 588589 - Button text size exceeds the button width
Button text size exceeds the button width
Status: RESOLVED FIXED
Product: banshee
Classification: Other
Component: User Interface
1.4.3
Other All
: Normal trivial
: 1.x
Assigned To: Banshee Maintainers
Banshee Maintainers
: 588644 594350 595239 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2009-07-14 23:40 UTC by Rodrigo Flores
Modified: 2009-09-15 08:01 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
A banshee screenshot (57.41 KB, image/png)
2009-07-14 23:42 UTC, Rodrigo Flores
  Details
Fixes layout of the sync-all button in the track editor. (842 bytes, patch)
2009-07-15 12:32 UTC, Alexander Kojevnikov
committed Details | Review

Description Rodrigo Flores 2009-07-14 23:40:49 UTC
Please describe the problem:
The text in the button "is bigger" than the width of the button.

Steps to reproduce:
1. Select multiple multimedia files
2. Click on edit file information (or something like that (I use the translated version))
3. See the text size exceeding the width of the button near the bottom-left corner of the screen


Actual results:
The text appears exceeding the width

Expected results:


Does this happen every time?
Yes.

Other information:
Comment 1 Rodrigo Flores 2009-07-14 23:42:55 UTC
Created attachment 138417 [details]
A banshee screenshot
Comment 2 Alexander Kojevnikov 2009-07-15 12:32:39 UTC
Created attachment 138435 [details] [review]
Fixes layout of the sync-all button in the track editor.
Comment 3 Andrés G. Aragoneses (IRC: knocte) 2009-07-15 13:34:20 UTC
Just wondering: I checked the documentation of gtk_widget_set_size_request here:

http://library.gnome.org/devel/gtk/unstable/GtkWidget.html#gtk-widget-set-size-request

and I saw:

"Note the inherent danger of setting any fixed size - themes, translations into other languages, different fonts, and user action can all change the appropriate size for a given widget. So, it's basically impossible to hardcode a size that will always be correct."

So why setting a width request in the first place?
Comment 4 Alexander Kojevnikov 2009-07-15 13:48:18 UTC
> So why setting a width request in the first place?
> 

AFAICT, it's done to make the width of the sync-all button equal to the sum of widths of Back and Forward buttons. Thus the size is not really fixed but based on the sizes of other widgets. Whether or not this is compatible with Gnome HIG is another question.
Comment 5 Andrés G. Aragoneses (IRC: knocte) 2009-07-15 14:23:37 UTC
(In reply to comment #4)
> > So why setting a width request in the first place?
> > 
> 
> AFAICT, it's done to make the width of the sync-all button equal to the sum of
> widths of Back and Forward buttons. Thus the size is not really fixed but based
> on the sizes of other widgets. Whether or not this is compatible with Gnome HIG
> is another question.


Interesting, then I wonder if this is a bug on the documentation *or* on gtk+, because the description of the function clearly says "Sets the minimum size of a widget;", it doesn't say anything about a maximum.
Comment 6 Alexander Kojevnikov 2009-07-15 15:02:17 UTC
Whether or not the widget should grow to all available space is controlled by the 'expand' and 'fill' parameters of PackStart. Both are false for the button meaning it won't grow beyond the requested minimum size (but still can be less than it, if there's not enough space)
Comment 7 Alexander Kojevnikov 2009-07-15 18:07:05 UTC
This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.

Andrés, please contact me on irc or by email if you have questions on this stuff.
Comment 8 Bertrand Lorentz 2009-07-15 19:39:25 UTC
*** Bug 588644 has been marked as a duplicate of this bug. ***
Comment 9 Alexander Kojevnikov 2009-09-07 08:03:58 UTC
*** Bug 594350 has been marked as a duplicate of this bug. ***
Comment 10 Alexander Kojevnikov 2009-09-15 08:01:49 UTC
*** Bug 595239 has been marked as a duplicate of this bug. ***