Boost logo

Boost :

From: Alan Gutierrez (alan-boost_at_[hidden])
Date: 2004-12-21 22:03:33

* 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.
> > 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.
> Anyway, I have started work on a metric type, available in the latest
> update to:

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

    My design for a C++ GUI library would being with creating an
    flow component that could render XML + CSS.
    The flow component would flow blocks. Blocks would contain text,
    images, or other objects. If a block changed size, the flow
    component would reflow immediately.

    This is basically what web designers work with in a modern
    browser like KHTML or Mozilla. I'm far more interested in
    creating a component of this nature, than another set of gray
    box wrappers.

    Initially, I figured I'd stop short of attempting to create a
    2d canvas, something that would be a outlet for vector graphics
    like SVG or flash.

    The components in the GUI library could then be implemented
    using the flow compnent.

    This would mean skipping platform specific widget library, and
    implementing an cross-platform widget library using this flow
    component, combining blocks, effects, and images, to create what
    ever look and feel is desired. The look and feel could be
    specified by designers somewhat simply using XML + CSS.
    You'd get skinnable applications.

    Swing took the route of defining look and feel in Java, and
    foroging native components. I'd like to make it much easier to
    implement the look and feel.

    Create all the widgets using the flow component, and with C++,
    you'd not pay too dear a penalty for forgoing native components.

    Native components are welcome, of course, so long as they play
    nice the canvas. (Win32 GDI objects do not.)

    A huge benefit, too, is that if someone implements a the device
    class for their device, they could turn to Boost to have a ready
    Windowing library.

    So, I'm going to get working on a flow component...

Alan Gutierrez - alan_at_[hidden]

Boost list run by bdawes at, gregod at, cpdaniel at, john at