On 25 September 2010 10:41, Hannes Hirzel <hannes.hirzel at gmail.com> wrote:
> 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?
>
No.
Its just my observation, that some parts of it look almost exactly as
in announcements.
Yes, and Announcements was born later than Morphic.

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

They are almost the same. This problem with Morphic, for any
entry-level developer,
that its a huge code base, and it sparsely documented.
So, it is really hard to make conclusions about what model it using
and what might break,
if you change/remove some code.


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



-- 
Best regards,
Igor Stasenko AKA sig.