Alan wrote:
* Aaron W. LaFramboise <aaronrabiddog51@aaronwl.com> [2004-12-16 23:18]:
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?
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 the decision on the representation of coordinates is an extremely important one--one that might doom a library to ultimate obsoletion if decided wrongly. As Boost is meant to be a model of _the C++ way_, future libraries may also be inclined to specify in the manner Boost does. It's very important to remain forward-looking, thinking not, "What sort of pixel representation do today's GUIs use?" but rather "Will tomorrow's GUI be based on pixels?"
What about todays printer? Is that based on pixels?
Printers are based on "dots per inch", e.g. a 600dpi printer. These dots can be seen as pixels, but the CSS documentation has information about converting screen pixels to other devices (e.g. printers) such that a pixel consists of 3 dots on a 300dpi printer and 5 dots on a 600dpi printer.
If I were to go to the trouble to create an GUI that rendered diagrams, I'd probably to to the touble to print those diagrams.
I'd like to use the same algorithm to render to the screen and to the printer, simply swap out the device context.
The Microsoft MFC library takes this approach and, IMHO, it is the best way to go. The problem is that with the MFC: * conversion between "metric spaces" (inches, pixels, picas) is not handled by the library, making it hard to say "draw a circle at (2in, 3.7in) with a radius of 2cm". * the way the library manages graphical objects and selecting a graphical object on a canvas is *way* off base! Anyway, I have started work on a metric type, available in the latest update to: http://uk.geocities.com/msclrhd/gui/gui.zip Be warned, though, that this is experimental. It provides conversion between the types that are directly convertable (e.g. points to inches). I have yet to work out how to properly handle conversions between the base types (pixels, inches and scalefactor). In principle, this is easy, given: * ppi: pixels per inch * max: maximum length of the object to which the metric value is bound we have pixels = inches * ppi = scale * max:px = scale * max:in * ppi inches = pixels / ppi = scale * max:in = scale * max:px / ppi scale = ? These values are dependant on the device being targetted. They are also dependant on the orientation of the metric (x-axis or y-axis). So how do we resolve the metric values? The best solution I can see is have a resolve_metric function on a device, such that: metric device::resolve_metric( metric, type, orientation ); it takes the metric and returns that metric with the units specified by type given the orientation. For example: p.x = dev.resolve_metric( p.x, metric::pixels, device::x_axis ); p.y = dev.resolve_metric( p.y, metric::pixels, device::y_axis ); This will convert the point p into pixels for the device specified by dev. Helper functions should be included to convert points, sizes and rects, e.g.: dev.resolve( val, metric::pixels, device::x_axis ); // metric dev.resolve( pt, metric::pixels ); // point dev.resolve( sz, metric::pixels ); // size dev.resolve( rc, metric::pixels ); // rect So, why the term device? A device (screen, printer, etc.) is an object that can perform graphical operations that render graphical content to it. The device can be queried for information relating to it (e.g. the size of a block of text or the number of pixels per inch along the y-axis). A canvas is an area that can be drawn on. It is possible to get a canvas for a device (allowing you to, for example, send a graphical image to a printer). Likewise, it is possible to get the device associated with the canvas (allowing you to perform metric conversions). The library update also includes some experimental work on basic graphics components (font) that I am using to compute the size of several widgets. The idea being that this can be plugged into a layout manager. The flow layout *does not work* at the moment and the whole layout mechanism may be subject to change. However, the widgets are fairly stable and usable. I have included buttons (push, checked (2 and 3 state), radio button/group), labels, textbox (textfield, textarea and password), along with a calendar widget that is MS-specific (I think). I intend on supporting a table control like the Java JTable component, with a TableModel-style interface. The link to the code is: http://uk.geocities.com/msclrhd/gui/gui.zip Regards, Reece