Re: Units and resolution independence for gtk+



On Thu, 2008-08-07 at 15:17 +0200, Alexander Larsson wrote:
> On Wed, 2008-08-06 at 17:07 -0400, David Zeuthen wrote:
> 
> > Also, a new type GdkUnit (and it's unsigned companion GdkUUnit) is
> > introduced. It's typedef'ed to gint. Like jrb proposed some high bits
> > are cannibalized to tag that the given value is an em and not a pixel
> > value. Also, some users of pixel values are already using -1 and
> > G_MAXINT as sentinels so bit 31 is off the table. Thus, bit 30 is used
> > to specify it's an em and if so, bit 29 is used to specify the sign. A
> > little convoluted but it works. Down the road one can add
> 
> I don't get why you need bit 29 here? Why can't you use bit 31 for signs
> in both pixels and units? You would need to use bit 30 != bit 31 to
> signify a unit instead of just having it be bit 30 == 1 be unit in order
> to make negative values work right. That leaves G_MAXINT, but you could
> just special case that value instead of a whole bit.

Yeah. That probably sounds right. I thought about this while driving to
work and here's what I'm planning to do. First of all, I'm going to
rename Unit to Size and place it in the GTK name space (the only reason
it's currently GdkUnit is that GtkUnit is used by printing; grrr!). 

Btw, I also want to store pixel sizes as a special unit (e.g. with a
high bit set) - this will allow us to automagically interpret current
pixel units (e.g. with no high bits set) as 1/12th of an em. Thus,
everything an app needs to do to Just Work(tm) with RI is to enable
resolution independence using gtk_size_enable_resolution_independence().
E.g. it should be a one-line patch [1].

Here's the revised proposal

 GTK_SIZE_EM
   GTK_SIZE_ONE_TWELFTH_EM for convenience

 GTK_SIZE_POINT
   cf. Behdad's proposal

 GTK_SIZE_MM
   GTK_SIZE_INCH for convenience

 GTK_SIZE_PIXEL

The storage format is going to be like this

 bit 31: sign
 bit 30, 29, 28: used for storing the unit type

giving us 7 different units (can't set all of bits 28, 29, 30 so it's 7
instead of 8); thus we'll have some room for future expansion. Does this
sound OK?

     David

[1] : actually the sole reason we can't turn RI on by default is that
some apps read structure fields that, if RI is enabled, will be stored
as GtkSize's with high bits set. For example, Firefox does this; if I
run Firefox with forcing RI on, the scroll bars look wrong.




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]