Since no one responded to this (unless you got some private email), I
thought I'd throw in a few thoughts.  I don't have any clear cut answers,
though.

I don't know if it's possible to fool Morphic into thinking that a
ScrollPane's submorphs are only the things inside the scroller.  What
about the ScrollBar morph?  It's still a submorph of ScrollPane which
needs to be drawn, etc, but it's definitely not inside the scroller.

The submorphs/owner concept in Morphic seems a little different than the
contents/container concept in the VisualWorks ScrollWrapper.  In Morphic,
everything that's drawn needs to be a submorph, whereas in VW the
"contents" are more specific, such as the stuff inside a scroll region.

I guess one answer is to somehow merge the ScrollBar class into
ScrollPane, so that the ScrollBar is no longer a submorph?  Or maybe make
your own new merged class, but leave the old ScrollPane alone?  (Hmm,
would the Transform functionality need to be merged too?) 

Or maybe you could continue on as you are, overriding the problem methods
which have references to the submorphs instvar.

In any case, a working PluggableScrollMorph widget which you could plop
any morph into would be *extremely* useful, definitely worthy of inclusion
in the base image.  So don't give up yet. :-)

- Doug Way
  EAI/Transom Technogies, Ann Arbor, MI
  dway at eai.com, dway at mat.net
  http://www.transom.com


On Sat, 26 Jun 1999, David Farber wrote:

> Dan,
> i've built a subclass of ScrollPane called PluggableScrollMorph that takes
> any ol' morph to be displayed inside the scroll region. in doing this,
> however, i've run across a snag. i've described the problem below. i have
> also attached the changes i have made to ScrollPane. if i am on the wrong
> track, the please set me to rights. if not, i'd like to submit my changes to
> be included in the next set of updates.
> 
> when i first starting playing around with ScrollPane morphs, i thought that
> adding a morph to the scrollable region would be as simple as something like:
> 
>   ScrollPane new
>     addMorph: (EllipseMorph new extent: 50 at 300);
>     openInWorld
> 
> while playing around with Morphic and trying to get familiar with everything
> i discovered that i could do the same thing interactively in a Morphic
> Project by:
> 
>   World->new morph...->Basic->EllipseMorph
>   EllipseMorph->resize
>   World->new morphs...->Windows->ScrollPane
>   drag EllipseMorhp on top of ScrollPane
>   EllipseMorph->embed... ScrollPane
> 
> both of these give me the same thing: a result other than the one i was
> hoping for--the EllipseMorph sits on top of the scroll pane, not inside the
> scroll region.
> 
> when building the ScollPane interactively, i noticed that when i went to
> embed the EllipseMorph inside the ScollPane i could choose to embed it
> inside some unnamed TransformMorph and i was closer to the result i wanted.
> rummaging through source code in the image i found that the programmatic
> equivalent was to ask the ScollPane for its scroller and put the
> EllipseMorph there.
> 
>   | pane |
>   pane := ScrollPane new.
>   pane scroller addMorph: (EllipseMorph new extent: 50 at 300).
>   pane openInWorld
> 
> well, there was two problems with this. number one, i didn't like it. it
> seemed like a violation of encapsulation to know that you needed to ask for
> scroller to add your morph to. number two, when you add your morph to the
> scroller, the ScrollPane doesn't know to update itself, so the scollbar
> doesn't adjust itself.
> 
> so, i "fixed" both of these problems by rewriting addMorph: in ScrollPane to
> add new morphs to the scroller and then update itself. (i also had to make
> changes to initialize.)
> 
> and it was Good.
> 
> until, in the course of building PluggableScrollMorph i realized that maybe
> it wasn't as easy as that. now that the submorphs are all inside the
> scroller, i see that i'll need to rewrite quite a few methods that get
> inherited. the first one i came across was replaceSubmorph:by:, but it looks
> like there are quite a few more. in addition, there are quite a few methods
> (200+) in the Morph heirarchy that reference the submorphs instance variable
> directly; these should probably get the collection of submorphs by calling
> an accessor method that can be overridden for container objects like
> ScrollPane.
> 
> so, i'm not quite sure if i am on the right track. let me know what you think.
> 
> david
> 
> At 09:44 PM 6/21/99 -0700, you wrote:
> >Folks -
> >
> >You may have noticed Squeak Central laying low through the last couple of
> mail storms.  It's not that we're not interested, it's just that we have
> been busy.
> >
> >We have made some progress in integrating balloon with morphic, integrating
> 3D with morphic, and integrating normal programming with scripting and
> viewers.  Also a unification of WorldMorphs with PasteUpMorphs so that any
> world or pasteUp can be written out to a SqueakPage, and then read in as a
> world, a pasteUp, or the page of a book.  Also some steps toward better
> modularity, such as being able to atomically assert/revert changes when
> entering/leaving a project.  And some fun new stuff in music that lets you
> enter melodies from a keyboard into a score, and then copy and paste them
> and play the results, as well as some tweaks that make it easier to play
> with looped sampled sounds.
> >
> >It's my hope to assemble all of this into a new image some time next week,
> but it might take a bit longer as several of the changes touch a lot of
> code.  We have lots of updates to put out, and I will probably release a
> spate of them toward the end of the week.
> >
> >A number of interesting enhancements and bug fixes have been put forward
> from this mailing list.  Please let me know privately of anything you feel
> deserves special consideration for inclusion in the main line release.
> >
> >In case you wonder, everyone here resonates with the desire to spruce up
> Squeak.org, and to clarify our mission a bit in the process, but we probably
> won't take any real action until we have put out the next release.
> >
> >Walk tall and talk Small
> >
> >	- Dan
> >
> >
> >
>