Couple of thoughts:
The drawing you have going is more of a graph visualization than a tree - I'm making this distinction to suggest that HTML is probably not sufficient to draw this. The angle of the lines between nodes alone is going to make this difficult - while some browsers support CSS that could make this happen, its not something that can be implemented for all browsers that GXT supports.
That said, I've seen this done for GXT 2, though with lines at right angles to each other. The basic idea is to build a table for each parent node, with the following structure:
The table has three rows - the first is just to draw the current node, which spans the full width of the row. The second then exists just to draw the center line to go down to the next level - no content in the cells, just a border between the two cells. The third row then holds all children, so that as it grows, it expands the first two rows to make them fit better. I think you may need several cells in that last row, one for each child, and then to set colspans on the second row to keep it even. Wait-- forgot one - you need one more row above the whole thing as a line *in* to the parent node - you may omit this for the root node.
| | |
| children |
The child cells then need three styles - first-child, last-child, and child. The regular child has a line above it, the first-child has a line above the right half of it, and the last child has a line above the right half of it:
Table lines that should be drawn in bold - note that the line above the word 'child' is actually part of the child.
| | | | |
| | | | | | |
|child | child | child|
This whole process then assumes that each set of children dom elements will be nested into a parent dom element - that recursive dom structure is what gives the existing Tree its shape as well.
TreeAppearance will need a complete re-implementation to do this. The guts will be in renderNode, which will draw each element (something like the first table I mentioned). Then, the various finder methods will need a custom setup to find the nodes that they describe - checking out existing implementations and usages for what these each are specifically for:
The Tree needs to be able to modify specific nodes as things expand/collapse, etc. These methods are responsible for that work:
XElement findIconElement(XElement target);
XElement findJointElement(XElement target);
XElement getCheckElement(XElement container);
XElement getContainerElement(XElement node);
XElement getIconElement(XElement container);
XElement getJointElement(XElement container);
XElement getTextElement(XElement container);
And last (from my quick glance, you may find more methods that are important, but these are the landmark ones), the Tree needs to be able to ask questions about what the user is clicking on - these methods let the tree find out what the user is doing:
XElement onCheckChange(XElement node, XElement checkElement, boolean checkable, CheckState state);
XElement onJointChange(XElement node, XElement jointElement, Joint joint, TreeStyle ts);
void onSelect(XElement node, boolean select);
/*If supporting DnD*/
void onDropOver(XElement node, boolean over);
void onHover(XElement node, boolean over);
Instead, a visualization package just draws elements on the page and positions them, whether it is done in a browser, or elsewhere. In this case, you do the bookkeeping of relative positioning in memory, not in any dom structure. This is how the various charts on the right half of your screen are implemented in GXT 3.
boolean isCheckElement(XElement target);
boolean isJointElement(XElement target);
The DrawComponent class allows any sprites to be added to it anywhere - LineSprites could make up the dashes between nodes (or a single PathSprite, using LineTo commands to draw, and MoveTo to get to the next position). ImageSprite or TextSprite or both then could be used to actually build each node. Depending on the size/distribution of the tree, you might want to start at the top and center the first node, then work your way down (easier approach, good for a smaller number of nodes) or walk depth-first and render nodes starting at the bottom-left corner, making children and parents fit where they can. If there are not enough nodes to reach to the top, just adjust all nodes to fit - if there are too many, then some kind of scrolling or expand/collapse mechanism will be required. Consider the use of TextMetrics to measure how large a string will be when deciding how much room you need.
This isn't an easy problem, and there is no canned answer for all cases, so we haven't built the One True Horizontal Tree and shipped it in GXT. Teams that need this typically have very specific requirements - DnD, icons drawn around/in nodes, specific scrolling or expanding features