Re: [boost] Re: [gui] GUI Taxonomy

From: Alan Gutierrez (alan-boost_at_[hidden])
Date: 2004-12-25 07:15:36

* Hajo Kirchhoff <mailinglists_at_[hidden]> [2004-12-25 05:47]:
> Hi, (and merry holidays to those that celebrate them :)
> 
> >>  - The Grid
> >
> >A grid is an example of a layout manager. Generic support should be 
> >added for layout managers and allow you to add managers such as 
> >grid-layouts. Another layout is a flow layout, for example, adding 

> I would like to take the concept of layout managers a lot further.

> Basically a layout is nothing but a particular strategy to calculate the 
> size and position of a set of widgets. The grid layout is one of them.

> Others are docking mechanisms, or autohide/unhide windows as you see 
> them in Visual Studio for example: a window that shows itself when you 
> hover with the mouse pointer over its tab for a while and that hides 
> itself again when a different window gets the focus.

> These too are size/position handlers. So I'd rather think along 
> positioning strategies rather than have a 'Grid'. A Grid is too low an 
> abstraction.

    Hajo

    I agree, as far as positioning strategies go. Layout management
    can be far richer. I was not putting forward The Grid as a
    positioning strategy, and I think both you and Reece mistook the
    point of the OP.

    The point of the OP (me) was to lay out a taxonomy of what goes
    into the client window of an application. I was attemping a
    highest-level look at the sort of interfaces developers must
    regularly assemble, so that a Boost GUI library would faciliate
    the those tasks.

    My post was to note, that in common business applications
    repeate four different canonical UI forms in their /client/
    areas, The Form, The Grid, The Document, or The Canvas.
    
    By The Grid, I'm thinking of applications like Excel, Access, or
    SASS, where information is presented in a tabular format.

    Information information is mapped to a tabular data structure,
    or a sparse matrix, rows and columns are added and deleted,
    ranges are selected, cells are referenced, etc.

    I'm noting that this is such a common display of data, that it
    should be considered as a special strategy for the client area.

    A grid, in this sense, is far more than just a layout.

    But, to address your concern directly, layout is far more than
    just a grid. The layout and arrament of client areas is a whole
    other area of discussion.

    Reece goes on to talk about a desire for something along
    JTable/TableModel, so I think we are talking about the same
    thing in different terms.

    It would be disappointing to see another library that was, like
    MFC or Java AWT, a whole lot of framing, but for the client area
    you have a set of stock widgets on the one hand, or take the pen
    and draw it yourself on the other.
    
    When I look at xwWindows, I see a library went from the OS,
    frames, widgets, and primtives, and on the way towards the
    application and got lost.
    
    I put forward what I thought were the four basic types of
    application that a library design could keep it's eyes on the
    prize.
    
    Also, so we can consider how to compartmentalize the library. If
    I'm developing a vector graphics application, I don't need a
    validation library, if I'm merely tracking the mouse over a
    grid, I don't need much in the way of hit-testing.

--
Alan Gutierrez - alan_at_[hidden]