Doug,

> The attached changeset should fix the problem Andreas 
> mentions.  Hopefully it also fixes Tim's problem, I'm not 
> sure. (see below)

No it doesn't ;-)

> (Ooh, I bet Tim's problem is not fixed, because the vertical 
> ordering is based on which morph is frontmost, or something?)

Yes, exactly.

> The attached changeset changes this second-to-last line to:
> 
> 			(self owner notNil and: [self owner 
> isAlignmentMorph])
> 				ifTrue: [self owner comeToFront]]
> 
> Perhaps a bit ugly, but not horrible. :-\

Ahem ... but then again, what's the point in it?! Now we figure we don't
want it for non-alignments, next we figure that we don't want it for
alignments, so we don't want it at all, do we?! Go figure ;-)

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

Cheers,
  - Andreas