I've been thinking a lot lately about the tree and grid widgets in XUL - each has its uses. With grids, you can put in just about any XUL element you want in each cell of the grid. With trees, you're more limited - single-line textboxes, progress meters, and "cyclers" - but the tree widget takes up a lot less space on the screen for the same amount of information, and is easier to navigate with keystrokes.
I'd like to combine the best of both: a grid-like layout of rows and columns, but in the compact space of a tree widget.
I've been thinking about three options:
(1) A grid element binding with much tighter spacing between elements, largely dictated by CSS rules and tree-inspired navigation controls.
(2) A tree element binding with carefully positioned and sized XUL controls, like the inputField property does for editable text cells.
(3) Modifications to the tree layout code to support additional types of controls.
Of these three options, I like #2 the best. The tree binding already supports editable text cells by directly positioning a textbox over the cell which the user would edit. If I could do the same with other controls (radio button, regular XUL button, menulist immediately come to mind), and make them move (and hide) along with the tree widget's own scrollable content, then I'd basically have that compact grid I'm looking for. In addition, by using a custom nsITreeView, I wouldn't need as many XUL elements as I'd need for a grid. Finally, by using special "properties" attribute settings that can't become part of a CSS selector, I could specify whether the control was visible all the time, while focused, or while activated.
I'm wondering if this really is the best approach, or if I'm overlooking something. I'm also looking for best practices on implementing this compacted grid widget in XBL.
On Jan 19, 2:52 pm, Alex Vincent <ajvinc...@gmail.com> wrote:
> I'd like to combine the best of both: a grid-like layout of rows and > columns, but in the compact space of a tree widget.
> I've been thinking about three options:
> (1) A grid element binding with much tighter spacing between elements, > largely dictated by CSS rules and tree-inspired navigation controls.
> (2) A tree element binding with carefully positioned and sized XUL > controls, like the inputField property does for editable text cells.
> (3) Modifications to the tree layout code to support additional types of > controls.
Personally, I'd stick to grids for a traditional group of controls in a dialog (or window). Seems like much less overhead. Tree might be useful when dealing with many "rows" of the same group of controls, just bound with different data. There is already a bug and patch for adding richer content to trees: https://bugzilla.mozilla.org/show_bug.cgi?id=441414
Alex Vincent wrote: > I'd like to combine the best of both: a grid-like layout of rows and > columns, but in the compact space of a tree widget.
It really depends on what you are trying to do. If you need a hierarchical list, or a row-oriented list with many rows, then a tree is what is desired.
In the future, my current plan is to expand richlistbox (and grids in general) to support multiple columns with resizing, dragging, etc. Doing this, though, requires changes to the grid layout code.
> (1) A grid element binding with much tighter spacing between elements, > largely dictated by CSS rules and tree-inspired navigation controls.
Note that its actually the margins around the elements that create the spacing, not the grid. The grid doesn't impose any spacing itself.
> (2) A tree element binding with carefully positioned and sized XUL > controls, like the inputField property does for editable text cells.
> (3) Modifications to the tree layout code to support additional types of > controls.
I made an attempt in the tree layout code to something like 2 and 3, but its one of those things where some of it easy but getting it right is hard. Handling scrolling (horizontal too) as well as painting is harder.
Really you need to decide which features you really need: hierarchies, column redordering/sizing, row or cell selection, large amounts of data, complex styles, arbitrary elements, etc.
|
