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