I hate doing this kind of commercial breaks but....... have a look at 
the StarBrowser. It is trivial to make it do the behaviour that you 
would like:
- create a subclass of class ItemChildren (MyChildren) where you 
override the doClass: method to return its methods (or include 
intermediate categories if you like this. I did this for the VW 
version, but you can omit the categories, or only show the methods 
starting with an 'a' if this pleases you :-) ).
- register this class so that it is used: evaluate 'MyChildren 
register'.
- retract/expand your root node in the classification browser so that 
it can recalculate the items (or open a new one if you find that safer).
- currently I don't have the latest version open here, but have a look 
at the class ItemEditor and its subclasses. This class determines what 
happens when you select something in the tree-view on the left. I think 
that by default it now shows a 'system browser', with categories etc. 
If it does not exist yet, make one that just puts a smaller class 
browser there (the one without the categories).

Tadaaaa. You don't have to look at the categories anymore, and you win 
a lot of screen real estate.

PS: I don't have an image open yet and it is after 1 AM here, so I'm of 
to bed. Let me know if you need help with this cookbook.

On Wednesday, December 18, 2002, at 11:48 PM, David Farber wrote:

> At 04:37 PM 12/18/2002 -0500, you wrote:
>> 	Method Categories and Class Categories are not part of the Smalltalk 
>> language!  They are user interface conveniences, and I generally just 
>> prefer to 'browse hierarchy' for classes and '--all--' for methods.  
>> The categories create another completely unrelated organization of 
>> classes, which I find confusing because it has nothing to do with 
>> inheritance.  I may be the only one, but I just don't like the 
>> categories facility, and while I don't want others to be denied the 
>> choice, I want to be free to ignore categories and not use them if I 
>> choose.
>
> Dean - Good point. Plus the categories lists take up UI space in the 
> Browser that makes long class and method names hard to read. I, 
> personally, happen to like having categories--I missed having method 
> categories when I worked in VisualAge--but having all that UI space 
> taken up by 4 seperate lists does bug me. But your message sparked an 
> idea:
>
> Why not collapse the category lists into the class and method 
> lists--and then make the categories optional?
>
> /Kernel-Objects/    | /accessing/
> Boolean             | classPool
> DepedentsArray      | name
> EventMessageSet     | /accessing class heirarchy/
> ...                 | addSubclass:
> /Kernel-Classes/    | removeSubclass:
> Behavior            | subclasses
> +CLASS++++++++++++++| subclassesDo:
> Class Builder       | subclassesDoGently:
> ...                 | ...
>
> Then you could add a menu item for each list that says "Show/Hide" 
> categories.
>
> (Hmmm...my proposal does seem like it would take a lot more effort to 
> scroll through the now larger Class list to find the class you were 
> looking for. But that just begs the question of how, in terms of the 
> user interface, a programmer goes looking for a class in the first 
> place. How often does a progammer know (from memory) which category a 
> class is in so as to be able to use the category list in the first 
> place?)
>
> david
>
> --
> David Farber
> dfarber at numenor.com
>
>
Roel Wuyts                                                   Software 
Composition Group
roel.wuyts at iam.unibe.ch                       University of Bern, 
Switzerland
http://www.iam.unibe.ch/~wuyts/
Board Member of the European Smalltalk User Group: www.esug.org