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

From: Alan Gutierrez (alan-boost_at_[hidden])
Date: 2004-12-22 00:32:19

* Alan Gutierrez <alan-boost_at_[hidden]> [2004-12-21 22:03]:
> * 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:
> >    http://uk.geocities.com/msclrhd/gui/gui.zip
> 
> > 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.

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

    A flow component would occupy a rectangle. It would represent a
    view port to a larger rectangle.

    It woud devide the larger rectange into rectangles. These
    divisions nest, so there would be a recursive structure. I
    suppose this outer rectangle contians a list of divisions that
    are sorted on the z-axis.

    The divisons are sorted on their y axis. A reference can be kept
    to the first division exposed by the view port, so that
    redrawing and hit testing can skip the divisions above the view
    port, and move through the list to the point where either the
    view port, or the division ends.

    Divisions can be buffered, so that if one division changes size,
    the divisions that beneith it can reflow without having to be
    redrawn.

    I'm not sure if divisions are kept in the standard containers,
    or if they are linked to each other explicitly, or through a
    special data structure.
    
    I'm not familiar with STL and such, but there would be a desire
    to to say, insert a division after this division frequently.

    The divisions in the list of divisions flow either to the right
    or the previous division or beneith the previous division.

    ?   Except in the cases where they are floating within the
        previous division, or other divisions piror, as in CSS
        float. CSS float translates to this structure, but the XML
        elements are going to be in a different order that the
        division objects.

    Any one of the divisions may be resized at any point, causing
    all of the divisions following it to reflow.

    Any one of the divisions may accept text input. This is a
    plubble structure that can be inserted as a division into a
    division, essentially a decoration. It is a text division?

    It contians a string of text. The string of text is a simple
    string, and is likely to be loosly coupled, perhaps M in MVC.
    
    It also contains a data structure that devides that text into
    strands of formating and another data structure that divides the
    text into futher divisions, which represent the inline
    formatting of the text. This ought to work for text directions
    other than the one I am familiar with.

    In this way, the text is broken up into ribbons, which indicate
    the styling applied to the text, and also into divisions, which
    indicate flow of the lines of text.

--
Alan Gutierrez - alan_at_[hidden]