[RFI] Possible enhancements to work on at the Squeak-End

Stephen Pair spair at advantive.com
Thu May 2 13:17:06 UTC 2002


Great ideas!  A weekend is certainly not much time to get anything huge
accomplished.  I've added these to the swiki
(http://coweb.cc.gatech.edu/mmworkshop).  I've also put my comments on
each item there.

- Stephen


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
> 
> 
> 




More information about the Squeak-dev mailing list