Re: [boost] Re: thoughts on a GUI component library

From: Alan Gutierrez (alan-boost_at_[hidden])
Date: 2004-12-21 21:45:19

* Reece Dunn <msclrhd_at_[hidden]> [2004-12-21 05:59]:
> 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.

    This means that integers are still appropriate then.

    Still, I'm imagining that choosing a specific point
    representation is near sighted. The thought you are putting into
    effective conversions between different point units is important.

    In the CSS world, designers like to use the em unit to design
    interfaces that can scale cleanly to different resolutions.

    I'd like to see the Boost library include the concept of
    relative units as well as absolute units.
    
    It would help me to implement CSS using the GUI library.

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

    No good.

> *  the way the library manages graphical objects and selecting a 
>       graphical object on a canvas is *way* off base!

    Fine. I've never liked MFC, the few minutes I've spent with it
    where agony.

> Anyway, I have started work on a metric type, available in the latest 
> update to:

>    http://uk.geocities.com/msclrhd/gui/gui.zip

    As soon as I get things to compile, I'll comment on this.

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

    The canvas is a hardware abstraction layer? It can be
    implemented once and devices can plug into it using adptor
    interfaces. The canvas could be generic type, and the template
    parameters are things like the preferred metric?

    I'm assuming that the canvas contains all of the drawing
    functions, like line_to and such.

--
Alan Gutierrez - alan_at_[hidden]