Re: [boost] Re: thoughts on a GUI component library

From: Reece Dunn (msclrhd_at_[hidden])
Date: 2004-12-16 11:22:37

Andy Little wrote:
> "John Torjo" <john.lists_at_[hidden]> wrote
>
>>As a side-node, I'm moderately against having float coordinates. Why would
>>you think int is not enough?
>
> I would have thought that both types would be required dependent on the type
> of  'space' you are in. When working in pixels or 'device units', integers
> are an obvious choice ie at very low level. Each pixel is then visualised as
> a rectangular tile in a grid.  The object (eg a window) is closely
> associated with the grid and the 'gridness' may well be taken into account
> when manipulating the object , which  is specifically designed to 'live'
> only within the grid. However there are obvious cases (drawing a circle)
> where an analogue space is a better choice to represent the object.
> Scrolling and scaling are other factors
>
> A more complete framework would have UDT's rather than ints, representing
> pixels, as well as other types representing inches, millimetres  as used in
> (say) CSS and (I think) SVG etc, which would allow automatic conversion
> (runtime for  pixels) of one measure to another. It would also allow precise
> control over the semantics of converting.

I think that the simplest way to do this is to have a coordinate_type
UDT that specifies either float, long or a special type (like the one
above). This type would then provide:

    long  to_long() const;
    float to_float() const;

This allows you to provide the necessary conversions (e.g. millimeters
to pixels) and not worry whether the OS uses long/int or float values.

The position, size and area types are then built using coordinate_type,
where coordinate_type will provide conversion as necessary.

One problem with this is how do you specify the coordinate_type used by
the position/size types. If you do it via a macro definition you
introduce binary incompatibility. If you use a template parameter, you
will need to have a template decleration wherether you use the
position/size, e.g.:

    template< typename CoordType >
    inline void move( const area< CoordType > & a );

which makes the implementation more complex, IMHO.

> Together with the point/size issue coordinate systems are in the set of
> primitives that are  the building blocks of a 'space system'. like ints,
> doubles and maths are the building blocks a numeric system.

Agreed. Though would it be better to have something like:

class float_space
{
    float val;
    public:
       long to_long() const{ return long( val ); }
       float to_float() const{ return val; }
    public:
       template< typename CoordType >
       float_space( CoordType ct ): val( ct.to_long())
       {
       }
};

class millimeter_space
{
    ...
    template< typename CoordType >
    millimeter_space( CoordType ct ):
       val( from_float( ct.to_float()))
    {
    }
};

template< typename CoordType >
struct position_type
{
    CoordType x, y;
    template< typename ConvType >
    position( ConvType a, ConvType b ): x( a ), y( b );
};

typedef position_type< float_space > position;

Though I am not sure if this would work.

Regards,
Reece