Cordova Plugins with Native Callbacks

[Aaron Charbonneau]

Hi,
Does anyone know of any Cordova plugin implementations that do a roundtrip
of callbacks?  For example on Android something like:
1.) JS calls cordova plugin exec function providing a CallbackContext
2.) Java calls C++ native function, wants CallbackContext called when that
function is complete

Calling a function defined in the JNI layer when the native function is
complete I’ve got, but what I’m having trouble piecing together is how to
call the correct CallbackContext from there, taking into account threading
and asynchronicity, I assume we need to retain a reference to the correct
CallbackContext, but what is a good way to match the native operation with
that exact CallbackContext? Unique Id passed into the native function and a
dictionary on the Java side?  Seems passing custom objects(not classes)
into native is not an option.  Curious if anyone has tackled this before.

Thanks!
Aaron

Re: plugin.xml config-file setting not copying all tags

[Anis KADRI]

the access tag should be top-level (as a common practice) but it should
work anywayweird...


On Thu, Apr 18, 2013 at 12:22 PM, Filip Maj  wrote:

> Bug, file that shizzle yo
>
> On 4/18/13 12:19 PM, "Michal Mocny"  wrote:
>
> >Anis/Fil:
> >
> >I've got a plugin that contains the following in the ios platform section:
> >
> >
> >  
> >   >src="chrome-extension://ohgfbmefaoadakchflddcopcmphnlcba/chromeapp.html"
> >/>
> >
> >
> >The content tag is being copied fine, but the access tag is not (!).  I
> >was
> >under the impression that config-file would do a raw copy over to platform
> >config?  Are we whitelisting/blacklisting tags somehow?  Bug?  User error?
> >
> >-Michal
>
>

Re: 2.7 for Adobe Max?

[Michael Brooks]

Sure Andrew. Alternatively, you can update the WIki to references the
README.md section.

Personally, I like keeping the release instructions with the project source
code. I know others have different opinions on that.

Michael


On Thu, Apr 18, 2013 at 3:04 PM, Andrew Grieve  wrote:

> Michael also pointed out that there are also release time instructions in
> cordova-app-hello-world's README.md file.
>
> I'd like to move these to the wiki as well.
>
>
> On Thu, Apr 18, 2013 at 4:16 PM, Andrew Grieve 
> wrote:
>
> > Good catch. I did update the version for cordova-js.
> >
> > Incrementing the version is in the Android release checklist on the wiki,
> > but it's not in the list of JIRA sub-tasks. I also failed to update
> release
> > notes.
> >
> > I think I actually like it better on the wiki, and maybe we can just
> point
> > to the wiki from the generate JIRA task?
> > I would put "updating JS" and "copying hello world app" under the same
> > category. They should be on the wiki and not as JIRA issues.
> >
> > Sound alright? If so, I'll make the changes.
> >
> >
> > On Thu, Apr 18, 2013 at 4:08 PM, Joe Bowser  wrote:
> >
> >> Remember to increment the versions.  I had to re-tag on Android
> >> because the version wasn't incremented.  Did it get incremented on
> >> cordova-js?  If not, we'll have to re-tag again.
> >>
> >> On Thu, Apr 18, 2013 at 12:49 PM, Andrew Grieve 
> >> wrote:
> >> > Also wanted to remind that we can still re-tag, but should not be
> doing
> >> any
> >> > merges between branches. Cherry-picks only.
> >> >
> >> >
> >> > On Thu, Apr 18, 2013 at 3:45 PM, Andrew Grieve 
> >> wrote:
> >> >
> >> >> Alrighty!
> >> >>
> >> >> Thanks Joe for creating the JIRA issues!
> >> >>
> >> >> What I just did:
> >> >> - branched & tagged cordova-js.
> >> >> - closed all of the sample-app issues after merging it into iOS
> showed
> >> >> there to be no changes.
> >> >> - for Android & iOS: updated the JS, branched & tagged
> >> >> - updated the CuttingReleases wiki page (still had the old
> master/next
> >> >> system on it)
> >> >>
> >> >> I haven't run mobile spec at all yet (did run the iOS unit tests
> >> though).
> >> >>
> >> >> I'm going to spend some time looking at CB-2698 before doing any
> mobile
> >> >> spec testing. Feel free to follow the master bug to see what else
> needs
> >> >> doing:
> >> >>
> >> >> https://issues.apache.org/jira/browse/CB-3072
> >> >>
> >> >> Andrew
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> On Thu, Apr 18, 2013 at 11:20 AM, Andrew Grieve <
> agri...@chromium.org
> >> >wrote:
> >> >>
> >> >>> New goal - let's aim for today!
> >> >>>
> >> >>>
> >> >>> I'd like to take a look and at CB-2698, but since this is
> iOS-specific
> >> >>> (and native-code only), I'll go ahead with creating issues &
> >> branching the
> >> >>> JS. If CB-2698 gets fixed, we can cherry-pick it.
> >> >>>
> >> >>>
> >> >>> On Tue, Apr 16, 2013 at 2:45 PM, Giorgio Natili <
> >> g.nat...@gnstudio.com>wrote:
> >> >>>
> >>  +1
> >> 
> >>  On 4/16/13 7:52 PM, "Filip Maj"  wrote:
> >> 
> >>  >+1.
> >>  >
> >>  >So, how do we feel about starting an RC soon?
> >>  >
> >>  >On 4/16/13 10:19 AM, "Brian LeRoux"  wrote:
> >>  >
> >>  >>It would be ideal to see 2.7 ship before the month is out for
> sure.
> >>  >>
> >>  >>
> >>  >>On Tue, Apr 16, 2013 at 7:41 AM, Joe Bowser 
> >> wrote:
> >>  >>
> >>  >>> I think that this would be a good thing.  It'd be nice to get a
> >>  >>> released lined up for Conf-Month! (Adobe Max, Google IO,
> JSConf,
> >>  etc).
> >>  >>>
> >>  >>> On Tue, Apr 16, 2013 at 7:35 AM, Andrew Grieve <
> >> agri...@chromium.org
> >>  >
> >>  >>> wrote:
> >>  >>> > Wanted to see what people thought of trying to get 2.7 out
> the
> >> door
> >>  >>>in
> >>  >>> time
> >>  >>> > for Adobe Max. The main motivation I see is to have a version
> >> that
> >>  >>>will
> >>  >>> > work the "future" branch of CLI. 2.6 is missing the
> >>  plugin_loader.js
> >>  >>>code
> >>  >>> > required to load a plugin's JS.
> >>  >>>
> >>  >
> >> 
> >> 
> >> 
> >> >>>
> >> >>
> >>
> >
> >
>

Re: Migrating to

[Filip Maj]

Set up issues to deprecate  in favor of  [1] and then
remove it in 3.0 [2].

[1] https://issues.apache.org/jira/browse/CB-3164
[2] https://issues.apache.org/jira/browse/CB-3172

On 4/18/13 5:48 AM, "Lucas Holmquist"  wrote:

>+1
>On Apr 18, 2013, at 7:29 AM, Giorgio Natili  wrote:
>
>> +1
>> 
>> On 4/17/13 10:37 PM, "Lorin Beer"  wrote:
>> 
>>> +1
>>> 
>>> 
>>> On Wed, Apr 17, 2013 at 1:20 PM, Jeffrey Heifetz
>>> wrote:
>>> 
 +1
 
 On 13-04-17 4:14 PM, "Joe Bowser"  wrote:
 
> +1 for deprecate now, remove 3.0
> 
> On Wed, Apr 17, 2013 at 12:15 PM, Shazron  wrote:
>> +1 for deprecate now, remove 3.0
>> 
>> 
>> On Wed, Apr 17, 2013 at 10:00 AM, Filip Maj  wrote:
>> 
>>> My vote is to set up deprecation of plugin now, and remove it
>>> completely
>>> for 3.0. Our tooling should be able to handle this stuff by then..
>>> 
>>> On 4/16/13 8:23 PM, "Joe Bowser"  wrote:
>>> 
 Only when we decide to drop plugin.
 On Apr 16, 2013 8:14 PM, "Filip Maj"  wrote:
 
> https://issues.apache.org/jira/browse/CB-1109
> 
> 
> We need to add a deprecation notice to change this, is that
 right?
> 
> 
>>> 
>>> 
 
 
 -
 This transmission (including any attachments) may contain confidential
 information, privileged material (including material protected by the
 solicitor-client or other applicable privileges), or constitute
 non-public
 information. Any use of this information by anyone other than the
 intended
 recipient is prohibited. If you have received this transmission in
 error,
 please immediately reply to the sender and delete this information
from
 your system. Use, dissemination, distribution, or reproduction of this
 transmission by unintended recipients is not authorized and may be
 unlawful.
 
>> 
>> 
>

Re: SysApps moving app: URI to first public working draft

[Brian LeRoux]

I really like this spec but suspect we want to hold off until post 3.x
to be safe.


On Thu, Apr 18, 2013 at 2:20 PM, Filip Maj  wrote:
> TL;DR this is a way to solve the "how to reference in-app package contents
> in a platform-agnostic fashion"
>
> Relevant to us because it would solve a mammoth / ancient issue that's
> been around for us [1].
>
> The full proposal is here [2].
>
>
> FirefoxOS already uses this. Chrome apps use a version of this (a la
> chrome-extension://). Opera used essentially this proposal for their
> widgets using the widget:// URI.
>
> I suggest that we tackle this post-3.0? Thoughts?
>
> [1] https://issues.apache.org/jira/browse/CB-285
>
> [2] http://app-uri.sysapps.org/
>
>

SysApps moving app: URI to first public working draft

[Filip Maj]

TL;DR this is a way to solve the "how to reference in-app package contents
in a platform-agnostic fashion"

Relevant to us because it would solve a mammoth / ancient issue that's
been around for us [1].

The full proposal is here [2].


FirefoxOS already uses this. Chrome apps use a version of this (a la
chrome-extension://). Opera used essentially this proposal for their
widgets using the widget:// URI.

I suggest that we tackle this post-3.0? Thoughts?

[1] https://issues.apache.org/jira/browse/CB-285

[2] http://app-uri.sysapps.org/

Re: plugman + plugin spec final q's

[Jesse]

We shouldn't insist if we don't have to. Me thinks.

@purplecabbage
risingj.com


On Thu, Apr 18, 2013 at 1:58 PM, Filip Maj  wrote:

>
> >The  tidbit might make it necessary to special
> >case permissions.
> >
> >E.g. the app sets a permission with required=true, then a plugin adds the
> >permission as well. We go to de-dupe, what happens? We'll need logic to
> >properly combine the two.
>
> My answer: if both app and plugin require the same permission, but one is
> qualified higher (I.e. More attributes or w/e), the more specific elements
> remain.
>
> >For native code added by the app developer, shouldn't we be insisting that
> >they try to do so by writing an app-specific plugin?
>
> I think so.
>
>

Re: 2.7 for Adobe Max?

[Andrew Grieve]

Michael also pointed out that there are also release time instructions in
cordova-app-hello-world's README.md file.

I'd like to move these to the wiki as well.


On Thu, Apr 18, 2013 at 4:16 PM, Andrew Grieve  wrote:

> Good catch. I did update the version for cordova-js.
>
> Incrementing the version is in the Android release checklist on the wiki,
> but it's not in the list of JIRA sub-tasks. I also failed to update release
> notes.
>
> I think I actually like it better on the wiki, and maybe we can just point
> to the wiki from the generate JIRA task?
> I would put "updating JS" and "copying hello world app" under the same
> category. They should be on the wiki and not as JIRA issues.
>
> Sound alright? If so, I'll make the changes.
>
>
> On Thu, Apr 18, 2013 at 4:08 PM, Joe Bowser  wrote:
>
>> Remember to increment the versions.  I had to re-tag on Android
>> because the version wasn't incremented.  Did it get incremented on
>> cordova-js?  If not, we'll have to re-tag again.
>>
>> On Thu, Apr 18, 2013 at 12:49 PM, Andrew Grieve 
>> wrote:
>> > Also wanted to remind that we can still re-tag, but should not be doing
>> any
>> > merges between branches. Cherry-picks only.
>> >
>> >
>> > On Thu, Apr 18, 2013 at 3:45 PM, Andrew Grieve 
>> wrote:
>> >
>> >> Alrighty!
>> >>
>> >> Thanks Joe for creating the JIRA issues!
>> >>
>> >> What I just did:
>> >> - branched & tagged cordova-js.
>> >> - closed all of the sample-app issues after merging it into iOS showed
>> >> there to be no changes.
>> >> - for Android & iOS: updated the JS, branched & tagged
>> >> - updated the CuttingReleases wiki page (still had the old master/next
>> >> system on it)
>> >>
>> >> I haven't run mobile spec at all yet (did run the iOS unit tests
>> though).
>> >>
>> >> I'm going to spend some time looking at CB-2698 before doing any mobile
>> >> spec testing. Feel free to follow the master bug to see what else needs
>> >> doing:
>> >>
>> >> https://issues.apache.org/jira/browse/CB-3072
>> >>
>> >> Andrew
>> >>
>> >>
>> >>
>> >>
>> >> On Thu, Apr 18, 2013 at 11:20 AM, Andrew Grieve > >wrote:
>> >>
>> >>> New goal - let's aim for today!
>> >>>
>> >>>
>> >>> I'd like to take a look and at CB-2698, but since this is iOS-specific
>> >>> (and native-code only), I'll go ahead with creating issues &
>> branching the
>> >>> JS. If CB-2698 gets fixed, we can cherry-pick it.
>> >>>
>> >>>
>> >>> On Tue, Apr 16, 2013 at 2:45 PM, Giorgio Natili <
>> g.nat...@gnstudio.com>wrote:
>> >>>
>>  +1
>> 
>>  On 4/16/13 7:52 PM, "Filip Maj"  wrote:
>> 
>>  >+1.
>>  >
>>  >So, how do we feel about starting an RC soon?
>>  >
>>  >On 4/16/13 10:19 AM, "Brian LeRoux"  wrote:
>>  >
>>  >>It would be ideal to see 2.7 ship before the month is out for sure.
>>  >>
>>  >>
>>  >>On Tue, Apr 16, 2013 at 7:41 AM, Joe Bowser 
>> wrote:
>>  >>
>>  >>> I think that this would be a good thing.  It'd be nice to get a
>>  >>> released lined up for Conf-Month! (Adobe Max, Google IO, JSConf,
>>  etc).
>>  >>>
>>  >>> On Tue, Apr 16, 2013 at 7:35 AM, Andrew Grieve <
>> agri...@chromium.org
>>  >
>>  >>> wrote:
>>  >>> > Wanted to see what people thought of trying to get 2.7 out the
>> door
>>  >>>in
>>  >>> time
>>  >>> > for Adobe Max. The main motivation I see is to have a version
>> that
>>  >>>will
>>  >>> > work the "future" branch of CLI. 2.6 is missing the
>>  plugin_loader.js
>>  >>>code
>>  >>> > required to load a plugin's JS.
>>  >>>
>>  >
>> 
>> 
>> 
>> >>>
>> >>
>>
>
>

Re: plugman + plugin spec final q's

[Filip Maj]

>The  tidbit might make it necessary to special
>case permissions.
>
>E.g. the app sets a permission with required=true, then a plugin adds the
>permission as well. We go to de-dupe, what happens? We'll need logic to
>properly combine the two.

My answer: if both app and plugin require the same permission, but one is
qualified higher (I.e. More attributes or w/e), the more specific elements
remain.

>For native code added by the app developer, shouldn't we be insisting that
>they try to do so by writing an app-specific plugin?

I think so.

Re: Point release for 2.6.1?

[Brian LeRoux]

Agree on 2.7 and love the idea for a regression label. Would be a good
'first bug' for folks new to the project to help cut support releases.

Here's a battery of queries, how do we decide we need a MINOR point
release? can it be just one issue cherry picked? does it need to be fully
packaged or is a tag enough?



On Thu, Apr 18, 2013 at 12:48 PM, Andrew Grieve wrote:

> We had previously discussed creating a 2.6.1 point release that had only
> stability fixes in it since 2.6.0, but no feature changes.
>
> Does anyone want to follow through with it for this round? I'm leaning
> towards focusing all efforts on making sure 2.7.0 is extra solid since
> we'll be promoting during "conference month".
>
> One thing I'm wondering is if it might be easier to do this if we added a
> "Regression" label to all issues that we would like cherry-picked into
> point releases. As of right now, we'll have to go through the commit log
> and manually figure out what changes fit the category and cherry-pick them.
>

Re: 2.7 for Adobe Max?

[Andrew Grieve]

Good catch. I did update the version for cordova-js.

Incrementing the version is in the Android release checklist on the wiki,
but it's not in the list of JIRA sub-tasks. I also failed to update release
notes.

I think I actually like it better on the wiki, and maybe we can just point
to the wiki from the generate JIRA task?
I would put "updating JS" and "copying hello world app" under the same
category. They should be on the wiki and not as JIRA issues.

Sound alright? If so, I'll make the changes.


On Thu, Apr 18, 2013 at 4:08 PM, Joe Bowser  wrote:

> Remember to increment the versions.  I had to re-tag on Android
> because the version wasn't incremented.  Did it get incremented on
> cordova-js?  If not, we'll have to re-tag again.
>
> On Thu, Apr 18, 2013 at 12:49 PM, Andrew Grieve 
> wrote:
> > Also wanted to remind that we can still re-tag, but should not be doing
> any
> > merges between branches. Cherry-picks only.
> >
> >
> > On Thu, Apr 18, 2013 at 3:45 PM, Andrew Grieve 
> wrote:
> >
> >> Alrighty!
> >>
> >> Thanks Joe for creating the JIRA issues!
> >>
> >> What I just did:
> >> - branched & tagged cordova-js.
> >> - closed all of the sample-app issues after merging it into iOS showed
> >> there to be no changes.
> >> - for Android & iOS: updated the JS, branched & tagged
> >> - updated the CuttingReleases wiki page (still had the old master/next
> >> system on it)
> >>
> >> I haven't run mobile spec at all yet (did run the iOS unit tests
> though).
> >>
> >> I'm going to spend some time looking at CB-2698 before doing any mobile
> >> spec testing. Feel free to follow the master bug to see what else needs
> >> doing:
> >>
> >> https://issues.apache.org/jira/browse/CB-3072
> >>
> >> Andrew
> >>
> >>
> >>
> >>
> >> On Thu, Apr 18, 2013 at 11:20 AM, Andrew Grieve  >wrote:
> >>
> >>> New goal - let's aim for today!
> >>>
> >>>
> >>> I'd like to take a look and at CB-2698, but since this is iOS-specific
> >>> (and native-code only), I'll go ahead with creating issues & branching
> the
> >>> JS. If CB-2698 gets fixed, we can cherry-pick it.
> >>>
> >>>
> >>> On Tue, Apr 16, 2013 at 2:45 PM, Giorgio Natili  >wrote:
> >>>
>  +1
> 
>  On 4/16/13 7:52 PM, "Filip Maj"  wrote:
> 
>  >+1.
>  >
>  >So, how do we feel about starting an RC soon?
>  >
>  >On 4/16/13 10:19 AM, "Brian LeRoux"  wrote:
>  >
>  >>It would be ideal to see 2.7 ship before the month is out for sure.
>  >>
>  >>
>  >>On Tue, Apr 16, 2013 at 7:41 AM, Joe Bowser 
> wrote:
>  >>
>  >>> I think that this would be a good thing.  It'd be nice to get a
>  >>> released lined up for Conf-Month! (Adobe Max, Google IO, JSConf,
>  etc).
>  >>>
>  >>> On Tue, Apr 16, 2013 at 7:35 AM, Andrew Grieve <
> agri...@chromium.org
>  >
>  >>> wrote:
>  >>> > Wanted to see what people thought of trying to get 2.7 out the
> door
>  >>>in
>  >>> time
>  >>> > for Adobe Max. The main motivation I see is to have a version
> that
>  >>>will
>  >>> > work the "future" branch of CLI. 2.6 is missing the
>  plugin_loader.js
>  >>>code
>  >>> > required to load a plugin's JS.
>  >>>
>  >
> 
> 
> 
> >>>
> >>
>

RE: Standardized gestures

[jbo...@openmv.com]

> Yes, it may have value. Consider writing a plugin.
> The pointer events spec[1] may be of interest, as things like tap/slide/pinch 
> are all non-standard.
> I did this exact same thing [2] for Windows Phone 7, as there aren't even 
> mouse events.

Super thanks for the helpful info, 

I'll try to wrap this into a plugin.

Re: 2.7 for Adobe Max?

[Joe Bowser]

Remember to increment the versions.  I had to re-tag on Android
because the version wasn't incremented.  Did it get incremented on
cordova-js?  If not, we'll have to re-tag again.

On Thu, Apr 18, 2013 at 12:49 PM, Andrew Grieve  wrote:
> Also wanted to remind that we can still re-tag, but should not be doing any
> merges between branches. Cherry-picks only.
>
>
> On Thu, Apr 18, 2013 at 3:45 PM, Andrew Grieve  wrote:
>
>> Alrighty!
>>
>> Thanks Joe for creating the JIRA issues!
>>
>> What I just did:
>> - branched & tagged cordova-js.
>> - closed all of the sample-app issues after merging it into iOS showed
>> there to be no changes.
>> - for Android & iOS: updated the JS, branched & tagged
>> - updated the CuttingReleases wiki page (still had the old master/next
>> system on it)
>>
>> I haven't run mobile spec at all yet (did run the iOS unit tests though).
>>
>> I'm going to spend some time looking at CB-2698 before doing any mobile
>> spec testing. Feel free to follow the master bug to see what else needs
>> doing:
>>
>> https://issues.apache.org/jira/browse/CB-3072
>>
>> Andrew
>>
>>
>>
>>
>> On Thu, Apr 18, 2013 at 11:20 AM, Andrew Grieve wrote:
>>
>>> New goal - let's aim for today!
>>>
>>>
>>> I'd like to take a look and at CB-2698, but since this is iOS-specific
>>> (and native-code only), I'll go ahead with creating issues & branching the
>>> JS. If CB-2698 gets fixed, we can cherry-pick it.
>>>
>>>
>>> On Tue, Apr 16, 2013 at 2:45 PM, Giorgio Natili 
>>> wrote:
>>>
 +1

 On 4/16/13 7:52 PM, "Filip Maj"  wrote:

 >+1.
 >
 >So, how do we feel about starting an RC soon?
 >
 >On 4/16/13 10:19 AM, "Brian LeRoux"  wrote:
 >
 >>It would be ideal to see 2.7 ship before the month is out for sure.
 >>
 >>
 >>On Tue, Apr 16, 2013 at 7:41 AM, Joe Bowser  wrote:
 >>
 >>> I think that this would be a good thing.  It'd be nice to get a
 >>> released lined up for Conf-Month! (Adobe Max, Google IO, JSConf,
 etc).
 >>>
 >>> On Tue, Apr 16, 2013 at 7:35 AM, Andrew Grieve >>> >
 >>> wrote:
 >>> > Wanted to see what people thought of trying to get 2.7 out the door
 >>>in
 >>> time
 >>> > for Adobe Max. The main motivation I see is to have a version that
 >>>will
 >>> > work the "future" branch of CLI. 2.6 is missing the
 plugin_loader.js
 >>>code
 >>> > required to load a plugin's JS.
 >>>
 >



>>>
>>

Re: 2.7 for Adobe Max?

[Andrew Grieve]

Also wanted to remind that we can still re-tag, but should not be doing any
merges between branches. Cherry-picks only.


On Thu, Apr 18, 2013 at 3:45 PM, Andrew Grieve  wrote:

> Alrighty!
>
> Thanks Joe for creating the JIRA issues!
>
> What I just did:
> - branched & tagged cordova-js.
> - closed all of the sample-app issues after merging it into iOS showed
> there to be no changes.
> - for Android & iOS: updated the JS, branched & tagged
> - updated the CuttingReleases wiki page (still had the old master/next
> system on it)
>
> I haven't run mobile spec at all yet (did run the iOS unit tests though).
>
> I'm going to spend some time looking at CB-2698 before doing any mobile
> spec testing. Feel free to follow the master bug to see what else needs
> doing:
>
> https://issues.apache.org/jira/browse/CB-3072
>
> Andrew
>
>
>
>
> On Thu, Apr 18, 2013 at 11:20 AM, Andrew Grieve wrote:
>
>> New goal - let's aim for today!
>>
>>
>> I'd like to take a look and at CB-2698, but since this is iOS-specific
>> (and native-code only), I'll go ahead with creating issues & branching the
>> JS. If CB-2698 gets fixed, we can cherry-pick it.
>>
>>
>> On Tue, Apr 16, 2013 at 2:45 PM, Giorgio Natili wrote:
>>
>>> +1
>>>
>>> On 4/16/13 7:52 PM, "Filip Maj"  wrote:
>>>
>>> >+1.
>>> >
>>> >So, how do we feel about starting an RC soon?
>>> >
>>> >On 4/16/13 10:19 AM, "Brian LeRoux"  wrote:
>>> >
>>> >>It would be ideal to see 2.7 ship before the month is out for sure.
>>> >>
>>> >>
>>> >>On Tue, Apr 16, 2013 at 7:41 AM, Joe Bowser  wrote:
>>> >>
>>> >>> I think that this would be a good thing.  It'd be nice to get a
>>> >>> released lined up for Conf-Month! (Adobe Max, Google IO, JSConf,
>>> etc).
>>> >>>
>>> >>> On Tue, Apr 16, 2013 at 7:35 AM, Andrew Grieve >> >
>>> >>> wrote:
>>> >>> > Wanted to see what people thought of trying to get 2.7 out the door
>>> >>>in
>>> >>> time
>>> >>> > for Adobe Max. The main motivation I see is to have a version that
>>> >>>will
>>> >>> > work the "future" branch of CLI. 2.6 is missing the
>>> plugin_loader.js
>>> >>>code
>>> >>> > required to load a plugin's JS.
>>> >>>
>>> >
>>>
>>>
>>>
>>
>

Point release for 2.6.1?

[Andrew Grieve]

We had previously discussed creating a 2.6.1 point release that had only
stability fixes in it since 2.6.0, but no feature changes.

Does anyone want to follow through with it for this round? I'm leaning
towards focusing all efforts on making sure 2.7.0 is extra solid since
we'll be promoting during "conference month".

One thing I'm wondering is if it might be easier to do this if we added a
"Regression" label to all issues that we would like cherry-picked into
point releases. As of right now, we'll have to go through the commit log
and manually figure out what changes fit the category and cherry-pick them.

Re: 2.7 for Adobe Max?

[Andrew Grieve]

Alrighty!

Thanks Joe for creating the JIRA issues!

What I just did:
- branched & tagged cordova-js.
- closed all of the sample-app issues after merging it into iOS showed
there to be no changes.
- for Android & iOS: updated the JS, branched & tagged
- updated the CuttingReleases wiki page (still had the old master/next
system on it)

I haven't run mobile spec at all yet (did run the iOS unit tests though).

I'm going to spend some time looking at CB-2698 before doing any mobile
spec testing. Feel free to follow the master bug to see what else needs
doing:

https://issues.apache.org/jira/browse/CB-3072

Andrew




On Thu, Apr 18, 2013 at 11:20 AM, Andrew Grieve wrote:

> New goal - let's aim for today!
>
>
> I'd like to take a look and at CB-2698, but since this is iOS-specific
> (and native-code only), I'll go ahead with creating issues & branching the
> JS. If CB-2698 gets fixed, we can cherry-pick it.
>
>
> On Tue, Apr 16, 2013 at 2:45 PM, Giorgio Natili wrote:
>
>> +1
>>
>> On 4/16/13 7:52 PM, "Filip Maj"  wrote:
>>
>> >+1.
>> >
>> >So, how do we feel about starting an RC soon?
>> >
>> >On 4/16/13 10:19 AM, "Brian LeRoux"  wrote:
>> >
>> >>It would be ideal to see 2.7 ship before the month is out for sure.
>> >>
>> >>
>> >>On Tue, Apr 16, 2013 at 7:41 AM, Joe Bowser  wrote:
>> >>
>> >>> I think that this would be a good thing.  It'd be nice to get a
>> >>> released lined up for Conf-Month! (Adobe Max, Google IO, JSConf, etc).
>> >>>
>> >>> On Tue, Apr 16, 2013 at 7:35 AM, Andrew Grieve 
>> >>> wrote:
>> >>> > Wanted to see what people thought of trying to get 2.7 out the door
>> >>>in
>> >>> time
>> >>> > for Adobe Max. The main motivation I see is to have a version that
>> >>>will
>> >>> > work the "future" branch of CLI. 2.6 is missing the plugin_loader.js
>> >>>code
>> >>> > required to load a plugin's JS.
>> >>>
>> >
>>
>>
>>
>

Re: Ian Clelland is now a Cordova Committer

[Benn Mapes]

Congrats Ian!


On Thu, Apr 18, 2013 at 12:28 PM, Ian Clelland  wrote:

> Thanks, everyone!
>
> I probably should have introduced myself last month, when I started. I
> guess I just got too busy right away with the code :)
>
> Ian
>
>
> On Thu, Apr 18, 2013 at 10:43 AM, James Jong  wrote:
>
> > Welcome Ian!
> > -James Jong
> >
> > On Apr 18, 2013, at 10:20 AM, Andrew Grieve 
> wrote:
> >
> > > Wanted to publicly announce that Ian is now a Cordova committer!
> > >
> > > Ian started working on Cordova just over a month ago and has already
> made
> > > many big changes. To highlight a few:
> > >
> > > - FileTransfer progress events for gzipped responses
> > > - executeScript and insertCss for InAppBrowser
> > > - Figuring out exactly why FileTransfer fails *every other request*
> > > sometimes (CB-2293 )
> > >
> > > Thanks Ian, and welcome aboard!
> > >
> > > Andrew
> >
> >
>

Re: Ian Clelland is now a Cordova Committer

[Ian Clelland]

Thanks, everyone!

I probably should have introduced myself last month, when I started. I
guess I just got too busy right away with the code :)

Ian


On Thu, Apr 18, 2013 at 10:43 AM, James Jong  wrote:

> Welcome Ian!
> -James Jong
>
> On Apr 18, 2013, at 10:20 AM, Andrew Grieve  wrote:
>
> > Wanted to publicly announce that Ian is now a Cordova committer!
> >
> > Ian started working on Cordova just over a month ago and has already made
> > many big changes. To highlight a few:
> >
> > - FileTransfer progress events for gzipped responses
> > - executeScript and insertCss for InAppBrowser
> > - Figuring out exactly why FileTransfer fails *every other request*
> > sometimes (CB-2293 )
> >
> > Thanks Ian, and welcome aboard!
> >
> > Andrew
>
>

Re: plugin.xml config-file setting not copying all tags

[Filip Maj]

Bug, file that shizzle yo

On 4/18/13 12:19 PM, "Michal Mocny"  wrote:

>Anis/Fil:
>
>I've got a plugin that contains the following in the ios platform section:
>
>
>  
>  src="chrome-extension://ohgfbmefaoadakchflddcopcmphnlcba/chromeapp.html"
>/>
>
>
>The content tag is being copied fine, but the access tag is not (!).  I
>was
>under the impression that config-file would do a raw copy over to platform
>config?  Are we whitelisting/blacklisting tags somehow?  Bug?  User error?
>
>-Michal

plugin.xml config-file setting not copying all tags

[Michal Mocny]

Anis/Fil:

I've got a plugin that contains the following in the ios platform section:


  
  


The content tag is being copied fine, but the access tag is not (!).  I was
under the impression that config-file would do a raw copy over to platform
config?  Are we whitelisting/blacklisting tags somehow?  Bug?  User error?

-Michal

Re: BlackBerry BB10 Repos on GitHub

[Bryan Higgins]

I should also mention that we've got a backlog of issues internally which
we're actively working on.

Once this gets merged into apache we'll start utilizing JIRA for that.

Features that should be coming in the near future are:
- Contacts, Globalization and FileTransfer plugins
- implementation of the new cordova/lib scripts
- validation of cordova/build, run, etc against the newly agreed upon
definitions
- remove plugins.json logic now that it has been implemented in cordova-js
(as cordova_plugins.json)

I can add these as sub-issues right now if that helps with tracking.


On Thu, Apr 18, 2013 at 2:41 PM, Lorin Beer wrote:

> excellent, thanks Bryan!
>
>
> On Thu, Apr 18, 2013 at 11:37 AM, Bryan Higgins  >wrote:
>
> > Thanks Lorin
> >
> > Looking forward to the feedback :)
> >
> > We're working off 'blackberry10' branch now which was somewhat recently
> > rebased from apache master.
> >
> >
> > On Thu, Apr 18, 2013 at 2:34 PM, Lorin Beer  > >wrote:
> >
> > > Hey guys,
> > >
> > > I'm tracking those issues we deem necessary to solve before we start
> the
> > > migration process of BB's new implementation of Cordova for BB10 and
> > > PlayBook.
> > >
> > > Master Issue lives here: https://issues.apache.org/jira/browse/CB-3070
> > > I'll be populating this with subissues.
> > >
> > > An issue of confusion: the blackberry github
> > > reposeems to have
> > > been push -f with Cordova's existing implementation. What
> > > happened to your codes?
> > >
> > >
> > > - Lorin
> > >
> > >
> > > On Mon, Apr 15, 2013 at 10:51 AM, Filip Maj  wrote:
> > >
> > > > Go with a pull req / side branch for now and give everyone a month to
> > > poke
> > > > at it.
> > > >
> > > > On 4/15/13 10:43 AM, "Jeffrey Heifetz" 
> > wrote:
> > > >
> > > > >Sounds awesome. Should we issue a pull request and someone will push
> > to
> > > a
> > > > >branch, or would you like to give myself or Bryan commit access to
> do
> > it
> > > > >ourselves.
> > > > >
> > > > >We can push a "blackberry10" branch for everyone to look at and
> > continue
> > > > >to update there while giving the community a chance to play.
> > > > >
> > > > >As per the timeline I know I just said 2.7, but with only two weeks,
> > > maybe
> > > > >we should spend a large amount of time on our porting guide to make
> > sure
> > > > >all current cordova bb10 developers understand the changes.
> > > > >
> > > > >On 13-04-15 1:20 PM, "Filip Maj"  wrote:
> > > > >
> > > > >>+1
> > > > >>
> > > > >>Pretty sure we can rewrite any history so it would probably be two
> > > > >>commits: a giant delete and a giant add.
> > > > >>
> > > > >>On 4/15/13 10:14 AM, "Brian LeRoux"  wrote:
> > > > >>
> > > > >>>Yep. Could be as simple as a hard reset to the latest SHA from
> > GitHub
> > > if
> > > > >>>the above is fulfilled. (Maybe start it in a new branch on Apache
> > Git
> > > > >>>for
> > > > >>>us to review in the meantime.)
> > > > >>>
> > > > >>>
> > > > >>>On Mon, Apr 15, 2013 at 10:04 AM, Filip Maj 
> wrote:
> > > > >>>
> > > >  WRT to BlackBerry since node is already required, it's not an
> > > "extra"
> > > >  dependency. The other thread is related to Android (and possibly
> > > >  iOS/windows).
> > > > 
> > > >  As long as the new BB repo supports:
> > > > 
> > > >  1. Plugin design and documentation on how to do so
> > > >  2. Command line scripts [1]
> > > >  3. Can run mobile spec and passes at a reasonable rate
> > > > 
> > > >  .. Im happy
> > > > 
> > > >  [1] http://wiki.apache.org/cordova/CommandLineToolingDesign
> > > > 
> > > >  On 4/15/13 9:45 AM, "Lorin Beer" 
> > wrote:
> > > > 
> > > >  >First steps are to bring your repo in line with the current
> > > workflow
> > > > and
> > > >  >cross platform tool chain.
> > > >  >A for instance is the create script: the other platforms use
> bash
> > > > scripts
> > > >  >for the 'create' command, and BlackBerry's BB10 repo is
> dependent
> > > on
> > > > Node.
> > > >  >There is an ongoing discussion on the list concerning node as a
> > > > dependency
> > > >  >for our build toolchain, which I would encourage you to chime
> in
> > > on.
> > > >  >
> > > >  >
> > > >  >
> > > >  >On Mon, Apr 15, 2013 at 9:09 AM, Jeffrey Heifetz
> > > >  >wrote:
> > > >  >
> > > >  >> So now that the code has been out for a bit we'd like to
> start
> > > > talking
> > > >  >> about getting the code into the 2.7 release.
> > > >  >>
> > > >  >> There are no longer any hacks or hoops to getting it running
> > and
> > > > anyone
> > > >  >> interested can try it out. Mobile spec results are about on
> par
> > > > with
> > > > the
> > > >  >> previous implementation and will continue to improve as we
> > > > re-implement
> > > >  >> plugins.
> > > >  >>
> > > >  >> So what is the process for getting a large nu

Re: BlackBerry BB10 Repos on GitHub

[Lorin Beer]

excellent, thanks Bryan!


On Thu, Apr 18, 2013 at 11:37 AM, Bryan Higgins wrote:

> Thanks Lorin
>
> Looking forward to the feedback :)
>
> We're working off 'blackberry10' branch now which was somewhat recently
> rebased from apache master.
>
>
> On Thu, Apr 18, 2013 at 2:34 PM, Lorin Beer  >wrote:
>
> > Hey guys,
> >
> > I'm tracking those issues we deem necessary to solve before we start the
> > migration process of BB's new implementation of Cordova for BB10 and
> > PlayBook.
> >
> > Master Issue lives here: https://issues.apache.org/jira/browse/CB-3070
> > I'll be populating this with subissues.
> >
> > An issue of confusion: the blackberry github
> > reposeems to have
> > been push -f with Cordova's existing implementation. What
> > happened to your codes?
> >
> >
> > - Lorin
> >
> >
> > On Mon, Apr 15, 2013 at 10:51 AM, Filip Maj  wrote:
> >
> > > Go with a pull req / side branch for now and give everyone a month to
> > poke
> > > at it.
> > >
> > > On 4/15/13 10:43 AM, "Jeffrey Heifetz" 
> wrote:
> > >
> > > >Sounds awesome. Should we issue a pull request and someone will push
> to
> > a
> > > >branch, or would you like to give myself or Bryan commit access to do
> it
> > > >ourselves.
> > > >
> > > >We can push a "blackberry10" branch for everyone to look at and
> continue
> > > >to update there while giving the community a chance to play.
> > > >
> > > >As per the timeline I know I just said 2.7, but with only two weeks,
> > maybe
> > > >we should spend a large amount of time on our porting guide to make
> sure
> > > >all current cordova bb10 developers understand the changes.
> > > >
> > > >On 13-04-15 1:20 PM, "Filip Maj"  wrote:
> > > >
> > > >>+1
> > > >>
> > > >>Pretty sure we can rewrite any history so it would probably be two
> > > >>commits: a giant delete and a giant add.
> > > >>
> > > >>On 4/15/13 10:14 AM, "Brian LeRoux"  wrote:
> > > >>
> > > >>>Yep. Could be as simple as a hard reset to the latest SHA from
> GitHub
> > if
> > > >>>the above is fulfilled. (Maybe start it in a new branch on Apache
> Git
> > > >>>for
> > > >>>us to review in the meantime.)
> > > >>>
> > > >>>
> > > >>>On Mon, Apr 15, 2013 at 10:04 AM, Filip Maj  wrote:
> > > >>>
> > >  WRT to BlackBerry since node is already required, it's not an
> > "extra"
> > >  dependency. The other thread is related to Android (and possibly
> > >  iOS/windows).
> > > 
> > >  As long as the new BB repo supports:
> > > 
> > >  1. Plugin design and documentation on how to do so
> > >  2. Command line scripts [1]
> > >  3. Can run mobile spec and passes at a reasonable rate
> > > 
> > >  .. Im happy
> > > 
> > >  [1] http://wiki.apache.org/cordova/CommandLineToolingDesign
> > > 
> > >  On 4/15/13 9:45 AM, "Lorin Beer" 
> wrote:
> > > 
> > >  >First steps are to bring your repo in line with the current
> > workflow
> > > and
> > >  >cross platform tool chain.
> > >  >A for instance is the create script: the other platforms use bash
> > > scripts
> > >  >for the 'create' command, and BlackBerry's BB10 repo is dependent
> > on
> > > Node.
> > >  >There is an ongoing discussion on the list concerning node as a
> > > dependency
> > >  >for our build toolchain, which I would encourage you to chime in
> > on.
> > >  >
> > >  >
> > >  >
> > >  >On Mon, Apr 15, 2013 at 9:09 AM, Jeffrey Heifetz
> > >  >wrote:
> > >  >
> > >  >> So now that the code has been out for a bit we'd like to start
> > > talking
> > >  >> about getting the code into the 2.7 release.
> > >  >>
> > >  >> There are no longer any hacks or hoops to getting it running
> and
> > > anyone
> > >  >> interested can try it out. Mobile spec results are about on par
> > > with
> > > the
> > >  >> previous implementation and will continue to improve as we
> > > re-implement
> > >  >> plugins.
> > >  >>
> > >  >> So what is the process for getting a large number of commits
> into
> > >  >>multiple
> > >  >> repos?
> > >  >>
> > >  >>
> > >  >> On 13-04-08 1:39 PM, "Ken Wallis" 
> > wrote:
> > >  >>
> > >  >> >To a degree I think the architecture has been simplified.  Was
> > not
> > > the
> > >  >> >Cordova APIs calling to WebWorks apis, which then hit native,
> > > whereas
> > >  >>now
> > >  >> >we don't have the WebWorks layer?
> > >  >> >--
> > >  >> >
> > >  >> >Ken Wallis
> > >  >> >
> > >  >> >Product Manager ­ WebWorks
> > >  >> >
> > >  >> >BlackBerry
> > >  >> >
> > >  >> >289-261-4369
> > >  >> >
> > >  >> >
> > >  >> >From: chris.del...@gmail.com [chris.del...@gmail.com] on
> behalf
> > > of
> > >  >>Chris
> > >  >> >DelCol [cdel...@blackberry.com]
> > >  >> >Sent: Monday, April 08, 2013 10:15 AM

Re: BlackBerry BB10 Repos on GitHub

[Bryan Higgins]

Thanks Lorin

Looking forward to the feedback :)

We're working off 'blackberry10' branch now which was somewhat recently
rebased from apache master.


On Thu, Apr 18, 2013 at 2:34 PM, Lorin Beer wrote:

> Hey guys,
>
> I'm tracking those issues we deem necessary to solve before we start the
> migration process of BB's new implementation of Cordova for BB10 and
> PlayBook.
>
> Master Issue lives here: https://issues.apache.org/jira/browse/CB-3070
> I'll be populating this with subissues.
>
> An issue of confusion: the blackberry github
> reposeems to have
> been push -f with Cordova's existing implementation. What
> happened to your codes?
>
>
> - Lorin
>
>
> On Mon, Apr 15, 2013 at 10:51 AM, Filip Maj  wrote:
>
> > Go with a pull req / side branch for now and give everyone a month to
> poke
> > at it.
> >
> > On 4/15/13 10:43 AM, "Jeffrey Heifetz"  wrote:
> >
> > >Sounds awesome. Should we issue a pull request and someone will push to
> a
> > >branch, or would you like to give myself or Bryan commit access to do it
> > >ourselves.
> > >
> > >We can push a "blackberry10" branch for everyone to look at and continue
> > >to update there while giving the community a chance to play.
> > >
> > >As per the timeline I know I just said 2.7, but with only two weeks,
> maybe
> > >we should spend a large amount of time on our porting guide to make sure
> > >all current cordova bb10 developers understand the changes.
> > >
> > >On 13-04-15 1:20 PM, "Filip Maj"  wrote:
> > >
> > >>+1
> > >>
> > >>Pretty sure we can rewrite any history so it would probably be two
> > >>commits: a giant delete and a giant add.
> > >>
> > >>On 4/15/13 10:14 AM, "Brian LeRoux"  wrote:
> > >>
> > >>>Yep. Could be as simple as a hard reset to the latest SHA from GitHub
> if
> > >>>the above is fulfilled. (Maybe start it in a new branch on Apache Git
> > >>>for
> > >>>us to review in the meantime.)
> > >>>
> > >>>
> > >>>On Mon, Apr 15, 2013 at 10:04 AM, Filip Maj  wrote:
> > >>>
> >  WRT to BlackBerry since node is already required, it's not an
> "extra"
> >  dependency. The other thread is related to Android (and possibly
> >  iOS/windows).
> > 
> >  As long as the new BB repo supports:
> > 
> >  1. Plugin design and documentation on how to do so
> >  2. Command line scripts [1]
> >  3. Can run mobile spec and passes at a reasonable rate
> > 
> >  .. Im happy
> > 
> >  [1] http://wiki.apache.org/cordova/CommandLineToolingDesign
> > 
> >  On 4/15/13 9:45 AM, "Lorin Beer"  wrote:
> > 
> >  >First steps are to bring your repo in line with the current
> workflow
> > and
> >  >cross platform tool chain.
> >  >A for instance is the create script: the other platforms use bash
> > scripts
> >  >for the 'create' command, and BlackBerry's BB10 repo is dependent
> on
> > Node.
> >  >There is an ongoing discussion on the list concerning node as a
> > dependency
> >  >for our build toolchain, which I would encourage you to chime in
> on.
> >  >
> >  >
> >  >
> >  >On Mon, Apr 15, 2013 at 9:09 AM, Jeffrey Heifetz
> >  >wrote:
> >  >
> >  >> So now that the code has been out for a bit we'd like to start
> > talking
> >  >> about getting the code into the 2.7 release.
> >  >>
> >  >> There are no longer any hacks or hoops to getting it running and
> > anyone
> >  >> interested can try it out. Mobile spec results are about on par
> > with
> > the
> >  >> previous implementation and will continue to improve as we
> > re-implement
> >  >> plugins.
> >  >>
> >  >> So what is the process for getting a large number of commits into
> >  >>multiple
> >  >> repos?
> >  >>
> >  >>
> >  >> On 13-04-08 1:39 PM, "Ken Wallis" 
> wrote:
> >  >>
> >  >> >To a degree I think the architecture has been simplified.  Was
> not
> > the
> >  >> >Cordova APIs calling to WebWorks apis, which then hit native,
> > whereas
> >  >>now
> >  >> >we don't have the WebWorks layer?
> >  >> >--
> >  >> >
> >  >> >Ken Wallis
> >  >> >
> >  >> >Product Manager ­ WebWorks
> >  >> >
> >  >> >BlackBerry
> >  >> >
> >  >> >289-261-4369
> >  >> >
> >  >> >
> >  >> >From: chris.del...@gmail.com [chris.del...@gmail.com] on behalf
> > of
> >  >>Chris
> >  >> >DelCol [cdel...@blackberry.com]
> >  >> >Sent: Monday, April 08, 2013 10:15 AM
> >  >> >To: dev@cordova.apache.org
> >  >> >Subject: Re: BlackBerry BB10 Repos on GitHub
> >  >> >
> >  >> >I think the biggest impact is that the architecture and features
> > of
> >  >> >Cordova
> >  >> >are now implemented directly, rather than through a proprietary
> > SDK
> >  >>that
> >  >> >is
> >  >> >"somewhat" aligned. I'm not sure there w

Re: BlackBerry BB10 Repos on GitHub

[Lorin Beer]

Hey guys,

I'm tracking those issues we deem necessary to solve before we start the
migration process of BB's new implementation of Cordova for BB10 and
PlayBook.

Master Issue lives here: https://issues.apache.org/jira/browse/CB-3070
I'll be populating this with subissues.

An issue of confusion: the blackberry github
reposeems to have
been push -f with Cordova's existing implementation. What
happened to your codes?


- Lorin


On Mon, Apr 15, 2013 at 10:51 AM, Filip Maj  wrote:

> Go with a pull req / side branch for now and give everyone a month to poke
> at it.
>
> On 4/15/13 10:43 AM, "Jeffrey Heifetz"  wrote:
>
> >Sounds awesome. Should we issue a pull request and someone will push to a
> >branch, or would you like to give myself or Bryan commit access to do it
> >ourselves.
> >
> >We can push a "blackberry10" branch for everyone to look at and continue
> >to update there while giving the community a chance to play.
> >
> >As per the timeline I know I just said 2.7, but with only two weeks, maybe
> >we should spend a large amount of time on our porting guide to make sure
> >all current cordova bb10 developers understand the changes.
> >
> >On 13-04-15 1:20 PM, "Filip Maj"  wrote:
> >
> >>+1
> >>
> >>Pretty sure we can rewrite any history so it would probably be two
> >>commits: a giant delete and a giant add.
> >>
> >>On 4/15/13 10:14 AM, "Brian LeRoux"  wrote:
> >>
> >>>Yep. Could be as simple as a hard reset to the latest SHA from GitHub if
> >>>the above is fulfilled. (Maybe start it in a new branch on Apache Git
> >>>for
> >>>us to review in the meantime.)
> >>>
> >>>
> >>>On Mon, Apr 15, 2013 at 10:04 AM, Filip Maj  wrote:
> >>>
>  WRT to BlackBerry since node is already required, it's not an "extra"
>  dependency. The other thread is related to Android (and possibly
>  iOS/windows).
> 
>  As long as the new BB repo supports:
> 
>  1. Plugin design and documentation on how to do so
>  2. Command line scripts [1]
>  3. Can run mobile spec and passes at a reasonable rate
> 
>  .. Im happy
> 
>  [1] http://wiki.apache.org/cordova/CommandLineToolingDesign
> 
>  On 4/15/13 9:45 AM, "Lorin Beer"  wrote:
> 
>  >First steps are to bring your repo in line with the current workflow
> and
>  >cross platform tool chain.
>  >A for instance is the create script: the other platforms use bash
> scripts
>  >for the 'create' command, and BlackBerry's BB10 repo is dependent on
> Node.
>  >There is an ongoing discussion on the list concerning node as a
> dependency
>  >for our build toolchain, which I would encourage you to chime in on.
>  >
>  >
>  >
>  >On Mon, Apr 15, 2013 at 9:09 AM, Jeffrey Heifetz
>  >wrote:
>  >
>  >> So now that the code has been out for a bit we'd like to start
> talking
>  >> about getting the code into the 2.7 release.
>  >>
>  >> There are no longer any hacks or hoops to getting it running and
> anyone
>  >> interested can try it out. Mobile spec results are about on par
> with
> the
>  >> previous implementation and will continue to improve as we
> re-implement
>  >> plugins.
>  >>
>  >> So what is the process for getting a large number of commits into
>  >>multiple
>  >> repos?
>  >>
>  >>
>  >> On 13-04-08 1:39 PM, "Ken Wallis"  wrote:
>  >>
>  >> >To a degree I think the architecture has been simplified.  Was not
> the
>  >> >Cordova APIs calling to WebWorks apis, which then hit native,
> whereas
>  >>now
>  >> >we don't have the WebWorks layer?
>  >> >--
>  >> >
>  >> >Ken Wallis
>  >> >
>  >> >Product Manager ­ WebWorks
>  >> >
>  >> >BlackBerry
>  >> >
>  >> >289-261-4369
>  >> >
>  >> >
>  >> >From: chris.del...@gmail.com [chris.del...@gmail.com] on behalf
> of
>  >>Chris
>  >> >DelCol [cdel...@blackberry.com]
>  >> >Sent: Monday, April 08, 2013 10:15 AM
>  >> >To: dev@cordova.apache.org
>  >> >Subject: Re: BlackBerry BB10 Repos on GitHub
>  >> >
>  >> >I think the biggest impact is that the architecture and features
> of
>  >> >Cordova
>  >> >are now implemented directly, rather than through a proprietary
> SDK
>  >>that
>  >> >is
>  >> >"somewhat" aligned. I'm not sure there will be actual performance
>  >>gains,
>  >> >or
>  >> >that the architecture is easier. But what it does mean is that
>  >> >compatibility should go way up, and focus on it will go up as well
>  >>since
>  >> >we
>  >> >are not split between 2 competing products.
>  >> >
>  >> >
>  >> >On Mon, Apr 8, 2013 at 12:09 PM, Michal Mocny
> 
>  >> wrote:
>  >> >
>  >> >> This sounds pretty cool.
>  >> >>
>  >> >> For those with no p

Re: Standardized gestures

[Andrew Grieve]

Agree as well! This would make for a great plugin. If there are things in
Java-land that aren't exposed to plugins that you need in order to make
this work, then we should change core to make them exposed.


On Thu, Apr 18, 2013 at 1:44 PM, Jesse  wrote:

> Yes, it may have value. Consider writing a plugin.
> The pointer events spec[1] may be of interest, as things like
> tap/slide/pinch are all non-standard.
> I did this exact same thing [2] for Windows Phone 7, as there aren't even
> mouse events.
> There are numerous things you need to be aware of when creating the event,
> like the current zoom/scale of the page, + any panning, scrolling, css3
> translations.
> You also need to consider the way all DOM events bubble from the element to
> the document and back up.
> IMHO, Implementing this correctly is not for the faint of heart, and your
> work may be negated at any time by a new browser.
>
> Cheers,
>   Jesse
>
> [1]
> http://www.w3.org/TR/pointerevents/
> [2]
>
> https://github.com/purplecabbage/cordova-wp7/blob/master/templates/standalone/cordovalib/BrowserMouseHelper.cs
>
>
> @purplecabbage
> risingj.com
>
>
> On Thu, Apr 18, 2013 at 10:08 AM, jbo...@openmv.com  >wrote:
>
> > On the short them, it would help solve 'Android fragmentation' problems:
> >
> >
> https://github.com/android/platform_frameworks_base/blob/android-cts-4.0.3_r2/core/java/android/webkit/WebView.java#L6044
> >
> >
> >
> https://github.com/android/platform_frameworks_base/blob/master/core/java/android/webkit/WebViewClassic.java#L5824
> >
> > Android doesn't exactly pass the touchstart etc.. events to webkit the
> > same way and more importantly with the same delays. Not to mention, some
> > versions have bugs (missing touchend, touchmove events).
> > If coding a pure HTML/javascript app, you can avoid the 'native'
> onTouch()
> > processing and pass events faster to your app.
> >
> > It's an educated guess at the moment, but I'm quite sure performance /
> > response time for the user on all platforms will be better if the gesture
> > detection is done on the native side.
> >
> > On the long term, I don't see how JavaScript libraries would allow
> (within
> > reasonable ms) for more complex 'gesture' detection. I would rather do
> > something like:
> > webView.addGesture('swipe');
> > webView.addGesture('handgrab');
> > onTouch/Gesture:
> > // do gesture detection in native code
> >webView.sendJavascript("cordova.fireEvent('handgrab', {node, ...}");
> >
> >
> > -Original Message-
> > From: Filip Maj [mailto:f...@adobe.com]
> > Sent: Wednesday, April 17, 2013 12:47 PM
> > To: dev@cordova.apache.org
> > Subject: Re: Standardized gestures
> >
> > I'm not convinced you need any additional code here.
> >
> > Touch events are already fired by the web view containers. You could
> build
> > up gesture detection in JavaScript by listening to these events.
> >
> > There are libraries out there that do this for you already:
> >
> >  - http://eightmedia.github.io/hammer.js/
> >  - http://quojs.tapquo.com/
> >  - https://github.com/plainview/Jester
> >  - jquery ui plugin: http://touchpunch.furf.com/
> >  - jquery plugin: http://labs.rampinteractive.co.uk/touchSwipe/demos/
> >  - moar jquery: https://github.com/HotStudio/touchy
> >
> > On 4/17/13 9:42 AM, "jbo...@openmv.com"  wrote:
> >
> > >I'm experimenting with Cordova on Android, iOS and Windows 8.
> > >
> > >Has there been a discussion around trying to implement to set of
> > >'standard' gesture recognizers:
> > >http://msdn.microsoft.com/library/windows/apps/BR241937
> > >http://developer.apple.com/library/ios/#documentation/EventHandling/Con
> > >cep
> > >tual/EventHandlingiPhoneOS/GestureRecognizer_basics/GestureRecognizer_b
> > >asi
> > >cs.html
> > >http://developer.android.com/reference/android/view/GestureDetector.htm
> > >l
> > >
> > >The idea would be that the native side executes JavaScript like:
> > >javascript:cordova.fireEvent('tap', {node:
> > >document.elementFromPoint(400, 300), x: 400, y:300 });
> > >javascript:cordova.fireEvent('slide', {node:
> > >document.elementFromPoint(400, 300), x: 400, y:300});
> > >
> > >This function could use document.createEvent to initiate events on the
> > >DOM node:
> > >https://developer.mozilla.org/en-US/docs/DOM/document.createEvent
> > >
> > >The purpose of this would be to have a consistent set of gesture
> > >recognition across different devices instead of having javascript code
> > >in the 'WebView' trying to do gesture detection.
> > >
> > >Thoughts?
> > >
> >
> >
> >
> >
>

Re: Unifying the config.xml

[Filip Maj]

We are about to tag 2.7.0rc1, so we'll hold off on adding this in until we
branch for the 2.7.0 release, then merge the config stuff into master.

Sorry for the wait!

On 4/17/13 11:18 PM, "Gorkem Ercan"  wrote:

>Hey Fil,
>Please let me know if I can help with anything.
>--
>Gorkem
>
>
>On Tue, Apr 9, 2013 at 12:18 PM, Filip Maj  wrote:
>
>> Hey Gorkem,
>>
>> There is a bunch of housework to do around merging the PR. Thank you for
>> providing two implementations, but we have to be sure that all other
>> platforms at least have issues filed for following support.
>>
>> I am currently attending a W3C meeting and don't have much time this
>>week,
>> but I have this flagged in my inbox to follow up with. I will slate it
>>for
>> next week.
>>
>> If anyone else wants to take on merging and filing outstanding issues
>>for
>> platform parity, that would be nice too :)
>>
>> On 4/8/13 9:51 PM, "Gorkem Ercan"  wrote:
>>
>> >Can we possibly proceed with this PR? Is there anything that I need to
>>do
>> >on my part?
>> >--
>> >Gorkem
>> >
>> >
>> >On Sat, Apr 6, 2013 at 1:56 AM, Gorkem Ercan 
>> >wrote:
>> >
>> >> Great! PRs are updated with the suggested changes
>> >> --
>> >> Gorkem
>> >>
>> >>
>> >> On Fri, Apr 5, 2013 at 11:36 PM, Andrew Grieve
>> >>wrote:
>> >>
>> >>> Yep, sounds good to me!
>> >>>
>> >>>
>> >>> On Fri, Apr 5, 2013 at 3:28 PM, Gorkem Ercan
>>
>> >>> wrote:
>> >>>
>> >>> > I see your point... I have unified the template config.xmls on all
>> >>> > platforms, perhaps it would be a better idea to differentiate the
>> >>> template
>> >>> > config.xml per platform so that the values from other platforms
>>are
>> >>>not
>> >>> > spread to all... CLIs template can still carry the values of all
>> >>> platforms
>> >>> > that is its purpose anyway. If that sounds fine I will update the
>>PR.
>> >>> > --
>> >>> > Gorkem
>> >>> >
>> >>> >
>> >>> > On Fri, Apr 5, 2013 at 12:04 AM, Andrew Grieve
>>> >
>> >>> > wrote:
>> >>> >
>> >>> > > On Thu, Apr 4, 2013 at 4:48 PM, Gorkem Ercan
>> >>>
>> >>> > > wrote:
>> >>> > >
>> >>> > > > On Thu, Apr 4, 2013 at 9:17 PM, Andrew Grieve
>>  >>> >
>> >>> > > > wrote:
>> >>> > > >
>> >>> > > > > Some feedback:
>> >>> > > > >
>> >>> > > > > +
>> >>> > > > > +http://127.0.0.1*"/> `
>> >>> > > > >
>> >>> > > > > Why have the second line? it's made redundant by the first,
>>and
>> >>> when
>> >>> > we
>> >>> > > > do
>> >>> > > > > serve files locally, we do so via file: URLs.
>> >>> > > > >
>> >>> > > > >
>> >>> > > > I have copied this use from the android's existing config.xml
>> >>>[1].
>> >>> It
>> >>> > > does
>> >>> > > > not make much sense to me either but since I did not have
>>time to
>> >>> > > > investigate it deeply and did not want to break anything, I
>>kept
>> >>>it
>> >>> as
>> >>> > it
>> >>> > > > is. We can easily remove it if you think it will not harm
>> >>>anything
>> >>> for
>> >>> > > > Android.
>> >>> > > >
>> >>> > > > [1]
>> >>> > > >
>> >>> > > >
>> >>> > >
>> >>> >
>> >>>
>> >>>
>> https://github.com/apache/cordova-android/blob/master/framework/res/xml/
>> >>>config.xml
>> >>> > >
>> >>> > >
>> >>> > > ah, okay. Yeah, I think it should just be removed.
>> >>> > >
>> >>> > >
>> >>> > >
>> >>> > > >
>> >>> > > >
>> >>> > > >
>> >>> > > >
>> >>> > > > >
>> >>> > > > >
>> >>> > > > > +
>> >>> > > > >
>> >>> > > > > I don't see  in the widget spec. Seems like a good idea
>> >>>to be
>> >>> > able
>> >>> > > > to
>> >>> > > > > se a log level, but probably would be more appropriate as a
>> >>> > > ,
>> >>> > > > > and out of the scope of this change.
>> >>> > > > >
>> >>> > > > >
>> >>> > > > >
>> >>> > > > Correct, this is not on the spec but Android at the moment is
>> >>> actually
>> >>> > > > using log element to configure its logging level and therefore
>> >>>it is
>> >>> > > > present on the current android config.xml. I also agree that
>> >>> logging is
>> >>> > > not
>> >>> > > > in the scope of this change and it is  probably a fair amount
>>of
>> >>> work.
>> >>> > If
>> >>> > > > you think the effect on Android is trivial, I can remove it
>>from
>> >>>the
>> >>> > > > templates.
>> >>> > > >
>> >>> > > >
>> >>> > > Cool, didn't know that. I think for now, let's at least keep
>>this
>> >>> > confined
>> >>> > > to Android's config.xml then or convert it to a 
>> >>>before we
>> >>> > > expose it to other platforms.
>> >>> > >
>> >>> > >
>> >>> > > >
>> >>> > > > >
>> >>> > > > > Using  for the class name does more align with the
>>spec,
>> >>> but
>> >>> > > using
>> >>> > > > > $platform-package to address platform differences seems out
>>of
>> >>> place
>> >>> > > > > compared with how these are addressed by CLI's config.xml
>> >>>(using
>> >>> > > > > gap:platform attributes or  tags). What would be
>> >>>better
>> >>> (I
>> >>> > > > think)
>> >>> > > > > would be to have , and
>>use
>> >>> > > CLI/plugman
>> >>> > > > > to deal with putting in the correct versions per platform.
>> >>> > > > >
>> >>> > > > > E.g., if iOS

Re: [iOS] iOSExec

[Shazron]

Alright, the concrete proposal is to take it out *now* and update the docs.
Leaving this for comments else it'll be just lazy consensus...

On Wednesday, April 17, 2013, Ian Clelland wrote:

> If it's going to be actually removed in 2.7, I would suggest that we should
> put a notice to that affect--immediately--in the 2.6 docs.
>
> It looks like that wording has been there since the 2.1 docs, so developers
> have certainly been warned for some time. On the other hand, keeping the
> deprecation notice unchanged for such a long time might make it look like
> we have no particular plans to remove it any time soon.
>
>
>
> On Wed, Apr 17, 2013 at 7:54 PM, Shazron >
> wrote:
>
> > It's deprecated, see "Deprecated Plugin Signature Note":
> >
> >
> http://docs.phonegap.com/en/2.6.0/guide_plugin-development_ios_index.md.html#Developing%20a%20Plugin%20on%20iOS
> >
> > ... although I don't think we print out a notice currently.
> >
> > I propose that we remove it for the next version, it's definitely more
> than
> > 6 months. Either that, if we detect the old format, reject it, and
> > console.log the new signature so they can update the JS call, since the
> old
> > format is not portable across platforms - until 3.0 is out. Changing the
> > old signature format on Objective-C is another matter as well...
> >
> >
> > On Wed, Apr 17, 2013 at 4:47 PM, Anis KADRI >
> wrote:
> >
> > > Hello,
> > >
> > > Any reason why we keep on supporting the old exec signature on iOS ?
> [1]
> > >
> > > [1]
> > >
> > >
> >
> https://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=blob;f=lib/ios/exec.js;h=5e237d968cb948438fc92694d9288d72c9c3a7ac;hb=125dca530923a44a8f44f68f5e1970cbdd4e7faf#l132
> > >
> > > -a
> > >
> >
>

Re: Ian Clelland is now a Cordova Committer

[Shazron]

Congrats!!

On Thursday, April 18, 2013, Andrew Grieve wrote:

> Wanted to publicly announce that Ian is now a Cordova committer!
>
> Ian started working on Cordova just over a month ago and has already made
> many big changes. To highlight a few:
>
> - FileTransfer progress events for gzipped responses
> - executeScript and insertCss for InAppBrowser
> - Figuring out exactly why FileTransfer fails *every other request*
> sometimes (CB-2293 )
>
> Thanks Ian, and welcome aboard!
>
> Andrew
>

Re: Ian Clelland is now a Cordova Committer

[Brian LeRoux]

Congratulations Ian!

On Thu, Apr 18, 2013 at 10:02 AM, Filip Maj  wrote:

> Welcome and looking forward to working with you!
>
> On 4/18/13 7:43 AM, "James Jong"  wrote:
>
> >Welcome Ian!
> >-James Jong
> >
> >On Apr 18, 2013, at 10:20 AM, Andrew Grieve  wrote:
> >
> >> Wanted to publicly announce that Ian is now a Cordova committer!
> >>
> >> Ian started working on Cordova just over a month ago and has already
> >>made
> >> many big changes. To highlight a few:
> >>
> >> - FileTransfer progress events for gzipped responses
> >> - executeScript and insertCss for InAppBrowser
> >> - Figuring out exactly why FileTransfer fails *every other request*
> >> sometimes (CB-2293 )
> >>
> >> Thanks Ian, and welcome aboard!
> >>
> >> Andrew
> >
>
>

Re: Standardized gestures

[Jesse]

Yes, it may have value. Consider writing a plugin.
The pointer events spec[1] may be of interest, as things like
tap/slide/pinch are all non-standard.
I did this exact same thing [2] for Windows Phone 7, as there aren't even
mouse events.
There are numerous things you need to be aware of when creating the event,
like the current zoom/scale of the page, + any panning, scrolling, css3
translations.
You also need to consider the way all DOM events bubble from the element to
the document and back up.
IMHO, Implementing this correctly is not for the faint of heart, and your
work may be negated at any time by a new browser.

Cheers,
  Jesse

[1]
http://www.w3.org/TR/pointerevents/
[2]
https://github.com/purplecabbage/cordova-wp7/blob/master/templates/standalone/cordovalib/BrowserMouseHelper.cs


@purplecabbage
risingj.com


On Thu, Apr 18, 2013 at 10:08 AM, jbo...@openmv.com wrote:

> On the short them, it would help solve 'Android fragmentation' problems:
>
> https://github.com/android/platform_frameworks_base/blob/android-cts-4.0.3_r2/core/java/android/webkit/WebView.java#L6044
>
>
> https://github.com/android/platform_frameworks_base/blob/master/core/java/android/webkit/WebViewClassic.java#L5824
>
> Android doesn't exactly pass the touchstart etc.. events to webkit the
> same way and more importantly with the same delays. Not to mention, some
> versions have bugs (missing touchend, touchmove events).
> If coding a pure HTML/javascript app, you can avoid the 'native' onTouch()
> processing and pass events faster to your app.
>
> It's an educated guess at the moment, but I'm quite sure performance /
> response time for the user on all platforms will be better if the gesture
> detection is done on the native side.
>
> On the long term, I don't see how JavaScript libraries would allow (within
> reasonable ms) for more complex 'gesture' detection. I would rather do
> something like:
> webView.addGesture('swipe');
> webView.addGesture('handgrab');
> onTouch/Gesture:
> // do gesture detection in native code
>webView.sendJavascript("cordova.fireEvent('handgrab', {node, ...}");
>
>
> -Original Message-
> From: Filip Maj [mailto:f...@adobe.com]
> Sent: Wednesday, April 17, 2013 12:47 PM
> To: dev@cordova.apache.org
> Subject: Re: Standardized gestures
>
> I'm not convinced you need any additional code here.
>
> Touch events are already fired by the web view containers. You could build
> up gesture detection in JavaScript by listening to these events.
>
> There are libraries out there that do this for you already:
>
>  - http://eightmedia.github.io/hammer.js/
>  - http://quojs.tapquo.com/
>  - https://github.com/plainview/Jester
>  - jquery ui plugin: http://touchpunch.furf.com/
>  - jquery plugin: http://labs.rampinteractive.co.uk/touchSwipe/demos/
>  - moar jquery: https://github.com/HotStudio/touchy
>
> On 4/17/13 9:42 AM, "jbo...@openmv.com"  wrote:
>
> >I'm experimenting with Cordova on Android, iOS and Windows 8.
> >
> >Has there been a discussion around trying to implement to set of
> >'standard' gesture recognizers:
> >http://msdn.microsoft.com/library/windows/apps/BR241937
> >http://developer.apple.com/library/ios/#documentation/EventHandling/Con
> >cep
> >tual/EventHandlingiPhoneOS/GestureRecognizer_basics/GestureRecognizer_b
> >asi
> >cs.html
> >http://developer.android.com/reference/android/view/GestureDetector.htm
> >l
> >
> >The idea would be that the native side executes JavaScript like:
> >javascript:cordova.fireEvent('tap', {node:
> >document.elementFromPoint(400, 300), x: 400, y:300 });
> >javascript:cordova.fireEvent('slide', {node:
> >document.elementFromPoint(400, 300), x: 400, y:300});
> >
> >This function could use document.createEvent to initiate events on the
> >DOM node:
> >https://developer.mozilla.org/en-US/docs/DOM/document.createEvent
> >
> >The purpose of this would be to have a consistent set of gesture
> >recognition across different devices instead of having javascript code
> >in the 'WebView' trying to do gesture detection.
> >
> >Thoughts?
> >
>
>
>
>

Re: Ian Clelland is now a Cordova Committer

[Max Woghiren]

Congrats Ian!


On Thu, Apr 18, 2013 at 10:20 AM, Andrew Grieve wrote:

> Wanted to publicly announce that Ian is now a Cordova committer!
>
> Ian started working on Cordova just over a month ago and has already made
> many big changes. To highlight a few:
>
> - FileTransfer progress events for gzipped responses
> - executeScript and insertCss for InAppBrowser
> - Figuring out exactly why FileTransfer fails *every other request*
> sometimes (CB-2293 )
>
> Thanks Ian, and welcome aboard!
>
> Andrew
>

Re: Ian Clelland is now a Cordova Committer

[Lorin Beer]

Welcome Ian!


On Thu, Apr 18, 2013 at 10:02 AM, Filip Maj  wrote:

> Welcome and looking forward to working with you!
>
> On 4/18/13 7:43 AM, "James Jong"  wrote:
>
> >Welcome Ian!
> >-James Jong
> >
> >On Apr 18, 2013, at 10:20 AM, Andrew Grieve  wrote:
> >
> >> Wanted to publicly announce that Ian is now a Cordova committer!
> >>
> >> Ian started working on Cordova just over a month ago and has already
> >>made
> >> many big changes. To highlight a few:
> >>
> >> - FileTransfer progress events for gzipped responses
> >> - executeScript and insertCss for InAppBrowser
> >> - Figuring out exactly why FileTransfer fails *every other request*
> >> sometimes (CB-2293 )
> >>
> >> Thanks Ian, and welcome aboard!
> >>
> >> Andrew
> >
>
>

Re: Standardized gestures

[Joe Bowser]

I would rather try and fix the touchstart than have to add a bunch of
gestures in Java on this.  This feels like we're taking something away
from the Javascript developer, which is a bad thing IMO.  This might
be cool as a plugin, but I don't know if we should add it as a core
feature of Cordova.

On Thu, Apr 18, 2013 at 10:08 AM, jbo...@openmv.com  wrote:
> On the short them, it would help solve 'Android fragmentation' problems:
> https://github.com/android/platform_frameworks_base/blob/android-cts-4.0.3_r2/core/java/android/webkit/WebView.java#L6044
>
> https://github.com/android/platform_frameworks_base/blob/master/core/java/android/webkit/WebViewClassic.java#L5824
>
> Android doesn't exactly pass the touchstart etc.. events to webkit the same 
> way and more importantly with the same delays. Not to mention, some versions 
> have bugs (missing touchend, touchmove events).
> If coding a pure HTML/javascript app, you can avoid the 'native' onTouch() 
> processing and pass events faster to your app.
>
> It's an educated guess at the moment, but I'm quite sure performance / 
> response time for the user on all platforms will be better if the gesture 
> detection is done on the native side.
>
> On the long term, I don't see how JavaScript libraries would allow (within 
> reasonable ms) for more complex 'gesture' detection. I would rather do 
> something like:
> webView.addGesture('swipe');
> webView.addGesture('handgrab');
> onTouch/Gesture:
> // do gesture detection in native code
>webView.sendJavascript("cordova.fireEvent('handgrab', {node, ...}");
>
>
> -Original Message-
> From: Filip Maj [mailto:f...@adobe.com]
> Sent: Wednesday, April 17, 2013 12:47 PM
> To: dev@cordova.apache.org
> Subject: Re: Standardized gestures
>
> I'm not convinced you need any additional code here.
>
> Touch events are already fired by the web view containers. You could build up 
> gesture detection in JavaScript by listening to these events.
>
> There are libraries out there that do this for you already:
>
>  - http://eightmedia.github.io/hammer.js/
>  - http://quojs.tapquo.com/
>  - https://github.com/plainview/Jester
>  - jquery ui plugin: http://touchpunch.furf.com/
>  - jquery plugin: http://labs.rampinteractive.co.uk/touchSwipe/demos/
>  - moar jquery: https://github.com/HotStudio/touchy
>
> On 4/17/13 9:42 AM, "jbo...@openmv.com"  wrote:
>
>>I'm experimenting with Cordova on Android, iOS and Windows 8.
>>
>>Has there been a discussion around trying to implement to set of
>>'standard' gesture recognizers:
>>http://msdn.microsoft.com/library/windows/apps/BR241937
>>http://developer.apple.com/library/ios/#documentation/EventHandling/Con
>>cep
>>tual/EventHandlingiPhoneOS/GestureRecognizer_basics/GestureRecognizer_b
>>asi
>>cs.html
>>http://developer.android.com/reference/android/view/GestureDetector.htm
>>l
>>
>>The idea would be that the native side executes JavaScript like:
>>javascript:cordova.fireEvent('tap', {node:
>>document.elementFromPoint(400, 300), x: 400, y:300 });
>>javascript:cordova.fireEvent('slide', {node:
>>document.elementFromPoint(400, 300), x: 400, y:300});
>>
>>This function could use document.createEvent to initiate events on the
>>DOM node:
>>https://developer.mozilla.org/en-US/docs/DOM/document.createEvent
>>
>>The purpose of this would be to have a consistent set of gesture
>>recognition across different devices instead of having javascript code
>>in the 'WebView' trying to do gesture detection.
>>
>>Thoughts?
>>
>
>
>

RE: Standardized gestures

[jbo...@openmv.com]

On the short them, it would help solve 'Android fragmentation' problems:
https://github.com/android/platform_frameworks_base/blob/android-cts-4.0.3_r2/core/java/android/webkit/WebView.java#L6044

https://github.com/android/platform_frameworks_base/blob/master/core/java/android/webkit/WebViewClassic.java#L5824

Android doesn't exactly pass the touchstart etc.. events to webkit the same way 
and more importantly with the same delays. Not to mention, some versions have 
bugs (missing touchend, touchmove events).
If coding a pure HTML/javascript app, you can avoid the 'native' onTouch() 
processing and pass events faster to your app.  

It's an educated guess at the moment, but I'm quite sure performance / response 
time for the user on all platforms will be better if the gesture detection is 
done on the native side.  

On the long term, I don't see how JavaScript libraries would allow (within 
reasonable ms) for more complex 'gesture' detection. I would rather do 
something like:
webView.addGesture('swipe');
webView.addGesture('handgrab');
onTouch/Gesture: 
// do gesture detection in native code
   webView.sendJavascript("cordova.fireEvent('handgrab', {node, ...}");


-Original Message-
From: Filip Maj [mailto:f...@adobe.com] 
Sent: Wednesday, April 17, 2013 12:47 PM
To: dev@cordova.apache.org
Subject: Re: Standardized gestures

I'm not convinced you need any additional code here.

Touch events are already fired by the web view containers. You could build up 
gesture detection in JavaScript by listening to these events.

There are libraries out there that do this for you already:

 - http://eightmedia.github.io/hammer.js/
 - http://quojs.tapquo.com/
 - https://github.com/plainview/Jester
 - jquery ui plugin: http://touchpunch.furf.com/
 - jquery plugin: http://labs.rampinteractive.co.uk/touchSwipe/demos/
 - moar jquery: https://github.com/HotStudio/touchy

On 4/17/13 9:42 AM, "jbo...@openmv.com"  wrote:

>I'm experimenting with Cordova on Android, iOS and Windows 8.
>
>Has there been a discussion around trying to implement to set of 
>'standard' gesture recognizers:
>http://msdn.microsoft.com/library/windows/apps/BR241937
>http://developer.apple.com/library/ios/#documentation/EventHandling/Con
>cep 
>tual/EventHandlingiPhoneOS/GestureRecognizer_basics/GestureRecognizer_b
>asi
>cs.html
>http://developer.android.com/reference/android/view/GestureDetector.htm
>l
>
>The idea would be that the native side executes JavaScript like:
>javascript:cordova.fireEvent('tap', {node: 
>document.elementFromPoint(400, 300), x: 400, y:300 }); 
>javascript:cordova.fireEvent('slide', {node:
>document.elementFromPoint(400, 300), x: 400, y:300});
>
>This function could use document.createEvent to initiate events on the 
>DOM node:
>https://developer.mozilla.org/en-US/docs/DOM/document.createEvent
>
>The purpose of this would be to have a consistent set of gesture 
>recognition across different devices instead of having javascript code 
>in the 'WebView' trying to do gesture detection.
>
>Thoughts? 
>

Re: Ian Clelland is now a Cordova Committer

[Filip Maj]

Welcome and looking forward to working with you!

On 4/18/13 7:43 AM, "James Jong"  wrote:

>Welcome Ian!
>-James Jong
>
>On Apr 18, 2013, at 10:20 AM, Andrew Grieve  wrote:
>
>> Wanted to publicly announce that Ian is now a Cordova committer!
>> 
>> Ian started working on Cordova just over a month ago and has already
>>made
>> many big changes. To highlight a few:
>> 
>> - FileTransfer progress events for gzipped responses
>> - executeScript and insertCss for InAppBrowser
>> - Figuring out exactly why FileTransfer fails *every other request*
>> sometimes (CB-2293 )
>> 
>> Thanks Ian, and welcome aboard!
>> 
>> Andrew
>

Re: 2.7 for Adobe Max?

[Andrew Grieve]

New goal - let's aim for today!


I'd like to take a look and at CB-2698, but since this is iOS-specific (and
native-code only), I'll go ahead with creating issues & branching the JS.
If CB-2698 gets fixed, we can cherry-pick it.


On Tue, Apr 16, 2013 at 2:45 PM, Giorgio Natili wrote:

> +1
>
> On 4/16/13 7:52 PM, "Filip Maj"  wrote:
>
> >+1.
> >
> >So, how do we feel about starting an RC soon?
> >
> >On 4/16/13 10:19 AM, "Brian LeRoux"  wrote:
> >
> >>It would be ideal to see 2.7 ship before the month is out for sure.
> >>
> >>
> >>On Tue, Apr 16, 2013 at 7:41 AM, Joe Bowser  wrote:
> >>
> >>> I think that this would be a good thing.  It'd be nice to get a
> >>> released lined up for Conf-Month! (Adobe Max, Google IO, JSConf, etc).
> >>>
> >>> On Tue, Apr 16, 2013 at 7:35 AM, Andrew Grieve 
> >>> wrote:
> >>> > Wanted to see what people thought of trying to get 2.7 out the door
> >>>in
> >>> time
> >>> > for Adobe Max. The main motivation I see is to have a version that
> >>>will
> >>> > work the "future" branch of CLI. 2.6 is missing the plugin_loader.js
> >>>code
> >>> > required to load a plugin's JS.
> >>>
> >
>
>
>

Re: plugman + plugin spec final q's

[Andrew Grieve]

The  tidbit might make it necessary to special
case permissions.

E.g. the app sets a permission with required=true, then a plugin adds the
permission as well. We go to de-dupe, what happens? We'll need logic to
properly combine the two.

For native code added by the app developer, shouldn't we be insisting that
they try to do so by writing an app-specific plugin?


On Wed, Apr 17, 2013 at 7:28 PM, Filip Maj  wrote:

> After chatting with Anis on IRC I think I understand your point a bit
> better with respect to plugin vs. app permissions.
>
> I believe our move from  to  in an application's
> config.xml should solve this issue. That is, if the application developer
> explicitly lists out permissions they deem as necessary in their
> application, plugman or other plugin tooling should respect those
> permissions and not remove them.
>
> On 4/17/13 4:16 PM, "Jesse"  wrote:
>
> >Yes,  element would work fine for wp7+8 as well.
> >I then see no other need for the  element.
> >
> > >parent="/Deployment/App/Capabilities">
> >  
> >  
> >  
> >
> >
> >@purplecabbage
> >risingj.com
> >
> >
> >On Wed, Apr 17, 2013 at 4:04 PM, Filip Maj  wrote:
> >
> >> Nope nothing being forced on anyone here. I agree with you: developers
> >> should be aware of the platforms they are targeting and should
> >>understand
> >> how their app works, regardless if its written with a cross-platform
> >> framework or not.
> >>
> >> We are talking about a spec helping standardize the way bits of
> >> functionality can be exposed to cordova applications. If you have
> >> something very app-specific, we (cordova) should not mandate that it be
> >> written as a plugin. If you have a cross-platform plugin to access
> >>special
> >> device functionality, then wrapping it up in a plugin with a manifest
> >>that
> >> is standardized will help with exposure, discovery and usability of the
> >> plugin.
> >>
> >> Back to the issue at hand, the contention was: do we need a special
> >> section of the spec listing out platform permissions required by a
> >>plugin?
> >> Originally my answer was yes, however, Anis brought up good points and
> >>now
> >> I am not as convinced. We already have a section for generic XML munging
> >> (the  element) which we can use in this case. The specific
> >> use case that needed satisfying (installing multiple plugins with
> >> shared/overlapping config changes, then uninstalling one of them, and
> >> having the shared/overlapping config changes remain in the config) can
> >>be
> >> satisfied with both approaches. However, adding a  element
> >>is,
> >> in a sense, redundant, as it doesn't satisfy any other use cases that we
> >> deem necessary.
> >>
> >> If there are other use cases in plugin management that are not
> >>satisfied,
> >> but would be by adding a  element, then we should list them
> >> out in this thread so we can keep pushing development of this plugin
> >>spec
> >> and our tooling around it.
> >>
> >> On 4/17/13 3:55 PM, "Jesse"  wrote:
> >>
> >> >The use case is any app that has any additional native functionality
> >>added
> >> >by the developer. ( every app I have ever written )
> >> >Otherwise we force an all or nothing stance with cordova use,  Android,
> >> >iOS, wp7, wp8 all support using cordova as a view in an otherwise
> >>strictly
> >> >native app, or adding a native view in an otherwise browser-control
> >> >(typical cordova) based app.
> >> >I am not suggesting we make drastic efforts to support every type of
> >>app
> >> >that could exist, but if we can make a few simple changes to allow it,
> >>I
> >> >think we should.
> >> >Ideally everyone would write any additions to their app as a plugin
> >> >according to our spec, but do we need to force it?
> >> >
> >> >@purplecabbage
> >> >risingj.com
> >> >
> >> >
> >> >On Wed, Apr 17, 2013 at 3:37 PM, Filip Maj  wrote:
> >> >
> >> >>
> >> >> >However, I do not think that removing permissions will end well.
> >> >>Looking
> >> >> >at the bigger picture, I can think of many cases where a permission
> >>is
> >> >> >required by the app itself, and should remain regardless of any
> >>plugin.
> >> >> > This needs to be decided by the app developer themselves imho.
> >> >>
> >> >> Can you provide one? I don't see how an application's permissions
> >>would
> >> >> stem from the application itself and not the device capabilities the
> >>app
> >> >> needs to access.
> >> >>
> >> >> I think for now leaving the permission stuff as children under
> >> >>  is good enough, but tweaking our tooling
> >>implementation to
> >> >> be smarter about handling it is the way forward. The idea behind the
> >> >>  element is: all of its child elements will be appended
> >> >>into
> >> >> specific parts of the native manifests for the platform it is
> >>specified
> >> >> under. So, as long as the tooling understands that permissions (and
> >> >> possibly other areas such as "requirements" in windows phone land)
> >>are a
> >> >> shared space between differen

Re: Ian Clelland is now a Cordova Committer

[James Jong]

Welcome Ian!
-James Jong

On Apr 18, 2013, at 10:20 AM, Andrew Grieve  wrote:

> Wanted to publicly announce that Ian is now a Cordova committer!
> 
> Ian started working on Cordova just over a month ago and has already made
> many big changes. To highlight a few:
> 
> - FileTransfer progress events for gzipped responses
> - executeScript and insertCss for InAppBrowser
> - Figuring out exactly why FileTransfer fails *every other request*
> sometimes (CB-2293 )
> 
> Thanks Ian, and welcome aboard!
> 
> Andrew

Ian Clelland is now a Cordova Committer

[Andrew Grieve]

Wanted to publicly announce that Ian is now a Cordova committer!

Ian started working on Cordova just over a month ago and has already made
many big changes. To highlight a few:

- FileTransfer progress events for gzipped responses
- executeScript and insertCss for InAppBrowser
- Figuring out exactly why FileTransfer fails *every other request*
sometimes (CB-2293 )

Thanks Ian, and welcome aboard!

Andrew

Re: Migrating to

[Lucas Holmquist]

+1
On Apr 18, 2013, at 7:29 AM, Giorgio Natili  wrote:

> +1
> 
> On 4/17/13 10:37 PM, "Lorin Beer"  wrote:
> 
>> +1
>> 
>> 
>> On Wed, Apr 17, 2013 at 1:20 PM, Jeffrey Heifetz
>> wrote:
>> 
>>> +1
>>> 
>>> On 13-04-17 4:14 PM, "Joe Bowser"  wrote:
>>> 
 +1 for deprecate now, remove 3.0
 
 On Wed, Apr 17, 2013 at 12:15 PM, Shazron  wrote:
> +1 for deprecate now, remove 3.0
> 
> 
> On Wed, Apr 17, 2013 at 10:00 AM, Filip Maj  wrote:
> 
>> My vote is to set up deprecation of plugin now, and remove it
>> completely
>> for 3.0. Our tooling should be able to handle this stuff by then..
>> 
>> On 4/16/13 8:23 PM, "Joe Bowser"  wrote:
>> 
>>> Only when we decide to drop plugin.
>>> On Apr 16, 2013 8:14 PM, "Filip Maj"  wrote:
>>> 
 https://issues.apache.org/jira/browse/CB-1109
 
 
 We need to add a deprecation notice to change this, is that
>>> right?
 
 
>> 
>> 
>>> 
>>> 
>>> -
>>> This transmission (including any attachments) may contain confidential
>>> information, privileged material (including material protected by the
>>> solicitor-client or other applicable privileges), or constitute
>>> non-public
>>> information. Any use of this information by anyone other than the
>>> intended
>>> recipient is prohibited. If you have received this transmission in
>>> error,
>>> please immediately reply to the sender and delete this information from
>>> your system. Use, dissemination, distribution, or reproduction of this
>>> transmission by unintended recipients is not authorized and may be
>>> unlawful.
>>> 
> 
> 

Re: Migrating to

[Giorgio Natili]

+1

On 4/17/13 10:37 PM, "Lorin Beer"  wrote:

>+1
>
>
>On Wed, Apr 17, 2013 at 1:20 PM, Jeffrey Heifetz
>wrote:
>
>> +1
>>
>> On 13-04-17 4:14 PM, "Joe Bowser"  wrote:
>>
>> >+1 for deprecate now, remove 3.0
>> >
>> >On Wed, Apr 17, 2013 at 12:15 PM, Shazron  wrote:
>> >> +1 for deprecate now, remove 3.0
>> >>
>> >>
>> >> On Wed, Apr 17, 2013 at 10:00 AM, Filip Maj  wrote:
>> >>
>> >>> My vote is to set up deprecation of plugin now, and remove it
>> >>>completely
>> >>> for 3.0. Our tooling should be able to handle this stuff by then..
>> >>>
>> >>> On 4/16/13 8:23 PM, "Joe Bowser"  wrote:
>> >>>
>> >>> >Only when we decide to drop plugin.
>> >>> >On Apr 16, 2013 8:14 PM, "Filip Maj"  wrote:
>> >>> >
>> >>> >> https://issues.apache.org/jira/browse/CB-1109
>> >>> >>
>> >>> >>
>> >>> >> We need to add a deprecation notice to change this, is that
>>right?
>> >>> >>
>> >>> >>
>> >>>
>> >>>
>>
>>
>> -
>> This transmission (including any attachments) may contain confidential
>> information, privileged material (including material protected by the
>> solicitor-client or other applicable privileges), or constitute
>>non-public
>> information. Any use of this information by anyone other than the
>>intended
>> recipient is prohibited. If you have received this transmission in
>>error,
>> please immediately reply to the sender and delete this information from
>> your system. Use, dissemination, distribution, or reproduction of this
>> transmission by unintended recipients is not authorized and may be
>>unlawful.
>>