Re: GtkCanvas requirements?

[Havoc Pennington <hp redhat com>]

Marco Pesenti Gritti wrote:
> There is something which bothers me though. Support for some units, 
> points for example, would require floating points measures. And I 
> suspect we don't want to do layout in floating point (instability 
> issues). Mozilla converts css units in twips (an arbitrary integer unit, 
> 1/20 of a point). That's a way to go about it I guess, though it 
> requires conversions it in the canvas items. Better ideas?

I agree that it would be really good to avoid floating point. Pixels are 
by far the most intuitive thing for people using or writing items, too 
(since as you say they avoid having to multiply everything). Pango does 
have the precedent though and for convenience we could just use the same 
units as Pango.

Maybe there's some way to make this optional, for example items that 
feel they can do something useful with sub-pixel sizes could implement 
an interface that did the size negotiation in sub-pixels. The default 
implementation of the sub-pixel size negotiation methods would call the 
whole pixels one, and the default implementation of the whole-pixels 
methods would call the sub-pixels one and round off. If you didn't 
override either one it would break badly, but don't do that then ;-)
all items would have to implement one or the other but not both.

One downside of doubles is simply the extra memory usage when storing 
coordinates; I think keeping the abstract base class for items and most 
common concrete classes as small as possible is a nice win. I'd like to 
see items be "lighter" than GtkWidget, in almost any of the usage 
scenarios (widget core or drawing api or other).

Havoc