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

From: Andy Little (andy_at_[hidden])
Date: 2004-12-17 12:43:46

"Reece Dunn" <msclrhd_at_[hidden]> wrote in message
news:BAY101-DAV14300DA4E52BA9F3F31320A0AE0_at_phx.gbl...
> 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.

Despite my previous remarks regarding automatic conversions, after reviewing
what I have done on this previously I now conjecture that the two types of
space (device space and logical space) have very different properties and
their types cannot be directly compared against each other eg using operator
< without some subtleties ( I now remember this is the reason that I havent
completed a 'pixel' type). There needs to be a device available, to provide
the 'context' of pixels_per_inch() or whatever, however,  by changing the
device mode( screen resolution) or the device itself( display <--> printer))
,the comparison of two constants, one of each type, may give different
results at different times. I am not sure that is a wise move! (I have
always ended up using physical units for very much the above reasons and
contrive to keep device units as a low level implementation detail.. It is a
major reason that I ended up looking for and eventually writing a physical
quantities library, to solve the problem once and for all! )

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

How about defining one  set of types which stands as the boost::gui
abstraction user level type at a distinct layer above the OS ( and Maybe use
a UDT, because you have complete control over the semantics of conversions
if they are necessary, whereas you really dont with inbuilts without taking
more drastic steps, though this does depend on the whole approach I guess)
and apply whatever  is necessary per operating system by actual conversion
at some lower layer rather than by typedefs which differ dependent on the
particular operating system... IOW a sort of encapsulation.

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

[snip code commented above]

Continuing on my old theme from several previous posts I think that
convincing the user of the benefits of using a logical coordinate system,
rather than using device coordinates is at the heart of this and honestly
makes life so much simpler.Ultimately a pixel is simply not well enough
defined ( How big is a pixel?) . However once the device is removed then
something needs to replace it, which is a well thought out logical
coordinate system. Rather than the crude approach I have taken recently in
declaring types as physical quantities( eg length::mm ... which causes
issues as to runtime scale changeing from mm to in for example), I have been
recently thinking more in terms of using some sort of transform object,
basically inspired by MS GDI+. A transform object at the level of the
application( for example) could then be used to convert to
logical coordinates in a (say) application window size event under control
of the user,
for example. I also wonder if  a window is not , from a coordinate/space/
drawing viewpoint, just another graphics element  and should  follow the
same graphics element rules as the objects in the client area. I have had a
brief look at the recent docs and am glad to see the docs progress.  It
would be interesting to see Concept definitions of eg a button, drop down
etc. IOW what is the 'minimalist essence of button' etc...:-)

regards
Andy Little