Columns
One way columns could be added to tkoutline would be to place a table widget (i.e. tktable.sourceforge.net) adjacent to the text widget containing the outline. The table would have to be able to register itself with the outline to be notified when text wrapping occurs, so the cell height can be adjusted accordingly. The table would also have to be notified about nodes being expanded/collapsed so the corresponding rows can be inserted/deleted. Sounds like a fun, but not short project. Not anything I plan to work on in the near future.
Update (06/09/03) - Back in march I wrote some code as a start to this. So far the code is focused on synchronizing the line heights and display position of two text widgets. This is with the idea of using a text widget for the columns (maybe Csaba Nemethi's text widget based multicolumn tablelist 1). I think it will be easier to do something text widget based. What I have so far can be viewed at http://tkoutline.sourceforge.net/cvs/lib/tabletree/tabletree.tcl. There's not much there and so far the test code (http://tkoutline.sourceforge.net/cvs/lib/tabletree/tabletree.test) dwarfs the actual code.
Update (02Sep04) - I have never returned to this code and the forthcoming Tk 8.5 (in alpha full release expected within a year) has text widget improvements that would make this much easier. TIP 155 2 adds the ability to index into parts of the text widget based on display line information rather than virtual line. Almost all of the above code that I wrote deals with trying to determine display line information given pre 8.5 limited capabilities
Filtering
I can't think of much to say about filtering. It doesn't seem like it should be that hard. It seems like it will look strange if a parent node is hidden because of a filter, but the child is visible. I should probably try out Ecco to get a feel for what the behavior is. (Ecco shows you the parent(s) to a visible item, but makes them grey so indicate that they're only visible because the child is)
Can anyone provide the specifics on a situation where this functionality is useful?
-Brian Theado ---
Ecco puts a table to the right of the outline, and each item in the outline gets a row in the table. Each column can be of type: true/false, number, text, drop-down list of text, or date. The one I use most is the drop-down list of text. Ecco also lets you build simple queries (with AND/OR/NOT and value tests on the columns), so you can view a smaller version of the outline, with just the parts that meet the query-constraint.
Let me give several use scenarios, so it's clearer what the purpose of this feature is:
SOFTWARE TODO LIST
I keep an outline of feature ideas for a product. I have several columns for each item: priority, difficulty, version # and status.
I assign each item a priority and difficulty ranking of 1 to 5.
I leave version # and status empty at this point.
I then view a sorted list of all ideas by priority and difficulty.
Everything that's high priority and easy gets assigned to the next version # (say 2.0). A few things that are high priority and hard get assigned to version 2.0 as well.
I then make a view of outline items for v2.0 -- that's my todo list.
As I complete each item, I change the status for "todo" to "needs testing" to "needs documenting" to "done". If I have comments about an item as I do it, I add sub-categorized outline items under the item I'm working on, and put my notes there.
I make a view that is != done, so I can see what I need to do. As I change status of items to done, they disappear from my view.
This outline process is a very handy way to go from a random list of ideas to managing the workflow of doing many small tasks.
MANY PERSON TODO LIST
I make an outline of the work tasks needed.
For each item, I make a 'priority', 'status' and 'assigned to' column.
For each item, I put my priority (typically a number 1-9), make the status 'todo', and assign the task to one of my partners on the project.
I then make a view for each assigned to, with the items sorted by priority, export it to email, and give it to each person on the project.
Now, each person knows what they need to work on, and in what order, and reports back to me as they complete tasks, and I change the 'status' of each item in my outline.
I make a != 'done' view so I know what still needs to be done, and the view is empty once everything is done.
- John Buckman
Another use case extracted from tkoutline discussion
16-Apr-03 Telmo Amaral (tga@fe.up.pt) - snip ...I use Ecco and find the columns and filter functionality very useful. When developing an application, I use two filtered views of my tree: To Do and Done; when an item gets marked as Done, it vanishes from the To Do's and gets "archived" in the Done's; this keeps the To Do view clean and comfortable. I also use a User Documentation filtered view, to display items marked as UserDoc; most importantly, I can also have items marked as Bug (describing unsolved bugs) conveniently appearing both on To Do and on User Documentation; needless to say, when such a Bug item gets marked as Done, it vanishes from both views.
ANOTHER USE CASE (from Auriel Manolson)
Imagine two col's "date created" , "date modified" for each node. Amung other things I use outlines for personal, journal / theraputic type of writing. Sometimes these documents are edited and new insights and thoughts added to sections over a period of several months, or even years. Using a simple outliner, there is no way to see when I was thinking such and such a thought ... which would be very useful and insightful, especially if I could filter out thoughts that were very old, or could some how mark certain nodes as no longer relevent, without loosing the insight that I once had that persective.
I guess I have got to try out the old Ecco, I have downloaded it, but not yet installed it, but of course what I really want to be using is an Open Source, actively developed application, not an antique like Ecco.
best to y'all :am. (sf user name: manolson)
Brian Theado - Wouldn't it be easier to have some optional functionality (probably via a plugin) that would automatically store a creation date/modification date on each node? Rather than having to add the date manually via the column? Oh, maybe that is what you are proposing and the columns are there for viewing purposes in order to help you construct the filter?