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
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
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]
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk