Is it Dolphin or Beachball :-)

As the Dolphin product line has matured the intial splash display has
changed from a fantastic undersea shot of a dolphin to a beachball in
various scenes.  After reading the Object-Arts discussion of the beachball
as being derived from the Byte cover story on Smalltalk where artist Tinney
portrayed it as leaving the ivory tower (ParcPlace) built on an island in a
sea of languages, one wonders about the details.  Did the balloon's fire
seal the open bottom, making it into a beachball?  Did the basket burn or
just fall -- maybe that explains why all the other languages adopted object
orientation -- the framework which powered the balloon got dispersed into
all of them.

 From my Bible studies, it seems important to explore such visions.  Perhaps
someone could have predicted the dispersion and the beachball washing up to
another island (England?) which the webpage calls Dolphin island.

Smalltalk vendors have often erred by placing their art above user needs.
Smalltalk-80 was so overpriced Digitalk was spawned. Adel's oft-touted "we
built it and they will come and develop killer apps for it" never happened.
IBM's slow entry came with an initially interesting but heavy overburded
visual front end excluding its applications from speed-demanding users.
First born Digitalk was cannibalized. Various other siblings started out but
a recent review shows even the free and slowest platform Squeak hasn't
progressed much lately. Dolphin seems to be fully taking over for Digitalk.
A minor developers choice in Dolphin causes me some concern.

The edit menu has been moved to a secondary position.  To an artist this may
be fully acceptable and defensible.  But to someone who plans to use Dolphin
as a programming platform, speed is important. Since any programmer more
often edits his program than executes it, it would save us all time if the
text edit menu were first as it is in the free version.  Is there a fix for
this in V.5?  Or is the beach-ball going to get undertowed by a Dolphin?

On Wed, 12 Jun 2002 11:16:35 -0700, "Kirk W. Fraser"
<[hidden email]> wrote:

>
>The edit menu has been moved to a secondary position.  To an artist this may
>be fully acceptable and defensible.  But to someone who plans to use Dolphin
>as a programming platform, speed is important. Since any programmer more
>often edits his program than executes it, it would save us all time if the
>text edit menu were first as it is in the free version.  Is there a fix for
>this in V.5?  Or is the beach-ball going to get undertowed by a Dolphin?
>

In my D5 the Edit menu is next to File when editing in CHB or a
workspace. Maybe you could clarify this?

Regards,

Costas

> In my D5 the Edit menu is next to File when editing in CHB or a
> workspace. Maybe you could clarify this?

Certianly:

In any text pane, a right click produces a menu which contains:
Edit     >

instead of:
copy
paste
etc...

As you can see it now takes one more click plus waiting for the secondary
menu plus one more mouse movement to accomplish anything that can't be done
adequately by dragging.  That takes about as much time as going up to use
the bar Edit menu you refer to.

Admitedly a trivial amount of time for an edit or two but for programmers
this adds up daily.  I was once in a project in one of Warren Buffet's
insurance companies where the project failed because the application written
in IBM Smalltalk was slower for the end user even though prettier than one
written in C.  For production oriented people speed rules.

"Kirk W. Fraser" <[hidden email]> wrote in message
news:9RON8.8442$[hidden email]... done
> adequately by dragging.  That takes about as much time as going up to use
> the bar Edit menu you refer to.
>...

It is where it is because the majority of people use the Cut, Copy, Paste,
etc, commands so frequently that they have learned the standard keyboard
accelerators for these (Ctrl+X, Ctrl+C, Ctrl+V, etc). These are much faster
(and less damaging to the human superstructure) than using the mouse,
particularly if one also uses the keyboard for performing most selections.
If, however, this is not to your taste, then you can just edit the views of
the SmalltalkWorkspace class - these are reused by the browsers so you'll
only need to edit a few. Using the WYSIWYG menu editor it is a trivial task
to reposition the commands in the context menu. It is also possible (in
Dolphin XP) to hook into the opening of the tools and programmatically alter
the menus (see the 'Dolphin IDE Extension Example' package), however this is
considerably more difficult.

Regards

Blair

Kirk,

> As you can see it now takes one more click plus waiting for the secondary
> menu plus one more mouse movement to accomplish anything that can't be
done
> adequately by dragging.  That takes about as much time as going up to use
> the bar Edit menu you refer to.

Easy enough to change though - the beauty of having an IDE that you can
tweak.  Evaluate the following in a workspace and you should have
cut/copy/paste on the top level of the context menu - for all the main
source views anyway.

Remember to save the image afterwards if you want to keep the changes.

#('Default view' 'Multiline text' 'Method source' 'Class comment')
    with: #(3 3 5 3)
    do: [:view :position |
        resourceIdentifier := ResourceIdentifier
            class: SmalltalkWorkspace
            name: view.
        resource := resourceIdentifier load.
        menu := resource contextMenu.
        menu insertItem: DividerMenuItem separator at: position.
        editMenu := menu find: 'Edit'.
        #('Paste' 'Copy' 'Cut') do: [:each |
            command := editMenu find: each.
            menu insertItem: command at: position].
        resourceIdentifier save: resource]

Regards
    Ian

Kirk W. Fraser <[hidden email]> wrote in message
news:dOMN8.8439$[hidden email]...
...
> The edit menu has been moved to a secondary position.  To an artist this
may
> be fully acceptable and defensible.  But to someone who plans to use
Dolphin
> as a programming platform, speed is important. Since any programmer more
> often edits his program than executes it, it would save us all time if the
> text edit menu were first as it is in the free version.  Is there a fix
for
> this in V.5?  Or is the beach-ball going to get undertowed by a Dolphin?
...

This was changed in Dolphin 4.0 I believe.  I understand your complaint, and
I did not like it myself, but not enough to complain about it.  I just
adapted to it. ;)  I suppose this was done to keep the size of the context
menu down.  I tend to use the hot keys (Ctrl-Insert etc...).  I imagine you
can change this by editing the resource, or using the new event (look at
OAIDEExtensions) that is triggered when views open to change it.

I have developed a code completion and lookup tool that helps me to cut and
paste less.  If all goes well I may be releasing it to the public latter
tonight.

Chris