Squeak-dev October 1998

squeak-dev@lists.squeakfoundation.org

107 participants
209 discussions

Re: [Fwd: Morphic Wrappers] (fwd)
by Gerardo Richarte 02 Oct '98

02 Oct '98

Daniel wrote: > Double click on my just dragged supposedly wrapped Form. Bummer - > Morphs aren't really wrappers. They don't give you a message menu, > they just blink dumbly. I had this problem myself, and Leandro [Caniglie] also has it. Once we use MorphicWrappers, we want everything to act as a MW, but no... As a result of this we started moving some messages in MW to Morph, this work is not finished yet, but it will be soon. We have to solve some design problems... if we move doubleClick menu, drop menu or keyboard handling to Morph then no Morph will be able to use those events anymore. As an example of this, suppose you have a GraphMorphicWrapper (one that I've done, and will post it somewhere soon) and you drop something over it. It can be a Number, as argument to some message, or it can ve a Vertex, so it can be added to the Graph. (this can be a default message... it's not a bad idea). I solved this problem checking the class of what is dropped, but this is not a good generic solution... Now I'm thinking that a default message can be sent holding shift down while dropping something in the MorphicWrapper... I'll test this, it sounds good, what do you think? (still don't know how to solve keyboard focus) > I started thinking about it, and realized that wrappers allow Objects > to live in Morphic, imitating Morphs. But by adding all that wonderful > Wrapper functionality, you leave Morphs behind, and therefore, they > don't mix. > > I was wondering whether and how you intended to address this. Ohhh, emmmm, well... one solution can be to turn everything Morphic in something MorphWrapped, and leave some Morphs as construction blocks, but I don't know if this is a good design idea. > Off the top of my head, it seems to me that the functionality in > Wrappers today might be better split between two levels, one allowing > a readable represetation on screen and the basic Morph menus, and the > next level providing the message sending interface. What do you mean with message sending interface? If you mean talking (typing) to an object, this can be moved to Morph with some work: We have to solve the problem of setting the keyboard focus by clicking on an object, because there are some morphs that need keyboard for their use (StringMorph for example) > [..] and the send level would allow all objects, Morph or wrapped, to > be sent arbitrary messages. I don't fully understand how to implement this interface on Morphs (or may be I don't understand what this message sending interface is...) > Which level is used should be decided by the World you're in. Can you expand this, please? > Waddaya think? > Anyway, thank you for Wrappers, certainly one of the coolest things > I've seen in Squeak. Ups! thanks! > What do you have in mind for version 2? + WrapperWorldMorph is gone, WorldMorph has learned all its functionallity + History (by Class) is implemented in CodeStringMorph. + A package with some interesting examples will be available, including GraphMorphicWrapper, VertexMorphicWrapper and (probably) some very interesting use of them, !!! ClassMorphicWrapper and (some kinf of) MethodMorphicWrapper (thanks to Leandro) !!! Some of them may be moved to the basic package... + Some rearrangement in classes: there is no more RoughMorphicWrapper, some methods have been moved from to MorphicWrapper, and some other to Morph. + everything I'm forgetting... Improving Bye! Richie++

2 1

How to start VM with more memory on Windows
by Michael S. Klein 02 Oct '98

02 Oct '98

I am trying to start Squeak with a larger than normal memory. The command line I am using is: S:\squeak\Squeak2_2\SqueakBeta S:\squeak\Squeak2_2\Squeak2.2.image -memory: 10000000 (all on one line, of course) The -memory: switch is being ignore by the VM startup code, and is being interpreted by the return from snapsot code as a filename to load in. Is there something I can put in the .ini file to change the default memory size? Is there a help page in general for the Windows VM... I recall sing one once, but can't seem to find it now. Thanks, Mike Klein mklein(a)alumni.caltech.edu

3 2

Re: GUI frameworks and prototype objects (Was: Getting Started with Squeak)
by wirth＠almaden.ibm.com 02 Oct '98

02 Oct '98

"Alejandro F. Reimondo" <aleReimondo(a)sugarweb.com> wrote: > Parts for Smalltalk works connecting objects with links. > The objects can be visual (GUI) objects or non-visual. > You can save your work in aFile with the component, > later you can use the component (loaded from file). > You can connect the parts with point & drag; but if you want to, you can write > a new method for any object. The method will be bound to the object (not to > its class) to expand the part or to implement a more convenient message > in the context where the part is been used. What we're getting into here is the advantage of instance-methods, or more radically, prototype object models, for dynamic GUI building environments. A couple interesting examples of such systems include: * Amulet, done by Brad Myers' group at CMU, in which they implemented a prototype object model on top of C++(!): http://www.cs.cmu.edu:80/afs/cs/project/amulet/www/amulet-overview.html *SK8, done at Apple (a project with which I was associated for awhile), with a prototype object model implemented on top of Lisp: http://sk8.research.apple.com/ <--- Sigh... this link appears to be dead. *NewtonScript, a relative of Self, with a really funky inheritance/containment model. *Hmm... I bet we can consider Cocoa (now Stagecast) to be built with prototypes, too :-) http://www.stagecast.com/ Mike Wirth

2 2

RE: Getting Started with Squeak
by Alejandro F. Reimondo 02 Oct '98

02 Oct '98

I wrote: >> Another point to consider is the codeGeneration vs. objectGeneration topic. >> Most toolkits are only code generators. They produce raw source code. >> I think that the product to be obtained with an OO toolkit must be anObject. Steve Dekorte <steve(a)dekorte.com> wrote: >It could do this because of Objective-C's Smalltalk-like features. >(dynamic binding, weak typing, introspection, etc) Are there any Smalltalk >tools that work like this? Parts for Smalltalk works connecting objects with links. The objects can be visual (GUI) objects or non-visual. You can save your work in aFile with the component, later you can use the component (loaded from file). You can connect the parts with point & drag; but if you want to, you can write a new method for any object. The method will be bound to the object (not to its class) to expand the part or to implement a more convenient message in the context where the part is been used. Ale.

2 1

CodeWarrior Pro3 Project file for Squeak 2.2
by Stephen Pope 02 Oct '98

02 Oct '98

For Mac users with newer versions of CodeWarrior, I've up-loaded a BinHexed CWPro3 project file to ftp://ftp.create.ucsb.edu/pub/Squeak/2.2. I'm moving to CWPro4, and will up-load a new project file in a few days. stp _ Stephen Travis Pope _ Center for Research in Electronic Art Technology (CREATE) _ Department of Music, Univ. of California, Santa Barbara (UCSB) _ stp(a)create.ucsb.edu, http://www.create.ucsb.edu/~stp/

2 1

Re: Getting Started with Squeak
by Steve Dekorte 01 Oct '98

01 Oct '98

"Alejandro F. Reimondo" <aleReimondo(a)sugarweb.com> wrote: > Another point to consider is the codeGeneration vs. objectGeneration topic. > Most toolkits are only code generators. They produce raw source code. > I think that the product to be obtained with an OO toolkit must be anObject. > Tools like Parts for Smalltalk are very powerful, because they generate > real GUI Objects! Is this code generation being done to do interface layout or set up connections between interface objects? If so, IMO, this is an example of a failure to abstract these behaviors. The NeXTstep Interface Builder, for example, could layout and set up connections without any code generation. It could do this because of Objective-C's Smalltalk-like features. (dynamic binding, weak typing, introspection, etc) Are there any Smalltalk tools that work like this? Steve

1 0

Re: Getting Started with Squeak
by Kevin Fisher 01 Oct '98

01 Oct '98

If I could just interject my 0x02 here...I've been touching Smalltalk on and off for several years now (Thanks to Squeak I have a decent environment!). However my first encounter with Smalltalk was back in the very early 80's when I was still in elementary school...I saw a video about 'new' technologies and it showcased Adele Goldberg giving a tour of the Smalltalk-80 system running on either an Alto or a Star (memory is a bit fuzzy on this). I believe this was pre-Mac and definitely pre-Windoze. From that point I've never truly been able to seperate the GUI from the object...the Smalltalk environment made a lot of sense (which is probably why I've never liked or gotten used to regular C-based GUI programming). It only really makes sense to me to do GUI programming in an object-oriented fasion; C++ is better than raw C for this (although MFC can make me cough hairballs :). However, none of it is _fun_ to do, it's more of a tedious chore that detracts from what you are trying to do (I still shudder when I think of my first Motif-based program...) In my limited experience with Squeak & Morphic, I've found it to be pure bliss compared to my C/C++ endeavours...with NO documentation I've figured out a lot and I'm amazed how easy it is to put something together...not in a lobotomized Visual Basic way, but in an intelligent and natural way... (well, natural to a programmer anyway). I've always thought of things in artistic terms...the painting is the end result (what you are trying to visualise) and the programming language is the tool or brush. I think the C/C++ way has created a tool that is more complex than the end result..it ends up obscuring what you are trying to visualize since you spend more time learning how to use the tool than creating your work of art. Refreshingly I've found Smalltalk to be the other way around...the tool is easy to learn and almost seems like a natural extension of my thoughts. Anyway, enough of my rambling...I just have to agree that Smalltalk/Squeak is a much easier way to do anything GUI related...and a heck of a lot more fun, too. (I must thank the Squeak team for making this wonderful environment available, and even taking the time to respond to my silly questions too...)

1 0

Re: Getting Started with Squeak
by Mark Guzdial 01 Oct '98

01 Oct '98

>> There are very few languages well suited to creating UIs. Smalltalk may be >> the only one. > >Please explain that statement. I am a Smalltalk novice. What makes the >*language* well-suited to creating UIs. The MVC or pluggable paradigms? >They are not language specific. Dan Olsen talks about this in his new book on "Developing User Interfaces" (Morgan-Kaufman, 1998). I don't think I grok all the subtleties, but I'll try to relate the story. The self-reflective and late-binding nature of Smalltalk allows you to create views that are more de-coupled from their models. For example, when a textbox sends #getText to its model, it doesn't care what the model is, as long as it can respond to getText -- you can even swap the model at run-time, and as long as the message is answerable, it all works. Olsen contrasts this with C/C++ where the compiler requires the model and view to be linked together at compile time, the types have to match, etc. Java can do this de-coupled model-view, too, but it had to invent (overly-complex, IMHO) inner classes to make it work. Mark -------------------------- Mark Guzdial : Georgia Tech : College of Computing : Atlanta, GA 30332-0280 (404) 894-5618 : Fax (404) 894-0673 : guzdial(a)cc.gatech.edu http://www.cc.gatech.edu/gvu/people/Faculty/Mark.Guzdial.html

5 4

Re: Getting Started with Squeak
by wirth＠almaden.ibm.com 01 Oct '98

01 Oct '98

<Very interesting anecdote from Dan Ingalls>: I have to relate an anecdote from the early days. We were using Smalltalk-76, the first Smalltalk that performed well enough to support serious software (it had the same engine as Smalltalk-80, and a simpler body ;-). There was a student (I can't remember who this was) on one of the Alto's in the corridor who was having fun implementing a Fraction class (there wasn't one built in). He came over and asked me to give him some help because he had gotten things in such a shape that something was preventing the screen from redisplaying successfully when he proceeded from the debugger. I went over and started to paw around, and discovered fairly soon that the bottom-level call on BitBlt was recieving Fractions as parameters, and was therefore failing. As I looked around to see how that happened, I was astounded to find that the entire browser in question had fractions in practically every point and rectangle in all its views and subviews. I asked him about this, and he said, "I just reframed it, but maybe it was because I made divide return a fraction." I said, "Hmm, maybe so. What do you send to a Fraction to get the integer part?" He told me. I added the coercion to BitBlt's fail code, and the whole thing proceeded to run just fine when I restarted the method. I remember feeling almost dizzy on the way back to my office. - D ================================== Dan says: "...the bottom-level call on BitBlt was recieving Fractions as parameters, and was therefore failing." And therein lies the value of multi-methods (that dispatch on more than one argument, as in CLOS). With multi-methods I could define an "around" method for the BitBlt call, without having to have any internal knowledge of BitBlt methods. But that gets us onto the slippery slope where methods aren't even "owned" by one class, but by the relationship between several (as defined in the method signature), and the message passing paradigm doesn't even make sense anymore. So I'll stop before we get into another religious war :-) Mike Wirth

1 0

Jump to page: