Re: A proposal for units in GTK+

[Havoc Pennington <hp redhat com>]

On Mon, Feb 03, 2003 at 02:53:08AM -0500, Jonathan Blandford wrote: 
>  * It might be nice to introduce a GtkSpacing widget as a means of
>    adding blank space to an area.

Wasn't there an earlier thread/proposal for that?

This is the function I most want when using glade:

 gtk_widget_set_padding (widget, GTK_SIDE_LEFT, 12)

Or I guess left_padding, right_padding, top_padding, bottom_padding
properties.

border_width and some of the box padding/spacing params are far less
useful than one would hope, because they always affect multiple
places, when you only want to change one...

> I'd appreciate any thoughts or comments.

It sounds reasonable. I think you'd have to keep things like
container->border_width updated with pixel values. Someone is
undoubtedly accessing the field directly.

There has been some past talk of "abstracting" the standard spacing
values such as the 12-pixel HIG distance. With this proposal, you
could probably have GTK_UNITS_STANDARD_GAP() that was the standard
spacing between two user-visible UI elements. Depending on how many
high bits you want to use.

I vote no on having "TWIP" anywhere in the API, it's cute but
confusing and weird. We have no leeway to scare programmers beyond the
type system etc. ;-)

An em is perhaps too large-grained, for typical font sizes. The
12-pixel spacing may well fall around a .5-em boundary.

I'm not sure how useful physical-screen units are; font-size-dependent
units seem much more useful.  If you're on a large/small screen you
will adjust the font, and the padding can just follow that.

Using dpi for font size adjustments in Pango seemed to work out
poorly. Plus, it seems like something bizarre would happen when you
have some units in a UI based on font size, some based on dpi, and
then the font size is itself based on dpi.

Maybe more importantly, when would a programmer choose physical units
vs. font-dependent units. That could lead to users changing their
font, and some apps resize their padding and some apps don't.  Which
is just a weird effect. It seems that surely we would decide that
either the font units or physical units was Right and the other one
would just be a mistake programmers could make.

Is it somehow context-dependent whether you want font units or
physical units?  Is it context-dependent according to a rule that's
simple enough for people to get right?

How does this relate to the units we end up using for a vector drawing
API?

How do you get the current setting in font/physical units? Say in
glade? gtk_container_get_border_width() etc. have to keep returning
pixels, do you add gtk_container_get_border_width_units() etc. 
in parallel to all the existing functions and properties?

Users will doubtless want a "user-configurable unit" so they can go on
anti-chubby campaigns.

Havoc