----- Original Message ----

> From: Andreas Raab 
> Markus Lampert wrote:
> > OK, the way I changed minExtentFrom: is that it multiplies the minExtent of a 
> morph with the fraction allocated by the frame. CodeHolder>>buildCodePaneWith: 
> sets the frame for the button row to '(0 at 0 corner: 1 at 0.11)' which is about a 
> tenth of the overall hight.
> 
> I must be missing something here. How exactly are the minimum extent and a 
> layout frame's fraction related? I would think that the min extent is entirely 
> unrelated to the fraction of a layout frame. I'm not really certain what the 
> intended effect of the changes is.

When you drag the proportional splitter, lets say a horizontal one up and down, the splitter checks how far it can be dragged by looking at the next parallel splitter in that direction. Originally the splitter added (or subtracted) an offset of 75. So if you would drag the splitter as far up as it goes it would stop 75 pixels below the next higher splitter (or the window boundary).

In order to increase the code pane size in any browser I always had to move the splitter for the 'instance/?/class' button pane up first. Given the splitter bounds calculation described above I ended up with buttons of a (minimum) height of 75 pixels. The changes I made replaced the fixed 75 pixel margins with the minimum height of the morphs inbetween. In the case of a button pane the minimum height is 20. Thereby not wasting any screen real estate but still ensuring that all submorphs can be displayed properly.

This works as desired as long as you don't make the whole window smaller ...

Have fun,
Markus


> 
> Cheers,
>   - Andreas
> 
> > The minimum height for the button row is 20 leading to a minimum height of the 
> code pane of almost 200. Which is used by the ProportionalSplitterMorph to 
> calculate its bounds...
> > 
> > Additional bonus: If the system window is made small enough it becomes 
> impossible for the ProportionalSplitterMorph to honour the minExtent of any of 
> it's adjecent morphs.
> > 
> > I see 2 options:
> >   1) Restrict the minimum size a system window can be reduced to
> >   2) Revert most of my changes and let the user decide on what they want to 
> see.
> > 
> > 
> > I lean towards 2) because it will probably show the 'least surprise' behaviour 
> and be more deterministic. If you let me know the preferred implementation I'll 
> make the changes.
> > 
> > Have fun,
> > Markus
> > 
> > 
> > 
> > ----- Original Message ----
> >> From: Markus Lampert
> >> To: The general-purpose Squeak developers list 
> 
> >> 
> >> Played a long time with it until I could reproduce it. Resizing the whole 
> browser window (making it smaller) leads to horrible sizing problems. 
> Interestingly it works fine with the default layout, only if the splitters have 
> been moved beforehand things become ugly (literally).
> >> 
> >> So this is probably an issue on smaller screens.
> >> 
> >> Will look into it, but it will take a few days.
> >> 
> >> Have fun,
> >> Markus
> >> 
> >> 
> >> 
> >> 
> >> ----- Original Message ----
> >>> From: Andreas Raab To: The general-purpose Squeak developers list Sent: 
> Sunday, September 27, 2009 6:52:25 PM
> >>> Subject: [squeak-dev] Re: Problem with ProportionalSplitters
> >>> 
> >>> Are you fully updated? I am unable to recreate the problem here.
> >>> 
> >>> Cheers,
> >>>   - Andreas
> >>> 
> >>> Robert Krahn wrote:
> >>>> Hi,
> >>>> 
> >>>> In the recent trunk version the browser is screwed up if one tries to 
> resize 
> >>> the code pane with its splitter (see below).
> >>>> Robert
> >>>> 
> >>>> 
> >>>> ------------------------------------------------------------------------
> >>>> 
> >>>> 
> >>>> 
> >>>> On Aug 17, 2009, at 12:29 AM, Alexander Lazarević wrote:
> >>>> 
> >>>>> Hi!
> >>>>> 
> >>>>> I guess not too many use ProportionalSplitters to change the layout of
> >>>>> windows these days, but they are broken in the latest trunk image.
> >>>>> This is because the Method containingWindow in Morph has changed. The
> >>>>> containing Window is now searched based on the model of the component,
> >>>>> but ProportionalSplitters do have no model.
> >>>>> A quick fix is to look up the owner chain of a ProportionalSplitter to
> >>>>> find an owner that has a model. Most of the time (always?) the owner
> >>>>> will be the containing window, so I don't know if the ifFalse: Branch
> >>>>> is needed.
> >>>>> I will publish this fix so ProportionalSplitters should work again
> >>>>> until someone with better insights has a better solution.
> >>>>> 
> >>>>> Alex
> >>>>> 
> >>>> 
> >>>> ------------------------------------------------------------------------
> >>>> 
> >>>> 
> > 
> > 
> > 
> >      
> >