Boost logo

Boost :

From: Reece Dunn (msclrhd_at_[hidden])
Date: 2004-12-25 06:12:26


Hajo Kirchhoff wrote:
>>> - 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.

Yes.

> 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.

This would also cover strategies such as scrolling, which allows you to
move about a space that is larger than the owning frame. These should be
kept separate: that is, there should not be explicit support for docking
toolbars or frames, but a dockable manager that adds docking support.

Perhaps then layout manager is too specific a term. How about "UI
manager"? There are two things that can be controlled: components and
renderers, where a renderer is something that draws content (such as a
vector graphic) onto a frames usable area.

This would encompass:
* layout managers (that control the layout of the component that they own),
* docking (that provides dockable support to the component it owns),
* scrolling (that provides scrolling functionality to a component or
renderer),
* splitters (that allow two components and/or renderers to be
positioned next to each other with a bar that allows their sizes to be
affected) and split-views (a specialised splitter that works for
renderers to allow two active views of some provided content),
* other advanced user interfaces.

> 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.

A grid in layout manager terms allows you to position components at
(x,y) positions, for example creating a calculator. There are other
layout strategies (flow/aligned, e.g. buttons along the bottom right
corner along the y-axis) that should be supported.

The Grid that Alan was referring to is a data control that serves a
large amount of data split into cells such as a spreadsheet. This is a
valid component and needs supporting. In this model, we have a "Cell
Provider" that is something like:

struct cell_provider
{
    long get_row_size() const = 0;
    std::string get_row_name( long r ) = 0;

    long get_column_size() const = 0;
    std::string get_column_name( long c ) = 0;

    bool is_cell_editable( long r, long c ) = 0;
    std::string get_cell( long r, long c ) = 0;
    void set_cell( long r, long c ) = 0;
};

This then serves a grid component that is used to provide a spreadsheet
style control, using both column *and* row name. It also serves a table
component to implement things like the list of e-mails in an e-mail
manager or the list of songs on an album (with additional details such
as track number, duration, etc.). This table component is akin to the
JTable/TableModel in Java Swing and does not make use of row name.

Happy Holidays,
Reece


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk