<div id="__MailbirdStyleContent" style="font-size: 10pt;font-family: Arial;color: #000000">
                                        
                                        
                                            
                                        
                                        
                                        Hi Tim,<div><br></div><div>if I recall correctly, we removed several minimal-window-size hacks in Squeak 5.1 when fixing several layouting bugs back then. Even in Squeak 4.4, minimal window sizes did not work properly:</div><div><br></div><div><img src="cid:173ea80a-9b13-4080-bdfa-d46b7519f185" width="auto"></img></div><div><br></div><div>So, there has neven been a working solution for a window's minimum size. Only trade-offs. :-) Yes, the current below-minimum effects seem somewhat worse:</div><div><br></div><div><img src="cid:f8ae6eff-3a16-40a1-8383-d4abbc9ef50c" width="auto"></img></div><div><br></div><div>However, this is still no easy fix. Even in Squeak 4.4, there was no code to correctly compute the minimum window size given a ProportionalLayout or TableLayout and *any* supported cell configuration.</div><div><br></div><div>I think this behavior is rarely noticed. I did some experiments together with Smart Splitters and introducing a "preferred size" to morphs. I think I can re-examine those soon to also make minimum window sizes work properly.</div><div><br></div><div>Best,</div><div>Marcel</div><div class="mb_sig"></div>
                                        
                                        <blockquote class="history_container" type="cite" style="border-left-style: solid;border-width: 1px;margin-top: 20px;margin-left: 0px;padding-left: 10px;min-width: 500px">
                        <p style="color: #AAAAAA; margin-top: 10px;">Am 17.07.2019 07:18:54 schrieb Tim Johnson <digit@sonic.net>:</p><div style="font-family:Arial,Helvetica,sans-serif">Hi all,<br><br>Really, really surprised I've never noticed this before, but I've seen it now on Squeak 5.2 and Squeak 5.3 trunk.  32-bit and 64-bit. <br><br>You can resize a Morphic system window, using the top resize border bar, far past the bottom border of the window.  MVC behaves somewhat differently, but probably in a way that will shed light on the problem.<br><br>It is at its worst (most visible) when preference #fastWindowDragForMorphic is disabled.  When that preference is enabled, one is disallowed from dragging past the bottom border of the window.  But still, the notion that a window has a minimum size seems to be gone...?<br><br>How to reproduce: <br>Open up a Workspace window.  Drag the top resize bar downward past the bottom border of the window.  Watch what happens.  Try it again with a different setting for preference #fastWindowDragForMorphic.  Try again in an MVC project or a Morphic project.<br><br>Doesn't happen on e.g. version 4.4.<br><br><br>Cheers,<br>Tim J<br><br><br><br>Image<br>-----<br>/Users/tcj/Downloads/Squeak5.3alpha-18661-64bit/Squeak5.3alpha-18661-64bit.image<br>Squeak5.3alpha<br>latest update: #18661<br>Current Change Set: Unnamed1<br>Image format 68021 (64 bit)<br><br>Virtual Machine<br>---------------<br>/Applications/Squeak/Squeak 64-bit 20190711.app/Contents/MacOS/Squeak<br>Croquet Closure Cog[Spur] VM [CoInterpreterPrimitives VMMaker.oscog-eem.2530] 5.0.201907112020<br>Mac OS X built on Jul 16 2019 21:59:46 PDT Compiler: 4.2.1 Compatible Apple LLVM 9.1.0 (clang-902.0.39.2)<br>platform sources revision VM: 201907112020 tcj@oxyd:src/opensmalltalk-vm Date: Thu Jul 11 13:20:10 2019 CommitHash: 1ea727fe2 Plugins: 201907112020 tcj@oxyd:src/opensmalltalk-vm<br>CoInterpreter VMMaker.oscog-eem.2530 uuid: 4d90ede0-0700-4d15-8173-2aaf2360b7d1 Jul 16 2019<br>StackToRegisterMappingCogit VMMaker.oscog-eem.2521 uuid: 4f1618e4-2a0c-4ba8-be03-b8670286ba00 Jul 16 2019<br><br><br><br></div></blockquote></div>