[Newbie] Morhic UI building

karl.ramberg at chello.se karl.ramberg at chello.se
Fri Oct 15 20:10:32 UTC 2004


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

> Hi all 
> 
> I am planning to build a few utility applications for others in my
> workgroup to use.
> So I need a fairly standard looking UI one with normal data entry type
> widgets etc.
> 
> Questions:  
> 
> 1.  Should I use BobsUI? Is the leading contender in the GUI
> Construction tools?
> ( see http://minnow.cc.gatech.edu/squeak/1576 )

I have never used it but I think it is ok.

> -  I am a little concerned that not being able to incorporate ordinary
> Morphic objects will be an issue eg GraphMorph would come in handy in my
> projects.

I think you should be able to use other morphs as well. 

> 
> 2.  What is the status of the Pluggable* morphs?  Should these morphs be
> avoided for new work?  I recall reading (somewhere - cant find the
> reference) that the Pluggable* morphs are provided for backward
> compatibility with MVC.

Pluggable morphs are perfectly fine.
  
> 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..

Most common use is to use the app as model and the SystemWindow as a
view.
Unless your app is a morph, then you can wrap the morph in a window.

> 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.

This is probably the way you also want to do it. 
 
> 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 can use #on:send:to: 

> Or am I missing something obvious?
> 
> 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
> 
> 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.

Send it with subject line starting with [BUG][FIX] or [ENH] to the list,
and attach 
the change set gzipped.

Note that SystemWindows are special morphs and have several behaviors
that
make them behave more or less like a operating sytem window.

Karl



More information about the Squeak-dev mailing list