Tree Widget

[Sting]

I am working on the design of a tree widget.  If this is already being done, then I will stop this development.  If not then I would consider feedback on the general idea.  I only need a two level tree for my application, but if it is useful I will make it more general.  The general idea is as follows.

There will be two tree elements, a TreeNode and a TreeItem.  The tree node will have a   gfxQueueASync    node_head;  at the end of the structure just like the tree object so other elements can be added.  Each element will be identifiable to determine if it is a node or an item.  The position in the tree is described by a string "a.b.c.d" where each element is an index to that particular level of the tree.  This limits the tree to 256 elements per level, If this is a problem it can be made into an array of uint16_t.  Maybe making the position into an array of uint8_t is a better idea?

The tree node will have a single char* identifier and a set of event spots that are selectable that will send events to the application. At the beginning of the node row  will be an indicator that is selectable to determine if the node is expanded or collapsed, selecting will toggle the state.  Two items can be added to the right of the node to send add node or add item events to the application, or anything the application wants to use them for,   When a node is selected an event is sent to the application to allow the application to respond to the selection.  I haven't looked close enough but I think this needs to be done in a similar way as the tabset is done so the application can set the UI to respond differently to the various node selections.  The difference will be that the node selected will be determined by a position as described above.

The tree item will be a row similar to the table widget. It can have an image and a set of columns.  I can't decide if the column count is fixed over the tree for all items or if it is specific to a tree node.  If it is specific to a tree node, each node has to carry the header information if the columns are to have headers.  This is an optionable feature. When an item is selected an event is sent to the application to allow the application to respond to the selection.  I haven't looked close enough but I think this needs to be done in a similar way as the tabset is done so the application can set the UI to respond differently to the various item selections.  The difference will be that the item selected will be determined by a position as described above.

There are probably many more things I haven't considered.  Any feedback would be appreciated.

[Joel Bodenmann]

There's currently no tree widget planned on our side and we don't know of anyone who would be working on one. You are more than welcome to pursue the idea

Personally I wouldn't recommend having two different types of times. In a tree structure, any item/node should be able to have children. An item with children only different from an item without children by not having children, that's all.
Having a list for the children in an item is the most straight forward implementations. However, you might also consider using just one global list. Each item would then have a pointer to its parent node. The order of the list determines the order of the children.
That is how the GWIN module keeps track of all the widgets: As you know you can assign child widgets to containers. It's possible to create an arbitrary hierarchy/tree structure that way. But the GWIN module only maintains one global list.
Note that you can always make a primary implementation to have something that is working and improve it later on.

I'm definitely keen to see what you come up with. It would be an interesting addition to the library and I'm sure I'm not the only one who has multiple uses for that in mind  

[Sting]

You are correct, in the general sense this widget should function as a general tree, like the Windows File Explorer.  I don't need nearly that level of generality so I will build a less general version and call it something specific to my application.  I don't have the screen real estate as the list of nodes in the tree for my application will contain about 10 elements.  What I need is a two level hierarchy with beer styles as the nodes and then recipes that I use for those styles as the children.  I really only make about 10 styles so I figure I can combine the styles and the children in the same list.

[Joel Bodenmann]

Personally I don't think that it will be any more complex to make it work with a generic tree structure rather than your application specific two-level forced approach. Actually, I feel like maintaining, debugging, extending & modifying will be a lot simpler if you go the generic approach. This way you only have one item to worry about, otherwise you will have to worry about two types of items.

I've no idea about your setup, but have you considered having a main list and a back or up button instead? This way the user can select an item in the list, the list will clear and populate the area with the selected items children. That frees a lot of space which allows using bigger icons. The up- or back-button would allow the user going one level back.

A community member wrote a custom rendering routine a few years ago for the list widget that converted the linear list into a grid of icons, similar to the app launchers of smart phones. This gives a lot of room for large, finger-friendly icons.