This version is much less invasive than the previous patch. I pushed
all multitouch support into the synaptics driver, and only have the
driver report a single event for multitouch situations, consisting of
the x and y coords set to the midpoint between the two touch points,
and the size field of the event set to the distance between the touch
point and each finger (i.e. the radius of stretch). Size == 0 when
there is only one finger on the screen. This patch is 100% compatible
with all current apps and the Android event pipeline, as far as I can
tell. Apps can be written to detect multitouch events by checking the
size field, and if it is > 1.0 (the max value returned by the current
driver, although this value appears to just consist of noise
currently), then the program can initiate a multitouch operation.
Under the new system, the size values stored in MotionEvents are in
screen coordinates just like x and y.
From a user standpoint, this patch could easily give multitouch
scaling in MapViews and WebViews, but does not allow for more
complicated operations such as rotation (see my previous post for the
reason why).
Comments please from core framework developers? I understand a driver
was checked into git for a "real" iPhone-style multitouch screen a
while back, but there doesn't appear to be any UI code checked in for
it yet, and obviously there is no announced device. Could something
like this be pushed upstream in the meantime though to at least
support multitouch scaling on the G1? Or is this unlikely to ever
pass?
Hi, this is really cool work, but I don't think we would accept something like this as a patch. At the very least, re-using the size field to report pseudo-multi-touch information is a pretty big hack.
The API I would expect to see for multi-touch would be something along the lines of a new set of action codes for when additional fingers are down, moved, or released, and a new field on MotionEvent for which finger that event is for. (So it would always be 0 for the current action codes, and some value 1-n for the new action codes, where n is the maximum number of fingers that can be detected.) Then each finger would be a new distinct MotionEvent stream, which would be delivered separately and the ones with the new action codes would be ignored by existing applications.
> This version is much less invasive than the previous patch. I pushed > all multitouch support into the synaptics driver, and only have the > driver report a single event for multitouch situations, consisting of > the x and y coords set to the midpoint between the two touch points, > and the size field of the event set to the distance between the touch > point and each finger (i.e. the radius of stretch). Size == 0 when > there is only one finger on the screen. This patch is 100% compatible > with all current apps and the Android event pipeline, as far as I can > tell. Apps can be written to detect multitouch events by checking the > size field, and if it is > 1.0 (the max value returned by the current > driver, although this value appears to just consist of noise > currently), then the program can initiate a multitouch operation. > Under the new system, the size values stored in MotionEvents are in > screen coordinates just like x and y.
> From a user standpoint, this patch could easily give multitouch > scaling in MapViews and WebViews, but does not allow for more > complicated operations such as rotation (see my previous post for the > reason why).
> Comments please from core framework developers? I understand a driver > was checked into git for a "real" iPhone-style multitouch screen a > while back, but there doesn't appear to be any UI code checked in for > it yet, and obviously there is no announced device. Could something > like this be pushed upstream in the meantime though to at least > support multitouch scaling on the G1? Or is this unlikely to ever > pass?
Note: please don't send private questions to me, as I don't have time to provide private support. All such questions should be posted on public forums, where I and others can see and answer them.
On the other hand, if the panel can track all fingers in a single processing pass, it'd be unfortunate to report that as multiple events: at some point in time the app would be in a state that doesn't match anything that the screen has ever read, i.e. where it has the new location for one finger but the old location for the other one.
On Tue, Jan 13, 2009 at 2:01 PM, Dianne Hackborn <hack...@android.com> wrote: > Hi, this is really cool work, but I don't think we would accept something > like this as a patch. At the very least, re-using the size field to report > pseudo-multi-touch information is a pretty big hack.
> The API I would expect to see for multi-touch would be something along the > lines of a new set of action codes for when additional fingers are down, > moved, or released, and a new field on MotionEvent for which finger that > event is for. (So it would always be 0 for the current action codes, and > some value 1-n for the new action codes, where n is the maximum number of > fingers that can be detected.) Then each finger would be a new distinct > MotionEvent stream, which would be delivered separately and the ones with > the new action codes would be ignored by existing applications.
> On Tue, Jan 13, 2009 at 1:53 PM, luke <luke.hu...@gmail.com> wrote:
>> I have put together a new patch for supporting multitouch scaling on >> the G1.
>> This version is much less invasive than the previous patch. I pushed >> all multitouch support into the synaptics driver, and only have the >> driver report a single event for multitouch situations, consisting of >> the x and y coords set to the midpoint between the two touch points, >> and the size field of the event set to the distance between the touch >> point and each finger (i.e. the radius of stretch). Size == 0 when >> there is only one finger on the screen. This patch is 100% compatible >> with all current apps and the Android event pipeline, as far as I can >> tell. Apps can be written to detect multitouch events by checking the >> size field, and if it is > 1.0 (the max value returned by the current >> driver, although this value appears to just consist of noise >> currently), then the program can initiate a multitouch operation. >> Under the new system, the size values stored in MotionEvents are in >> screen coordinates just like x and y.
>> From a user standpoint, this patch could easily give multitouch >> scaling in MapViews and WebViews, but does not allow for more >> complicated operations such as rotation (see my previous post for the >> reason why).
>> Comments please from core framework developers? I understand a driver >> was checked into git for a "real" iPhone-style multitouch screen a >> while back, but there doesn't appear to be any UI code checked in for >> it yet, and obviously there is no announced device. Could something >> like this be pushed upstream in the meantime though to at least >> support multitouch scaling on the G1? Or is this unlikely to ever >> pass?
> Note: please don't send private questions to me, as I don't have time to > provide private support. All such questions should be posted on public > forums, where I and others can see and answer them.
-- Jean-Baptiste M. "JBQ" Queru Android Engineer, Google.
How do action codes work? Can you just specify which codes your app
is listening for? It sounds like you are describing some sort of "opt-
in" filter system.
On Jan 13, 5:01 pm, "Dianne Hackborn" <hack...@android.com> wrote:
> Hi, this is really cool work, but I don't think we would accept something
> like this as a patch. At the very least, re-using the size field to report
> pseudo-multi-touch information is a pretty big hack.
> The API I would expect to see for multi-touch would be something along the
> lines of a new set of action codes for when additional fingers are down,
> moved, or released, and a new field on MotionEvent for which finger that
> event is for. (So it would always be 0 for the current action codes, and
> some value 1-n for the new action codes, where n is the maximum number of
> fingers that can be detected.) Then each finger would be a new distinct
> MotionEvent stream, which would be delivered separately and the ones with
> the new action codes would be ignored by existing applications.
> On Tue, Jan 13, 2009 at 1:53 PM, luke <luke.hu...@gmail.com> wrote:
> > I have put together a new patch for supporting multitouch scaling on
> > the G1.
> > This version is much less invasive than the previous patch. I pushed
> > all multitouch support into the synaptics driver, and only have the
> > driver report a single event for multitouch situations, consisting of
> > the x and y coords set to the midpoint between the two touch points,
> > and the size field of the event set to the distance between the touch
> > point and each finger (i.e. the radius of stretch). Size == 0 when
> > there is only one finger on the screen. This patch is 100% compatible
> > with all current apps and the Android event pipeline, as far as I can
> > tell. Apps can be written to detect multitouch events by checking the
> > size field, and if it is > 1.0 (the max value returned by the current
> > driver, although this value appears to just consist of noise
> > currently), then the program can initiate a multitouch operation.
> > Under the new system, the size values stored in MotionEvents are in
> > screen coordinates just like x and y.
> > From a user standpoint, this patch could easily give multitouch
> > scaling in MapViews and WebViews, but does not allow for more
> > complicated operations such as rotation (see my previous post for the
> > reason why).
> > Comments please from core framework developers? I understand a driver
> > was checked into git for a "real" iPhone-style multitouch screen a
> > while back, but there doesn't appear to be any UI code checked in for
> > it yet, and obviously there is no announced device. Could something
> > like this be pushed upstream in the meantime though to at least
> > support multitouch scaling on the G1? Or is this unlikely to ever
> > pass?
> Note: please don't send private questions to me, as I don't have time to
> provide private support. All such questions should be posted on public
> forums, where I and others can see and answer them.
Another problem is that if you put a finger down (finger 0), then another one (finger 1), then lift the first one, the only finger being tracked is now finger 1, and that might not work that well with existing apps.
On Tue, Jan 13, 2009 at 2:06 PM, Jean-Baptiste Queru <j...@google.com> wrote: > On the other hand, if the panel can track all fingers in a single > processing pass, it'd be unfortunate to report that as multiple > events: at some point in time the app would be in a state that doesn't > match anything that the screen has ever read, i.e. where it has the > new location for one finger but the old location for the other one.
> JBQ
> On Tue, Jan 13, 2009 at 2:01 PM, Dianne Hackborn <hack...@android.com> wrote: >> Hi, this is really cool work, but I don't think we would accept something >> like this as a patch. At the very least, re-using the size field to report >> pseudo-multi-touch information is a pretty big hack.
>> The API I would expect to see for multi-touch would be something along the >> lines of a new set of action codes for when additional fingers are down, >> moved, or released, and a new field on MotionEvent for which finger that >> event is for. (So it would always be 0 for the current action codes, and >> some value 1-n for the new action codes, where n is the maximum number of >> fingers that can be detected.) Then each finger would be a new distinct >> MotionEvent stream, which would be delivered separately and the ones with >> the new action codes would be ignored by existing applications.
>> On Tue, Jan 13, 2009 at 1:53 PM, luke <luke.hu...@gmail.com> wrote:
>>> I have put together a new patch for supporting multitouch scaling on >>> the G1.
>>> This version is much less invasive than the previous patch. I pushed >>> all multitouch support into the synaptics driver, and only have the >>> driver report a single event for multitouch situations, consisting of >>> the x and y coords set to the midpoint between the two touch points, >>> and the size field of the event set to the distance between the touch >>> point and each finger (i.e. the radius of stretch). Size == 0 when >>> there is only one finger on the screen. This patch is 100% compatible >>> with all current apps and the Android event pipeline, as far as I can >>> tell. Apps can be written to detect multitouch events by checking the >>> size field, and if it is > 1.0 (the max value returned by the current >>> driver, although this value appears to just consist of noise >>> currently), then the program can initiate a multitouch operation. >>> Under the new system, the size values stored in MotionEvents are in >>> screen coordinates just like x and y.
>>> From a user standpoint, this patch could easily give multitouch >>> scaling in MapViews and WebViews, but does not allow for more >>> complicated operations such as rotation (see my previous post for the >>> reason why).
>>> Comments please from core framework developers? I understand a driver >>> was checked into git for a "real" iPhone-style multitouch screen a >>> while back, but there doesn't appear to be any UI code checked in for >>> it yet, and obviously there is no announced device. Could something >>> like this be pushed upstream in the meantime though to at least >>> support multitouch scaling on the G1? Or is this unlikely to ever >>> pass?
>> Note: please don't send private questions to me, as I don't have time to >> provide private support. All such questions should be posted on public >> forums, where I and others can see and answer them.
On Tue, Jan 13, 2009 at 2:08 PM, luke <luke.hu...@gmail.com> wrote: > What is the size field intended for currently?
It is the size of the finger on the screen, for ex tip or thumb.
> How do action codes work? Can you just specify which codes your app > is listening for? It sounds like you are describing some sort of "opt- > in" filter system.
No, they are just the code identifying the action associated with the event -- DOWN, MOVE, UP, etc. The app looks at the code to decide what to do with the event.
Note: please don't send private questions to me, as I don't have time to provide private support. All such questions should be posted on public forums, where I and others can see and answer them.
On Tue, Jan 13, 2009 at 2:14 PM, Jean-Baptiste Queru <j...@google.com> wrote: > Another problem is that if you put a finger down (finger 0), then > another one (finger 1), then lift the first one, the only finger being > tracked is now finger 1, and that might not work that well with > existing apps.
Whether this is reported as the first or second finger going up is an implementation detail (in the screen firmware as well as the framework).
Note: please don't send private questions to me, as I don't have time to provide private support. All such questions should be posted on public forums, where I and others can see and answer them.
On Jan 13, 5:06 pm, Jean-Baptiste Queru <j...@google.com> wrote:
> On the other hand, if the panel can track all fingers in a single
> processing pass, it'd be unfortunate to report that as multiple
> events: at some point in time the app would be in a state that doesn't
> match anything that the screen has ever read, i.e. where it has the
> new location for one finger but the old location for the other one.
You are right, but the rate that motion events are passed along makes
this effect almost negligible... There is a lot of messiness like
this in event processing, I have come to discover...
On Jan 13, 5:14 pm, Jean-Baptiste Queru <j...@google.com> wrote:
> Another problem is that if you put a finger down (finger 0), then
> another one (finger 1), then lift the first one, the only finger being
> tracked is now finger 1, and that might not work that well with
> existing apps.
Correct. This is actually a hardware limitation, and needs to be
handled with smarts at some level. Apparently the iPhone SDK leaves
it up to the user to handle this.
On Jan 13, 5:15 pm, "Dianne Hackborn" <hack...@android.com> wrote:
> On Tue, Jan 13, 2009 at 2:08 PM, luke <luke.hu...@gmail.com> wrote:
> > What is the size field intended for currently?
> It is the size of the finger on the screen, for ex tip or thumb.
Not for the synaptics driver -- size information is passed in the
pressure field. Sometimes you can convince yourself the value gets
smaller just as a touchpoint lifts off the screen, but it's a
stretch. Also the range of values [0.0,1.0] are quantized to 15
levels at the driver level. I tried really hard to find meaning for
the value in the size field, and just couldn't believe it was used for
anything meaningful -- and certainly the information is not reliable
enough to do anything meaningful with. It is effectively just noise.
> > How do action codes work? Can you just specify which codes your app
> > is listening for? It sounds like you are describing some sort of "opt-
> > in" filter system.
> No, they are just the code identifying the action associated with the event
> -- DOWN, MOVE, UP, etc. The app looks at the code to decide what to do with
> the event.
Oh, those codes. That makes sense as a way of building in multitouch
without creating a major new API.
On Jan 13, 5:01 pm, "Dianne Hackborn" <hack...@android.com> wrote:
> Hi, this is really cool work, but I don't think we would accept something
> like this as a patch. At the very least, re-using the size field to report
> pseudo-multi-touch information is a pretty big hack.
No problem, totally understandable. I will probably put this out
there as a "community hack" and see if it catches on (i.e. whether
Market apps start appearing that use it). I am going to hack together
a map and browser apps that use this for scaling, and people can
choose whether or not to use this on their phone as a workaround,
until multitouch is officially available.
Actually I have one more question if anyone can answer it -- does
anyone know for sure if the threat of being sued by Apple really is a
barrier to getting multitouch on Android? I don't need an official
word from Google or anybody else -- I just need to know if this is
just rumor or if it is a real possibility.
Thanks!
On Jan 13, 5:29 pm, luke <luke.hu...@gmail.com> wrote:
> On Jan 13, 5:01 pm, "Dianne Hackborn" <hack...@android.com> wrote:
> > Hi, this is really cool work, but I don't think we would accept something
> > like this as a patch. At the very least, re-using the size field to report
> > pseudo-multi-touch information is a pretty big hack.
> No problem, totally understandable. I will probably put this out
> there as a "community hack" and see if it catches on (i.e. whether
> Market apps start appearing that use it). I am going to hack together
> a map and browser apps that use this for scaling, and people can
> choose whether or not to use this on their phone as a workaround,
> until multitouch is officially available.
On Tue, Jan 13, 2009 at 2:27 PM, luke <luke.hu...@gmail.com> wrote: > Not for the synaptics driver -- size information is passed in the > pressure field. Sometimes you can convince yourself the value gets > smaller just as a touchpoint lifts off the screen, but it's a > stretch. Also the range of values [0.0,1.0] are quantized to 15 > levels at the driver level. I tried really hard to find meaning for > the value in the size field, and just couldn't believe it was used for > anything meaningful -- and certainly the information is not reliable > enough to do anything meaningful with. It is effectively just noise.
If we are talking about accepting a patch (and I need to emphasize, I can't make an promises about anything here, except that the current approach will not be accepted), it can't be just designed around what the synaptics driver happens to currently do.
What you are doing is great work for shimming in a multi-touch demo that touches as little code as possible. For a patch that would add multitouch APIs, though, the approach is much different and should result in an API that is clear and easy to understand and sufficient for a wide variety of devices. There would also be other things to deal with, for example a way for an app to find out up-front if the screen is capable of multi-touch.
Note: please don't send private questions to me, as I don't have time to provide private support. All such questions should be posted on public forums, where I and others can see and answer them.
And everything I have seen says apple patented -gestures-. EG pinch to zoom, etc. So .. ymmv. But it cannot prevent general multitouch from working (ahem, ms surface) or - likely - even stretch to zoom (prior art)..
On Tue, Jan 13, 2009 at 5:31 PM, luke <luke.hu...@gmail.com> wrote:
> Actually I have one more question if anyone can answer it -- does > anyone know for sure if the threat of being sued by Apple really is a > barrier to getting multitouch on Android? I don't need an official > word from Google or anybody else -- I just need to know if this is > just rumor or if it is a real possibility.
> Thanks!
> On Jan 13, 5:29 pm, luke <luke.hu...@gmail.com> wrote: > > On Jan 13, 5:01 pm, "Dianne Hackborn" <hack...@android.com> wrote:
> > > Hi, this is really cool work, but I don't think we would accept > something > > > like this as a patch. At the very least, re-using the size field to > report > > > pseudo-multi-touch information is a pretty big hack.
> > No problem, totally understandable. I will probably put this out > > there as a "community hack" and see if it catches on (i.e. whether > > Market apps start appearing that use it). I am going to hack together > > a map and browser apps that use this for scaling, and people can > > choose whether or not to use this on their phone as a workaround, > > until multitouch is officially available.
> And everything I have seen says apple patented -gestures-. EG pinch to zoom,
> etc. So .. ymmv. But it cannot prevent general multitouch from working
> (ahem, ms surface) or - likely - even stretch to zoom (prior art)..
> On Tue, Jan 13, 2009 at 5:31 PM, luke <luke.hu...@gmail.com> wrote:
> > Actually I have one more question if anyone can answer it -- does
> > anyone know for sure if the threat of being sued by Apple really is a
> > barrier to getting multitouch on Android? I don't need an official
> > word from Google or anybody else -- I just need to know if this is
> > just rumor or if it is a real possibility.
> > Thanks!
> > On Jan 13, 5:29 pm, luke <luke.hu...@gmail.com> wrote:
> > > On Jan 13, 5:01 pm, "Dianne Hackborn" <hack...@android.com> wrote:
> > > > Hi, this is really cool work, but I don't think we would accept
> > something
> > > > like this as a patch. At the very least, re-using the size field to
> > report
> > > > pseudo-multi-touch information is a pretty big hack.
> > > No problem, totally understandable. I will probably put this out
> > > there as a "community hack" and see if it catches on (i.e. whether
> > > Market apps start appearing that use it). I am going to hack together
> > > a map and browser apps that use this for scaling, and people can
> > > choose whether or not to use this on their phone as a workaround,
> > > until multitouch is officially available.
> > > Thanks for answering my questions.- Hide quoted text -
> For a patch that would add multitouch
> APIs, though, the approach is much different and should result in an API
> that is clear and easy to understand and sufficient for a wide variety of
> devices. There would also be other things to deal with, for example a way
> for an app to find out up-front if the screen is capable of multi-touch.
> --
> Dianne Hackborn
Could it be possible to add an "option" in so "settings", where the
user could select whether his device supports MT or just a single
touch? In this way Android would have this nice feature for devices
that support it, and be able to work as it is now for devices that are
not MT capable.
For hardward that doesn't support multitouch this would need to always be false, and if it does I don't see why you would want to turn it off, so I'm not sure I the point of a user setting for it...?
On Mon, Jan 26, 2009 at 12:09 AM, Miroslav Mandov <miro...@gmail.com> wrote:
> > For a patch that would add multitouch > > APIs, though, the approach is much different and should result in an API > > that is clear and easy to understand and sufficient for a wide variety of > > devices. There would also be other things to deal with, for example a > way > > for an app to find out up-front if the screen is capable of multi-touch.
> > -- > > Dianne Hackborn
> Could it be possible to add an "option" in so "settings", where the > user could select whether his device supports MT or just a single > touch? In this way Android would have this nice feature for devices > that support it, and be able to work as it is now for devices that are > not MT capable.
Note: please don't send private questions to me, as I don't have time to provide private support. All such questions should be posted on public forums, where I and others can see and answer them.
On Jan 26, 8:14 pm, Dianne Hackborn <hack...@android.com> wrote:
> For hardward that doesn't support multitouch this would need to always be
> false, and if it does I don't see why you would want to turn it off, so I'm
> not sure I the point of a user setting for it...?
May be I did not explain my point correctly.
My idea was to have the MT functionality in Android OS and at the same
time to keep the existing GUI for devices that are not MT capable.
Android concept is that all applications should be compatible with all
Android devices that could lead to the bad idea to keep it only as
"single touch" platform.
Yes, it could be an "option" that the manufacturer is selecting, or
Android can select it based on the screen drivers.
On Tue, Jan 27, 2009 at 4:41 AM, Miroslav Mandov <miro...@gmail.com> wrote:
> On Jan 26, 8:14 pm, Dianne Hackborn <hack...@android.com> wrote: >> For hardward that doesn't support multitouch this would need to always be >> false, and if it does I don't see why you would want to turn it off, so I'm >> not sure I the point of a user setting for it...?
> May be I did not explain my point correctly. > My idea was to have the MT functionality in Android OS and at the same > time to keep the existing GUI for devices that are not MT capable. > Android concept is that all applications should be compatible with all > Android devices that could lead to the bad idea to keep it only as > "single touch" platform. > Yes, it could be an "option" that the manufacturer is selecting, or > Android can select it based on the screen drivers.
Well yes of course if or when multi-touch is introduced into the platform, you will NOT be able to rely on it being there. Android will be running on devices without a multitouch screen, you can count on it.
On Tue, Jan 27, 2009 at 4:41 AM, Miroslav Mandov <miro...@gmail.com> wrote:
> On Jan 26, 8:14 pm, Dianne Hackborn <hack...@android.com> wrote: > > For hardward that doesn't support multitouch this would need to always be > > false, and if it does I don't see why you would want to turn it off, so > I'm > > not sure I the point of a user setting for it...?
> May be I did not explain my point correctly. > My idea was to have the MT functionality in Android OS and at the same > time to keep the existing GUI for devices that are not MT capable. > Android concept is that all applications should be compatible with all > Android devices that could lead to the bad idea to keep it only as > "single touch" platform. > Yes, it could be an "option" that the manufacturer is selecting, or > Android can select it based on the screen drivers.
> Unfortunately I just saw that Apple was awarded "Touch screen device, > method, and graphical user interface for determining commands by > applying heuristics" patent:
Note: please don't send private questions to me, as I don't have time to provide private support. All such questions should be posted on public forums, where I and others can see and answer them.
Please think about soft keyboards when considering multi-touch APIs,
where the problem isn't detecting the distance between two finger, but
rather is allowing a 2nd finger (or thumb) to come down on a 2nd key
before the first finger (or thumb) has been released. The proposed
API to provide only a centroid and the distance between fingers won't
work at all for this sort of application.
I think you'd ultimately want to package this as additional
GestureDetector subclasses, depending on whether the type of gesture
detection wanted was pinch/zoom or multiple/overlapping taps.
Keyboards (and maybe games) would use one class, browsers another.
Providing the right information from a touch panel to drive either
detector might be challenging, especially if the panel provides
'unpaired' x and y coordinates rather than individual touch locations,
but I believe it could be done.
On Jan 13, 4:08 pm, Disconnect <dc.disconn...@gmail.com> wrote:
> And everything I have seen says apple patented -gestures-. EG pinch to zoom,
> etc. So .. ymmv. But it cannot prevent general multitouch from working
> (ahem, ms surface) or - likely - even stretch to zoom (prior art)..
> On Tue, Jan 13, 2009 at 5:31 PM, luke <luke.hu...@gmail.com> wrote:
> > Actually I have one more question if anyone can answer it -- does
> > anyone know for sure if the threat of being sued by Apple really is a
> > barrier to getting multitouch on Android? I don't need an official
> > word from Google or anybody else -- I just need to know if this is
> > just rumor or if it is a real possibility.
> > Thanks!
> > On Jan 13, 5:29 pm, luke <luke.hu...@gmail.com> wrote:
> > > On Jan 13, 5:01 pm, "Dianne Hackborn" <hack...@android.com> wrote:
> > > > Hi, this is really cool work, but I don't think we would accept
> > something
> > > > like this as a patch. At the very least, re-using the size field to
> > report
> > > > pseudo-multi-touch information is a pretty big hack.
> > > No problem, totally understandable. I will probably put this out
> > > there as a "community hack" and see if it catches on (i.e. whether
> > > Market apps start appearing that use it). I am going to hack together
> > > a map and browser apps that use this for scaling, and people can
> > > choose whether or not to use this on their phone as a workaround,
> > > until multitouch is officially available.
> Please think about soft keyboards when considering multi-touch APIs, > where the problem isn't detecting the distance between two finger, but > rather is allowing a 2nd finger (or thumb) to come down on a 2nd key > before the first finger (or thumb) has been released. The proposed > API to provide only a centroid and the distance between fingers won't > work at all for this sort of application.
> I think you'd ultimately want to package this as additional > GestureDetector subclasses, depending on whether the type of gesture > detection wanted was pinch/zoom or multiple/overlapping taps. > Keyboards (and maybe games) would use one class, browsers another.
> Providing the right information from a touch panel to drive either > detector might be challenging, especially if the panel provides > 'unpaired' x and y coordinates rather than individual touch locations, > but I believe it could be done.
> On Jan 13, 4:08 pm, Disconnect <dc.disconn...@gmail.com> wrote: > > And everything I have seen says apple patented -gestures-. EG pinch to > zoom, > > etc. So .. ymmv. But it cannot prevent general multitouch from working > > (ahem, ms surface) or - likely - even stretch to zoom (prior art)..
> > On Tue, Jan 13, 2009 at 5:31 PM, luke <luke.hu...@gmail.com> wrote:
> > > Actually I have one more question if anyone can answer it -- does > > > anyone know for sure if the threat of being sued by Apple really is a > > > barrier to getting multitouch on Android? I don't need an official > > > word from Google or anybody else -- I just need to know if this is > > > just rumor or if it is a real possibility.
> > > Thanks!
> > > On Jan 13, 5:29 pm, luke <luke.hu...@gmail.com> wrote: > > > > On Jan 13, 5:01 pm, "Dianne Hackborn" <hack...@android.com> wrote:
> > > > > Hi, this is really cool work, but I don't think we would accept > > > something > > > > > like this as a patch. At the very least, re-using the size field > to > > > report > > > > > pseudo-multi-touch information is a pretty big hack.
> > > > No problem, totally understandable. I will probably put this out > > > > there as a "community hack" and see if it catches on (i.e. whether > > > > Market apps start appearing that use it). I am going to hack > together > > > > a map and browser apps that use this for scaling, and people can > > > > choose whether or not to use this on their phone as a workaround, > > > > until multitouch is officially available.
Note: please don't send private questions to me, as I don't have time to provide private support. All such questions should be posted on public forums, where I and others can see and answer them.
> Please think about soft keyboards when considering multi-touch APIs, > where the problem isn't detecting the distance between two finger, but > rather is allowing a 2nd finger (or thumb) to come down on a 2nd key > before the first finger (or thumb) has been released. The proposed > API to provide only a centroid and the distance between fingers won't > work at all for this sort of application.
> I think you'd ultimately want to package this as additional > GestureDetector subclasses, depending on whether the type of gesture > detection wanted was pinch/zoom or multiple/overlapping taps. > Keyboards (and maybe games) would use one class, browsers another.
> Providing the right information from a touch panel to drive either > detector might be challenging, especially if the panel provides > 'unpaired' x and y coordinates rather than individual touch locations, > but I believe it could be done.
> On Jan 13, 4:08 pm, Disconnect <dc.disconn...@gmail.com > <mailto:dc.disconn...@gmail.com>> wrote: > > And everything I have seen says apple patented -gestures-. EG > pinch to zoom, > > etc. So .. ymmv. But it cannot prevent general multitouch from > working > > (ahem, ms surface) or - likely - even stretch to zoom (prior art)..
> > On Tue, Jan 13, 2009 at 5:31 PM, luke <luke.hu...@gmail.com > <mailto:luke.hu...@gmail.com>> wrote:
> > > Actually I have one more question if anyone can answer it -- does > > > anyone know for sure if the threat of being sued by Apple > really is a > > > barrier to getting multitouch on Android? I don't need an > official > > > word from Google or anybody else -- I just need to know if this is > > > just rumor or if it is a real possibility.
> > > Thanks!
> > > On Jan 13, 5:29 pm, luke <luke.hu...@gmail.com > <mailto:luke.hu...@gmail.com>> wrote: > > > > On Jan 13, 5:01 pm, "Dianne Hackborn" <hack...@android.com > <mailto:hack...@android.com>> wrote:
> > > > > Hi, this is really cool work, but I don't think we would > accept > > > something > > > > > like this as a patch. At the very least, re-using the > size field to > > > report > > > > > pseudo-multi-touch information is a pretty big hack.
> > > > No problem, totally understandable. I will probably put > this out > > > > there as a "community hack" and see if it catches on (i.e. > whether > > > > Market apps start appearing that use it). I am going to > hack together > > > > a map and browser apps that use this for scaling, and people can > > > > choose whether or not to use this on their phone as a > workaround, > > > > until multitouch is officially available.
> Note: please don't send private questions to me, as I don't have time > to provide private support. All such questions should be posted on > public forums, where I and others can see and answer them.
-- ====== Funky Android Limited is registered in England & Wales with the company number 6741909. The registered head office is Kemp House, 152-160 City Road, London, EC1V 2NX, UK.
The views expressed in this email are those of the author and not necessarily those of Funky Android Limited, it's associates, or it's subsidiaries.
>> Please think about soft keyboards when considering multi-touch APIs, >> where the problem isn't detecting the distance between two finger, but >> rather is allowing a 2nd finger (or thumb) to come down on a 2nd key >> before the first finger (or thumb) has been released. The proposed >> API to provide only a centroid and the distance between fingers won't >> work at all for this sort of application.
>> I think you'd ultimately want to package this as additional >> GestureDetector subclasses, depending on whether the type of gesture >> detection wanted was pinch/zoom or multiple/overlapping taps. >> Keyboards (and maybe games) would use one class, browsers another.
>> Providing the right information from a touch panel to drive either >> detector might be challenging, especially if the panel provides >> 'unpaired' x and y coordinates rather than individual touch locations, >> but I believe it could be done.
>> On Jan 13, 4:08 pm, Disconnect <dc.disconn...@gmail.com >> <mailto:dc.disconn...@gmail.com>> wrote: >> > And everything I have seen says apple patented -gestures-. EG >> pinch to zoom, >> > etc. So .. ymmv. But it cannot prevent general multitouch from >> working >> > (ahem, ms surface) or - likely - even stretch to zoom (prior art)..
>> > On Tue, Jan 13, 2009 at 5:31 PM, luke <luke.hu...@gmail.com >> <mailto:luke.hu...@gmail.com>> wrote:
>> > > Actually I have one more question if anyone can answer it -- does >> > > anyone know for sure if the threat of being sued by Apple >> really is a >> > > barrier to getting multitouch on Android? I don't need an >> official >> > > word from Google or anybody else -- I just need to know if this is >> > > just rumor or if it is a real possibility.
>> > > Thanks!
>> > > On Jan 13, 5:29 pm, luke <luke.hu...@gmail.com >> <mailto:luke.hu...@gmail.com>> wrote: >> > > > On Jan 13, 5:01 pm, "Dianne Hackborn" <hack...@android.com >> <mailto:hack...@android.com>> wrote:
>> > > > > Hi, this is really cool work, but I don't think we would >> accept >> > > something >> > > > > like this as a patch. At the very least, re-using the >> size field to >> > > report >> > > > > pseudo-multi-touch information is a pretty big hack.
>> > > > No problem, totally understandable. I will probably put >> this out >> > > > there as a "community hack" and see if it catches on (i.e. >> whether >> > > > Market apps start appearing that use it). I am going to >> hack together >> > > > a map and browser apps that use this for scaling, and people can >> > > > choose whether or not to use this on their phone as a >> workaround, >> > > > until multitouch is officially available.
>> Note: please don't send private questions to me, as I don't have time to >> provide private support. All such questions should be posted on public >> forums, where I and others can see and answer them.
> -- > ====== > Funky Android Limited is registered in England & Wales with the company > number 6741909. The registered head office is Kemp House, 152-160 City > Road, London, EC1V 2NX, UK. > The views expressed in this email are those of the author and not > necessarily those of Funky Android Limited, it's associates, or it's > subsidiaries.
> > > Please think about soft keyboards when considering multi-touch APIs, > > > where the problem isn't detecting the distance between two finger, but > > > rather is allowing a 2nd finger (or thumb) to come down on a 2nd key > > > before the first finger (or thumb) has been released. The proposed > > > API to provide only a centroid and the distance between fingers won't > > > work at all for this sort of application.
> > > I think you'd ultimately want to package this as additional > > > GestureDetector subclasses, depending on whether the type of gesture > > > detection wanted was pinch/zoom or multiple/overlapping taps. > > > Keyboards (and maybe games) would use one class, browsers another.
> > > Providing the right information from a touch panel to drive either > > > detector might be challenging, especially if the panel provides > > > 'unpaired' x and y coordinates rather than individual touch locations, > > > but I believe it could be done.
> > > On Jan 13, 4:08 pm, Disconnect <dc.disconn...@gmail.com > > > <mailto:dc.disconn...@gmail.com>> wrote: > > > > And everything I have seen says apple patented -gestures-. EG > > > pinch to zoom, > > > > etc. So .. ymmv. But it cannot prevent general multitouch from > > > working > > > > (ahem, ms surface) or - likely - even stretch to zoom (prior art).. > > > > > > > > On Tue, Jan 13, 2009 at 5:31 PM, luke <luke.hu...@gmail.com > > > <mailto:luke.hu...@gmail.com>> wrote: > > > > > > > > > Actually I have one more question if anyone can answer it -- does > > > > > anyone know for sure if the threat of being sued by Apple > > > really is a > > > > > barrier to getting multitouch on Android? I don't need an > > > official > > > > > word from Google or anybody else -- I just need to know if this is > > > > > just rumor or if it is a real possibility. > > > > > > > > > Thanks! > > > > > > > > > On Jan 13, 5:29 pm, luke <luke.hu...@gmail.com > > > <mailto:luke.hu...@gmail.com>> wrote: > > > > > > On Jan 13, 5:01 pm, "Dianne Hackborn" <hack...@android.com > > > <mailto:hack...@android.com>> wrote: > > > > > > > > > > > Hi, this is really cool work, but I don't think we would > > > accept > > > > > something > > > > > > > like this as a patch. At the very least, re-using the > > > size field to > > > > > report > > > > > > > pseudo-multi-touch information is a pretty big hack. > > > > > > > > > > No problem, totally understandable. I will probably put > > > this out > > > > > > there as a "community hack" and see if it catches on (i.e. > > > whether > > > > > > Market apps start appearing that use it). I am going to > > > hack together > > > > > > a map and browser apps that use this for scaling, and people can > > > > > > choose whether or not to use this on their phone as a > > > workaround, > > > > > > until multitouch is officially available. > > > > > > > > > > Thanks for answering my questions.
> > > Note: please don't send private questions to me, as I don't have time to > > > provide private support. All such questions should be posted on public > > > forums, where I and others can see and answer them.
> > -- > > ====== > > Funky Android Limited is registered in England & Wales with the company > > number 6741909. The registered head office is Kemp House, 152-160 City > > Road, London, EC1V 2NX, UK. > > The views expressed in this email are those of the author and not > > necessarily those of Funky Android Limited, it's associates, or it's > > subsidiaries.
|
