> We could still use styled text within Squeak, 
> and have conventions for writing code in plain text 
> when necessary.  

Isn't this what the "Tiles" view of source code is all about?

I feel that the "Tiles" view is severly under utilized.

Shouldn't the "Tiles" view be where we graphically represent:
   * The concepts behind the code
   * The meta information of the application
   * The object message or timing structure
by changing the colors, shapes, empty tile spaces to plug things into, and such 
like?

What are the "Tiles" view's current drawbacks that keep it from being used, 
optimizd, and/or enhanced? 

   * Tile's 'properties' morph like eToy's Inspector?
   * Drag & Drop tray of common or useful messages components and values 
components like eToy's Inspector?
   * Autocomplete or pop up list to complete?
   * Direct links to documentation? 
   * Patterns & Antipatterns?


Cheers,
Darius







-----Original Message-----
From: Avi Bryant [mailto:avi at beta4.com] 
Sent: Thursday, December 04, 2003 4:57 PM
To: The general-purpose Squeak developers list
Subject: Re: Morph>>Delete



On Dec 4, 2003, at 4:52 PM, Alan Kay wrote:

> Lots of appearance things were nicer before the Smalltalk-80 release 
> efforts. I wasn't there at the time, but I think they decided 
> (probably rightly) to use the existing character set in the outside 
> world. And, today, it would be nice to do something like your 
> suggestion (maybe a different one) and many other cosmetic 
> possibilities, but several folks have pointed out that even a slight 
> deviation from unadorned text is not supported by all email clients 
> (sigh).

We could still use styled text within Squeak, and have conventions for 
writing code in plain text when necessary.  For example, I always write 
:= instead of _ when sending email, even though I much prefer the left 
arrow where it's supported.