Boost logo

Boost :

From: Alan Gutierrez (alan-boost_at_[hidden])
Date: 2004-12-22 01:08:28

* Mathew Robertson <mathew.robertson_at_[hidden]> [2004-12-22 00:27]:
> > 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...

> The real benefit is that every widget now gets to have
> multi-lingual support as a native capability.

> And you also get word wrapping, hyphenation, etc.. on every widget...!

    Yes. I get giddy. You get a multi-lingual, bidi wrapping, rich
    text editor, or get a table full of them.

    It really seems like the right way to do things, and I'm
    inspired by web designers that roll their own very complex
    controls using XHTML divs and spans.

    I'm also looking at how Swing is trying to find an XML
    expression for itself. XML langauges for Swing have sprouted
    like mushrooms. Any new GUI toolset should design a declarative
    layout into itself, not attach one later.

    Note that I'm not touting XML, per se, but the CSS flow model.

    I'd imagine that one might declare the composition of their
    interface using Python, or that a very clever generic
    programming library could be developed, like Spirit.
    XHTML would be obvious, but not necessary.
    In fact, I think some of the Swing XML implementations miss the
    point. The flow layout plus the bubbling event model is what
    makes XHTML programming so simple.

    I don't think this is a replacement for MVC. I think it is a
    great way to implement the VC part.

    In writing about it, I've come to see this as a VC
    implementation option; a component that implements CSS flow.

    CSS flow only.
    I'd not take it one step further and make it an implementation
    of SVG, since XHTML + CSS address the issues you've hit on, bidi
    word wrapping, hypenation, and since most controls are some
    flavor of text box.
    An vector graphics component would be a separate animal, or
    specialization of the species that addressed a different set of

Alan Gutierrez - alan_at_[hidden]

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