Morphic

> Writing libraries and reusable components is a different project.
>
>> - the license is BSD, so the code can't be included in Pharo/Squeak
>
> I googled for
>    BSD MIT license compatibility
>
> and found some interesting information
>
> see for example
> http://www.dwheeler.com/essays/floss-license-slide.html
>
> the paragraph about BSD in
> http://producingoss.com/en/license-choosing.html
>
> The license might be compatible depending on the "version" of the BSD
> license. And if not you could extract code and then ask the developers
> to release it as MIT.
>
> MIT and BSD are very close (or the same depending on the version)
>
> To summarize: The statement
>
> "the license is BSD, so the code can't be included in Pharo/Squeak"
>
> is too strong. There might be some problems including code, but they
> may be solved easily with by writing a few emails....

> On Thu, 23 Sep 2010, Hannes Hirzel wrote:
>
>>>
>>> Why can't we have stuff from Sophie back to Squeak/Pharo?
>>> - only the Sophie developers are familiar with the code and they are not
>>> motivated enough to extract it
>>
>> Not necessarily their task.....  :-)
>
> That's right, but tell me who else is up to the task?
>
>> Writing libraries and reusable components is a different project.
>>
>>> - the license is BSD, so the code can't be included in Pharo/Squeak
>>
>> I googled for
>>    BSD MIT license compatibility
>>
>> and found some interesting information
>>
>> see for example
>> http://www.dwheeler.com/essays/floss-license-slide.html
>>
>> the paragraph about BSD in
>> http://producingoss.com/en/license-choosing.html
>>
>> The license might be compatible depending on the "version" of the BSD
>> license. And if not you could extract code and then ask the developers
>> to release it as MIT.
>>
>> MIT and BSD are very close (or the same depending on the version)
>>
>> To summarize: The statement
>>
>> "the license is BSD, so the code can't be included in Pharo/Squeak"
>>
>> is too strong. There might be some problems including code, but they
>> may be solved easily with by writing a few emails....
>
> The license is the 3-clause BSD license, it contains the following
> non-endorsement clause:
>
> "Neither the name of the University of Southern California, Los Angeles
> nor the names of its contributors may be used to endorse or promote
> products derived from this software without specific prior written
> permission."

>
> Levente
>
>>
>>
>> --Hannes
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

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

> 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

> On 9/24/10, Sean P. DeNigris <[hidden email]> 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
>

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

> On 25 September 2010 09:34, Hannes Hirzel <[hidden email]> wrote:
>> On 9/24/10, Sean P. DeNigris <[hidden email]> 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
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
>

> 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 <[hidden email]> wrote:
>> On 25 September 2010 09:34, Hannes Hirzel <[hidden email]> wrote:
>>> On 9/24/10, Sean P. DeNigris <[hidden email]> 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
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>>
>>
>>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>>
>>
>
>

> 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