[UI] ToolBuilder

[Igor Stasenko]

On 12/09/2007, Jason Johnson <jason.johnson.081 at gmail.com> wrote:
> On 9/12/07, tim Rowledge <tim at rowledge.org> wrote:
> > The problem with 'decorators' or wrappers is that they need to
> > implement all the methods of anything that they will wrap in order to
> > pass them on to the internal component. You could, of course, try to
> > handle this by (ab)using doesNotUnderstand but the performance cost
> > would be nasty. I think. Anyone got time to implement and time a test
> > harness?
>
Hmm.. i thought that decorations was exactly to avoid that?
Suppose window having a frame as decoration. Since we interesting in
operating with a window at first place in our model domain, we care
less about it's frame decoration, title e.t.c which can be set while
initializing and then handle some genereic UI events like
resizing/moving.

And what you describing is not what i had in mind.
A wrapper or 'decoration' morph don't need to delegate anything to
wrapped morph, because its not on top in message hierarchy.
And its not visible to any morph outside decoration chain.

For example:

World have submorph textMorph.

textMorph have decoration ScrollPane.
ScrollPane have decoration SystemWindow.
Finally SystemWindow have decoration = nil.

At this point i have textMorph (most interesting morph object) on top
of hierarchy and have direct access to its interface (so no delegation
ever needed). A decoration chain can consist of any number of morphs
and they referenced only by text morph and not visible outside.

A drawing order can be easily changed like:

drawOn: aCanvas
  self decoration ifNotNil: [ self decoration drawOn: aCanvas ].
  self drawOnCanvas: aCanvas.

or:

fullBounds
^ self decoration ifNil: [ fullBounds ] ifNotNil: [ decoration fullBounds ].

> Well, I was hoping that if we start from ground up we will end up with
> components that don't have such incredibly wide interfaces.
>
> Failing that, we don't have to pay the price of DNU, we can have the
> DNU handler just create a forwarding method for any methods that
> actually get called.
>
> Another possibility is that perhaps there is another way around this.
> For example, in our new framework how will these View classes be used?
>  If they have to register for any UI events they deal with then then
> decorator just registers himself for the events he decorates and the
> decorated class for all others.
>
> Totally hypothetical example:
>
> MySpecialScrollyTextBox>>register
>
>   World allPossibleEvents do: [:event|
>     (self decoratedEvents includes: event)
>       ifTrue: [ World on: event send: event to: self ]
>       ifFalse: [ World on: event send: event to: decoratee ] ]

An event handling with decorations can be done simply through forwarding
like:

handlesEvent: anEvent
^ (self handleMyself: anEvent) or: [ decoration handlesEvent: anEvent ].

or, if we prefer to handle event by decoration morph , then change order.

> _______________________________________________
> UI mailing list
> UI at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/mailman/listinfo/ui
>


-- 
Best regards,
Igor Stasenko AKA sig.