Hi Everyone!

	I hope everybody got to take some time off and enjoy the holiday
season.  I had a two week holiday, but I did manage to look into the
'-- all --' category issues.  I've attached a change set that is the
distilled results of my investigation.

	The behavior that you should get with this change set is as
follows:

	1) with a system category and a class selected, the message
	   category list displays the list of categories, including
	   the '-- all --' category.

	   If no message category is selected, all method selectors
	   for the selected class will be displayed in the message
	   list pane, and the code pane will display the class
	   template for the selected class.  The code pane will be
	   in 'editClass' mode.

	2) as above, but with any message category selected, including
	   the '-- all --' category, but with no method selector
	   selected in the message list pane, the new method template
	   will be displayed in the code pane and selected.  The code
	   pane will be in 'newMessage' mode.

	3) Accepting a new method while the '-- all --' category is
	   selected will add the new message to the 'as yet unclassified'
	   category.  The 'as yet unclassified' category will be
	   created if it doesn't exist.

	I have manually tested these changes fairly completely in a
morphic project and I did some less thorough testing in an MVC
project as well.  Everything I tested behaved as I expected, and
hopefully the way others would expect as well (i.e. no weird,
un-helpful error messages, etc.).  Sorry, but I didn't write
any SUnit tests for these changes.

	This fix required touching four methods:

	METHOD						PREVIOUS VERSION
	------------------------------------	-------------------
	Browser>>classListIndex:			nk  2/13/2001 13:26
	Browser>>contentsSelection			dew 7/28/2000 00:44
	Browser>>messageCategoryListIndex:		dew 7/28/2000 01:13
	Browser>>messageList				ccn 3/24/1999 10:48

I started with a clean 3.2-4956 image, and I have also tried the change
set on a clean 3.0 final image, and things seem to work properly.  If
anybody is interested in reviewing the history of my work, I can make
the image and change log available.

	I am happy with my fix, as far as I have looked at it.  I don't
know if this has implications for any other tools.  Class browsers,
senders, implementors, and things like that, that I used to "learn"
the browser and find the places to change still work ok, but I haven't
made any specific effort to look for other code that might be affected
by my edits... So, caveat emptor.  I would like to see the changes
subject to some serious testing in other people's day-to-day work to
see if I missed any problems or more importantly, unintentionally
broke something.

	And an editorial comment on my part:  The browser seems to have
accumulated quite a bit of 'cruft' over the years.  There are cases
where there are methods with different selectors, but the same
functionality, etc.  Being such a central tool to the system, it
might be worth the effort to seriously over-haul and/or re-build
the browser from scratch.

	I spent a few days mucking around in the browser code, and I
still don't feel like I really understand it (for whatever that is
worth).  I _feel_ that a simpler design with equivalent functionality
should be possible.  I would be interested in other points of view on
this.


					-Dean


> -----Original Message-----
> From: Doug Way [mailto:dway at riskmetrics.com]
> Sent: Thursday, December 19, 2002 12:03 AM
> To: squeak-dev at lists.squeakfoundation.org
> Subject: Re: Automatic selection of '--all--'
> 
> 
> 
> I agree with Stephane and Andreas that the most 
> straightforward solution 
> is to just show all method names (and the class template) 
> when no method 
> category is selected.
> 
> If we do this, there are still a couple of minor points:
> 
> - I assume that we would get rid of the '-- all --' category, 
> since you 
> would already have a way to display all method names.  It also might 
> make things a little cleaner for the Browser to have one less special 
> pseudo-category to deal with.
> 
> - We would still have the 'no messages' pseudo-category which 
> shows up 
> when a new class is created.  So you could still select this 
> category if 
> you want to add new methods which would show up as 'as yet 
> unclassified'.
> 
> Anyway, 3.4 is almost finalized (in a couple of weeks), so these 
> enhancements will have to wait for 3.5alpha.  The current 
> behavior (not 
> including the recent #5137 fix attempt) has existed for a couple of 
> years, so it seems reasonable to wait.
> 
> If Dean or anyone else wants to try fixing it, that would be great.  
> Some of the Browser code can be tricky, but it should be doable. :-)  
> Otherwise I might try fixing it in a few weeks.
> 
> - Doug Way
> 
> 
> On Wednesday, December 18, 2002, at 04:25 PM, Andreas Raab wrote:
> 
> > Dean and all,
> >
> > There's no reason to flame nor to blame here. This entire thread has
> > been taken out of context of other messages. So let's try 
> to summarize:
> > There is an apparent problem at this point if you try to add class
> > variables. This is because there is a pattern match in the browser
> > trying to recognize the '*subclass:' for class definitions 
> if the '--
> > all --' category is selected. The proposal has been made to 
> change the
> > pattern match that it "better recognizes" any attempt to 
> define a class
> > when you hit accept while '-- all --' is selected.
> >
> > Looking at the code it appeared to me that all of this is due to the
> > fact that if the '-- all --' category is selected we may or 
> may not try
> > to define a class or a message. Since a category is selected you may
> > expect to define a message. But since the '-- all --' 
> category shows the
> > class definition when selected it is equally reasonable 
> trying to define
> > a class rather than a message. That's the heart of the problem.
> >
> > My proposal was basically recognizing the fact that if a category is
> > selected you should expect to edit a method and not a class 
> definition.
> > There is nothing wrong with the '-- all --' category itself. What is
> > wrong is the inability to distinguish between "class 
> definition mode"
> > and "method definition mode" when '-- all --' is selected. 
> One way of
> > solving this problem would be show all of the selectors even if no
> > category is selected. This preserves the intent of automatically
> > selecting the '-- all --' category (namely to give an 
> overview of the
> > entire protocol of some class) without getting into the trouble of
> > trying to do magic pattern matches if it is selected. In 
> which case it'd
> > be very simple: You select a method category, you edit a method. You
> > have no category selected, you edit the class definition.
> >
> > That's really all there is to it.
> >
> > Cheers,
> >   - Andreas
> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: AllCategoryBrowserChanges.2.cs
Type: application/octet-stream
Size: 2862 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20030106/e50a4c81/AllCategoryBrowserChanges.2.obj