Is it possible for an Adobe AIR app to receive touch events in OS X? - macos

I'm working on software in OS X that receives touches from a multi-touch device and posts them to the system for applications to process. I was hoping that it would be possible to support Adobe AIR applications, but from the research I've done, it looks like they don't support multi-touch events on OS X. This page in particular seems to indicate that, and consistent with what it says, the AIR applications I've tested with do indeed only respond to gesture events, but not touch events. However I'm (perhaps naively) hoping there's a way to do it regardless.
So is it possible for an AIR application running in Mac OS X to receive touch events at all? Perhaps using a different method than posting system-wide touch events? For example, is there any way my software could somehow send touch events directly to an AIR app?
Thanks in advance!

Related

Detect Keyboard event in MAC

i'm developing a JAVA cross platform software that is essentialy based on AWT and Processing. I'm stuck with an issue about key-responsiveness on MAC: it seems that the AWT canvas can't gain focus -just for keyboard events-.
Is there any software available on MAc that detect the input events of the OS and that says to which window or process they're going to?
Thank you all,
Stefano

How to send raw multitouch trackpad data under Mac OS X?

The end goal is to take touch input from an iOS device, send it over a websocket, accept it on the Mac OS X side, and send it through the system so everything using the private multitouch framework to accept input sees the data as if it were normal multitouch trackpad data.
The synthesize sub-project under https://github.com/calftrail/Touch seems like a good place to start. However it seems like the developer created it with the intent of taking valid multitouch input (from a magic mouse when there was arbitrarily little software support from Mac OS X), and piping it as multitouch trackpad input. I need to create valid/acceptable multitouch trackpad out of thin air (with just sequences of touch locations, not real HID data).
In deep here. Help, someone. :)
Glad you found my TouchSynthesis subproject — I think it will let you do what you need, since internally it is split up as you want it. [Please note however that this code is GPL licensed, i.e. virally open source, unlike many Mac libraries.]
You can treat TouchSynthesis.m as example code for using the TouchEvents "library" which provides support for your specific question via one "simple" function: tl_CGEventCreateFromGesture
The basic gist is that tl_CGEventCreateFromGesture takes in a dictionary of gesture+touch data and will return a CGEvent that you can inject via Quartz Event Services into the system. A gesture event is required to send what becomes NSTouch data, but IIRC could be a fairly generic "gesture" type rather than zoom/pan/etc.
This is sort of a halfway-private solution: Apple support injecting CGEvents into the system [at least outside The Sandbox? …I've since lost interest in their platforms so haven't researched that one…] so that part is "fine", but the actual CGEvent I create is of an undocumented type, the format for which I had to figure out via hex dumps and some Darwin source code HID headers they shared. It's that work that "TouchEvents.m" implements — that's how Sesamouse could "create valid/acceptable multitouch trackpad out of thin air" — and it should already be separate from the private framework MultitouchSupport stuff that read in the Magic Mouse input.

Notifications Center Alternate in MAC OS X 10.6

I have an application that fires notification 5-6 times a day on some specific times set by users. Right now I'm using Notification Center fo scheduling of notifications but unfortunately it's supported only in Mac OS X 10.8. Actually, I want my app available for the users of MAC OS X 10.6 too. For that I searched the internet and found a third party app GROWL. But here the problem is, if I use Growl, 1st it requires users to install it to get notifications from apps. 2nd and main problem is I dont think there is any functionality in GROWL to schedule notifications on particular time just like we have in Notifications Center to schedule by giving fireDate.
+[GrowlApplicationBridge
notifyWithTitle:(NSString *)title
description:(NSString *)description
notificationName:(NSString *)notificationName
iconData:(NSData *)iconData
priority:(signed int)priority
isSticky:(BOOL)isSticky
clickContext:(id)clickContext]
theres nothing to fire on a particular time in GROWL, can you please guide me to the right path ? how this can be done in 10.6 ??
Well I'm using NSTimer that will call a selector after every second to keep track of the time and checks whether notification time arrived or not. But I dont think its a good practice.

What devices are available to test WM_GESTURE and WM_TOUCH code on a desktop machine?

I'm writing some code to handle WM_GESTURE and WM_TOUCH events in Windows 7, but I can't figure out how to test it. I do my development in Boot Camp on a 17" Mac Book Pro.
So far, I have determined that the Boot Camp trackpad driver in Windows 7 does not generate those events, and this generic trackpad I found on Amazon.com that claims to be 'multi-touch' works as advertised, but not by creating WM_GESTURE or WM_TOUCH events. I verified this by using Spy++ to report the events; nothing with the WM_GESTURE or WM_TOUCH value was reported.
What kind of hardware is supposed to generate these kinds of events? At this point, I'm assuming it's only for tablet or mobile (Windows CE) hardware, but I'd appreciate any other suggestions.
I suppose there's another way to approach this -- I want to get functionality similar to Cocoa's [NSResponder swipeWithGesture:] and related methods, which report back swipes, rotation, and other gestures on the trackpad. WM_GESTURE appears to be the equivalent on Windows 7.
An other option, which would require only another physical mouse device to work with, and should get you at least 95% of the way there is the Multi-Touch Vista project, which can emulate up to 256 touch points using physical devices - thus the need for an extra mouse, or two since it can be awkward to simultaneously work with a mouse in one hand and trackpad with another.
There are several monitors out there supporting touch with Windows 7. For example: Acer T230H.
HTH
Wacom makes several touchpads that support multitouch; a particularly inexpensive version is the Bamboo Touch. This gives you touch without having to buy another monitor - although it doesn't give that direct interaction feeling.

How to use Mac OS X Cocoa events for multitouch gestures

I'm writing a program that has an NSView embedded in an NSScrollView which user can zoom. I'd love to set it up so the user can zoom the view using the multitouch pinch gesture supported on MacBook Air and the new unibody MacBooks/MacBooks Pro and in applications like Safari and iPhoto. I've hunted through Apple's documentation and can't figure out how do to this.
Is this supported using publicly available APIs on Mac OS X 10.5 Leopard?
If not, how "bad" are the private APIs (e.g. is it just an undeclared constant or a whole new set of methods)?
Edit: Snow Leopard adds supported APIs for gestures and multi-touch. See the AppKit release notes for Snow Leopard; ⌘F for “gesture” and “MultiTouch” (sic). They'll look pretty familiar if you've used ones below, but there probably are some fine differences, so read the new documentation anyway.
Is this supported using publicly available APIs on Mac OS X 10.5 Leopard?
No. 10.5.0 doesn't support it at all, and 10.5.1 through 10.5.6 make you implement undocumented methods.
If not, how "bad" are the private APIs (e.g. is it just an undeclared constant or a whole new set of methods)?
Not bad at all. You have to implement some undocumented event methods in your view. Since you're the one implementing the methods, you shouldn't crash if Apple changes the methods; all that will happen is the feature will stop working.
However, if you'll be retrieving the absolute (not delta) magnification or rotation from the event, then those are as-yet-undocumented methods of the event, so you should guard those messages with respondsToSelector: messages and perform careful range-checking on the methods' return values.

Resources