ColumnView widget


#1

Hi Guys,

I was wondering if someone has already done some
kind of ColumnView widget ala OSX finder
to display TreeViewItems.

Thanks,


#2

I’ve started to make one with the idea that I could switch between a TreeView and a ColumnView using TreeViewItem for both.

However TreeViewItem is really tied to TreeView so in order to do what I want, there’s no choice but to derive ColumnView from TreeView even if there are many methods and variables which don’t make sense in a ColumnView or have the same meaning in both like openness, indent size, number of rows…

But as TreeView wasn’t meant to be subclassed it is not possible to override its behaviour.

So for now, there’s no choice but to make a separate ColumnView with its own ColumnViewItem but I can see no way to reuse existing TreeViewItems in a column View…

I could imagine writing a TreeViewItem to ColumnViewItem adapter tough.

What’s your opinion Jules?


#3

well I suppose the ideal solution would be to extend the treeview class and make it flexible enough to cope with a completely different layout like this. No idea how tricky that’d be…


#4

doesn’t look so obvious to me, otherwise I’d have suggested some concrete modications. but there are several places to modify.


#5

on a related matter (tree centred widgets), that would be great to have lazy Menu entries that would only look for sub-items when necessary (i.e. in the same fashion as TreeViewItem::itemOpennessChanged)

that would allow to use menus in potentially slow/big contexts like browsing directories…


#6

Good point. Maybe there’s a nice base class of hierarchical items that could be created do all of these jobs.


#7

Funny, I’ve been working on exactly this sort of thing for a while now. It should be possible to have a framework through which any kind of display style can be used to show the same hierarchical structure.

I believe that the different types of display should be built upon a common base. Looking at the possible scenarios (popup menu, tree view, column view, etc…) they can all be represented by two key parts.

  • A Component to display the contents of a single node [let’s call it a ‘page’]
  • A master controller to take a single node and create/arrange/manage these pages to display the structure it holds.

e.g.
column view: controller is in a big component which arranges pages side by size
popup menu: controller adds/positions pages on the desktop
treeview: controller can overlap each page with an indent -e.g. open a child, the page expands vertically, creating a gap upon which the next page can overlap with an indent.

so, there should be a mechanism for opening a subitem within a page, which should interact with the controller to get it done.

the main problem seems to lie in making a ‘node’ structure that is flexible enough to be represented in any form, and allows a mixture of static and dynamic content (as well as being possible for it to be represented in any of these tree display forms, or showing different types of data - e.g. custom components might want to be displayed per item, different formatting etc…). I think that for maximum flexibility, a node should probably have an XmlElement to store any kind of metadata. That doesn’t necessarily mean that it must keep to the XmlElement structure (that would restrict the sort of meta data you might add to attributes only, if the children were expected to represent the child nodes), rather contain an array of XmlElement-based nodes.
[this also makes it easier to restore static content from a file]

We already know that a node needs to indicate that it might have children. It should probably also have an indication of whether or not it needs any - e.g. static content doesn’t need updating, dynamic content will probably want to be updated each time it’s opened.

I think it probably needs some kind of ‘node population model’ too, which a ‘TreeDisplayManager’ can use to populate a given node [if it hasn’t already been populated] - rather than leave it to subclassing the item type. If the node has an Xml structure, the data used can be read to determine what to do [perhaps even delegate to another model for populating specific ‘types’ of node]. A model can be defined for dynamically assembled node-trees, which can then be slotted into any of the ‘TreeDisplayManager/TreePageComponent’ based display types.

these are just my thoughts and findings on the situation though… and not in any particular order. And potentially indecipherable. ymmv! :slight_smile: i’d certainly be keen to learn of anyone else’s thoughts on the subject.


#8

Wouldn’t a column view just be another way of painting the treeview, with maximum one item open?


#9

Hello, are talking about this ?