More understandable classes, objects and keywords please!

I'm reading through the First Splash, which is definitely a dive into
the deep end. I've used VisualWorks extensively so I'm reasonably happy
with this entry tutorial, but I worry about the beginner. For instance,
you are asked to refresh the screen by using:

UserLibrary default invalidate: nil lpRect: nil bErase: true

At this point the beginners probably wonder if they should check out
Java instead. Surely this needs to be rewritten to something like:

Screen refresh

This would also help the more expert. In VisualWorks, I found I could
mostly guess the class names and method keywords for the functions I
required. I would never have guessed how to get rid of that digital
clock in a million years!

Also, the digital clock example is rather involved for beginners. If,
say, someone has dabbled with VBA scripts, then he might think
Smalltalk looks just as complicated as Java when he compares the
digital clock to initial examples in the Java tutorial. The
multi-processing subtlety is just going to go right over a beginner's
head. The way it just draws over windows also looks naff - not a good
initial impact. Why  not impress the beginner with how simple it is to
create a functional window in Smalltalk using one line of code:

Dialog warn:'Hello World!'

(or whatever Dolphin's equivalent is)

Then again, perhaps you are aiming for the disgrunteled experienced
Java programmer rather than beginners. If so, maybe this First Splash
will work.

In summary, I do not think Dolphin has much chance of catching the
interest of an inexperienced programmer who has not been sold on
Smalltalk. Which is a shame, because it should.

Mal,

> UserLibrary default invalidate: nil lpRect: nil bErase: true
>
> [...] Surely this needs to be rewritten to something like:
>
> Screen refresh

Or at least the introduction could say something like:

    Don't worry about this, it's a bit of obscure Windows magic,
    and you will probably never need use it again as long as you
    live.


> Also, the digital clock example is rather involved for beginners. If,
> say, someone has dabbled with VBA scripts, then he might think
> Smalltalk looks just as complicated as Java when he compares the
> digital clock to initial examples in the Java tutorial.

Do you think that:

    window := TextPresenter show: 'Static text'.
    window view font: (Font name: 'Arial' pointSize: 72) beBold.
    window topShell extent: 600@200.
    digitalClockProcess := [[
       Processor sleep: 1000.
       window value: Time now printString;
    ] repeat] fork.

would be preferable, or does that suffer from the same problems ?  (I have no
opinion myself -- I had never seen or executed a single line of Smalltalk when
I first went through what's now called the "first splash", and it didn't put
/me/ off, but who's to tell how it affects others...)

    -- chris

Mal,


Well you might have if you were a Windows programmer (VB or otherwise).
But I do accept what you say. How about we modify it to:

View desktop invalidate.

In the current system this won't work because of a vagary with the way
that InvalidateRect works in Windows. But if we override:

---
!DesktopView methodsFor!

invalidateRect: aRectangle erase: aBoolean
        "Invalidates the specified desktop rectangle (a RECT, Rectangle, or
nil for the whole client window).
        Set whether to erase the receivers background before repainting.
Answer whether the function succeeds."

        ^UserLibrary default
                invalidate: nil
                lpRect: aRectangle asParameter
                bErase: aBoolean asParameter! !
!DesktopView categoriesFor: #invalidateRect:erase:!drawing!public! !
---

then it should work ok. I'll get this method and the First Splash
updated for the next patch level. The enhancement is recorded as #2121.

Well the Dolphin equivalent is:

MessageBox notify: 'Hello World'

but I don't see how that would be very impressive at all (unless the
reader had come straight from reading Petzold, of course). You might be
right about drawing directly over the desktop but, without creating a
specialized class only for the tutorial it's hard to see how to do it
otherwise. Remember that the example states that it is there to
illustrate multiple processes which are hardly ever straighforward in
themselves.

Anyhow, thanks for the reports.

Best regards

--
Andy Bower
Dolphin Support
www.object-arts.com

I wrote:

>     window := TextPresenter show: 'Static text'.
>     window view font: (Font name: 'Arial' pointSize: 72) beBold.
>     window topShell extent: 600@200.
>     digitalClockProcess := [[
>        Processor sleep: 1000.
>        window value: Time now printString;
>     ] repeat] fork.

Maybe it would be a good idea to split it into two pages displaying different
aspects of the system:

"Showing a Window"
    window := TextPresenter show: 'Static text'.
    window view font: (Font name: 'Arial' pointSize: 72) beBold.
    window value: 'Hello from Dolphin!'.
Blah, blah, blah.

And then in the next taster page:

"A Digital Clock"
    digitalClockProcess := [[
        Processor sleep: 1000.
        window value: Time now printString;
    ] repeat] fork.
Blah, blah, blah.

Just a thought...

    -- chris

Andy,

> but I don't see how that would be very impressive at all (unless the
> reader had come straight from reading Petzold, of course). You might be
> right about drawing directly over the desktop but, without creating a
> specialized class only for the tutorial it's hard to see how to do it
> otherwise. Remember that the example states that it is there to
> illustrate multiple processes which are hardly ever straighforward in
> themselves.

My general approach to graphics is to make something draws on an
arbtrary canvas. Debugging starts with drawing on display compatibile DC
that I don't expect to see until the initial errors go away.  Then I
start drawing on bitmaps that I show in image presenters.  With a little
determination, one can do quite a lot with an image presenter; it might
be all you need.

Have a good one,

Bill


--
Wilhelm K. Schwab, Ph.D.
[hidden email]

> Well you might have if you were a Windows programmer (VB or otherwise).

You might be right, I was really thinking of the VERY inexperienced
programmer - maybe someone who was fining VB hard and was looking for
something else.

> View desktop invalidate.

I'm confused about what View refers to.

In MS Office the View menu always refers to current application window.


So if the clock were only trashing one window "View refresh" would be
good, but it barfs over all windows which is why I suggested "Screen
refresh".

If you use "refresh" the novice might have encountered the term in
Internet Explorer.

I have visions of the inexperienced panicing and turning off the
computer to get rid of that clock. (OK you tell them how to get rid of
it, but novices skip a lot and never read when panicing - in my too
many years experience of supporting intro. programming classes).

>> Dialog warn:'Hello World!' ... (or whatever Dolphin's equivalent is)
>Well the Dolphin equivalent is:
>MessageBox notify: 'Hello World'

Thanks for telling me! I was having fun playing with your Dialog class
trying to get something to work, but...

Maybe there's a case for moving the naming conventions closer to
VisualWorks? Or might that be a copyright problem?

> but I don't see how that would be very impressive at all

I think it's worth sticking with the tradition of having "hello world!"
as
the first "program". Then novices can get "something, anything" to work
and just about understand what that "something" is. At that stage
they don't need to be impressed (if the digital clock can do that!
I thought the Dolphin launcher was neat, almost impressive. The
Digital clock just spoiled the decor!)

Novices and experts can also get an initial feel of  how easy or hard
your language is, and have an initial basis of copmparison with other
languages. The Java tutorial, if memory serves, starts with "hello
world"
and Smalltak'sd one liner might impress in copmparson! (Maybe
Transcript
show:'Hello world!' should be the first thing they see?)

>Without creating a  specialized class only for the tutorial it's hard to see how to do it
>otherwise.

Why not!

>Remember that the example states that it is there to
>illustrate multiple processes which are hardly ever straighforward in
>themselves.

This is an interesting consideration for second year computer science
students. Is that your target audience in First Splash? Or are you of
the "throw the non-swimmers in the deep end" school. "They'll learn
soon
enough".

Hope my comments help, I'm trying to give you "first impressions" as I
have them. After using a system for a while you just don't notice many
faults, or the problems you had initially. The system, generally, looks
great and I'm certainly motivated to carry on (but I'm a  Smalltalk
fan).