Thanks, Igor

Two questions.

1) I have not been following closely the Pharo development. Does Pharo
rely mainly on Announcements (Event objects) for Morphic GUI code
these days?

MCHttpRepository location:
'http://source.lukas-renggli.ch/announcements' user: '' password: ''

2) I found
How Morphic processes events
   http://wiki.squeak.org/squeak/118
written by Andreas Raab in 2003

Could somebody have a quick look at it and tell me if this still more
or less applies to the current Squeak and Pharo implementations?

Where do I find a description how Pharo handles Morphic events these days?

--Hannes


On 9/25/10, Igor Stasenko <siguctua at gmail.com> wrote:
> 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.
>
>