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.

Suggestions?

Alex

On Jan 19, 2:52 pm, Alex Vincent <ajvinc...@gmail.com> wrote:

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

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.

Note that its actually the margins around the elements that create the
spacing, not the grid. The grid doesn't impose any spacing itself.

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.