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 403753 - GtkFrame painting glitch with ythickness != 2
GtkFrame painting glitch with ythickness != 2
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Widget: Other
2.10.x
Other Linux
: Normal minor
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2007-02-02 22:36 UTC by Xan Lopez
Modified: 2007-06-22 10:17 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Patch (2.35 KB, patch)
2007-02-02 22:37 UTC, Xan Lopez
none Details | Review
Testcase (4.66 KB, text/plain)
2007-02-02 22:40 UTC, Xan Lopez
  Details
Painting glitch with ythickness != 2 in GtkFrame, v2 (1.87 KB, patch)
2007-02-13 16:58 UTC, Xan Lopez
none Details | Review
Updated test (4.97 KB, text/plain)
2007-02-13 17:00 UTC, Xan Lopez
  Details
Also update the docs. (2.46 KB, patch)
2007-02-13 17:08 UTC, Xan Lopez
none Details | Review

Description Xan Lopez 2007-02-02 22:36:16 UTC
GtkFrame frame is slightly mispositioned when ythickness is different of the default value 2. Attached patch hopefully fixes this and avoids drawing the gap in the frame when yalign is 0 or 1, it looks quite silly in those cases IMHO.

Had to add the IS_ZERO macro as the direct comparision == 0.0 was failing. Seems this is a recurrent issue, see bug 69482, maybe some standard mechanism for this should be added to glib?
Comment 1 Xan Lopez 2007-02-02 22:37:19 UTC
Created attachment 81793 [details] [review]
Patch
Comment 2 Xan Lopez 2007-02-02 22:40:03 UTC
Created attachment 81794 [details]
Testcase

Testcase that allows to set {x,y}thickness and {x,y}align to a GtkFrame.
Comment 3 Tim Janik 2007-02-13 11:56:44 UTC
Xan, why is your patch checking with EPSILON-pading around 0.0, but checks for 1.0 precisely? it looks like your patch means to change the API, so that yalign=(0..1) allowes the user to do alignment specification, and yalign=0 || yalign=1 means to paint no gap whatsoever.
if that's really what you meant to do, there's however no point in using IS_ZEOR() at all. 

also,
> +#define IS_ZERO(x) (((x) < EPSILON)? TRUE : FALSE) 
can be written more conscise as:
  #define IS_ZERO(x) ((x) < EPSILON)

furthermore, your patch does:
> -	  g_print ("height extra %d\n", height_extra);
there is no such line in upstream, is this patch maybe relative to some local changes you have?

it'd be nice if you could clean up the above issues and supplied a patch that applies cleanly against upstream ;)
Comment 4 Tim Janik 2007-02-13 15:30:08 UTC
in a later conversation it turns out that the need for IS_ZERO was due to using spin button values directly in the test application. the documentation has been extended now to explain possible pitfalls with using floating point calculation results, particularly adjustment->value:

http://developer.gnome.org/doc/API/2.0/gtk/GtkAdjustment.html#numerical-precision
Comment 5 Xan Lopez 2007-02-13 16:58:46 UTC
Created attachment 82472 [details] [review]
Painting glitch with ythickness != 2 in GtkFrame, v2

Moving the IS_ZERO hack to the test and removing debug fallout.
Comment 6 Xan Lopez 2007-02-13 17:00:28 UTC
Created attachment 82473 [details]
Updated test

Check for rounding errors in the values returned by spinbutton.
Comment 7 Xan Lopez 2007-02-13 17:08:30 UTC
Created attachment 82474 [details] [review]
Also update the docs.
Comment 8 Tim Janik 2007-06-22 10:17:20 UTC
thanks, applied:

Fri Jun 22 12:13:39 2007  Tim Janik  <timj@imendio.com>

        * gtk/gtkframe.c (gtk_frame_paint): applied patch from Xan Lopez
        to eliminate gap in painted frame for yaling=0.0 or yalign=1.0.

        * tests/testframe.c: added test application from Xan Lopez to
        test xalign/yalign interactions with xthickness/ythickness.