GNOME Bugzilla – Bug 578626
Vertical Scale Widget sometimes not allocating enough room for it's value digits
Last modified: 2016-06-08 01:34:20 UTC
Please describe the problem: Whilst learning gtk+ I came across a problem with the layout of a vscale widget. The problem only shows itself when the value display is placed at the GTK_POS_TOP (default) or GTK_POS_BOTTOM of the vertical slider. When the value is placed to the side there is no problem. [The equivalent problem on the hscale widget appears not to occur but if the application font size is magnified (to about 30 pt!) then the digits are tall enough to show the problem with hscale also.] Steps to reproduce: 1. Compile attached program 2. Run it Actual results: Observe the formatting problem of the digits on one of the vertical sliders. It looks like the widget does not allow for the fact that the value display is wider than the slider and allow it self enough room to be drawn. Not only is the widget too small but the repainting of the digits is wrong. Expected results: I would have expected the widget to sort its size out correctly as it does when the digits are placed to the side. Does this happen every time? Yes. Other information: I'm new to GTK+ but I think this is a problem with the Scale Widgets.
Created attachment 132477 [details] A self contained C program to show the problem. A C program I was working on to teach myself GTK+. I want to place the value digits of the vertical sliders (vscales) above the sliders. My gut intuition is that both scale widgets are missing some code that compares the value display layout size (perhaps from pango?) with the smaller dimension of the widget and takes the larger of the two.
Seems I might've duplicated most of this here - https://bugzilla.gnome.org/show_bug.cgi?id=766372 - although my report also implies an option to include the width in the sizing of horizontal Scales too. (N.B. HScale/VScale variants are deprecated since GtkOrientable came around.) That's because otherwise large value strings eat into the scale trough's size, meaning that as the values get wider, the trough gets less size too. Having an option to size the trough independently and use the combined width for sizing would be splendid.