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