Program Testing and Persistent Properties - Thread Conclusion

[Bob Warren]

Colleagues:

Some days ago I published a "worst case scenario" account of what it might
be like for a VB programmer to make the switch to the Rev IDE and the
confusions he might encounter when presuming that the setup of distinct
project design /project testing existed as he had been used to. For those of
you who might have missed the thread, the original  illustrated story of the
VB programmer's demise is at http://www.howsoft.com/runrev/article.htm .

Of course, the question of VB programmers entering into the Rev world
touches on various other crucial issues under discussion at the moment, such
as the quality and availability of the Rev documents, whether or not Rev is
too MAC-centric, whether or not Rev should do more to attract non-MAC
clients, cross-platform technical issues, etc. Other colleagues are far more
qualified to discuss these issues than I am. However, from my own egocentric
point of view I have discovered that:

1. Although there are profounder aspects of the IDE's project testing
environment that I really do need to work at, I am still suffering mental
blocks over the denomination and inter-relationship of the Browse Tool,
Pointer Tool, Modeless (properties??) and "Top Level", together with the
fact that projects tested with the Browse Tool (or Modeless request) retain
their acquired properties.

2. I am not the only one to be confused. Some people with far more
experience in Rev and far less experience in VB do not understand the design
of the interface in these respects, but so far have had little trouble
because they have not asked too many questions. For example, I am perfectly
happy using my video cassette player by learning how to start, stop, rewind,
etc. All the other knobs and buttons I ignore. Or if I use Microsoft Word, I
can quite happily produce my texts by ignoring about 80% of the resources
available to me.

The procedure I am used to in VB makes me very happy, and unfortunately, has
become a precondition for my happiness:

1. Project design and project testing are totally separate modes.

2. I feel absolutely no need to include user data in my project. I prefer to
keep it separately on the HD or elsewhere. If necessary, I can bundle it
with my standalone program and distribute it as a single file, but this is
done separately and by other means. (However, it should be noted that Rebol
for example permits the mixing of program and user data in the same script,
and this is considered to be an advantage in some circumstances.)

3. I can work in the following manner: Program a bit / Test it / Program a
bit more / Test it / Program a bit more / Test it
....................................... This particular characteristic is so
valuable that anything which prevented me from doing it easily would upset
me to say the least.

Some people have pointed out that Rev is different to VB, being born in the
MAC tradition. Rev means MAC, and proudly so, so welcome to Macintosh and
roll up your sleeves. If I were the average VB programmer (which I am not),
I would simply say "OK, bye-bye". What does the average man do when his
favourite program ends on the TV and he doesn't fancy watching the next one?
He takes a quick look at all the other channels. And how does he judge
whether he will switch to another channel? I don't know about you, but I
usually make up my mind in a few seconds. Is it the type of program I am
looking for? What is the overall quality of the pictures I take a glimpse
at? Do I like the actors' faces? Or perhaps I am looking for something
completely different to the program I have been watching, or not. So all
this relates back to whether Rev is interested in occupying a conservative
niche of about 10% of the overall market, or whether it considers that it
needs to expand (and really capture potential users such as myself) in order
to survive.

These things said, I would like to introduce you to an absolutely brilliant
analysis of the initial difficulties I encountered with the Rev IDE. It was
sent to me by Ken Ray, and it appears below. But for those of you who missed
the start of this thread, I should explain the following. The last 2
pictures of the article at http://www.howsoft.com/runrev/article.htm express
the idea of providing Rev with a mechanism for project testing in the VB
manner I have described. Troy Rollins thinks that (even as a beginner) I
could quite easily produce the plugin stack depicted there. I might well try
to do it. But Ken has an important observation to make about this question,
as you will see. Within a few days, I will put Ken's analysis on my site at
http://www.howsoft.com/runrev, since it is so useful. There are even
indications that Ken intends to pursue the Rev/VB comparison further and
that perhaps many more useful insights are in the pipeline. Anyway, here is
Ken's analysis:

(Bob, I'm writing this to you "off list" - if you feel that it should be "on
list", feel free to post it or to tell me it's OK to post it.)

>> If you really need it, you could do it.
>
> That was exactly what I had in mind, except that I am a complete beginner
in
> RR and I was a bit nervous about attempting such a thing as a first
> programming effort.

I agree, Bob... you shouldn't have to try to develop a plugin as your first
programming effort, considering the trouble you went through to understand
the pointer/browse dynamic in the first place.

To me, something like this is like a conversion program that converts from
one xTalk to another - once it is used it is no longer needed. As you said,
until such a time as you can apprecite the "persistent properties" (which is
really the result of a unified design+run mode), you would like a tool like
this. Which implies that once you "get there", you won't need it anymore.

I printed out your article and read it over in detail to see what I could
glean from your experience. Here's what I discovered:

1) Coming from a VB background, you naturally looked for a way to assign a
value to a property for an object. So much like in VB where you'd do:

  TextBox1.Text = "Hello World!"

I'm assuming you looked for a "text" property of a Rev field, found it, and
decided to test it:

  set the text of Field 1 to "Hello World!"

Which worked (of course). But it seems that without guidance, the whole
concept of "containers" (e.g. a field as a container for text data) was
missed, and the whole "put"/"get" approach was not explained. This is how it
is "normally" done:

  put "Hello World!" into field 1

Those who come from an xTalk background already have this under their belt,
but non-xTalk programmers do not.

POINT #1: RunRev needs to document better the container concept, along with
its "set the <property>" alternatives.

2) You assumed that there was the classic "design mode" and "run mode", and
so went off down the path of looking for a way to toggle between the two
(this was stated by me in an earlier post). But rather than discover that
there *aren't* two modes, you mistakenly assumed that the "browse tool mode"
is one mode and the "pointer tool mode" is the other mode. This is certainly
a very understandable mistake, as you pointed out  - you were looking for a
way to test your project and you found it. But that brings me to the next
point:

POINT #2: RunRev needs to explain clearly the "single mode with different
tools" approach, and not merely assume that everyone will "get it". In fact,
only xTalk programmers from other tools will "get it" - everyone else will
have to make a conceptual shift.

3) After migrating from MetaCard to Rev, you ran the same test and for some
reason couldn't find the browse tool in the tool palette. I'm curious - why
did this happen? MetaCard's tools were in the toolbar and Rev's were in a
palette, but it doesn't seem to me that there is that much of a cognitive
shift between the two. Is it because of the similarity to the move tool in
Photoshop?

You eventually went down the path of using the Application Browser to do
"Go" (which just displays the card you selected; the currently selected tool
doesn't change - which is why you thought nothing happened).

By choosing "Modeless", you invoked a mode that forced the stack window to
effectively close and reopen *as a dialog box*. Modal and modeless dialogs
automatically get the browse tool regardless of what is the currently active
tool.

POINT #3: RunRev needs to explain clearly how different stack modes change
the tool selection.

4) You hunted around and found the Property Inspector and used that to clear
the text of the field. You were unaware that you could use the browse tool
to click and select the text in the field and hit the delete key to remove
it (unless the field was locked through the 'lockText' property being set to
true, but I'm assuming that wasn't the case).

Once again a disconnect between modes - thinking in "two modes", it wouldn't
make any sense to wipe and delete the text, because as soon as you return to
"design mode", whatever changes you had made would be irrelevant (as they
are in VB). However thinking in "one mode", where the field's contents are
there regardless of tool chosen, it would make *perfect* sense to switch to
browse tool and wipe the text and delete it. Of course this wouldn't affect
the stack when it started up again unless you saved it first, but at this
point in the story, that is not the most important thing.

(see POINT #2)

5) You discovered that RunRev didn't have good drawing tools or
antialiasing. Yup... that about covers it. :-)

6) Instead of counting sheep, you repeated the mantra:

RUN - BROWSE TOOL - POINTING FINGER - MODELESS
STOP - SELECT CONTROLS - DIAGONAL ARROW - TOP LEVEL

Can I assume that now you know the mantra is:

  BROWSE TOOL - POINTING FINGER
  POINTER TOOL - DIAGONAL ARROE

And that there isn't really a "run" and "stop", and that the "modeless" and
"toplevel" are ways of displaying stacks and don't really correlate to
browse/pointer?

If not, let me know and I'll be happy to explain them. The reason why there
isn't really a "run" and "stop" is that even with the pointer tool selected,
scripts can still run. It's just that you usually can't *activate* most
handlers because they depend on the browse tool. For example, "mouseUp" is
one of those that depends on the browse tool - "mouseEnter" (the message
sent when the mouse enters the rectangle of the object) is activated
regardless of tool.

Try this:

- Create a button in Rev. Edit the script so it has this code:

on mouseUp
  beep
end mouseUp

on mouseEnter
  beep
end mouseEnter

Then switch to browse tool. As your mouse enters the button you will hear a
beep. Click the button and you'll hear another beep.

Then move the mouse out of the button area and switch to pointer tool. As
your mouse enters the button you will hear a beep. Click on the button and
the button will be selected, but will not beep.

So you see, there isn't a "mode" in Rev where NO scripts run. Scripts run
due to messages being sent to specific objects, and these messages get sent
all the time, *sometimes* dependent on what tool you have chosen. There are
methods to "lock messages" temporarily so that certain messages are
prevented from being sent, but there is no way to lock all the messages
forever (or until a specific action has taken place). The best that can be
done is to create a "frontscript" (I'll explain this later if you like) that
can trap and absorb all of these messages and not pass them through to other
stack objects.

POINT #4: RunRev needs to understand, document and make easily available a
set of instructions to guide programmers from other environments to being
able to understand how Rev is used. It can't just assume that everyone will
"get it", or will know where to find things in the docs or even *go* to the
online docs. After first time installation, it should not just bring up a
"tip of the day" window, but should provide a wizard that asks the user
their past experience and guides them to finding the right data in the docs.

Bob, the Rev documentation is really very good - most of the problems that
people have had with it are that sometimes the information is in a
non-intuitive place, or that an imporatnt concept is buried several levels
down and hard to get to. This is the exception and not the rule, though.

For example, when I opened the docs and clicked on "Welcome to Revolution",
the first thing that greeted me is "What describes you best?" with a list of
different places one could have come from. When I clicked on "experienced
traditional language programmer" there was a wealth of information on making
the conceptual shift between traditional languages and Rev.

So it's not that the information isn't *there*, it's just that it is not
where it needs to be, IMHO, for the beginning user.

Anyway, that's my take on things,

Ken Ray
Sons of Thunder Software
Web site: http://www.sonsothunder.com/
Email: kray at sonsothunder.com