[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
|