August 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] An idea about visual feedback in Athens

by StÃ©phane Ducasse

how much would you think your idea would cost? Stef On Aug 31, 2012, at 8:19 PM, Igor Stasenko wrote: > so, > the problem is that all you see on screen consists from shapes, which > are drawn by Athens. > Now, since drawings can be quite complex and include various transformations, > it will be hard to track them manually to use for mouse (or fat > finger) pointer hits. > > A simplest example: > i wanna draw a rectangle, rotated by 45 degrees. > and i wanna change it's color when mouse is over it. > > If you look at the situation from global coordinate system > perspective, in order to find whether some morph contains given point > or not, > you have to iterate over all it's parent morphs (because they also can > have coordinate system transformations). > > But in a local coordinate system, things remain extremely simple: to > test whether a point is inside of rectangle (most morphs usually is) > is a piece of cake, isnt? > > I think i found an interesting approach for a coordinate system > feedback, (so it can be used for 'hit tests' as well as many other > things) > > So, lets consider a simple draw method: > > Morph>>drawOnAthensCanvas: aCanvas > aCanvas > setPaint: Color red; > drawShape: self bounds > > now if we add a single line here: > > self registerShapeForEvents: self bounds canvas: aCanvas. > > Things getting very interesting: > > what this method should do, is to simply capture enough state from > current canvas (like transformation matrix, clipping > and the shape , of course), so later it can be used to test whether > some point (like mouse cursor position) is over it or not. > > Why in drawing method , you might ask? Where else, i would answer.. A > parent morphs branch can impose own clipping and transformation, > which you can easily observe during drawing, but it becomes tedious > once you leave outside of it: > to get same amount of information you'll have to manually go over all > morph's hierarchy and apply same transformation/clipping calculations > once you get to the morph under the question. > > The drawing method responsible for visual representation of morph on > display media, which means that it actually defines the shape(s) with > which users will interact. > > So, by drawing a bunch of morphs on desktop using such approach, we > can automatically capture all the geometry (as well as its relative > hierarchy), which needs to be tested for mouse hits (or receiving a > mouse events in general). > And the hit test , which we need to perform every mouse move, boils > down to simply iterating over that hierarchical list and testing the > current hand position against each element. > > The morphs, which are not interested in receiving a mouse events (like > hidden or parent morphs of various kinds), apparently can simply avoid > publishing anything into that list, > instead of implementing numerous #handlesMouseDown/#handlesMouseOver etcc... > and like that saving cycles for being tested every time you touching > the mouse, because some of their submorphs are actually interested in > receiving such events. > > And of course a most interesting aspect of this approach is handling a > complex geometry for morphs. > Because with rectangles it is fairly simple to imagine a visual > feedback system which based solely on morph's bounds (like the one > which we currently using), but for morphs with complex geometry, > things can become quite tedious. > > -- > Best regards, > Igor Stasenko. >

Aug. 31, 2012

Re: [Pharo-project] Pharo 2.0 + Travis = ?

by Igor Stasenko

On 31 August 2012 20:03, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Frank Shearar-3 wrote >> >>> 'asdasd' asFileReference writeStreamDo: [:s | >>> s nextPutAll: 'baz' ] >> > > First rule of filesystem... write something beautiful and it will probably > work... > 'path' asFileReference ensureFile ... pick a stream... > well, i was unsure if the intent was to create a file if it not exists. And reading from 0-sized file, you just created, don't looks like a good idea either. > -- > View this message in context: http://forum.world.st/Pharo-2-0-Travis-tp4645663p4645783.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > -- Best regards, Igor Stasenko.

Aug. 31, 2012

[Pharo-project] An idea about visual feedback in Athens

by Igor Stasenko

so, the problem is that all you see on screen consists from shapes, which are drawn by Athens. Now, since drawings can be quite complex and include various transformations, it will be hard to track them manually to use for mouse (or fat finger) pointer hits. A simplest example: i wanna draw a rectangle, rotated by 45 degrees. and i wanna change it's color when mouse is over it. If you look at the situation from global coordinate system perspective, in order to find whether some morph contains given point or not, you have to iterate over all it's parent morphs (because they also can have coordinate system transformations). But in a local coordinate system, things remain extremely simple: to test whether a point is inside of rectangle (most morphs usually is) is a piece of cake, isnt? I think i found an interesting approach for a coordinate system feedback, (so it can be used for 'hit tests' as well as many other things) So, lets consider a simple draw method: Morph>>drawOnAthensCanvas: aCanvas aCanvas setPaint: Color red; drawShape: self bounds now if we add a single line here: self registerShapeForEvents: self bounds canvas: aCanvas. Things getting very interesting: what this method should do, is to simply capture enough state from current canvas (like transformation matrix, clipping and the shape , of course), so later it can be used to test whether some point (like mouse cursor position) is over it or not. Why in drawing method , you might ask? Where else, i would answer.. A parent morphs branch can impose own clipping and transformation, which you can easily observe during drawing, but it becomes tedious once you leave outside of it: to get same amount of information you'll have to manually go over all morph's hierarchy and apply same transformation/clipping calculations once you get to the morph under the question. The drawing method responsible for visual representation of morph on display media, which means that it actually defines the shape(s) with which users will interact. So, by drawing a bunch of morphs on desktop using such approach, we can automatically capture all the geometry (as well as its relative hierarchy), which needs to be tested for mouse hits (or receiving a mouse events in general). And the hit test , which we need to perform every mouse move, boils down to simply iterating over that hierarchical list and testing the current hand position against each element. The morphs, which are not interested in receiving a mouse events (like hidden or parent morphs of various kinds), apparently can simply avoid publishing anything into that list, instead of implementing numerous #handlesMouseDown/#handlesMouseOver etcc... and like that saving cycles for being tested every time you touching the mouse, because some of their submorphs are actually interested in receiving such events. And of course a most interesting aspect of this approach is handling a complex geometry for morphs. Because with rectangles it is fairly simple to imagine a visual feedback system which based solely on morph's bounds (like the one which we currently using), but for morphs with complex geometry, things can become quite tedious. -- Best regards, Igor Stasenko.

Aug. 31, 2012

Re: [Pharo-project] Pharo 2.0 + Travis = ?

by Frank Shearar

On 31 August 2012 19:03, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Frank Shearar-3 wrote >> >>> 'asdasd' asFileReference writeStreamDo: [:s | >>> s nextPutAll: 'baz' ] >> > > First rule of filesystem... write something beautiful and it will probably > work... > 'path' asFileReference ensureFile ... pick a stream... Now _that_ looks like what I was looking for! Thanks! At any rate, it turns out Dale's all over the issue, and resolved everything (but I've not tested it yet :) ): https://github.com/dalehenrich/builderCI/commit/7ce30ca1b78f9c3f34977614f14… frank

Aug. 31, 2012

Re: [Pharo-project] Pharo 2.0 + Travis = ?

by Frank Shearar

On 31 August 2012 18:55, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>> >> >> Sure. And maybe I would have, if I didn't first have to get a Pharo >> 2.0 image and then install it and then figure out the various new APIs >> and so on and so on. So instead I wimped out and asked a clear >> question in a place where the experts on the relevant APIs would have >> a chance to see it :P > > :) > >>>> and the relevant code (I think) is >>>> >>>> transcriptStream := ((Smalltalk at: #FileSystem) workingDirectory >>>> / transcriptFileName) readStream >>>> >>> so, why you don't just wrap this thing with exception handler? >>> >>> [ transcriptStream := ((Smalltalk at: #FileSystem) >>> workingDirectory / transcriptFileName) readStream >>> >>> ] on: Error do: [ aha... somethign wrong with that file ] >>> >>> this will prevent image from bailing out to OS. :) >> >> Well, no. Catching Error is a terrible idea. I'll just touch the file >> if it doesn't already exist. >> >> Thanks for taking the trouble to answer the question, Igor. If it's >> any consolation, this means Dale & I can get our CI stuff working for >> Pharo 2.0 that must quicker. > > Pay attention that 2.0 is bleeding edge for real. > We will take some action this week to improve the situation. I understand :) In this particular case it's probably just unfamiliarity on my part. I know, at least, that my Control library works in both Pharo 1.4 and 2.0, and while ContextPart's left alone I shouldn't need to touch code much to keep it working. It's just the CI part that's currently broken, again, probably because I haven't bothered reading the documentation properly yet :) frank > Stef > >

Aug. 31, 2012

Re: [Pharo-project] Pharo 2.0 + Travis = ?

by Sean P. DeNigris

Frank Shearar-3 wrote > >> 'asdasd' asFileReference writeStreamDo: [:s | >> s nextPutAll: 'baz' ] > First rule of filesystem... write something beautiful and it will probably work... 'path' asFileReference ensureFile ... pick a stream... -- View this message in context: http://forum.world.st/Pharo-2-0-Travis-tp4645663p4645783.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Aug. 31, 2012

Re: [Pharo-project] Pharo 2.0 + Travis = ?

by StÃ©phane Ducasse

>> > > Sure. And maybe I would have, if I didn't first have to get a Pharo > 2.0 image and then install it and then figure out the various new APIs > and so on and so on. So instead I wimped out and asked a clear > question in a place where the experts on the relevant APIs would have > a chance to see it :P :) >>> and the relevant code (I think) is >>> >>> transcriptStream := ((Smalltalk at: #FileSystem) workingDirectory >>> / transcriptFileName) readStream >>> >> so, why you don't just wrap this thing with exception handler? >> >> [ transcriptStream := ((Smalltalk at: #FileSystem) >> workingDirectory / transcriptFileName) readStream >> >> ] on: Error do: [ aha... somethign wrong with that file ] >> >> this will prevent image from bailing out to OS. :) > > Well, no. Catching Error is a terrible idea. I'll just touch the file > if it doesn't already exist. > > Thanks for taking the trouble to answer the question, Igor. If it's > any consolation, this means Dale & I can get our CI stuff working for > Pharo 2.0 that must quicker. Pay attention that 2.0 is bleeding edge for real. We will take some action this week to improve the situation. Stef

Aug. 31, 2012

Re: [Pharo-project] Gaucho? (was Re: Breaking another dependency to Compiler (related to Traits I think))

by StÃ©phane Ducasse

> > Fernando, > > Just curious, are there more news besides this > http://www.inf.usi.ch/phd/olivero/gaucho/home.html > and your 2010 ESUG presentation? > > I assume Gaucho is part of your PhD disserationâ¦ gaucho now works on top of athens and the event model changes we introduce. Stef

Aug. 31, 2012

Re: [Pharo-project] Pharo 2.0 + Travis = ?

by Frank Shearar

On 31 August 2012 17:23, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 31 August 2012 18:00, Frank Shearar <frank.shearar(a)gmail.com> wrote: >> On 31 August 2012 16:43, Igor Stasenko <siguctua(a)gmail.com> wrote: >>> On 31 August 2012 08:10, Frank Shearar <frank.shearar(a)gmail.com> wrote: >>>> On 31 August 2012 05:04, Dale Henrichs <dhenrich(a)vmware.com> wrote: >>>>> Frank, >>>>> >>>>> I'll try to get the Pharo-2.0 build for builderCI working soon ... >>>> >>>> I _think_ it'll be as simple as figuring out how to say "open this >>>> file, creating it first if necessary" in FileSystem-speak. I realise >>>> you've not done Metacello+Pharo2 yet, and asked on list hoping that >>>> one of the FS folk would pipe up with something :) >>>> >>> >>> 'asdasd' asFileReference writeStreamDo: [:s | >>> s nextPutAll: 'baz' ] >> >> But for reading? My debug output's here: >> >> http://travis-ci.org/#!/frankshearar/Control/jobs/2288671 >> > reading non-existent file? > > you know, you can always test if file exists before trying to open it. I had mentioned that in the original mail. > ref := 'asdasd' asFileReference. > (ref exists and: [ ref isFile and: [ ref isReadable ]]) ifTrue: [ ref > readStream ....] > > i never used FS before.. so to post the code above, i vent to system browser, > and read some method names in FileReference class. > This is something what you can do by yourself, isn't? :) Sure. And maybe I would have, if I didn't first have to get a Pharo 2.0 image and then install it and then figure out the various new APIs and so on and so on. So instead I wimped out and asked a clear question in a place where the experts on the relevant APIs would have a chance to see it :P >> and the relevant code (I think) is >> >> transcriptStream := ((Smalltalk at: #FileSystem) workingDirectory >> / transcriptFileName) readStream >> > so, why you don't just wrap this thing with exception handler? > > [ transcriptStream := ((Smalltalk at: #FileSystem) > workingDirectory / transcriptFileName) readStream > > ] on: Error do: [ aha... somethign wrong with that file ] > > this will prevent image from bailing out to OS. :) Well, no. Catching Error is a terrible idea. I'll just touch the file if it doesn't already exist. Thanks for taking the trouble to answer the question, Igor. If it's any consolation, this means Dale & I can get our CI stuff working for Pharo 2.0 that must quicker. frank >> where transcriptFileName = 'TravisTranscript.txt'. >> >> The "old style" file handling works, and says this: >> >> transcriptStream := fileDirectoryClass default newFileNamed: >> transcriptFileName >> >> frank >> >>>> frank >>>> >>>>> Dale >>>>> >>>>> ----- Original Message ----- >>>>> | From: "Frank Shearar" <frank.shearar(a)gmail.com> >>>>> | To: "Pharo Development" <pharo-project(a)lists.gforge.inria.fr> >>>>> | Cc: "Dale Henrichs" <dhenrich(a)vmware.com> >>>>> | Sent: Thursday, August 30, 2012 1:52:37 PM >>>>> | Subject: Pharo 2.0 + Travis = ? >>>>> | >>>>> | Hi Dale, >>>>> | >>>>> | I'm getting a build failure against Pharo 2.0 [1] with the error >>>>> | "FileDoesNotExist: >>>>> | /home/travis/dalehenrich-builderCI-cd2facd/builds/travisCI/TravisTranscript.txt". >>>>> | >>>>> | I think that's because the before.st says "transcriptStream := >>>>> | ((Smalltalk at: #FileSystem) workingDirectory / transcriptFileName) >>>>> | readStream ]" and that file doesn't exist. >>>>> | >>>>> | Is there a convenient way of saying "please open a readStream on this >>>>> | file and, if it's not there, make one" ? >>>>> | >>>>> | (If one semi-replicates the build, by opening a Pharo 2.0 image, >>>>> | manually loading the ConfigurationOfControl, and running >>>>> | "ConfigurationOfControl loadDevelopment", one will see Control >>>>> | 1.1.dev >>>>> | running with a green light for Pharo 2.0!) >>>>> | >>>>> | frank >>>>> | >>>>> | [1] http://travis-ci.org/#!/frankshearar/Control/jobs/2282004 >>>>> | >>>> >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko. >>> >> > > > > -- > Best regards, > Igor Stasenko. >

Aug. 31, 2012

Re: [Pharo-project] Pharo 2.0 + Travis = ?

by Igor Stasenko

And.. basic rule of thumb for headless mode: if you don't want image to leave to OS, put an exception handler around your code. Because in headless mode , an UnhandledException by default quits to OS (logging an error before that, of course) -- Best regards, Igor Stasenko.

Aug. 31, 2012