Hmm, well, while I agree with many points and disagree with many points, I’m not going to trawl through each one - too long.
What I will say is that I think the Minority Report interface is cool looking (as everyone does) but that it would be horrible to use. We already have better. The problem is that we are coders and want that sort of ease-of-use in our code from an API but that the API has to provide the lowest level of access and allow us to create our own interface gestures.
Standard UI elements provide gestures which are simple and sensible, but we’re working with very non-standard elements which do not necessarily fit any set of rules save those we create ourselves.
My answer to the previous comment by @krystian6 is the code below, but your comment, @dmccuskey, got me thinking about the setFocus function itself.
Here’s the code answer I mention.
[lua]-- multitouchtest
– enable multi-touch
system.activate(‘multitouch’)
– reference for easier use
stage = display.getCurrentStage()
– the image to handle multiple touches - http://www.coronalabs.com/images/slides/community_1010x400_v2.jpg
local image = display.newImage( “community.jpg” )
image.class = “image”
image.x, image.y = display.contentCenterX, display.contentCenterY
– manipulate the image based on touch point information
function image:manipulate()
local sx, x, sy, y, c = 0, 0, 0
– sum the touch points
for i=1, stage.numChildren do
local point = stage[i]
if (point.class == “track”) then
c = c + 1
sx = sx + point.start.x
x = x + point.start.x
sy = sy + point.start.y
y = y + point.y
end
end
– apply the manipulation
– not going to put code here because it will appear messy.
end
– function to create multiple touch tracking points
– this function handles the began event, the inner function handles the other events (moved, ended, cancelled)
function createPoint( startEvent )
– create a new tracking point, name it and set focus onto it
local point = display.newCircle( startEvent.x, startEvent.y, 50 )
point.class = “track”
point.alpha = .4
stage:setFocus( point, startEvent.id )
– record the start position of this touch point
point.start = startEvent
– create a function to handle the other event phases
function point:touch( event )
if (event.phase == “moved”) then
– manipulate the image
image:manipulate()
else – this will be the ended or cancelled phase
point:removeEventListener( “touch”, point )
point:removeSelf()
end
– indicate that the point handled the event
return true
end
point:addEventListener( “touch”, point )
– the return true for the began event
return true
end
– use runtime to captue initial touches
Runtime:addEventListener( “touch”, createPoint )[/lua]
I was going to implement something cool in the image function, but that would just make the code messy and appear more complex than it is. Pinch-zoom-rotate is a complex function and it would be great to have that sort of gesture built in. I believe that level of gesture recognition needs a lot of wrapping and, in our environment, will not and should not be provided by Corona but Apple, as the hardware interface vendor.
In short: There are so many ways to interact with the screen and we, as developers, want all of them and the ability to create new ones. There is a natural conflict there. It’s the same with creating Widgets. Either you define your own interaction model or you limit yourself to what is provided.
Attempting not to ramble: What if we define setFocus ourselves?..
[I am a big believer in not simply whinging about new functionality but demonstrating that it can and should be implemented a certain way. ie: Show Corona Labs how to do it a good way and they may well implement something better.]
If we define a setFocus which then does what we’ve talked about already - pretending to handle multiple touches for a single object - we could give the impression of increased control.
The problem I find here is that we would also need to redefine the function parameters. The current parameters, in a multitouch environment, allow for one nil argument to remove the current single touch ID. The question about attaching more touches is to use the same format function as we have. The question about removing individual touches by ID is more complex. What should the parameters be? I would suggest:
[lua]-- adds touches upon each other to a single display object
– passing a nil eventId removes all touches from the display object
function setFocus( dispObj, eventId )
– passing an eventId removes an individual touch from the object
– passing a nil eventId is the same as calling setFocus( dispObj, nil )
function unsetFocus( dispObj, eventId )[/lua]
So now, the problem is how to limit the number of touches which can be received by the display object in question. The original setFocus blocks subsequant user touches on the object - do we want the same functionality after, say, a maximum of 5 touches? I would say no and that our touch event handler would simply pass the touch event down by returning false.
A remaining question would be this: Would having the current setFocus function allow ‘return false’ to pass touch events down, instead of blocking (as it currently does) and appearing to be a return true, also be a requirement? This, to me, is a bug - intended or not - but the only actual bug. [import]uid: 8271 topic_id: 27893 reply_id: 113011[/import]
