[Q] [Morphic] SystemWindow

tblanchard at mac.com tblanchard at mac.com
Mon Mar 10 00:53:43 UTC 2003


On Sunday, March 9, 2003, at 04:43  PM, Andreas Raab wrote:

> A word of advise: As always, before you start hacking classes that are 
> used
> throughout the system, make a COPY and hack this copy.

yes, thanks, I've learned this the hard way. :-)

> Also, Morphs should actually be rather robust in this area - 
> #fullBounds
> contains an error handler which will fix up its bounds if a problem is
> encountered in the layout process before passing the error.

Yeah, but this doesn't do anything for detecting infinite recursion - 
which is really quite easy to induce I think.

> Therefore,
> unless you hack any of the existing layout managers this should be 
> pretty
> robust.

Well, I was trying to write a new layout manager - but looking at the 
two existing ones didn't really give me a clue as to exactly what I was 
supposed to do with my new bounds that I calculated.

The various bounds aren't too easy to figure out either.  fullBounds, 
outerBounds, layoutBounds, innerBounds, bounds.  Holy cow.  I figured 
out that layoutInset doesn't seem to be used anywhere but TileMorph and 
nuked it. For the added complexity, I think we could do something 
special with TileMorph if you want a 1 pixel horizontal margin.  Like 
use the struts and springs layout and initialize it with a 1 pixel 
strut on either side and a springy middle.

In reference to Stef's message - if you were to do Morphic all over 
again - what would you change?


> Cheers,
>   - Andreas
>
>> -----Original Message-----
>> From: squeak-dev-bounces at lists.squeakfoundation.org
>> [mailto:squeak-dev-bounces at lists.squeakfoundation.org] On
>> Behalf Of tblanchard at mac.com
>> Sent: Saturday, March 08, 2003 7:06 PM
>> To: The general-purpose Squeak developers list
>> Subject: Re: [Q] [Morphic] SystemWindow
>>
>>
>> FWIW,  I've been working on ProtoMorph, trying to get a new
>> base Morph
>> class that is more straightforward to use.  The number one "issue" I
>> run into when trying to build composite morphs is layout.  It is my
>> opinion that the current layout schemes are a little too
>> "tense" - IOW
>> they execute too much code that sometimes conflicts and this
>> makes them
>> unpredictable.
>>
>> I am making slow progress getting a ProtoMorph that can be composed
>> using a struts and springs scheme like you find in NextStep.
>>
>> I've completely given up on trying to fix Morph itself as it is
>> *FRAGILE* and making little changes in it frequently results in a
>> frozen system (as does trying to write new layout managers).
>>
>> My plan is to get ProtoMorph working properly including doing struts
>> and springs layout, then start reimplementing many of our popular
>> morphs on top of ProtoMorph rather than Morph.  When SystemWindow is
>> done, it should be really easy to make a new tool with conventional
>> resizing behavior.
>>
>> I just thought I'd mention what I'm doing in case anyone else is
>> thinking about tackling the same issue.
>>
>> On Saturday, March 8, 2003, at 07:03  AM, Chris Burkert wrote:
>>
>>> Hello Squeakers
>>>
>>> I want to build a nice SystemWindow for my application. The
>> problem is
>>> resizing. For example take a Package Browser and resize it
>> as small as
>>> possible. There will be Morphs displayed outside the SystemWindow.
>>>
>>>
>>>
>>>
>>> My code with the same problem would look like this (a DoIt should
>>> work):
>>>
>>> | window playfield bar |
>>> bar _ (RectangleMorph new) width: 500.
>>> window _ (SystemWindow labelled: 'my App').
>>> playfield _ (RectangleMorph new)
>>> 	layoutPolicy:		TableLayout new;
>>> 	hResizing:		#spaceFill;
>>> 	vResizing:		#spaceFill.
>>> playfield addMorph: bar.
>>> window
>>> 	addMorph: playfield fullFrame: (LayoutFrame fractions:
>> (0 at 0 corner:
>>> 1 at 1) offsets: (0 at 0 corner: 0 at 0));
>>> 	openInWorld.
>>>
>>>
>>>
>>>
>>> So I tried the following:
>>>
>>> | window playfield bar |
>>> bar _ (RectangleMorph new) width: 500.
>>> window _ (SystemWindow labelled: 'my App')
>>> 	layoutPolicy:		TableLayout new;
>>> 	hResizing:		#shrinkWrap;
>>> 	vResizing:		#shrinkWrap.
>>> playfield _ (RectangleMorph new)
>>> 	layoutPolicy:		TableLayout new;
>>> 	hResizing:		#spaceFill;
>>> 	vResizing:		#spaceFill.
>>> playfield addMorph: bar.
>>> window
>>> 	addMorphBack: playfield;
>>> 	openInWorld.
>>>
>>>
>>>
>>>
>>> Now the Titelbar and some colors are displayed completely
>> wrong _but_
>>> it resizes correct. I believe this is a problem with Alignment. Is
>>> there a way around so that the window displays itself
>> correct _and_ it
>>> resizes to #shrinkWrap?
>>>
>>> Should SystemWindow be refactored so that it supports the
>> newer layout
>>> Policies?
>>>
>>> thanks
>>>            Chris Burkert
>>> --  
>>>
>> --------------------------------------------------------------
>> ---------
>>> -
>>> Student of applied Computer Science at Chemnitz University of
>>> Technology
>>>      http://www.chrisburkert.de/            chris at chrisburkert.de
>>>
>> --------------------------------------------------------------
>> ---------
>>> -
>>> "I invented the term Object-Oriented, and I can tell you I
>> did not have
>>>  C++ in mind." - Alan Kay --> http://www.whysmalltalk.com/
>>>
>>>
>>
>>
>
>



More information about the Squeak-dev mailing list