"Stow, Edward" <EStow at csu.edu.au> wrote:


> Questions:  

> 2.  What is the status of the Pluggable* morphs?  Should these
> morphs be avoided for new work?
I am not aware of plans to remove these morphs from
coming versions of Squeak.

> I recall reading (somewhere - cant find the reference) that the
> Pluggable* morphs are provided for backward compatibility
> with MVC.
Yes, that is true. The pluggable morphs are protocol compatible
to the pluggable views. Some models (e.g. Browser) use
that compatibility to support both the Morphic and the
MVC interface. 

> 3.  I started with SystemWindow morph for the application
> frames.   Are there standard idioms for building the interface 
> with StandardWindow or other morphs as a base.

> The options seem to be : 

> 3.1 Subclass StandardWindow -- MyAppWindow. 
> This was my first choice, esp. coming from 
> VisualWorks - subclass ApplicationModel..
I think this should read *SystemWindow*
There are in fact some applications that are 
implemented as subclasses of SystemWindow.
ArchiveViewer is a very understandable example.


> 3.2  Create Subclass of StringHolder.  Eg Inspector
> classes.  An instance of the SystemWindow is created
> and nearly all contain Pluggable* morphs that have the
> subclass (eg the Inspector) as a model.
> (See question 2)

> This is the most common approach.  But it does seem
> to rely upon the Pluggable classes for most of the work.

StringHolder is really legacy code from MVC.
In principle, StringHolder is the preferred model
of a StringHolderView, nothing more. In practice,
it can also be used as a model for a PluggableTextView.

StringHolder has many subclasses. All these
are models for windows that have one text edit field
(usually an instance of PluggableTextView) and
some additional views (often instances of
PluggableListView).
StringHolder is not a good starting point for
an application that does not need text editing
facilities or that has to implement support for many
text editing fields. 
 
The protocol of StringHolder includes a lot of
methods that are needed for various code browsers.
Most of these methods should be moved to
subclasses, look at the comment of CodeHolder
(also a subclass of StringHolder) 

3.3 You should also consider the option to define your
application as a subclass of  Model. A quick look into the
image shows that Model has a lot of subclasses, most of
them applications, some even applications that do not
have an MVC interface. (e.g. PDA, which uses 
PDAMorph, a subclass of SystemWindow, as its
window.  PDAMorph adds only stepping, which is
needed for the clock
To try this app, evaluate  PDAMorph new openInWorld) 

> 4.  Event dependency mechanism ---  #triggerEvent,
> #when:send:to: etc are these the standard mechanism
> for the observer pattern.  There are only 3 senders of 
> #triggerEvent: in the standard 3.6 image.  

You use 
   on: <event-symbol>
   send: <message-selector>
   to: <interested-instance>
to tell a morph that it should propagate the events
with name  <event-symbol>

> Or am I missing something obvious?
How can I know? :-)
Note that a model sends change methods that a morph
may handle in its update:,  methods. This is *not* 
obvious, but it is the way a model communicates
with its dependents.
Examine the instance protocol of PDA to see
how change notification works.


>5.  SystemWindow does not appear to respond to
> #position: and #extent: prior to opening the window.  Eg

   w _ SystemWindow labelled: 'Test'.
   w position: 50 at 50.
   w openInWorld

Try this:

 | w |
  w_ SystemWindow labelled: 'Test'.
   w bounds: (20 @120 extent: 300 @ 250).
   w openAsIs

Alternatively, you can do this:

  | w |
   w _ SystemWindow labelled: 'Test'.
   w fullBounds; position: 150 at 250.
   w openAsIs

The difficult question is to decide whether or not these
idioms are tricks. 

> This was very confusing trying to see why this morph
> behaves differently from other morphs.  The answer
> is SystemWindow>>#openInWorld:extent:
> resets the extent for the window.


>I would consider the change in behaviour for #position: and extent: to
>be bugs -  I have a fix -  for almost all cases.   How do I feed that
>suggestion back into group for consideration.

Have a look at
http://minnow.cc.gatech.edu/squeak/1385
http://minnow.cc.gatech.edu/squeak/1962

Hope that helps
Boris