hi Doug

I was thinking that using the dependency model to notify all the browsers 
when  changes are made (new method, removed methods, new class) would be 
great. The concept of the update menu item is wrong. Roel implemented a 
small change in VW to egt all the events and this is excellent to catch 
all the modification and build cleverer and simpler browsers

Stef


On Thursday, May 2, 2002, at 07:01  AM, Doug Way wrote:

>
> Here are some RFI's (Requests For Implementation) that I've been jotting 
> down over the last several months.
>
> These are basically some ideas for enhancements to Squeak, some of which 
> should be small enough for folks to implement at the Squeak-End, which I'
> ll be attending.  (not everyone likes to work on bug-fixes, sometimes new 
> features are more fun)
>
> Since this is mostly brainstorming, comments are definitely welcome. I've 
> listed the ones that I think are easier first.
>
> * Display Class Comment in Definition Pane
>   Display a class' comment below the class definition in the browser (in 
> double quotes), so that it's immediately noticeable when browsing through 
> classes, and also immediately apparent when it's missing.  If there is no 
> comment, use the string "This class has not yet been commented." instead.
>   (VisualWorks now does this.)  For simplicity's sake, editing the 
> comment could still be handled by switching to the comment pane (via the 
> "?" button).
>
> * "Decompress to file" Should Refresh
>   The "decompress to file" menu item in the FileList (for .gz files) 
> should refresh the file list afterward, and probably select the 
> decompressed file, too.
>
> * Store Output in the Transcript Even If Not Open?
>   I haven't really looked into whether this is easily doable, but it will 
> be very cool if it were possible to store output directed to the 
> Transcript, even if a transcript window wasn't opened yet.  Then, when 
> you opened the transcript window, the output would already be in the 
> window.  It often happens that I forget to have a transcript window open 
> when I need to look at the output from some operation, and this would 
> solve that problem.
>
> * Class-side Changes in FileContentsBrowser
>   The FileContentsBrowser should show class-side changes with a separate
> "ClassNameXXX class" class-side entry in the class pane (in addition to a 
> possible "ClassName" instance-side entry).  This would be just like how 
> the change sorter displays class changes, and would prevent accidentally 
> overlooking class-side changes.  We could also get rid of the 
> instance/?/class buttons then.  (Perhaps class comment changes could be 
> appended to the class definition area.)
>
> * TextEntryMorph
>   Create a TextEntryMorph, which is a text morph restricted to a single 
> line, which does not change its size as text is typed in, ignores CRs, 
> and also horizontally (not vertically) scrolls itself as text (of 
> unlimited length) is typed or highlighted past the edge.  Very useful for 
> specific applications.
>
> * Class Definition Timestamps
>   Class definitions should be stored with a version timestamp, just like 
> methods are.  They're stored in the .changes file anyway, right? Then you 
> could see instance variable/etc changes show up by browsing "versions" 
> for definitions, with diffs!  Seems like this shouldn't be impossible.  
> ENVY never even supported this, for reasons I've never understood.  (This 
> one's more of a brainstorm, probably not doable during the SqueakEnd.)
>
> * Command Completion Dependent on Preceding Expression
>   It would be really cool to have command completion (alt-q) work in 
> workspaces/inspectors, such that the preceding expression is parsed and 
> evaluated first so that the outputted "type" of the expression is known, 
> which can then restrict the messages listed to the ones that object 
> understands.  On second thought, this may not be feasible, since you 
> probably don't want to evaluate expressions which have side effects, or 
> take a long time to execute, ah well.
>
> * Have MethodFinder ignore methods which only return self. (it could just 
> return self for those methods, without actually executing them) This 
> would greatly reduce the number of hardcoded methods-to-avoid.  (is there 
> a way to quickly detect if a CompiledMethod always returns self?)  
> Admittedly, this one is just a random brainstorm.
>
> - Doug Way
>   dway at riskmetrics.com
>
>