Consider the scenario where a user touches the screen, holding the first finger down. The user then taps the screen sequentially in two separate locations with a second finger. I want to respond to this as three independent taps, and all I really care about are the initial tap locations.
I have tried using touchstart, but I can't figure out how to not reuse the first touch. If I look for changes in the length of event.touches, I don't pick up the second (final) tap.
Can someone suggest a strategy for responding to each touch individually? I am guessing it is quite simple, but I can't quite figure it out.
If you're using JQuery or Zepto JQTouch is a good plugin that wraps up touch events nicely for you. If you're interested in doing this at a lower level, you could always take a look at how they've done it.
Related
I am currently busy with an assignment (using P5.JS) that involves using the webcam as user input to trigger sounds. This works by creating a grid across the camera input and using color differencing to detect whether there is movement in a specific grid block. If there is movement, the grid block is "activated", which triggers something visual on screen. I have linked each grid block to a monosynth note, and when the grid block is activated, the corresponding monosynth note plays. However, when I run it, I get a scratchy and unpleasant sound, which I assume is because monosynth is trying to play many different notes simultaneously. Is there a way I can limit it only to playing one note at a time?
https://p5js.org/reference/#/p5.MonoSynth
In the above link, I see there is a "duration" argument for the .play method function. Is there a way that I can wait for that duration to finish before allowing it to play another note? Or perhaps a method function that checks whether the Monosynth is currently playing something or not, and then use that in an if statement before using the .play method.
Any advice would be appreciated.
PS: for plagiarism reasons, I can't share any of my code online.
The MonoSynth example on the documentation page does not exhibit a "scratchy and unpleasant sound" even if you hit the tap to play button as quickly as you possibly can.
Since the monosynth literally is a single oscillator and a single envelope, there is no way it could play multiple sounds at once (and start clipping).
Since we can't see your code, I have to rely on my crystal ball with this guess: Are you possibly instantiating a new monosynth whenever you start playing a note instead of telling a single monosynth to change up its pitch? That would explain it.
I did some research on this topic here, on the GoJS documentation site, etc., but I am not able to find anything coming even near to what I want.
Here's the thing: I have a diagram written in GoJS. As the data behind it is fairly big, it happens to be fairly large. So I was wondering if there was any possibility to increase the zoom speed built into GoJS, so that with one scrollstep more scale was added.
What i tried until now is doubling the
scrollHorizontalLineChange:
scrollVerticalLineChange:
both to 32.
No difference to before so far. Or is there any of the many tools GoJS has, to allow me this sweet increase when needed?
Theoretically, it is possible to use the "ViewportBoundsChanged" event to change the zoom factor when it's triggered. But would this be a good solution?
Thanks in advance.
Oh and if any additional details are needed, I will be happy to provide them.
Set CommandHandler.zoomFactor, http://gojs.net/latest/api/symbols/CommandHandler.html#zoomFactor :
$(go.Diagram, ...,
{ "commandHandler.zoomFactor": 1.2 },
...)
The ToolManager handles mouse events when no specific Tool is running, and it calls Tool.standardMouseWheel, which calls CommandHandler.increaseZoom or CommandHandler.decreaseZoom as appropriate.
By the way, Diagram.scrollVerticalLineChange controls how far the diagram is scrolled when you click on the scrollbar's up button or down button. Or when you call http://gojs.net/latest/api/symbols/Diagram.html#scroll
I have made a small app that allows the user to create rectangles, and drag them around.
The implementational details are that the "green" workspace area you see is a Marionette CollectionView
and when you are drawing boxes, you're essentially instantiating new rectangle models and rendering views for them. HTML-wise, the rectangles are child nodes of #workspace.
Here's a working demo (on dropbox since jsfiddle keeps failing me all the time)
From what I know,in order to avoid the creation of a new rectangle while I'm moving around an already existing one, I need to stopPropagation of the mousedown/mousemove/mouseup events (That's what I'm using in the first place to determine if the user is dragging, to acquire mouse pointer position, calculate rectangle properties, and append the rectangle view on mouseup)
The problem is that although I stopPropagation for mousedown/mousemove/mouseup, apparently the mouseup event doesn't fire and the rectangle keeps following the cursor even after the mouse button has been released.
Also dragging a rectangle around is not as smooth as I would expect, but a bit glitchy. I'm suspecting that there must be either something horrible that I've done (most likely), or a conflict between how I'm handling events and how jQuery and jQuery UI are. (I need to comply, but I don't know how).
Please enlighten me!
In the end I've decided to write a short jQuery UI plugin that would take care of all the calculations and would allow me better control over event handling.
For more information about what I ended up doing check this post
It can be difficult to use (webpage) sliders that cover a large range with fine granularity. On the one hand, it is easy to move across the range. On the other hand, it is difficult to locate the exact point one wants, assuming a fine enough granularity.
I was thinking that a magnify effect around the cursor could solve this problem (assuming the problem really exists).
I looked for existing solutions or ideas via google, but couldn't find anything.
Any suggestions here?
I doubt if this is what you're looking for, but... within Mac OSX, holding down the control key and moving the scroll wheel will zoom in and out.
I'm having trouble thinking of a scenario where having so much data that scrolling of this nature would be a problem you'd want to have. In almost all scenarios it makes more sense to chunk up the data or reduce it down in some other way.
About the only thing that makes sense is the seek-bar/scrubber on a video player. If your player is 400px wide with a 360px wide scrubber, but the video is an hour long, the best granularity you'll get is 10 seconds-per-step (with the step-size being 1 pixel).
If that isn't enough granularity, then it's possible you'll need to augment your scrubber with another UI convention - which could be a magnifier - but it could also be other things. Like a "jump to point" text field that would allow to user to entire a time and seek to that exact position.
It sounds like you're going for something (visually) like the OS X dock. This is called a fish-eye effect. There's a jQuery plugin for a fish eye menu which you may be able adapt and merge with a slider to give you the functionality that you're looking for.
This might seem like a really dumb question, but I am writing an application and I have come across where my mouse-over, mouse-click and mouse-hover need different events bound to them. Now on Internet Explorer, Firefox, and Safari. It all works as expected.
However, on my iPhone the actions will not trigger. Now my question is are their any specific ways I can have the Mouse-Over essentially be fired when I hold my finger down and trigger an event?
An example where this doesn't work is right on this website when you hover over a comment it is supposed to display the +1 or flag icon.
I am using jQuery.
The answer is in the documentation that Remus posted. If you add an onclick = "void(0)" declaration, you will instruct Mobile Safari that the element is clickable, and you will gain access to the mouseover event on that element.
More info here
I think you need to reconsider your design for the iPhone (and any mobile for that matter). iPhone web interfaces shouldn't depend on mouse-overs and hovers, as they just complicate the interface significantly.
I strongly recommend that you design a new interface that is optimized for mobile viewing, that don't require clicking on small tiny arrows just to show more options.
Mobile Safari has no mouse and hover events (at least not in the usual accepted sense), they are explicitly called out in Creating Compatible Web Content Unsupported iPhone OS Technologies:
Mouse-over events The user cannot “mouse-over” a
nonclickable element on iPhone OS. The
element must be clickable for a
mouseover event to occur as described
in “One-Finger Events.”
Hover styles Since a mouseover event is sent only
before a mousedown event, hover styles
are displayed only if the user touches
and holds a clickable element with a
hover style. Read “Handling Events”
for all the events generated by
gestures on iPhone OS.
Yeah...I don't think anyone posing the question actually expected the device to "sense" a hover or mouseover. Actually you'd have to be pretty arrogant to assume someone actually meant that. Some method of triggering those event handlers is what is desired. I can definitely see a use for them in "hint" text appearing above items.
And whomever said not using mouse events makes a cleaner, simpler experience is taking their own opinion a bit too seriously. Those can greatly enhance a web page/application experience or make them worse. It's a matter of prudent usage.
The only answer anyone provided here worthwhile is whomever said it is best to have an alternate site optimized for mobile. Or possibly use a content management system that generates the page based on the browser type (similar to how Wikipedia works).
Congratulations on discovering the first thing about touch screen UI design. The bad news, is that what you want just is not going to happen.
The good news is that this will force you to make a much easier interface, for both iphone users and regular web users.
You simply cannot have a mouseover or hover functionality on touch screen devices, unless you can move a virtual pointer (though no touch UI offer that kind of functionality), but that would defeat the point of a touch screen UI.
Touch screen UI's are a paradigm shift and retro-fitting mouse-pointer UI interfaces back into touch UI design only limits and damages your solution.
Writing a mousehandler in javascript seems fairly straightforward, although I can imagine it being easy to get a lot of edge cases wrong.
The good news is, someone wrote a javascript mouse-handler/emulator whatever -- as a bookmarklet. It's called iCursor (not to be confused with the pointless mac app of the same name).
The bad news is, the guy's site (icursor.mobi) has gone off the air, and I can't find a copy, so I can't tell you how well it works. Here's a review (because I can only post one link):
What apple should have done for the iPhone/iPad was make one-finger panning move a virtual mouse pointer, and two-finger panning move within the viewport (as one-finger does now).
Two finger panning is easy; the only reason I can imagine for Apple not doing this is that they actually wanted to break 50% of the websites in the world. Seriously. It's right up there with the evil manipulative attempts to break standards that Microsoft has been doing all these years.
You're a web developer. What do you hate most? Internet Explorer. Because of all the extra headaches it causes you. Well, Stevie had to have his "me too" moment, and you're going to pay for it.