Re: [boost] Re: [gui] Concerning Scope (Was: thoughts on a GUI component library)

From: Alan Gutierrez (alan-boost_at_[hidden])
Date: 2004-12-28 10:34:30

* Dave Harris <brangdon_at_[hidden]> [2004-12-28 09:21]:
> In-Reply-To: <20041224050911.GA9037_at_[hidden]>
> alan-boost_at_[hidden] (Alan Gutierrez) wrote (abridged):
> > > I'm a bit concerned about the scope of this boost project. Our 
> > > drawing framework is pretty huge.

> >     This is an important discussion to have sooner than later.
> > 
> >     1) Is a GUI project a bad idea?
> > 
> >     2) Is Boost the right place for the a GUI project?

> Supposing "yes" to both, that still leaves the question of scope. Possibly 
> a "GUI" could just mean a high-level windowing system, and not a graphics 
> drawing system. There is a lot to do just managing a tree of rectangles 
> and dispatching events to and through them. The windowing system should 
> arguably not care about the contents of the rectangles.

    Supposing "no" to 1, and "yes" for 2, you mean?

    In another thread, I'm trying to drive home the point that the
    graphics needs are different for different platforms, indeed for
    different client area within the same program.

    An application might need a form bindery, another might be able
    to get by with only axis-aligned boxes, and another might
    require full compliment of vector graphics abstractions. I'm
    also trying to make the point that there is more to rendering
    than widgets on the one hand, and vector graphics on the other.

    I belive the scope is large, but if decomposed correctly, far
    more managable than what is currently available.
    
> It seems to me that adding a graphics system, with pens and brushes and 
> polygons and text and bitmaps and wotnot, makes the project much bigger. 
> Which isn't to say we shouldn't do it, and do all of it, but perhaps it is 
> worth dividing it up into chunks or layers that are more or less 
> independent. If that is possible.

    I agree completely! :^) Whew!
    
    In my thread on a GUI taxonomy, I came to see that it was really
    a rendering taxonomy. That a dialog is one way to render and hit
    test, a tree of rectangles, each containing a "component", a
    grid is similiar, but adds scrolling and selection. Both of
    these components can leave "visibility testing" to the windowing
    system, and focus on routing events. Rendering is clipped by
    rectangular view ports, so the overflow strategy is always clip
    or scroll, never reflow.

    A document reflows according to publishing convention. I might
    have a z-axis, so it might require visibility testing.

    A canvas is a collage of geographic shapes. It certialy requires
    it's own visibility testing. 

    If I were to create a calendar for PalmOS, I might want to use
    forms and grids to arrange my information. I'd need axis-aligned
    boxes for rendering, but no ploygons, and no visibility testing.

    If I were to create an ER diagraming tool, I'd like to be able
    to draw on an vector graphics library that would let me compose
    shapes, and handle the visibility testing.

    I do not see how one is based off the other, and those libraries
    that model themselves in a heirarchy are destined to bloat.

    I think a Canvas is an abstraction that can be compiled out of
    many GUI applications. It is, to me, a rendering strategy that
    draws on a Surface, which is a software abstraction of a Device.

    A Surface class might provide line drawing, or it might provide
    ploylines, there could be a few classes of Surfaces, just like
    there are classes of Windows (modal, alert, SDI, MDI, etc.)

    Again, a very robust Palm OS application can bind to Palm OS
    form resources, and wouldn't require a Surface abstraction at all.

> >     I believe the time is ripe for a small, light-weight, XML + CSS
> >     renderer to attack the new surge of RSS content on the web.

> OK. Perhaps my issue is that when I think of "GUI" I don't immediately 
> translate that into "XML + CSS".

    I know. I don't think many people here do. I don't think
    XML+CSS, but I do think semi-structured content, like documents,
    and I'm putting forward XML+CSS as devil we all know.

    Also, XUL and XHTML make for nice declarative UIs. With C++, I
    feel you could create generic rednering compontents, Forms,
    Grids, Documents, and Canvases, and use generic programming to
    compose lean UIs.

    With C++ you can get the declaration and the behavior in the
    same langauge. You could compose UI renderers from generics, in
    the same way XUL is used to compose UI from nested XML elements
    and JavaScript.
     
    Talking about this application is to note it doesn't fit in this
    binary classifcation of widgets/vector graphpics. It is
    somewhere in between.
    
  ~ Also, I'm well aware that the G doesn't belong in the library
    name. In proper library I'd be able to model forms and documents
    on the console, just as I can now with curses and lynx.

    I think we are really talking about an event UI library.

 !~ In any case, I'm getting ready to wind down my participation in
    these discussions, because I don't think there is much interest
    here for a UI library, and I don't want to be accused of again
    hijacking, especially if I do make some progress on my own.

    I'll still be mucking around with Boost.Build and maybe that
    will be of some use to you all.

--
Alan Gutierrez - alan_at_[hidden]