Tap Event - Included in a future release?

Mells · December 2013

Hi,

I was wondering if Tap (and Double, Triple Tap) Events would be included in a future version of Gideros?

Back in May 2012
@atilim said :

Currently we don't support but I've added it to the roadmap:

As Atilim said there are different ways to interpret how double tap events should be handled but I believe that would be great if it could be included with default settings (delay to accept taps, area).

Consecutive taps should be near to each other (e.g. 20-30 pixels) and the delay between them should be small.

Is that still part of the roadmap?

thanks

ar2rsawseen · December 2013

The idea is/was to create a lua wrapper above current input events to provide tap gestures.
Think its possible.
What type of tap gestures are there?

Tap,
Double Tap,
Triple Tap,
Long Tap
anything else?

Mells · December 2013

Well if we abstract a few other things I would say that swipeUp/Down/Left/Right would be great...
And I don't know if that would be too abstract but from a designer's point of view I would love a "onDragStart", "onDragMove", "onDragEnd". There might be a few differences with "onTouchBegin/Moves/End" I think.

Is that part of the future future future items on the roadmap or already a work in progress?

ar2rsawseen · December 2013

Swipes are possible, but drag start could really depend on your UI.
As in from wrapper code I can't actually know if you are dragging something or not. But the idea is interesting. Maybe there should be dragging api

Mells · December 2013

Maybe

... and is that part of the future future future future items on the roadmap or already a work in progress?

eezing · December 2013

Here's a quick and dirty solution for consecutive taps if you need one.

I find it fun to make specific actions like this myself. This is the kind of stuff that'll make you a better coder.

 
local lapse = 0.2
local dist = 50
 
local count
local stamp
local x
local y
 
local function onTouchesBegin(event)
 
	if stamp and stamp > (os.timer() - lapse) then
 
		if x and y and math.abs(x - event.touch.x) < dist and math.abs(y - event.touch.y) < dist then
			count = ( count or 1 ) + 1
			stage:dispatchEvent(event.new("Tap" .. count))
		else
			count = nil
		end
	else
		count = nil
	end
 
	stamp = os.timer()
	x = event.touch.x
	y = event.touch.y
end
 
local function onTap(event)
 
	print("Tap event: " .. count)
end
 
stage:addEventListener(Event.TOUCHES_BEGIN, onTouchesBegin, event)
stage:addEventListener("Tap2", onTap, event)
stage:addEventListener("Tap3", onTap, event)
stage:addEventListener("Tap4", onTap, event)

ar2rsawseen · December 2013

officially, there are no projects like this internally for now, sorry

amaximov · December 2013

I've always liked how committed the Gideros team is to to stability over new buggy features as compared to the Beer SDK team. I would love to see Gideros keep focusing on core engine features and leave implementations like this up to developers to share with the community. Gideros Studio provides us with EVERYTHING needed to implement our own screen interaction mechanisms, and thus I think it would be a waste of human resources asking Gideros team to do these trivial things for us developers. Sorry if I came off a bit arrogant there, but those are my 2 cents

Mells · December 2013

@amaximov

Sorry if I came off a bit arrogant there

You don't

But I maintain my point that I'd like to see it included in the future and there is no problem in asking the team.

I think it would be a waste of human resources asking Gideros team to do these trivial things for us developers

I take it the opposite way : the solution is to increase human resources (from scarcity to abundance mindset).

Maybe the Gideros user base is not made of developers only.
If you find it trivial, then I'm really glad for you though

@eezing has been very kind to share his library but it will remain stored on the forum, with a few others here and there. How does a user know if it's maintained? If it works well enough? Where are the docs? etc... (not talking about your own lib specifically, @eezing)

Gideros Studio provides us with EVERYTHING needed to implement our own screen interaction mechanisms

So every new user has to invest time in recreating his own mechanism.

I believe not all users want to reinvent the wheel and I'd rather use one library that has been reviewed by a few devs from the community than try xx libs shared on the forums, just because I'm not able to get which is the best choice and where to get started.
You see my point?

There is no collaboration between devs to maintain one library so I'd rather ask the team directly.

Anyway I believe the team knows well what they want to work on or not.

@ar2rsawseen
ideally pinch in, pinch out would be great. But I'm not making a feature request, just adding to the beginning of the conversation.

@eezing thanks

eezing · December 2013

@Mells
I think you do make a point. I also agree with @amaximov about leaving the trivial stuff to the community.

During the windows CDROM days, I was scripting installers using an open source installer library (NSIS). The MediaWiki site the users contributed to was extremely valuable. Much of the code in my installers was from that wiki... no doubt it made my life a lot easier.

Gideros isn't open source, but a community managed centralized location to store code, libraries and tutorials isn't a bad idea. It would help us users get projects done a little quicker and free up the Gideros Development team to focus on the important stuff.

Of course, something like this would require quite a bit of time and effort from a select few individuals from the community to get going.

ar2rsawseen · December 2013

There is a provided way:
http://giderosmobile.com/tools
Anyone with Gideros account in website can add tools and manage them there (from your Account menu -> Manage Tools)

It's still under development, but usable and will take all suggestions to improve it into consideration

keszegh · December 2013

btw this looks like spam:
http://giderosmobile.com/tools/classic-cartoon

kredor7 · December 2013

Maybe a bunch of pages could be set up on www.giderosmobile.com/DevCenter/index.php/Main_Page or set up another wiki and anyone (maybe just forum members or subscribers) can post any useful code snippets for common things that might be wanted by new developers.

Although there is a forum section for this its a bit of a mess to search through it all instead of just viewing a list or categories.

As with the tools (mentioned above) section this is good however it doesn't really allow others to build on it eg bug fixes on another member's code or posting a faster version etc.

Mells · December 2013

But let's be honest : it takes time to provide a library, and it takes a leader to manage the collaboration and everything like a project with rules, assignments, etc...
This is why in my mind the only way to see something happen is if it's added by the team.

If they say "no, we are not working on it" then 99% of the time it will never happen other way.

I'm not saying that user contributions are worthless, I have found amazing things shared on the forums and I try to contribute with my own skills.
And Ideally I love the idea of everyone sharing but it rarely works and once the initial motivation spike is over, the project becomes dead. Unless someone really takes the project under his wing. No project manager = idea that fails.

Even though I love the idea of seeing more features in Gideros, I also know that a library that abstracts everything from the user could attract more people who might use Kwiksher instead, for example.

Only Gideros team can know if it's worth more :
- attracting devs who know how to take advantage of the latest features and have the willingness to pay for it
- vs attract users who are looking for a tool to achieve something they have in mind (ex : make a storybook app).

Today we are still early adopters so we are kind of interested at how things work, but soon users will be "normal" people who are looking for tools.
I don't care how a car works and what's the engine inside, I want to take my kids to school and know I won't have trouble with it and that we are safe with it (wait, I don't have kids).

I don't want to "create my own blur effects in opengl2", I want to have available (or pay) for a blur filter.
My time is worth much more than what the team would ask me to pay for it.
Let's say I have no experience and spend 2 hours writing a blur filter vs you ask me $20 for a ready to use/supported filter.

You know what? 2 hours of my time is worth much more than $20.
I don't want to go through a "trial and error" time, that's too much pain and frustration. I want to get things done.
That's ok to do it for fun, as a learning project, but if you mean business then every minute spent costs you money (that most of us don't have).

So that's my point. I want to use tools, not create those tools.
And I believe (even though I want to fight that idea) that community generated libs and projects are bound to fail

Hence, the idea of asking directly the team.

eezing · December 2013

@Mells
Yea, a community driven site would require some form of management, but if structured as a wiki, maybe not too much.

I personally would rather have the Gideros team working on things like LuaJit and OpenGL 2.0 and leave the trivial junk to us.

Mells · December 2013

Agree agree.

But last thing can we please stop using the word "trivial"?
Trivial for a developer who has the ability and willingness to invest his time in doing it maybe.
I feel like an idiot that everyone here reminds me that "hey it's trivial you should be able to do it."
Even if it's not what you mean, that's what I hear. And I'm not trying to have an argument, it's just that this word keeps popping up in the conversation.

Myself, I wouldn't feel comfortable saying marketing is "trivial" while most of the people here don't even have the slightest idea about what it is really. But hey, I know how to do it so that's trivial.
Some people want to learn, some people want to apply. And maybe that's good to consider both sides. I get that people using that word didn't have bad intentions though.

Also, the fact that providing access to tap/double tap/triple tap/pinch in and out events hasn't been done after 2 years of Gideros being in business (or 3?), and that no group of experienced devs has stepped in to say "ok we take care of that!" maybe proves that it's not such a trivial thing.
I understand there are priorities, but want to emphasize that if that was such an easy task that would have been created as a weekend project already. A long time ago.

I can not do it myself and I know it takes time. I could do an ok job, but that's not enough.
Indeed I can not ask a member of the community to do it for me, and unfortunately I don't believe in community generated projects (=never shipped, or even started).
I believe in individual projects (like Arturs with GiderosCodingEasy, Andy with BHWax, etc). But the hardest thing in that case is to maintain the lib.
So I'm kind of stuck.

When I read "leave the trivial junk to us." I can not stop wondering "who is us?".
As far as I know, there is no collective effort to provide most of the stuff that the team can not work on (the trivial things) :

- There is no list of "what would be good in Gideros" so that people could pick items in the list, and say "ok let's work together on that feature because anyway we're gonna need it for our next app".

- There are no guidelines so that those libs could fit the Gideros way of doing things and be easy to plug and play or integrate to the core later.

- Also, most of the features are asked by users with technical skills who want more features to display or increase those technical skills.
Asking a more diversified panel of users (i.e content producers who don't necessarily have a technical background) what would be great to see in Gideros might be a good idea.

- Why not having the guidance from someone at Gideros to review libs that are submitted and adapt them to Gideros

My point is that if those trivial things were abstracted (and taken to completion by anyone who wants to do it) Gideros would attract more content providers/producers.

For instance I can see the benefit of OpenGL 2.0 (and I really expect those features) but in some way I'm still curious to see how many people will actually use it to its potential (more than technical demos) and how devs will actually use it to create better apps.

At some point, the technical barrier to entry will disappear and we will have to focus on content anyway.

ar2rsawseen · December 2013

I think that what guys actually mean, is that, it is much easier to implement tap event handling for the specific situation that your app requires, rather then preparing the general tap event lib to cover most of the needed situations.
Because the latter one, will be really complicated.
Thats basically why there are no generic libs for such gesture events

ar2rsawseen · December 2013

Just added GestureEventEasy.lua to GiderosCodingEasy as my take on these Gesture events.
As usually exclude it from execution and require inside init.lua

And usage looks like this:

--set up test image
local bmp = Bitmap.new(Texture.new("ball.png", true))
bmp:setScale(4)
stage:addChild(bmp)
 
--tap events
bmp:addEventListener(Event.SINGLE_TAP, function(e)
	print("single tap with "..e.touchCount.." touches")
end)
 
bmp:addEventListener(Event.DOUBLE_TAP, function(e)
	print("double tap with "..e.touchCount.." touches")
end)
 
bmp:addEventListener(Event.TRIPLE_TAP, function(e)
	print("triple tap with "..e.touchCount.." touches")
end)
 
bmp:addEventListener(Event.LONG_TAP, function(e)
	print("long tap with "..e.touchCount.." touches")
end)
 
--swipe events
bmp:addEventListener(Event.SWIPE_DOWN, function(e)
	print("swipe down with distance: ", e.swipeDistance)
end)
bmp:addEventListener(Event.SWIPE_UP, function(e)
	print("swipe up with distance: ", e.swipeDistance)
end)
bmp:addEventListener(Event.SWIPE_LEFT, function(e)
	print("swipe left with distance: ", e.swipeDistance)
end)
bmp:addEventListener(Event.SWIPE_RIGHT, function(e)
	print("swipe right with distance: ", e.swipeDistance)
end)
 
--enable dragging
--bmp:setDragging(true)
 
--drag events
bmp:addEventListener(Event.DRAG_START, function(e)
	print("drag start")
end)
 
bmp:addEventListener(Event.DRAG_MOVE, function(e)
	print("drag move")
end)
 
bmp:addEventListener(Event.DRAG_END, function(e)
	print("drag end")
end)

ar2rsawseen · December 2013

The behavior of some events can be negotiable, it was just my approach and can be modified

Mells · December 2013

@ar2rsawseen you always come up with solutions.
Gideros team bringing you on board was one of the best move of this year 2013

Howdy, Stranger!

Categories

In this Discussion

Top Posters

Tap Event - Included in a future release?

Comments

Howdy, Stranger!

Quick Links

Categories

In this Discussion

Top Posters

Tap Event - Included in a future release?

Comments