In
MCHttpRepository location: 'http://www.squeaksource.com/iPhone' user: '' password: ''
Name: iPhone-VMMaker-Only-JMM.1
I had some changes to handle:
(a) readImageFromFile: f HeapSize: desiredHeapSize StartingAt: imageOffset This was to handle mmap allocation, but it's obsoleted and replaced a year back with the macros we talked about earlier on image reading
(b) primitiveGetNextEvent
I have a change here where eventTypeIs == 6 if so that's a complex event and you'll find a description of that in the sq.h that I submitted in my microsecond clock changes last week or so. One of the issues is that the event type coming up is assumed to be an integers. However I change slot 4 to point to an oops. What is in the oops is platform dependent. I did have some constants I added for iphone touchs, and the generic location, acceleration data.
The ioGetNextEvent then is responsible for population slot 4 with smalltalk object. Althought the engineers at Apple tell me there *might* be touch area & pressure data, it's not accessible so you get the four types of events, the object is a set containing one or more items to enable the handling of 4 fingers down... 2 fingers up... with twist rotation on the other two fingers. Then in EventSensor(whatever) I deal with the interpretation of the complex object type. So no decision is done in the VM.
typedef struct sqComplexEvent { int type; /* type of event; EventTypeComplex */ unsigned int timeStamp; /* time stamp */ /* the interpretation of the following fields depend on the type of the event */ int action; /* one of ComplexEventXXX (see below) */ usqInt objectPointer; /* used to point to object */ int unused1; /* */ int unused2; /* */ int unused3; /* */ int windowIndex; /* host window structure */ } sqComplexEvent;
#define ComplexEventTypeTouchsDown 1 /* */ #define ComplexEventTypeTouchsUp 2 /* */ #define ComplexEventTypeTouchsMoved 3 /* */ #define ComplexEventTypeTouchsStationary 4 /* */ #define ComplexEventTypeTouchsCancelled 5 /* */ #define ComplexEventTypeAccelerationData 6 /* */ #define ComplexEventTypeLocationData 7 /* */ #define ComplexEventTypeApplicationData 8 /* */
On 2010-01-18, at 11:30 PM, Andreas Raab wrote:
BTW, one of the things I'm considering is to change the event type for touch events. That's mostly because it seems like on Android you actually get a coverage for a touch event, i.e., how many pixels were covered by your fatty fingers. And what I'm thinking here is that interaction could be *greatly* improved if the dispatch of such events would take coverage of the target area into account. That means that even if a click doesn't land "on" a relatively small button that the button will get the click if it's the ui element with the largest coverage in the region. I could see this working very well for relatively small UI elements. However, that does require extra information (pressure, coverage) and I'm wondering if it's worthwhile to package and dispatch those events separately. How does this level of stuff work on the iPhone? Are you dispatching touch events ore are you dispatching mouse events? Any additional parameters you're passing along?
Cheers,
- Andreas
-- =========================================================================== John M. McIntosh johnmci@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================