Boost logo

Boost :

From: Reece Dunn (msclrhd_at_[hidden])
Date: 2004-12-18 11:54:11

Andy Little wrote:
> "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
>>>>you think int is not enough?
>>>I would have thought that both types would be required dependent on the
>>>of 'space' you are in. When working in pixels or 'device units',
>>>are an obvious choice ie at very low level. Each pixel is then visualised
>>>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
>>>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
>>>(say) CSS and (I think) SVG etc, which would allow automatic conversion
>>>(runtime for pixels) of one measure to another. It would also allow
>>>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! )

Hmm. This is a complex issue! It makes sense to have some sort of
metric_type that supports pixels, percentages, picas/points, millimeters
and inches. As you hint at, these need a device to resolve or convert.

In general, you will only want to manipulate a value using one specific
metric type (e.g. specifying a font in points). You only really need to
perform conversions when evaluating a value (e.g. when drawing a line
from two coordinates). However, there may be a need for conversions in
other areas, e.g. when getting the size that a string will take when
rendered to a device using a specific font, you may want this to be in

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

This is the thinking I am now making w.r.t. the metric type.

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

It should be possible to select whether you want to use logical
coordinates (picas/points, millimeters, inches) or device coordinates

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

I see the advantages of this approach and am working on supporting
logical coordinate systems (especially for graphics), but it should also
be possible to use device coordinates (e.g. for specifying component
positions and sizes). I am aware of problems with specifying component
positions, which is where some basic layout engines are essential, and
am working toward being able to implement them.

> 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 will need to take a look at this.

> 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 can see the advantages of this approach, but you need to take into
account native-vs-custom drawn components.

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

I am working on this. I have implementations of buttons and need to
document their properties: push buttons, 2-state and 3-state check boxes
and radio buttons/groups.


Boost list run by bdawes at, gregod at, cpdaniel at, john at