Re: A proposal for units in GTK+

[Jonathan Blandford <jrb redhat com>]

Havoc Pennington <hp redhat com> writes:

> 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?

It's been discussed, but I've never seen a proposal.

> 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...


This is a different feature.  It would be very nice to have, but is
totally orthogonal to my proposal. (-:

> > 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.

That would be really nice, similar to what we had
GNOME_PAD/GNOME_PAD_SMALL for.  However, having values like this unless
we pick units for them.  Something like that would have to be
implemented in terms of this.

> 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. ;-)

It's also used by Mozilla and Windows, so there's some precedent.
Possibly putting a comment in the header would be sufficient.  Also, we
probably want to discourage physical sizes anyway.

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

Yeah, I was thinking of storing the base unit as 1/100 of an em or
something.  GTK_UNIT_EM would just convert the number, just like
GTK_UNIT_INCH(val) would do something like ((val*1440)|(1<<32)).  I

> 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.

I think you rarely want physical units, but could want them occasionally
(possibly in an app like gdm's greeter, for example).  The font-based
sizing is much more interesting and useful.  I imagine it would get much
more use, especially if we extend the mechanism w/ macros in the hig.

> 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?

Well, I think that we want to build some helpful macros on top of this
for more 'stylistic' sizes. eg something like
  gtk_container_set_border_width (container, GTK_DIALOG_BORDER_SIZE);
could be nice.

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

What vector drawing API?  (-;

The units are, for the most part, independent of mechanism, so I expect
it will probably work out alright.

> 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?

Another subject for discussion.  We could do one of three things.

1) Change the getters then include the unit information.  This could
   break people who aren't expecting it.  We may have to add a
   gtk_i_want_to_use_units() to let newer programs use the feature.

2) Add additional getters.

3) Wait until 3.0 before doing this and just break the compat there.

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

"user-configurable unit" seems totally crazy, but perhaps we can come up
with something.

Thanks,
-Jonathan