Quote:
Originally posted by kinook
Columns in the tree don't seem as useful to me as columns in the Child/Search results pane. In a separate pane, the columns, sorting, sizing, etc. can be customized (and is remembered) for each search or item selected in the tree. There is also more room to display columns without hogging most of the main window area. [snip]
I'm probably missing something, so please describe in detail how columns in the tree could be implemented in a useful way.
Now, I agree that alternative sorting (on different attribute[s] and ascending/descending) of the items in the tree, could be useful, but for now, customized sorting is only available in the Child/Search results (and you can get a tree-like view in that pane by creating a limited search for all children [empty search criteria] and showing the Lineage attribute in a column).
|
I agree w you on all counts but here's a thought:
A view structured from a hoisted explorer topic could make use of synched columns.
Examples, contact list as well as appointments or a project with varied steps & due dates. All these could be sorted by different criteria, stored & reached by shortcut or favorite. The two panes, would be synched to one another. Sorting woule directly affect the explorer topic order.
It seems to me that some of this work might already be done in so much as the explorer exists, the child pane with 'linked' data exists. It requires a bridge.
I think what I'm describing, albeit from a non-programmer's POV, is adding a further function to the child pane under certain circumstances, i.e. when a topic is hoisted. Option: hoist linked items, y or n?
If yes, child pane replaces the page pane until a particular item is selected.