[boost] Re: thoughts on a GUI component library

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
>>>>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! )

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

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

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

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

Regards,
Reece