[boost] Re: thoughts on a GUI component library

From: Reece Dunn (msclrhd_at_[hidden])
Date: 2004-12-21 05:44:44

Alan wrote:
> * Aaron W. LaFramboise <aaronrabiddog51_at_[hidden]> [2004-12-16 23:18]:
> 
>>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?
>>
>>>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