Uli's Web Site
[ Zathras.de - Uli's Web Site ]
Other Sites: Stories
Pix
Abi 2000
Stargate: Resurgence
Lost? Site Map!
 
 
     home | blog | moose | programming | articles >> blog

 Blog Topics
 
 Archive
 

15 Most Recent [RSS]

 Less work through Xcode and shell scripts
2011-12-16 @600
 
 iTunesCantComplain released
2011-10-28 @954
 
 Dennis Ritchie deceased
2011-10-13 @359
 
 Thank you, Steve.
2011-10-06 @374
 
 Cocoa Text System everywhere...
2011-03-27 @788
 
 Blog migration
2011-01-29 @520
 
 All you need to know about the Mac keyboard
2010-08-09 @488
 
 Review: Sherlock
2010-07-31 @978
 
 Playing with Objective C on Debian
2010-05-08 @456
 
 Fruit vs. Obst
2010-05-08 @439
 
 Mixed-language ambiguity
2010-04-15 @994
 
 Uli's 12:07 AM Law
2010-04-12 @881
 
 Uli's 1:24 AM Law
2010-04-12 @874
 
 Uli's 6:28 AM Law
2010-04-12 @869
 
 Uli's 3:57 PM Law
2010-04-12 @867
 

More...

Heterogeneous outline lists

In his article Forest for the Heterogeneous Trees, Andrew Pontious writes about the malady that are heterogeneous outline views (aka heterogeneous tree views). He also mentions, as one example, my TADS Workbench.

While I fully agree with him that I really am cramming a tad too much into the same list, I'm not sure I agree about how much is "too much". From his comments, I understand he would like to see every of the pseudo-folders in Workbench in its own list.

I guess the problem is that Andrew didn't really define what he meant by "heterogeneous". If one takes a very strict definition, even folders and files shouldn't be in the same list, because a folder is not a file. On the other hand, if we take too loose a definition, we get something like Workbench has, where, because each of the items in the list is simply an entry in the TADS Project File, all of them belong in this list.

Obviously, these are both nonsense. But there's a lot of intermediate positions. In the case of Workbench, one could argue that the Include Folders are file system items, just like the source files and the library files, and thus should be in the main list.

So, how would one go about scientifically determining whether a particular list is too full? Well, I guess apart from checking for heterogenity in the kind of items, one should also check for heterogenity of their use. With this in mind, I would put the Source files and Libraries groups in the main window:

  • They both contain files
  • The files they contain both eventually add code (new classes, new functions) to the project
The only difference between them is that a library groups several source files that have usually been provided by someone else than the current game's author.

OTOH, while the constant definitions obviously shouldn't be in this list, we now have a rationale that makes us realize why the include paths shouldn't be in this list:

  • They contain folders, not files
  • These folders aren't actually added to the project in any way, they modify how file names are treated which aren't fully specified.
They modify. When something modifies the behavior of other parts of the program, this must obviously be a preference. Just like the constants, which modify what a certain piece of text in the source files means, or what particular language variant of the library you get. That's why I just changed Workbench to display these two lists in the Project Settings window.

We'll see whether Andrew agrees. Since he will probably be releasing the next version of Workbench, he'll get another opportunity for fixing this before it reaches your hands. I'm looking forward to seeing some of his plans bear fruit. He has lots of ideas that would be really cool to have in Workbench.

 
Created: 2004-11-14 @709 Last change: 2004-11-14 @740 | Home | Admin | Edit
© Copyright 2003-2024 by M. Uli Kusterer, all rights reserved.