Here is a proposed patch: https://issues.apache.org/jira/secure/attachment/12482729/TRINIDAD-2108.patch
Sorry for the odd diff, the svn EOL was not set to native for the capabilities.xml. I can add a "none" for all other browsers, but it appears that for the other capabilities, the "none" is not used, but instead the capability is simply not set and therefore null. On Mon, Jun 13, 2011 at 3:24 PM, Blake Sullivan <blake.sulli...@oracle.com>wrote: > I think we should have one per device and we might eventually want to > support some keyboard-related ones as well to include differences between > real and various on-screen keyboards. > > -- Blake Sullivan > > > On 6/13/11 10:52 AM, Andrew Robinson wrote: > > We could have it return constant strings of "none", "single" and "multiple" > if that would suit our needs. > > So my question is if we want one capability per-human interaction device > or multiple? > > Option 1, one-per: > > 1. touchScreen capability > 2. mouse capability > 3. drawingPad capability > > Option 2, one that returns a set > "interactionDevices" capability with "touchScreen", "mouse", "drawingPad", > etc. > > If using the former, we could have strings returned and not boolean > (touchScreen could return "multiTouch", "singleTouch"). Not sure how that > would look for option 2 other than a Map<String, String> being returned, but > that API seems a bit ugly to me with having to down-cast the capability > value to a generic collection. > > Thoughts? > > On Mon, Jun 13, 2011 at 10:31 AM, Blake Sullivan < > blake.sulli...@oracle.com> wrote: > >> On 6/13/11 9:22 AM, Andrew Robinson wrote: >> >> https://issues.apache.org/jira/browse/TRINIDAD-2108 >> >> I am proposing to add a new Agent capability for touch devices. >> >> It would involve adding: >> static public final CapabilityKey CAP_TOUCH_SCREEN = >> CapabilityKey.getCapabilityKey("touchScreen", true); >> >> To org.apache.myfaces.trinidadinternal.agent.TrinidadAgent. And also >> adding the code to add this for the Andoid and iOS devices. >> >> Any comments? Name of the key sound reasonable to everyone? >> >> Thanks, >> Andrew >> >> I think that we want to consider the cases where the device supports >> both touch gestures and other input devices at the same time. So, it >> depends on the expected usage. Are consumers of this api supposed to use it >> to query whether the device could send them touch events, or are they >> expected to use it to determine whether the device is primarily touch? If >> it is for the first case, then I think we should expand the values to >> encompass the quality of the touch events. For example, is multi-touch >> supported? Anyway, we know from experience that we really don't want to ever >> add any boolean values. >> >> -- Blake Sullivan >> >> > >
