Morphic
Locked
12
12
Re: AW: [squeak-dev] Morphic
 
|
> At least > one good-looking mono-spaced font would be great. :) + 1 Stef |
|
Administrator
|
In reply to this post by Chris Muller-3
Thanks Chris, I got it to work now. Tracing (in panes) is the default in Pharo, and thus was the "thing that doesn't capture the model for me" that I want to improve on ;-) I appreciate that it may be great for many people and I'm exploring the ultimate visual expression of this model. Sean
Cheers,
Sean |
|
Administrator
|
In reply to this post by Hannes Hirzel
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. Yes, he mentions #1 and #4 and adds a fifth - your own EventHandler 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.
Cheers,
Sean |
Re: AW: [squeak-dev] Morphic
|
Administrator
|
In reply to this post by marcel.taeumel (old)
Yes, saving a composite morph (probably by subclassing) that has been dragged together visually is on my list ( actually doesn't seem that hard, but maybe I'm naive :) ). Sean
Cheers,
Sean |
Re: [Pharo-project] [squeak-dev] Morphic
|
|
In reply to this post by Hannes Hirzel
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..... HJH |
Re: [Pharo-project] [squeak-dev] Morphic
|
|
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 > 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. |
Re: [Pharo-project] [squeak-dev] Morphic
|
|
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 <[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. > > |
|
|
On 25.09.2010, at 09:41, Hannes Hirzel wrote:
> 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? I think this is still how it works in Squeak. However, it is not quite complete, because it stops at "Finally, the user-level handler (#mouseDown:) is invoked." It goes on from there: The default implementation (Morph>>mouseDown:) actually triggers the registered event handler. This is what makes #on:send:to: work. However, many subclasses implement #mouseDown: thus breaking that mechanism (which admittedly was introduced later). - Bert - |
Re: [Pharo-project] [squeak-dev] Morphic
|
|
In reply to this post by Hannes Hirzel
On 25 September 2010 10:41, Hannes Hirzel <[hidden email]> 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 <[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. >> >> > > -- Best regards, Igor Stasenko AKA sig. |
Re: [Pharo-project] [squeak-dev] Morphic
|
|
In reply to this post by Hannes Hirzel
[This answer went to the Pharo list but not the Squeak list, so I send
it a second time]. On 9/24/10, Sean P. DeNigris <[hidden email]> wrote: > 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 Yes, for a start, here are some very simple metrics. --Hannes metrics ^HelpTopic title: 'Metrics' contents: ' http://www.squeak.org/ Squeak 4.1 Morph allSubclasses size 323 http://ftp.squeak.org/trunk/ Squeak4.2-alpha-10382 Morph allSubclasses size 330 Squeak4.2-alpha-10548 Morph allSubclasses size 330 http://pharo-project.org/pharo-download/release-1-1 Pharo 1.1 Morph allSubclasses size 282 http://www.jvuletich.org/Cuis/Index.html (Description) http://www.jvuletich.org/Cuis (Download) Cuis 2.7 Morph allSubclasses size 57 Cuis 2.6 Morph allSubclasses size 56 ' -------------------------------------------------------------------------------------------------------------------- The form is a page of a help book which you get when you do for example CustomHelp subclass: #NotesOnMorphicByHannesHirzel instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'Morphic-Help' |
Re: [Pharo-project] [squeak-dev] Morphic
|
|
On 27.09.2010, at 12:28, Hannes Hirzel wrote:
> http://www.squeak.org/ > Squeak 4.1 > Morph allSubclasses size > 323 Etoys 4.0 Morph allSubclasses size 486 (difference mainly from Connectors, Games, Media, Collaboration, Kedama) http://www.squeakland.org/ Etoys 4.1 Morph allSubclasses size 508 (22 of the new morphs come from DrGeo, and one for the new Speech Bubbles) - Bert - |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |