Andreas Raab wrote:
> 
> > Hmm, flop-out scrollbars on the right works for me, at least
> > in 3.2gamma.  But anyway, I guess Simon's original changeset
> > had the "self owner comeToFront" because the class list (2nd
> > from left) pane in a Browser is embedded in an
> > AlignmentMorph, which caused the flopout-scrollbar-on-right
> > to be partly obscured... so the AlignmentMorph needs to
> > comeToFront too.  But most of the time the owner is the
> > SystemWindow, which we don't want coming to the front...
> 
> Oh dude, I gotcha! You mean it's the ordering of lists in a browser that
> make us change scrollpane????

Yep!

> Why not just fixing this problem in the
> place where it occurs, namely in the system windows?! E.g., something
> like:
> 
>         SystemWindow>>addMorph: aMorph fullFrame: aFrame
>                 "... all the other stuff before ..."
>                 Preferences scrollBarsOnRight
>                         ifTrue:[self addMorphFront: aMorph]
>                         ifFalse:[self addMorphBack: aMorph].
> 
> ought to work just nicely.

Yes, that's probably the best, safest fix for now (along with reverting the ScrollbarOnRight change)... that should fix the problem Tim was seeing.

On the other hand, you could argue that it's reasonable for a ScrollPane to become the frontmost morph when it needs to display its flop-out scrollbar, so that the scrollbar isn't stuck behind something else.  It's better in a lot of ways than having to worry about which order to put scrollpanes in a window (such as a Browser).  (I had to do some extra work in Whisker to make sure the panes were in the right order so that the flop-out scrollbars would work.)

If you do the ScrollPane/frontmost thing, the trick is figuring out exactly what it should be in front of, which I guess could get hairy.  You want to to be in front of other fellow morphs inside its parent composite morph (often a SystemWindow), but you don't want it to pop up over totally unrelated morphs (such as other windows).

Also, it seems a bit shady that AlignmentMorph (newColumn) changes the meaning of comeToFront/goBehind submorph-ordering so that it really orders things vertically instead of front-to-back.  Although I guess this indicates that maybe comeToFront/goBehind are really only intended to be used by freestanding morphs/windows in a PasteUpMorph.

Hmmm... given that, maybe we should just stick with Andreas' fix above. :)

- Doug Way
  dway at riskmetrics.com