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