Andy Little wrote:
"Reece Dunn" <msclrhd@hotmail.com> wrote in message news:BAY101-DAV14300DA4E52BA9F3F31320A0AE0@phx.gbl...
Andy Little wrote:
"John Torjo" <john.lists@torjo.com> 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