On 25 September 2010 09:34, Hannes Hirzel <hannes.hirzel at gmail.com> wrote:
> On 9/24/10, Sean P. DeNigris <sean at clipperadams.com> wrote:
>>
>>
>> Hannes Hirzel-2 wrote:
>>>
>>>> I tried (one of these felt very satisfying):
>>>> * Morph>>on:send:to:, which sounded good, but never got called
>>>> * intercepting Morph>>processEvent:using: (which I was told was not a
>>>> good
>>>> idea)
>>>> * (after seeking help), locking the submorphs and overriding the dozen or
>>>> so
>>>> event-related methods in the chain from my morph to TextMorphForShout
>>>> (the
>>>> Morph that actually handles the text and input).
>>>> * subclassing TextMorphForShout and then subclassing PluggableShoutMorph
>>>> to
>>>> use that subclass.
>>>
>>> Which method did you like best?
>>>
>>
>> Ha ha, should have been *none of these felt...*, but:
>
>> 1. The on:send:to: was what I /wanted/ to do, with the downside being that
>> it did nothing, lol.
>
>> 2. The intercept of Morph>>processEvent:using: was okay, but dangerous
>> because it's easy to lock the image when messing with this.
>
>> 3 & 4. Lock&Forward and SubclassItAll were both okay, but seemed very heavy
>> weight for listening in on one event.  IOW I may have gone that route
>> eventually if the behavior got complex, but didn't like being chained to it
>> for my simple case.
>>
>>
>> Hannes Hirzel-2 wrote:
>>>
>>> There are some notes on this issue at
>>> http://wiki.squeak.org/squeak/2477
>>> ( Eddie Cottongim writes: I know of three main ways to handle events
>>> in Morphic.......)
>>>
>> Yes, he mentions #1 and #4 and adds a fifth - your own EventHandler
>>
>>
>> Hannes Hirzel-2 wrote:
>>>
>>> Conclusion: It might be worthwile to find out more how Juan has pruned
>>> Morphic in Cuis and if it is still valuable for use, document that and
>>> put it to use in Squeak and Pharo.
>>>
>> Cool, I've started this as well.  Let's keep the list posted if we come up
>> with anything.
>>
>> Sean
>
>
>
>
>> p.s. #1 seems to be broken in Squeak and Pharo.  I'm going to start another
>> thread.
>
> Juan has in Cuis 2.6
>
> Morph
>
> on: eventName send: selector to: recipient
>
i saw such message pattern. Guess where?
Announcements! :)

announcer on: MyAnnouncement send: #foo to: bar

>        self flag: #jmv.
>        "Do NOT implement EventHandler in Morphic 3 or LightWidgets.
>        Even more. Try to avoid all the stuff in Morphic-OldEvents"
>
>        self eventHandler ifNil: [self eventHandler: EventHandler new].
>        self eventHandler on: eventName send: selector to: recipient
>
>
> So the best thing as of now would be to remove this in Squeak and
> Pharo so that the next people who analyze this do not loose time with
> it and can advance more with the things which work.....
>

The dichotomy here is , that Morph from one side acts as an event recipient,
but from another side, it acts as an events source for eventHandler.
(as far as i can tell, this is an intent of introducing EventHandler).

This could be managed in more gracious manner, by having a single
entry point for all events,
which coming to morph. Then you can write:

singleEntryPointForAllEvents: anEvent
   self eventHandler ifNotNil: [ ^ handler handleEvent: anEvent
fromMorph: self ].
   self handleEvent: anEvent

and get rid of repetituous code from all places, like:

keyStroke: anEvent
	"Handle a keystroke event.  The default response is to let my
eventHandler, if any, handle it."

	self eventHandler ifNotNil:
		[self eventHandler keyStroke: anEvent fromMorph: self].


> HJH
>
> _______________________________________________
> Pharo-project mailing list
> Pharo-project at lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>



-- 
Best regards,
Igor Stasenko AKA sig.