Living happily together

Lex Spoon lex at cc.gatech.edu
Tue Jul 10 15:39:01 UTC 2001


"Jim Benson" <jb at speed.net> wrote:
> Lex,
> 
> Do the text editors appear beside the lists in this scenario?

No, I imagine that text will appear *beneath* the method list -- so that
if you start with the class category list pane, and expand four times,
you will have something that looks a lot like a regular browser.


> 
> >
> > 2. Titles are equally important to all morphs, at least under my usage.
> >  This is especially true if you use the default color scheme, so that
> > you can recognize windows by their color.
> >
> 
> Does this mean show titles always, or never show the titles? If the answer
> is show titles, what do they look like?

I really don't use titles much, so I'd prefer they are left in the halo
the way the are right now.


> 
> 
> Overall, how would you compare this browser with something more structured
> such as Whisker, and how do you envision such tasks as integrating the lint
> and refactoring browser tools in to this gui?

I would call whisker fairly unstructured, from what I've seen of it.  I
do like it quite a bit, from what little I've seen.  If I had more time,
I'd definitely be looking into it!


> 
> In some sense, I get the feeling that I need (at the very least) a coding
> equivalent to a word processor. A word processor checks for spelling and
> grammatical mistakes, so should my development tools but in a different
> context. It has to compile it of course, but it should also do lint checking
> and make sure I don't make the 10 stupid Smalltalk mistakes. Ideally it
> would know other thing too. Like when I've made algorithmic errors ( On2 vs
> On for example ) , knows of a better algorithm than the one I'm using, or
> has a better 'pattern' for some spot of code, but obviously all that's
> somewhere down the road.

Of course, this isn't just UI changes -- there is  significant
technology required to find an error in an algorithm!


> As I see it, the current browsers do a smashing job of classifying the
> system into named categories. What it doesn't do is tell me how the various
> classes interrelate. While I hate to use the term 'CASE tool' , it's
> difficult at a glance to tell what the design intentions behind a small app
> are (or even what the apps are ;-) and how the classes are related. Even
> simple apps require that you have more 'image' specific knowledge than is
> reasonable to expect.

A good English essay is pretty good at this, actually!  If writing five
paragraphs seems like too much trouble, then how much trouble is it
going to be to document it in some fancier system (once the initial fun
wears off, that is!) ?   It's true, though, that there are only limitted
spots to put such commentary in the system, right now.  Class comments
are a step in the right direction, but I'd love to also see variable
comments and category comments, too!




Lex




More information about the Squeak-dev mailing list