Re: Steve on Vacation
Congrats Steve! Have a great time on your honeymoon! -James Jong On Sep 3, 2014, at 9:14 PM, Lisa Seacat DeLuca wrote: > Steve! Amazing! What a fun video. It's neat to see you both surrounded > with love by so many friends and family. ...and of course the cordova > community was virtually pulling for you both as well. :) Congratulations!! > > > Lisa > > > > Carlos Santana ---09/01/2014 11:35:19 PM---Wow Steve the video is super > Amazing, Have fun and enjoy the brake and turn off your smartphone :-) > > From: Carlos Santana > To: "dev@cordova.apache.org" > Date: 09/01/2014 11:35 PM > Subject: Re: Steve on Vacation > > > > Wow Steve the video is super Amazing, Have fun and enjoy the brake and turn > off your smartphone :-) > > > On Sat, Aug 30, 2014 at 12:11 PM, Hazem Saleh wrote: > > > Congratulations Steven! > > > > > > On Fri, Aug 29, 2014 at 10:20 PM, Kerri Shotts > > wrote: > > > > > Congrats! Enjoy your honeymoon. The video is absolutely amazing -- you > > two > > > look made for each other. :-) > > > > > > > > > ___ > > > *Kerri Shotts* > > > photoKandy Studios, LLC > > > > > > On the Web: http://www.photokandy.com/ > > > > > > *Social Media:* > > > Twitter: @photokandy, http://twitter.com/photokandy > > > App.net: @photokandy, https://alpha.app.net/photokandy > > > Google+: https://plus.google.com/110429856422449500918/posts > > > Facebook: https://www.facebook.com/photoKandy > > > Behance: https://www.behance.net/kerrishotts > > > Tumblr: http://photokandy.tumblr.com/ > > > Github: https://github.com/kerrishotts > > > > > https://github.com/organizations/photokandyStudios > > > CoderWall: https://coderwall.com/kerrishotts > > > Stack Overflow: > > > http://stackoverflow.com/users/741043/kerri-shotts > > > > > > > > > *Apps on the Apple Store:* > > > Greek Interlinear Bible 1.3: > > > > > > https://itunes.apple.com/us/artist/photokandy-studios-llc/id498577828 > > > > > > *Books:* > > > PhoneGap 3.x Mobile Application Development Hotshot: > > > http://www.photokandy.com/books/phonegap-3-x-hotshot/ > > > > > > PhoneGap 2.x Mobile Application Development Hotshot: > > > http://www.photokandy.com/books/phonegap-2-x-hotshot/ > > > > > > Instant PhoneGap Social Application Development: > > > http://www.photokandy.com/books/instant-social-app/ > > > > > > > > > > > > > > > On Fri, Aug 29, 2014 at 1:37 PM, Steven Gill > > > wrote: > > > > > > > Thanks Mike and Michal! > > > > > > > > The wedding went amazingly and I'm sure everyone had a blast. It was > > the > > > > same weekend. Indian ceremony was on Friday and western one was > > > Saturday. I > > > > have to say though, planning it was not easy. > > > > > > > > > > > > On Fri, Aug 29, 2014 at 10:53 AM, Michal Mocny > > > > wrote: > > > > > > > > > Thats the best wedding video I've ever seen! I love the dual > > > ceremonies > > > > -- > > > > > it must have been a blast for all the guests. Did you do it on the > > > same > > > > > weekend? > > > > > > > > > > > > > > > On Fri, Aug 29, 2014 at 1:46 PM, Mike Billau > > > > > wrote: > > > > > > > > > > > Wow Steve you clean up well man! Haha :p What a cool video. > > > > > > > > > > > > > > > > > > > > > > > > On Fri, Aug 29, 2014 at 11:51 AM, Steven Gill < > > > stevengil...@gmail.com> > > > > > > wrote: > > > > > > > > > > > > > Haha Thanks guys! I got married July 11-12 up in Vancouver. That > > is > > > > > why I > > > > > > > was MIA for start of July and end of June. You can see a short > > > > wedding > > > > > > > highlight video at http://vimeo.com/m/102964420 > > > > > > > > > > > > > > Wife is cool with the delayed honeymoon. Decided to avoid summer > > &
Re: Attending WWDC 2014?
exciting news! -James Jong On Jun 3, 2014, at 6:57 PM, Shazron wrote: > https://twitter.com/vickimurley/status/473955064629829632 > > On Tue, Jun 3, 2014 at 2:47 PM, Jesse wrote: >> Wow, that's new! Has the whole world gone sane? >> >> @purplecabbage >> risingj.com >> >> >> On Tue, Jun 3, 2014 at 2:17 PM, Shazron wrote: >> >>> Actually - this is a breath of fresh air -- we can talk about the >>> Apple pre-release stuff with certain conditions: >>> http://oleb.net/blog/2014/06/apple-lifted-beta-nda/ >>> >>> On Tue, Jun 3, 2014 at 12:58 PM, Shazron wrote: >>>> Hmm. I thought the link was under a login. Turns out it isn't - oh well >>> :P >>>> I think the main difference I saw is it opens up a lot more interfaces >>>> (delegates) for us to fix some of our workarounds with. >>>> >>>> On Tue, Jun 3, 2014 at 12:55 PM, Kerri Shotts >>> wrote: >>>>> Ooooh, those diffs have some *very interesting* things going on >>> there. >>>>> ;-) >>>>> >>>>> >>>>> >>>>> >>>>> ___ >>>>> Kerri Shotts >>>>> photoKandy Studios, LLC >>>>> >>>>> On the Web: http://www.photokandy.com/ >>>>> >>>>> Social Media: >>>>> Twitter: @photokandy, http://twitter.com/photokandy >>>>> Tumblr: http://photokandy.tumblr.com/ >>>>> Github: https://github.com/kerrishotts >>>>> >>> https://github.com/organizations/photokandyStudios >>>>> CoderWall: https://coderwall.com/kerrishotts >>>>> >>>>> Apps on the Apple Store: >>>>> >>>>> https://itunes.apple.com/us/artist/photokandy-studios-llc/id498577828 >>>>> >>>>> Books: >>>>> >>> http://www.packtpub.com/phonegap-2-mobile-application-hotshot/book >>>>> http://www.packtpub.com/phonegap-social-app-development/book >>>>> >>>>> >>>>> On Tue, Jun 3, 2014 at 2:37 PM, Marc Weiner >>> wrote: >>>>> >>>>>> WOW! Really?? That sounds promising! >>>>>> >>>>>> >>>>>> On Tue, Jun 3, 2014 at 3:23 PM, Michal Mocny >>> wrote: >>>>>> >>>>>>> WKWebView?! >>>>>>> >>>>>>> >>>>>>> On Tue, Jun 3, 2014 at 3:14 PM, Shazron wrote: >>>>>>> >>>>>>>> See API diffs: >>>>>>>> >>>>>>> >>>>>> >>> https://developer.apple.com/library/prerelease/ios/releasenotes/General/iOS80APIDiffs/index.html >>>>>>>> Some random search terms: UIWebView, Tofu, Rice Pilaf, WebKit, >>> Curry, >>>>>>>> Green Beans >>>>>>>> >>>>>>>> >>>>>>>> On Tue, Jun 3, 2014 at 10:05 AM, purplecabbage < >>>>>> purplecabb...@gmail.com> >>>>>>>> wrote: >>>>>>>>> The sessions will all be nda, but the docs should be available >>> now, >>>>>> and >>>>>>>> videos to come. >>>>>>>>> So I recommend you don't live tweet. >>>>>>>>> >>>>>>>>> Sent from my iPhone >>>>>>>>> >>>>>>>>>> On Jun 3, 2014, at 2:47 AM, tommy-carlos williams < >>>>>> to...@devgeeks.org >>>>>>>> >>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> Carlos, >>>>>>>>>> >>>>>>>>>> PLEASE tell me you are going to “Introducing the Modern WebKit >>> API” >>>>>>> and >>>>>>>> live tweeting it, or something?! >>>>>>>>>> >>>>>>>>>> “...advanced bridging between JavaScript and Objective-C, >>> increased >>>>>>>> JavaScript performance via WebKit's super-fast JIT, and more" >>>>>>>>>> >>>>>>>>>> Is that saying what I THINK it’s saying? >>>&
Re: Speculation: Apple supports WebGL in UIWebView, soon
Yeah, hopefully they are right. I guess we will find out in a couple of weeks! -James Jong On May 22, 2014, at 12:00 PM, Shazron wrote: > About time! > > > On Thu, May 22, 2014 at 8:14 AM, Ian Clelland wrote: > >> The reasoning is a little thin, but it's an interesting possibility: >> http://blog.playcanvas.com/apple-embraces-webgl/ >>
Re: 3.5.0 blog post review
LGTM. Nice work! -James Jong On May 21, 2014, at 6:08 PM, Marcel Kinard wrote: > Good looking blog post! > > I was noticing how all the BB10 items have a CB prefix, not so consistent in > the Android list ;-)
Re: [Vote] 3.5.0 iOS Release
+1 * verified using coho —verify-archive * verified tag matches repo@3.5.0 -James Jong On May 20, 2014, at 5:01 AM, Shazron wrote: > +1 verified archive using coho. > Verified tag sha, and zip contents identical to repo contents at that tag. > When I initially tagged iOS, all tests were passing in mob-spec, but now > the battery-status plugin is failing 1 test (battery.spec.4) > > > On Thu, May 15, 2014 at 10:36 AM, Ian Clelland wrote: > >> +1: Verified archive, confirmed match to repo@3.5.0. Ran tests on iOS >> 7.0.6, 7.1.1. (Enough tests to ensure that the platform is functioning. CI >> is red because of battery-status plugin.) >> >> >> On Wed, May 14, 2014 at 4:12 PM, Steven Gill >> wrote: >> >>> Please review and vote on this 3.5.0 iOS Release. >>> >>> Release issue: https://issues.apache.org/jira/browse/CB-6586 >>> >>> Repos ready to be released have been published to dist/dev: >>> https://dist.apache.org/repos/dist/dev/cordova/CB-6586/final >>> >>> The package was published from the corresponding git tag: >>> cordova-ios: 3.5.0 (643886ba8b) >>> >>> Upon a successful vote I will upload the archives to dist/, publish them >> to >>> NPM, and post the corresponding blog post. >>> >>> Voting guidelines: >>> >> https://github.com/apache/cordova-coho/blob/master/docs/release-voting.md >>> >>> Voting will go on for a minimum of 48 hours. >>> >>> I vote +1: >>> * Verified archive >>> * Ensured continuous build was green when repos were tagged >>> >>
Re: [DISCUSS] Automate signed icla to git commits
Agreed that it is working as intended. It’s also good to know that although Cordova’s been requiring CLA’s for it’s contributions, it isn’t a hard Apache requirement. For some contributions I’ve wanted to pull in, the CLA has been the holdup. Thanks for the clarification. -James Jong On Apr 28, 2014, at 10:40 PM, Andrew Grieve wrote: > I'm pretty confident it's working as intended for now. > > > On Mon, Apr 28, 2014 at 3:05 PM, Marvin Humphrey > wrote: > >> On Mon, Apr 28, 2014 at 9:20 AM, Andrew Grieve >> wrote: >>> Interesting! Going by this description, it sounds like we wound't need >>> ICLAs for the majority of pull requests since pull requests details get >>> forwarded to the mailing-list. >> >> Legally, the party making the pull request implicitly asserts that they >> have >> the right to contribute the commits under the ALv2 section 5. >> >> However, if a release with infringing material escapes out into the wild, >> having somebody to blame will be cold comfort. Should the original >> copyright >> owner request that we cease distributing the offending release, Cordova's >> users are going to be in a bad situation regardless. >> >>> New proposal: don't worry about CLAs at release time. >> >> The key here is that the Cordova PMC needs to be vigilant with every pull >> request from somebody who has not signed a CLA or is otherwise well-known >> to >> be submitting clean IP. The Cordova committer who accepts the pull request >> and pushes to the ASF repo is the first line of defense. However, the >> rest of >> the PMC is also collectively responsible for reviewing all commits. >> >> So the question is, how confident are you in the existing review process? >> If >> it's working as intended, then there's indeed no need to perform an >> additional >> audit at release time. On the other hand if it's porous, then building in >> more checks might be wise. >> >> Marvin Humphrey >>
Re: What should it mean to +1 a release
I went to Marvin’s talk on the release process at ApacheCon and several of the Cordova committers spoke with him afterwards. He was very knowledgeable and willing to help. Any help in smoothing out the release process while limiting the overhead would be greatly appreciated Marvin. -James Jong On Apr 25, 2014, at 3:25 PM, Marvin Humphrey wrote: > On Fri, Apr 25, 2014 at 10:55 AM, Andrew Grieve wrote: >> Had some discussions about this at ApacheCon, and I think it would be >> good to formalize this in a release-process doc within coho/docs. > > I'd like to help with this. ASF release policy is an area of expertise for > me, and I look forward in particular to suggesting mechanisms which reduce > overhead while keeping Cordova and the ASF in sync. > > Marvin Humphrey
Re: [DISCUSS] Automate signed icla to git commits
+1 -James Jong On Apr 25, 2014, at 4:10 PM, Ian Clelland wrote: > Instead, just don't worry about any commit hook, and have a coho tool that > scans the repo for all commits *since the last release* -- not since the > beginning of time -- looking for non-CLA-signed-contributions. The release > manager can make an executive decision at that point.
Re: Nomination for a new chair for Apache Cordova
+1 to chair nomination for Shaz. He will do a great job. Let’s try and keep this on topic and move the Apache Way discussion to a separate thread. -James Jong On Apr 23, 2014, at 3:09 AM, Joe Bowser wrote: > I think I need to go into why I don't like "The Apache Way" from the > view of the people that I actually care about, our users. The people > who talk to me at conventions, and wonder why things are so slow, > broken and stupid. > > 1. All communication on the e-mail list > > We've been breaking this one with Google Hangouts. From my > understanding we can't make any decision on the Google Hangout because > that is against the Apache Way and some committer can't make the > hangout in theory. The reality is that we have zero European > contributors and we manage to accomodate Tommy though magic of him > either being able to not sleep, or us picking a weird ass time that > screws over the East Coast. Before we did hangouts, connect and > conference calls on a more regular basis and it was easier for us to > actually work on shit together instead of being in weird silos. > > 2. Bureaucracy > Community > Code > > We've had numerous users complain about how we had to leave GitHub, > how hard it is to submit an issue, about API changes because of > Trademark Issues, and other issues pertaining to Apache Cordova > updates. We've had people criticize our fix for the non-voting and > people criticize the voting. We've basically had people criticize > everything that we've done to abide by the Apache Way because it makes > no sense. If Community > Code actually meant something, we'd listen > to all the users we had before we donated PhoneGap to Apache and > created Cordova. Just beacuse we're not httpd or OpenOffice doesn't > mean we don't have an active and passionate userbase that frankly > loves us and is passionate about this project far more than we ever > deserve. We should do better to listen to them and push back against > bureaucracy that doesn't make sense. It's not us being special > snowflakes, it's us fighting for the user! > > 3. Being bad at working with people and projects isn't funny > > I really didn't find the SVN abandoning SVN and adopting Git funny > (https://issues.apache.org/jira/browse/INFRA-7524) because I was privy > to all the communications sent during the whole > not-voting-for-releases battle. Everything is a big fight with > Apache, especially with people such as Jim. The first e-mail I > remember receiving from Jim was the cced one basically telling us to > go pound sand, which is my first impression of how the Apache board > works. Being assholes in private or public isn't funny, it's sad and > pathetic. However, it appears to be the Apache Way, which is why I do > it on this list, albeit not nearly as hard as people do it on most of > the lists that I've seen. > > I know that people don't care what anyone thinks of them, but that's a > bad attitude when you're trying to attract contributors, and when > you're trying to attract projects to the foundation. Whether it's > hangover posts from the Git war, or other posts bemoaning the Apache > culture of RTFM when it comes to its arcane policies, this is actively > discouraging people from being involved with Apache at all, including > Apache Cordova. I have some friends who were formerly with Apache, or > associated with the ASF that aren't because of it's toxic culture, and > it pisses me off that aspects of it continue, so yeah, I'm pretty > toxic to things that I see as toxic. I'm not going to air all the > dirty laundry here. > > Now, those are probably my main three complaints. I already know that > there's going to be some defence about not caring what other people > think and popularity contests, and I don't view that as productive. > I'm not asking everyone to sing kumbaya, but it would be nice if the > ASF, and those trying to curry favour with the ASF, would stop > purposely trying to alienate the people who helped create this project > in the first place. If you forwarded me an e-mail, even > unintentionally where you were abusive to myself or other people who > created this thing, I'll definitely remember that. > > Now, I think I derailed this thread enough with my personal opinion. > I think Shaz should be our chair because I think he'll do a good job > at it. > > Joe > > > On Tue, Apr 22, 2014 at 7:36 PM, Brian LeRoux wrote: >> Coming from Joe's perspective this is year 6 of the source code now known >> as Cordova. Jim and others have as muc
Re: [iOS] Objective-C object binding to UIWebWiew's JavaScriptCore
Pretty neat stuff there. We would have to be careful in adding it to core for app submissions. Perhaps a new target that includes it? -James Jong On Apr 22, 2014, at 12:13 PM, Andrew Grieve wrote: > Like it! Also - in the linked blog post they show how to capture > console.log. Would be another good DEBUG-only option. > > > On Tue, Apr 22, 2014 at 11:48 AM, Shazron wrote: > >> Yup, thats what I was thinking as well :) >> >> Another thing to add through this new method is to catch all JS exceptions >> and NSLog them natively, but there is already window.onerror, but not >> everyone uses it (or knows about it)...could be a DEBUG only option >> >> >> On Tue, Apr 22, 2014 at 8:43 AM, Andrew Grieve >> wrote: >> >>> Thanks for pointing this out! Very cool! Would allow for a much more >>> performance bridge on iOS. >>> >>> Maybe we could add it is as an optional bridge mode and let users that >> want >>> a faster bridge test the AppStore waters? >>> >>> >>> On Fri, Apr 18, 2014 at 9:38 PM, Brian LeRoux wrote: >>> >>>> This is awesome. >>>> On Apr 18, 2014 12:02 PM, "Shazron" wrote: >>>> >>>>> Note: iOS 7 only. >>>>> >>>>> Two ways to grab the JSContext: >>>>> 1. Through KVC of the UIWebView object and key >>>>> "documentView.webView.mainFrame.javaScriptContext" [1] >>>>> 2. Create a NSObject category for selector >>>>> "webView:didCreateJavaScriptContext:forFrame:" [2] >>>>> >>>>> Usual caveats apply to whether any of these methods is acceptable for >>> the >>>>> App Store. >>>>> >>>>> [1] >>>>> >>>>> >>> >> http://blog.impathic.com/post/64171814244/true-javascript-uiwebview-integration-in-ios7 >>>>> [2] https://github.com/TomSwift/UIWebView-TS_JavaScriptContext >>>>> >>>> >>> >>
Re: [DISCUSS] Plugin master branches
+1 Making it easier and less confusing for our new contributors is good. -James Jong On Apr 22, 2014, at 12:07 PM, Andrew Grieve wrote: > +1! Certainly it's causing us a lot of pain still. Moving to releasing off > of master seems like it would work fine. It's been working fine for > CLI/plugman, and they move much faster. > > > On Tue, Apr 22, 2014 at 11:37 AM, Braden Shepherdson > wrote: > >> We originally needed the plugin releases to be on the master branch because >> there was no way to have CLI/Plugman fetch from other branches. That is no >> longer the case. Further, you're correct that the registry's tarballs is >> the primary source now. Even if someone does have a git dependency >> somewhere, they can specify a branch (actually any ref) in the >> tag. Likewise the command line. >> >> I'm all for moving development into the master branch. >> >> Braden >> >> >> On Tue, Apr 22, 2014 at 10:23 AM, Bryan Higgins >> wrote: >> >>> +1 >>> >>> I think the registry has been around for long enough that the vast >> majority >>> of users won't be installing directly from git. >>> >>> >>> On Tue, Apr 22, 2014 at 9:44 AM, Ian Clelland >>> wrote: >>> >>>> I totally agree that we should do this. >>>> >>>> I think that once the current plugin release is complete, I can set up >>> the >>>> branches so that the master branch is for development, and we can go >> from >>>> there. >>>> >>>> Is it a requirement that plugins be tagged in git for npm to function? >> I >>>> thought that the plugins were uploaded, zipped, to our couch server, >> for >>>> each release, and that there was no further communication with the git >>>> repository? It shouldn't be a problem to go back and make sure they're >>>> properly tagged, but I'm just wondering if it's still a necessity. >>>> >>>> Ian >>>> >>>> On Mon, Apr 21, 2014 at 9:27 PM, Jesse >> wrote: >>>> >>>>> I am seeing more and more pull requests that aren't easy merges >> because >>>>> people are starting their work from the master branch, and not dev. >>>>> >>>>> We discussed *a long time ago* that at some point, we would consider >>>> master >>>>> to be the bleeding edge of each plugin, and we could then get rid of >>> the >>>>> dev branches. The requirements to make this possible included, >> using a >>>>> branch/tag for every npm release of the plugin, and making sure that >>>> plugin >>>>> dependencies were correctly mapped. >>>>> >>>>> Has anyone given this any more thought, and do we have any idea when >> we >>>>> will make the switch? >>>>> >>>>> Cheers, >>>>> Jesse >>>>> >>>>> >>>>> @purplecabbage >>>>> risingj.com >>>>> >>>> >>> >>
Re: [VOTE] Plugins Release
+1 verified signatures and hashes -James Jong On Apr 17, 2014, at 11:55 AM, Ian Clelland wrote: > Please review and vote on the release of this plugins release. > > Release issue: https://issues.apache.org/jira/browse/CB-6452 > > The plugins have been published to dist/dev: > https://dist.apache.org/repos/dist/dev/cordova/CB-6452/ > > The packages were published from their corresponding git tags: > >cordova-plugin-battery-status: 0.2.8 (c19c13c167) >cordova-plugin-camera: 0.2.9 (b76b5ae670) >cordova-plugin-console: 0.2.8 (266973315d) >cordova-plugin-contacts: 0.2.10 (134b3a6ba1) >cordova-plugin-device: 0.2.9 (4ae85e854d) >cordova-plugin-device-motion: 0.2.7 (2b6ca58b61) >cordova-plugin-device-orientation: 0.3.6 (b02b21774a) >cordova-plugin-dialogs: 0.2.7 (fa7f9adad7) >cordova-plugin-file: 1.1.0 (c1a105245f) >cordova-plugin-file-transfer: 0.4.3 (8b727b2cfd) >cordova-plugin-geolocation: 0.3.7 (77342cc4b9) >cordova-plugin-globalization: 0.2.7 (e61df29abd) >cordova-plugin-inappbrowser: 0.4.0 (1c98bc5b3f) >cordova-plugin-media: 0.2.10 (19dd42984e) >cordova-plugin-media-capture: 0.3.0 (ae84ed3f31) >cordova-plugin-network-information: 0.2.8 (a3e7f1a135) >cordova-plugin-splashscreen: 0.3.0 (8052d3804d) >cordova-plugin-statusbar: 0.1.5 (50febd81ba) >cordova-plugin-vibration: 0.3.8 (b8b46415c0) > > Upon a successful vote I will upload the archives to dist/, upload them to > the Plugins Registry, and post the corresponding blog post. > > Voting will go on for a minimum of 72 hours. > > I vote +1.
Re: [VOTE] Plugins Release
Ian, I’ll work on verifying this today. -James Jong On Apr 22, 2014, at 9:50 AM, Ian Clelland wrote: > So, this vote has gone exactly nowhere :) > > Do people need more time than this to review plugins? Should I split this > into 19 vote threads? :) > > Ian > > > On Tue, Apr 22, 2014 at 9:48 AM, Ian Clelland wrote: > >> Thanks, Jesse -- I didn't see that -- maybe because of master/dev issues; >> maybe because it's a new plugin to core, and I couldn't easily tell from >> the git tree what was in the last released version. (WP support is >> definitely on master; I only added the changes between master and dev to >> the release notes) >> >> >> On Thu, Apr 17, 2014 at 4:23 PM, Jesse wrote: >> >>> Support for org.apache.cordova.statusbar was added to Windows Phone. >>> >>> Windows Phone: >>> *statusbar *new* >>> >>> >>> @purplecabbage >>> risingj.com >>> >>> >>> On Thu, Apr 17, 2014 at 10:06 AM, Andrew Grieve >>> wrote: >>> >>>> I think we're be fine to +1 on just packaging / compliance. Checking >>>> for release quality is a bonus. >>>> >>>> On Thu, Apr 17, 2014 at 9:02 AM, Michal Mocny >>> wrote: >>>>> ..specifically, because I won't be testing all of the platforms >>> (doubtful >>>>> anyone will), I would like to be able to +1 for release packaging and >>>>> Android and iOS functionality only. Is that enough to bless the whole >>>>> release? >>>>> >>>>> >>>>> On Thu, Apr 17, 2014 at 12:59 PM, Michal Mocny >>>> wrote: >>>>> >>>>>> Interesting question: Can we +1 for a subset? >>>>>> >>>>>> >>>>>> On Thu, Apr 17, 2014 at 12:13 PM, Ian Clelland < >>> iclell...@chromium.org >>>>> wrote: >>>>>> >>>>>>> For the interest of those testing the plugins, these plugins have >>> had >>>> no >>>>>>> changes, except for documentation (license headers, NOTICE file, >>> etc): >>>>>>> * battery-status >>>>>>> * console >>>>>>> * vibration >>>>>>> >>>>>>> By platform, the following plugins have had significant (i.e., >>> native >>>>>>> code) >>>>>>> changes: >>>>>>> >>>>>>> Android: >>>>>>> * device >>>>>>> * file >>>>>>> * geolocation >>>>>>> * globalization >>>>>>> * media-capture >>>>>>> * statusbar >>>>>>> >>>>>>> BlackBerry10: >>>>>>> * camera >>>>>>> * device >>>>>>> * dialogs >>>>>>> * file >>>>>>> * media-capture >>>>>>> >>>>>>> FirefoxOS: >>>>>>> * >>>>>>> >>>>>>> FireOS: >>>>>>> * file-transfer >>>>>>> >>>>>>> iOS: >>>>>>> * camera >>>>>>> * contacts >>>>>>> * dialogs >>>>>>> * file >>>>>>> * file-transfer >>>>>>> * geolocation >>>>>>> * globalization >>>>>>> * inappbrowser >>>>>>> * media >>>>>>> * media-capture >>>>>>> * network-information >>>>>>> * splashscreen >>>>>>> >>>>>>> Tizen: >>>>>>> * splashscreen >>>>>>> >>>>>>> Windows8: >>>>>>> * camera >>>>>>> * device >>>>>>> * device-motion >>>>>>> * device-orientation >>>>>>> * dialogs >>>>>>> * file >>>>>>> * file-transfer >>>>>>> * geolocation >>>>>>> * inappbrowser >>>>>>> * media >>>>>>> * media-capture >>>>>>> * network-information >>>>>>> * splashscreen >>>>>>> >>>>>>> Windows Phone: >
Re: should FileTransfer.download() auto mkdir target's path?
me too! ;-) -James Jong On Apr 17, 2014, at 11:02 AM, Ian Clelland wrote: > On Thu, Apr 17, 2014 at 10:33 AM, purplecabbage > wrote: > >> I assume Ian and James mean consistency between current implementations on >> wp/ios/android ... >> and not between File+FileTransfer. >> > > Yes, this is exactly what I meant :) > > Me too! >> Go ahead and create the issue Mike. >> >> >> Sent from my iPhone >> >>> On Apr 17, 2014, at 7:07 AM, James Jong wrote: >>> >>> +1 for consistency >>> -James Jong >>> >>>> On Apr 17, 2014, at 8:36 AM, Ian Clelland >> wrote: >>>> >>>> +1 for consistency, and the simplest API. >>>> >>>> >>>> >>>> On Thu, Apr 17, 2014 at 8:29 AM, Mike Billau >> wrote: >>>> >>>>>> >>>>>> We can choose to make file-transfer it's own (higher level) thing with >>>>> it's >>>>>> own conventions, or we can aim for cohesiveness ... the original >> design >>>>> was >>>>>> based on being cohesive, I think. >>>>> >>>>> While I feel like being cohesive and in line with the File API is the >>>>> better choice, it seems that since Android and iOS already implement >> the >>>>> mkdir functionality, FileTransfer is already its own thing. It seems >> like >>>>> it would be more of a headache to deprecate the mkdir feature on >> Android >>>>> and iOS than it would be to just say "FileTransfer is it's own higher >> level >>>>> thing" and bring WP8 into alignment. And who knows, maybe we will want >> to >>>>> add new functionality into FileTransfer in the future (although I can't >>>>> think of any examples.) If nobody has any issues I'll create the JIRA >> issue >>>>> for WP8. >>>>> >>>>> >>>>> >>>>>> On Wed, Apr 16, 2014 at 3:50 PM, Jesse >> wrote: >>>>>> >>>>>> No, no spec, the issue was a File API issue, and the file-transfer >> plugin >>>>>> inherits some of the conventions. >>>>>> We can choose to make file-transfer it's own (higher level) thing with >>>>> it's >>>>>> own conventions, or we can aim for cohesiveness ... the original >> design >>>>> was >>>>>> based on being cohesive, I think. >>>>>> >>>>>> >>>>>> @purplecabbage >>>>>> risingj.com >>>>>> >>>>>> >>>>>> On Wed, Apr 16, 2014 at 12:42 PM, Ian Clelland < >> iclell...@chromium.org >>>>>>> wrote: >>>>>> >>>>>>> There's a spec? I thought filetransfer was something that PhoneGap >>>>>>> introduced. >>>>>>> >>>>>>> >>>>>>> On Wed, Apr 16, 2014 at 3:32 PM, Jesse >>>>> wrote: >>>>>>> >>>>>>>> Originally WP8 was creating any missing intermediate folders, but >>>>> this >>>>>>> was >>>>>>>> raised as a defect because the spec explicitly states it should >>>>> produce >>>>>>> an >>>>>>>> error in this case. >>>>>>>> Trying to dig up the issue ... >>>>>>>> >>>>>>>> >>>>>>>> @purplecabbage >>>>>>>> risingj.com >>>>>>>> >>>>>>>> >>>>>>>>> On Wed, Apr 16, 2014 at 12:07 PM, James Jong >> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> I think iOS attempts to create the directory first. >>>>> >> https://github.com/apache/cordova-plugin-file-transfer/blob/master/src/ios/CDVFileTransfer.m#L660 >>>>>>>>> -James Jong >>>>>>>>> >>>>>>>>>> On Apr 16, 2014, at 2:58 PM, Shazron wrote: >>>>>>>>>> >>>>>>>>>> Additional info: >>>>>>>>>> iOS will not create intermediate folders for download(), they >>>>> must >>>>>>>>> already >>>>>>>>>> exist >>>>>>>>>> (based on my tests with NSFileManager >>>>>>>>> createFileAtPath:contents:attributes >>>>>>>>>> call that is used by FileTransfer.download()) >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Wed, Apr 16, 2014 at 10:57 AM, Mike Billau < >>>>>> mike.bil...@gmail.com >>>>>>>> >>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> Hello, >>>>>>>>>>> >>>>>>>>>>> When using FileTransfer.download(), if the target location >>>>>> contains >>>>>>>>> folders >>>>>>>>>>> that do not exist on the device, should FileTransfer >>>>>> auto-magically >>>>>>>>> mkdir >>>>>>>>>>> these folders to save the download? >>>>>>>>>>> >>>>>>>>>>> If target= /foo/image.png, and if /foo/ doesn't exist, Android >>>>>> will >>>>>>>>> create >>>>>>>>>>> the /foo/ dir for you. WP8 doesn't seem to do this and will >>>>>> instead >>>>>>>>> return >>>>>>>>>>> with an error. I don't know which implementation should be >>>>>>> considered >>>>>>>>>>> "correct." It seems like a "good" dev should first check that >>>>> the >>>>>>>> target >>>>>>>>>>> exists and create it before saving the image, but I'm all for >>>>>> making >>>>>>>>> things >>>>>>>>>>> easier for the developer and just doing it auto-magically (I >>>>> hate >>>>>>> that >>>>>>>>>>> word...) >>>>>>>>>>> >>>>>>>>>>> I'm using 3.1 btw, sigh and sorry! Thanks everyone for your >>>>>>> opinions. >>> >>
Re: should FileTransfer.download() auto mkdir target's path?
+1 for consistency -James Jong On Apr 17, 2014, at 8:36 AM, Ian Clelland wrote: > +1 for consistency, and the simplest API. > > > > On Thu, Apr 17, 2014 at 8:29 AM, Mike Billau wrote: > >>> >>> We can choose to make file-transfer it's own (higher level) thing with >> it's >>> own conventions, or we can aim for cohesiveness ... the original design >> was >>> based on being cohesive, I think. >>> >> >> While I feel like being cohesive and in line with the File API is the >> better choice, it seems that since Android and iOS already implement the >> mkdir functionality, FileTransfer is already its own thing. It seems like >> it would be more of a headache to deprecate the mkdir feature on Android >> and iOS than it would be to just say "FileTransfer is it's own higher level >> thing" and bring WP8 into alignment. And who knows, maybe we will want to >> add new functionality into FileTransfer in the future (although I can't >> think of any examples.) If nobody has any issues I'll create the JIRA issue >> for WP8. >> >> >> >> On Wed, Apr 16, 2014 at 3:50 PM, Jesse wrote: >> >>> No, no spec, the issue was a File API issue, and the file-transfer plugin >>> inherits some of the conventions. >>> We can choose to make file-transfer it's own (higher level) thing with >> it's >>> own conventions, or we can aim for cohesiveness ... the original design >> was >>> based on being cohesive, I think. >>> >>> >>> @purplecabbage >>> risingj.com >>> >>> >>> On Wed, Apr 16, 2014 at 12:42 PM, Ian Clelland >>> wrote: >>> >>>> There's a spec? I thought filetransfer was something that PhoneGap >>>> introduced. >>>> >>>> >>>> On Wed, Apr 16, 2014 at 3:32 PM, Jesse >> wrote: >>>> >>>>> Originally WP8 was creating any missing intermediate folders, but >> this >>>> was >>>>> raised as a defect because the spec explicitly states it should >> produce >>>> an >>>>> error in this case. >>>>> Trying to dig up the issue ... >>>>> >>>>> >>>>> @purplecabbage >>>>> risingj.com >>>>> >>>>> >>>>> On Wed, Apr 16, 2014 at 12:07 PM, James Jong >>>> wrote: >>>>> >>>>>> I think iOS attempts to create the directory first. >>>>>> >>>>>> >>>>> >>>> >>> >> https://github.com/apache/cordova-plugin-file-transfer/blob/master/src/ios/CDVFileTransfer.m#L660 >>>>>> -James Jong >>>>>> >>>>>> On Apr 16, 2014, at 2:58 PM, Shazron wrote: >>>>>> >>>>>>> Additional info: >>>>>>> iOS will not create intermediate folders for download(), they >> must >>>>>> already >>>>>>> exist >>>>>>> (based on my tests with NSFileManager >>>>>> createFileAtPath:contents:attributes >>>>>>> call that is used by FileTransfer.download()) >>>>>>> >>>>>>> >>>>>>> On Wed, Apr 16, 2014 at 10:57 AM, Mike Billau < >>> mike.bil...@gmail.com >>>>> >>>>>> wrote: >>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> When using FileTransfer.download(), if the target location >>> contains >>>>>> folders >>>>>>>> that do not exist on the device, should FileTransfer >>> auto-magically >>>>>> mkdir >>>>>>>> these folders to save the download? >>>>>>>> >>>>>>>> If target= /foo/image.png, and if /foo/ doesn't exist, Android >>> will >>>>>> create >>>>>>>> the /foo/ dir for you. WP8 doesn't seem to do this and will >>> instead >>>>>> return >>>>>>>> with an error. I don't know which implementation should be >>>> considered >>>>>>>> "correct." It seems like a "good" dev should first check that >> the >>>>> target >>>>>>>> exists and create it before saving the image, but I'm all for >>> making >>>>>> things >>>>>>>> easier for the developer and just doing it auto-magically (I >> hate >>>> that >>>>>>>> word...) >>>>>>>> >>>>>>>> I'm using 3.1 btw, sigh and sorry! Thanks everyone for your >>>> opinions. >>>>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >>
Re: [File Plugin, iOS] What to do with FileEntry.setMetadata?
How about documenting it as an iOS specific extension? We can mention it’s not part a current spec. -James Jong On Apr 17, 2014, at 9:03 AM, Ian Clelland wrote: > It's not in the File API spec; it's in the "File API: Directories and > System" (http://www.w3.org/TR/file-system-api/#methods-2), which is what > our File plugin is largely based on. > > (Unfortunately, it's now one of two competing File System specs at the W3C, > and it looks like it's losing. The last I heard, that document is going to > be relegated to "Note" status, and the browser vendors are going to move > forward with Mozilla's FileSystem API spec: > http://w3c.github.io/filesystem-api/Overview.html. We may be left on our > own supporting this particular spec.) > > Ian > > On Wed, Apr 16, 2014 at 11:07 PM, Steven Gill wrote: > >> Maybe this is something we could suggest to the W3C group for addition? >> >> [1] http://www.w3.org/TR/FileAPI/ >> [2] public-weba...@w3.org >> >> >> >> On Wed, Apr 16, 2014 at 6:08 PM, Shazron wrote: >> >>> This function is not in the W3C File API spec, thus not documented. But >>> users need to use this to set the metadata for files so they don't get >>> backed up to iCloud: https://issues.apache.org/jira/browse/CB-6195 >>> >>> It's not really a "quirk", more like an addition to the spec. >>> >>
Re: ApacheCon recordings and slides
You’re right. There’s another Cordova one from Hazem Saleh as well but the others are not there. Not sure if they just haven’t posted all of them yet or what. -James Jong On Apr 16, 2014, at 3:11 PM, Carlos Santana wrote: > Can't find the cordova related ones on that website, only Lisa's on > translation. > > Which is the one that Marcel mentioned yesterday during hangout > > > On Wed, Apr 16, 2014 at 2:07 PM, James Jong wrote: > >> Someone asked about links to ApacheCon slides and audio recordings during >> the hangout. >> >> Slides >> >> http://events.linuxfoundation.org/events/apachecon-north-america/program/slides >> >> Audiocast (currently featuring our own Steve Gill at top!) >> http://feathercast.apache.org >> >> -James Jong >> >> > > > -- > Carlos Santana >
Re: should FileTransfer.download() auto mkdir target's path?
I think iOS attempts to create the directory first. https://github.com/apache/cordova-plugin-file-transfer/blob/master/src/ios/CDVFileTransfer.m#L660 -James Jong On Apr 16, 2014, at 2:58 PM, Shazron wrote: > Additional info: > iOS will not create intermediate folders for download(), they must already > exist > (based on my tests with NSFileManager createFileAtPath:contents:attributes > call that is used by FileTransfer.download()) > > > On Wed, Apr 16, 2014 at 10:57 AM, Mike Billau wrote: > >> Hello, >> >> When using FileTransfer.download(), if the target location contains folders >> that do not exist on the device, should FileTransfer auto-magically mkdir >> these folders to save the download? >> >> If target= /foo/image.png, and if /foo/ doesn't exist, Android will create >> the /foo/ dir for you. WP8 doesn't seem to do this and will instead return >> with an error. I don't know which implementation should be considered >> "correct." It seems like a "good" dev should first check that the target >> exists and create it before saving the image, but I'm all for making things >> easier for the developer and just doing it auto-magically (I hate that >> word...) >> >> I'm using 3.1 btw, sigh and sorry! Thanks everyone for your opinions. >>
ApacheCon recordings and slides
Someone asked about links to ApacheCon slides and audio recordings during the hangout. Slides http://events.linuxfoundation.org/events/apachecon-north-america/program/slides Audiocast (currently featuring our own Steve Gill at top!) http://feathercast.apache.org -James Jong
Re: Introducing myself
Welcome Victor! -James Jong On Apr 14, 2014, at 12:51 PM, Victor Sosa wrote: > Hello Apache Cordova Community. > > My Name is Victor Sosa. Really excited to start contributing to this > project. > My background is as Java developer focused on Eclipse tools, but lately > I've been doing some mobile development and that's how I discovered Cordova. > I also have some background on other areas, like Web development, Cloud > computing and scripting languages (I am a Linux user ;-). > > Cheers!
Re: [iOS] CB-6441 System frameworks issue
+1 to removing the cache. Reliability is more important. -James Jong On Apr 15, 2014, at 8:42 PM, Anis KADRI wrote: > There are currently a lot people reporting this issue on the google groups. > > iOS frameworks don't get added when plugin with dependencies gets > installed. It's a big problem because projects don't compile. > > A great example of this is: mobile-spec/dependencies-plugin/. It seems like > the double caching of pbxproject file in plugman (platforms, > config-changes) is causing this and deleting this line [1] fixes it. > > this would have been easier for me to figure out if everything > was broken out into shorter discreet modules. Instead it took me several > hours. > > The change was introduced with this pull request it seems: > https://github.com/apache/cordova-plugman/pull/45/files > > I am not sure what the proper fix is. I love performance but I love > reliability even more. I think ideally we'd have one cache shared across > modules but we need an immediate fix for this so unless someone thinks they > can implement it before the next release I propose that we don't use the > cache for the time being. > > Thoughts ? > > [1] > https://git-wip-us.apache.org/repos/asf?p=cordova-plugman.git;a=blob;f=src/platforms/ios.js;h=9631e6450c4481def593a8043519d2e55a9e69f2;hb=HEAD#l156
Re: [DISCUSS] Plugin release this week / early next
SGTM. It has been awhile since our last plugins release. -James Jong On Apr 15, 2014, at 11:53 AM, Ian Clelland wrote: > It's been a while since we did a plugin release, and I have a number of > changes to File / Media that I'd like to make public. It looks every plugin > has had at least one commit since the last release, though, so maybe we > want to do a release of the full suite. > > (The one minimum commit for each appears to be an "Added NOTICE file", so > it might be good from an ASF-compliance POV) > > From what I can see this morning: > > cordova-plugin-battery-status: release 0.2.8, 1 commit > cordova-plugin-camera: release 0.2.9, 12 commits > cordova-plugin-console: release 0.2.8, 1 commit > cordova-plugin-contacts: release 0.2.10, 5 commits > cordova-plugin-device: release 0.2.9, 3 commits > cordova-plugin-device-motion: release 0.2.7, 2 commits > cordova-plugin-device-orientation: release 0.3.6, 3 commits > cordova-plugin-dialogs: release 0.2.7, 5 commits > cordova-plugin-file: release 1.0.2, 25 commits > cordova-plugin-file-transfer: release 0.4.3, 7 commits > cordova-plugin-geolocation: release 0.3.7, 4 commits > cordova-plugin-globalization: release 0.2.7, 4 commits > cordova-plugin-inappbrowser: release 0.3.4, 12 commits > cordova-plugin-media: release 0.2.10, 4 commits > cordova-plugin-media-capture: release 0.2.9, 8 commits > cordova-plugin-network-information: release 0.2.8, 3 commits > cordova-plugin-splashscreen: release 0.2.8, 3 commits > cordova-plugin-statusbar: release 0.1.5, 4 commits > cordova-plugin-vibration: release 0.3.8, 1 commit > > > I have a couple of changes that I want to get in to media-capture today, > but after that I'm happy with the state of the file-related plugins. > > Thoughts? We could start a vote thread tomorrow or Thursday, and release on > Monday if it passes. > > Ian
Re: [ANNOUNCE] Released cordova-cli@3.4.1-0.1.0, cordova-plugman@0.21.0, cordova-ios@3.4.1
Woot! Thanks Steve! -James Jong On Apr 9, 2014, at 6:00 PM, Steven Gill wrote: > CLI, Plugman and cordova-ios have been released! > > You can view the release blog post at > http://cordova.apache.org/news/2014/04/09/tools-ios-release.html. > > Tweet: https://twitter.com/apachecordova/status/454045980959047680
Re: Get your test results here! Medic/CI viewing available
Nice work David! -James Jong On Mar 25, 2014, at 4:50 PM, David Kemp wrote: > Hi all, > After many months of delays, we now have our Buildbot master available for > the community to view. You can see the status of the tests for Android, > iOS, CLI and Plugman, > > You can see/view the build display at: > > http://108.170.217.131:8010/waterfall or http://goo.gl/UNijok > > For those not familiar with Buildbot, each phase of the test has a 'stdio' > link that allows you to see any command output from that step. If a step > fails (stopping the build) you can generally just click the link and see > the error messages. > Test results are saved in a couchDB for posterity, but there is no pretty > dashboard for that. > > *Currently Configuration:* > Android Master : master platform, dev plugins, master CLI, master Plugman > Android Release : 3.4.x platform, master plugins, master CLI, master Plugman > iOS Master : master platform, dev plugins, master CLI, master Plugman > iOS Release : 3.4.x platform, master plugins, master CLI, master Plugman > Tools CLI Master : master CLI, master Plugman > Tools Plugman : master plugman > Chrome Desktop : Chrome API tests on release Chrome > Chrome Mobile : Chrome API tests on cca - android > > Note that the last two tests are for our Chrome Apps on Mobile toolchain > (not part of Cordova). > > Android and iOS tests currently run on only one device: iPad mini v7.0 > and Nexus 7 v4.3
Re: Release Managers
+1 Would be great to spread the knowledge around. -James Jong On Mar 13, 2014, at 3:16 PM, Braden Shepherdson wrote: > +1 to this concept. > > I'm in to manage the tools releases, not familiar at all with the process > for the others. But I'm willing to learn enough to do it, if we're just > passing these responsibilities around. > > Braden > > > On Thu, Mar 13, 2014 at 2:10 PM, Marcel Kinard wrote: > >> +1, I'm throwing my hat in the ring. >> >> On Mar 13, 2014, at 1:34 PM, Bryan Higgins wrote: >> >>> +1, I'll throw my hat in the ring as well >> >>
Re: [cordova-plugins/statusbar] Publishing as core
Similar to keyboard plugin, I like the idea of letting this bake in labs for now and moving them into core if we see multiple platforms start needing a similar API. So (a) and (c) for me. I would add that the iOS 6/7 specific code may not make sense as "core”. -James Jong On Mar 5, 2014, at 9:10 PM, Jesse wrote: > I have created a task in JIRA for all the statusbar related discussion. [1] > There are numerous inconsistencies we need to address here. > > [1] https://issues.apache.org/jira/browse/CB-6177 > > @purplecabbage > risingj.com > > > On Wed, Mar 5, 2014 at 5:15 PM, Shazron wrote: > >> Some background on the statusbar plugin. >> >> This was conceived because of iOS 7 where the statusbar overlays the >> webview, and a lot of people didn't like their UI changing especially if >> they still support iOS 6. That is the primary purpose of this plugin, but >> there are other features in there as well. In the last few weeks, there was >> a pull request (now integrated) for StatusBar.hide and StatusBar.show for >> Android as well. >> >> The issues related to the statusbar are under the label "statusbar-plugin" >> in JIRA, and there are currently 11 open issues. There are pull requests >> for it from the PhoneGap Build team that I am waiting to integrate -- not >> until we get this namespace stuff sorted out. >> >> I am not opposed to it being under the "labs" namespace. After talking to >> the Adobe team, we could also host the plugin under the PhoneGap Github >> org, but I'd rather use that as a last resort. >> >> >> On Wed, Mar 5, 2014 at 11:36 AM, Michal Mocny wrote: >> >>> (a) Yes. >>> (b) No -- some organizations (Adobe) don't like this, and we respect >> that. >>> We also want to point users at these plugins, so its good to have >>> developers protected by Apache. >>> (c) Sure -- so long as labs is clearly separate, and we leave them out of >>> blogs / plugin release notes, and we don't impact the rate of releases >>> (i.e. we don't force devs to test the labs plugins, just verify the >>> signatures is enough). >>> (d) I think the "guardian" of these labs plugins should be free to >> publish. >>> There is no reason they are lower quality than anything else. >>> >>> >>> Separate issue: is statusbar ready for Core? I think we should leave it >> in >>> labs for a little bit, have at least a few eyes audit the API and >>> investigate if there is any other similar work in the field before we >> make >>> users depend on this, but that it should move to core eventually. >>> >>> -Michal >>> >>> >>> On Wed, Mar 5, 2014 at 1:14 PM, Shazron wrote: >>> >>>> statusbar is already published org.apache.cordova.statusbar. >>>> >>>> And... Since these plugins are somewhat experimental and we're starting >>> the >>>> process of voting and publishing plugins to dist/, I wonder: >>>> >>>> a) Should we change the ID of these plugins to, say >>>> "org.apache.cordova.labs" >>>> b) Should we move these plugins to github and have them not under >> apache >>>> for now, e.g.: com.shazron.statusbar >>>> c) Should we just add them to the plugin release process. >>>> d) Should we just never publish them to the registry and have people >> use >>>> them via git url. >>>> >>> >>
Re: [cordova-plugins/keyboard] Publishing as core
I like the idea of letting this bake in labs for now and moving them into core if we see multiple platforms start needing a similar API. So (a) and (c) for me. -James Jong On Mar 5, 2014, at 8:19 PM, Shazron wrote: > Some background on the keyboard plugin. > > This was extracted from the iOS core, and put into its own plugin so > updates are not tied to a platform release, and fixes can be rapid. Someone > filed this issue https://issues.apache.org/jira/browse/CB-6176 and I didn't > know that BlackBerry also supported some of the keyboard preferences, so it > might be multi-platform -- the BB code is definitely not extracted out into > this plugin. > > The issues related to the keyboard are under the label "keyboard-plugin" in > JIRA, and there are currently 18 open issues. It is a complicated plugin > (see its mobile-spec manual tests), and complicated to test. > > I am not opposed to it being under the "labs" namespace. After talking to > the Adobe team, we could also host the plugin under the PhoneGap Github > org, but I'd rather use that as a last resort. > > > On Wed, Mar 5, 2014 at 10:14 AM, Shazron wrote: > >> keyboard is already published org.apache.cordova.keyboard. >> >> And... Since these plugins are somewhat experimental and we're starting the >> process of voting and publishing plugins to dist/, I wonder: >> >> a) Should we change the ID of these plugins to, say >> "org.apache.cordova.labs" >> b) Should we move these plugins to github and have them not under apache >> for now, e.g.: com.shazron.statusbar >> c) Should we just add them to the plugin release process. >> d) Should we just never publish them to the registry and have people use >> them via git url. >>
Re: [VOTE] Cordova 3.0.0
+1 -James Jong On Feb 25, 2014, at 4:55 PM, RUDD, Brett wrote: > +1 > > On Feb 25, 2014, at 12:17, Steven Gill wrote: > >> Please review and vote on our past release of Cordova 3.0.0. >> >> You can find the src + asc + md5 + sha at the following links: >> * http://archive.apache.org/dist/cordova/cordova-3.0.0-src.zip >> * http://archive.apache.org/dist/cordova/cordova-3.0.0-src.zip.asc >> * http://archive.apache.org/dist/cordova/cordova-3.0.0-src.zip.md5 >> * http://archive.apache.org/dist/cordova/cordova-3.0.0-src.zip.sha >> >> http://git-wip-us.apache.org/repos/asf?p=cordova-android.git;a=shortlog;h=refs/tags/3.0.0 >> d0b3f419efb0e364879b79139936a1a8a9ff6459 refs/tags/3.0.0 >> http://git-wip-us.apache.org/repos/asf?p=cordova-ios.git;a=shortlog;h=refs/tags/3.0.0 >> 26df4e23076c91dfc048b1a52b1a1ffa8963b6cd refs/tags/3.0.0 >> http://git-wip-us.apache.org/repos/asf?p=cordova-blackberry.git;a=shortlog;h=refs/tags/3.0.0 >> 3b791ff310ca944aa57afd71c462998cb36f9c80 refs/tags/3.0.0 >> http://git-wip-us.apache.org/repos/asf?p=cordova-windows.git;a=shortlog;h=refs/tags/3.0.0 >> 7055d60fbd320f8c31a9942032057977bb51b2fd refs/tags/3.0.0 >> http://git-wip-us.apache.org/repos/asf?p=cordova-wp8.git;a=shortlog;h=refs/tags/3.0.0 >> 1ef8f6a0a6431930f5c9826d3c315e99d9194371 refs/tags/3.0.0 >> http://git-wip-us.apache.org/repos/asf?p=cordova-cli.git;a=shortlog;h=refs/tags/3.0.0 >> 40979c6789b29e43470737673a8476d94e57f086 refs/tags/3.0.0 >> http://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=shortlog;h=refs/tags/3.0.0 >> e670de91e68b2bf08f04b05cf997305f4bc3d4b1 refs/tags/3.0.0 >> http://git-wip-us.apache.org/repos/asf?p=cordova-mobile-spec.git;a=shortlog;h=refs/tags/3.0.0 >> e12609d87241d57113ac27399a2061798a8ecd88 refs/tags/3.0.0 >> http://git-wip-us.apache.org/repos/asf?p=cordova-app-hello-world.git;a=shortlog;h=refs/tags/3.0.0 >> c9fb07b84401da76dc805d2a550ca5c77dc03457 refs/tags/3.0.0 >> http://git-wip-us.apache.org/repos/asf?p=cordova-docs.git;a=shortlog;h=refs/tags/3.0.0 >> 52e16d09b3eae6eda94927ce8e9ea3145cff211a refs/tags/3.0.0 >> >> Voting will go on for 48 hours. >
Re: [VOTE] Cordova 3.1.0
+1 -James Jong On Feb 25, 2014, at 4:55 PM, RUDD, Brett wrote: > +1 > > On Feb 25, 2014, at 12:21, Steven Gill wrote: > >> Please review and vote on our past release of Cordova 3.1.0. >> >> You can find the src + asc + md5 + sha at the following links: >> * http://archive.apache.org/dist/cordova/cordova-3.1.0-src.zip >> * http://archive.apache.org/dist/cordova/cordova-3.1.0-src.zip.asc >> * http://archive.apache.org/dist/cordova/cordova-3.1.0-src.zip.md5 >> * http://archive.apache.org/dist/cordova/cordova-3.1.0-src.zip.sha >> >> http://git-wip-us.apache.org/repos/asf?p=cordova-android.git;a=shortlog;h=refs/tags/3.1.0 >> e5b01579711e845c34e80b91bd1005a6d0205451 refs/tags/3.1.0 >> http://git-wip-us.apache.org/repos/asf?p=cordova-ios.git;a=shortlog;h=refs/tags/3.1.0 >> bbc04638e38a2978d05d8178c2d78d9b4406bdc4 refs/tags/3.1.0 >> http://git-wip-us.apache.org/repos/asf?p=cordova-blackberry.git;a=shortlog;h=refs/tags/3.1.0 >> c60b4a44e4df33523c1f70bc8432c8aab5a0c371 refs/tags/3.1.0 >> http://git-wip-us.apache.org/repos/asf?p=cordova-windows.git;a=shortlog;h=refs/tags/3.1.0 >> 0ca3a25e9b092e5446f29f20f37d8f808df8e49a refs/tags/3.1.0 >> http://git-wip-us.apache.org/repos/asf?p=cordova-wp8.git;a=shortlog;h=refs/tags/3.1.0 >> 0b539a85bd390f78f9bb95f57c8536bed84dd726 refs/tags/3.1.0 >> http://git-wip-us.apache.org/repos/asf?p=cordova-firefoxos.git;a=shortlog;h=refs/tags/3.1.0 >> 129489d8160bc4397c6d71660534cb40192f88f8 refs/tags/3.1.0 >> http://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=shortlog;h=refs/tags/3.1.0 >> 1517b704704016e408f29b1326a5b94dc39b2399 refs/tags/3.1.0 >> http://git-wip-us.apache.org/repos/asf?p=cordova-mobile-spec.git;a=shortlog;h=refs/tags/3.1.0 >> a7cebd57660348baf28d8936a2187f10373a5337 refs/tags/3.1.0 >> http://git-wip-us.apache.org/repos/asf?p=cordova-app-hello-world.git;a=shortlog;h=refs/tags/3.1.0 >> 5683220ad99ea3e879b742b6eb7ecb42d9c79698 refs/tags/3.1.0 >> http://git-wip-us.apache.org/repos/asf?p=cordova-docs.git;a=shortlog;h=refs/tags/3.1.0 >> 1a73cb7147e6229681db8788fb1022c2f98b45e6 refs/tags/3.1.0 >> >> http://git-wip-us.apache.org/repos/asf?p=cordova-cli.git;a=shortlog;h=refs/tags/3.1.0-0.1.0 >> f346be0c4221a6dfba909d154cddcbf6ba843542 refs/tags/3.1.0-0.1.0 >> >> Voting will go on for 48 hours. >
Re: [VOTE] Cordova 3.3.0
+1 -James Jong On Feb 25, 2014, at 4:49 PM, Joe Bowser wrote: > +1 > > On Tue, Feb 25, 2014 at 12:27 PM, Steven Gill wrote: >> Please review and vote on our past release of Cordova 3.3.0. >> >> You can find the src + asc + md5 + sha at the following links: >> * http://archive.apache.org/dist/cordova/cordova-3.3.0-src.zip >> * http://archive.apache.org/dist/cordova/cordova-3.3.0-src.zip.asc >> * http://archive.apache.org/dist/cordova/cordova-3.3.0-src.zip.md5 >> * http://archive.apache.org/dist/cordova/cordova-3.3.0-src.zip.sha >> >> http://git-wip-us.apache.org/repos/asf?p=cordova-android.git;a=shortlog;h=refs/tags/3.3.0 >> 97ad4d84ce333f05d6240b75f65da8536bcc3eb1 refs/tags/3.3.0 >> http://git-wip-us.apache.org/repos/asf?p=cordova-ios.git;a=shortlog;h=refs/tags/3.3.0 >> 4972510ca591f8756a0a6b756c0d6691976e2106 refs/tags/3.3.0 >> http://git-wip-us.apache.org/repos/asf?p=cordova-blackberry.git;a=shortlog;h=refs/tags/3.3.0 >> ac5f461fabd598271b4a6bdeb5b57018e2cb5e61 refs/tags/3.3.0 >> http://git-wip-us.apache.org/repos/asf?p=cordova-windows.git;a=shortlog;h=refs/tags/3.3.0 >> b92941c90ff2f3a99d77e77bfa334a7d2c74f534 refs/tags/3.3.0 >> http://git-wip-us.apache.org/repos/asf?p=cordova-wp8.git;a=shortlog;h=refs/tags/3.3.0 >> 68de03b36dd32d3707b9cdf6ef050bbe87343a48 refs/tags/3.3.0 >> http://git-wip-us.apache.org/repos/asf?p=cordova-firefoxos.git;a=shortlog;h=refs/tags/3.3.0 >> 02b07dfe0115e4ce92e494c6c43ba882a5564b26 refs/tags/3.3.0 >> http://git-wip-us.apache.org/repos/asf?p=cordova-ubuntu.git;a=shortlog;h=refs/tags/3.3.0 >> c477479a8ddccb4c1a2e2630e5300c1629ebe94c refs/tags/3.3.0 >> http://git-wip-us.apache.org/repos/asf?p=cordova-amazon-fireos.git;a=shortlog;h=refs/tags/3.3.0 >> e9d39c53c448905eacfefed00dbb3af82a3856d6 refs/tags/3.3.0 >> http://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=shortlog;h=refs/tags/3.3.0 >> b7feb74d4e72d2b759350433286d88d50fc59be7 refs/tags/3.3.0 >> http://git-wip-us.apache.org/repos/asf?p=cordova-mobile-spec.git;a=shortlog;h=refs/tags/3.3.0 >> 86d912c7c6938c6b936183a2e8b30e1638906242 refs/tags/3.3.0 >> http://git-wip-us.apache.org/repos/asf?p=cordova-app-hello-world.git;a=shortlog;h=refs/tags/3.3.0 >> 01af7dca35ff413b9fbb4e24b664861f6f45731b refs/tags/3.3.0 >> http://git-wip-us.apache.org/repos/asf?p=cordova-docs.git;a=shortlog;h=refs/tags/3.3.0 >> c6219cfc76e070df7ddc0a79b97e99ef856e86c6 refs/tags/3.3.0 >> >> http://git-wip-us.apache.org/repos/asf?p=cordova-cli.git;a=shortlog;h=refs/tags/3.3.0-0.1.0 >> f338c0fc6f2ccc09b48001e96dd80d15757c8e83 refs/tags/3.3.0-0.1.0 >> >> Voting will go on for 48 hours.
Re: [VOTE] Cordova 3.2.0
+1 -James Jong On Feb 26, 2014, at 12:39 AM, Don Coleman wrote: > +1 > > > On Tue, Feb 25, 2014 at 4:55 PM, RUDD, Brett wrote: > >> +1 >> >> On Feb 25, 2014, at 12:24, Steven Gill wrote: >> >>> Please review and vote on our past release of Cordova 3.2.0. >>> >>> You can find the src + asc + md5 + sha at the following links: >>> * http://archive.apache.org/dist/cordova/cordova-3.2.0-src.zip >>> * http://archive.apache.org/dist/cordova/cordova-3.2.0-src.zip.asc >>> * http://archive.apache.org/dist/cordova/cordova-3.2.0-src.zip.md5 >>> * http://archive.apache.org/dist/cordova/cordova-3.2.0-src.zip.sha >>> >>> >> http://git-wip-us.apache.org/repos/asf?p=cordova-android.git;a=shortlog;h=refs/tags/3.2.0 >>> 221b10b1e6a94f5739f8795a679ea019c8b9343e refs/tags/3.2.0 >>> >> http://git-wip-us.apache.org/repos/asf?p=cordova-ios.git;a=shortlog;h=refs/tags/3.2.0 >>> 6874642dda11d792a6ccb9cd861b36b73fc45aa8 refs/tags/3.2.0 >>> >> http://git-wip-us.apache.org/repos/asf?p=cordova-blackberry.git;a=shortlog;h=refs/tags/3.2.0 >>> 3f92336a1510985c90b05130429c20bcd43e6895 refs/tags/3.2.0 >>> >> http://git-wip-us.apache.org/repos/asf?p=cordova-windows.git;a=shortlog;h=refs/tags/3.2.0 >>> 02b49166061bcb7f3d663e79752c7aab29b07afe refs/tags/3.2.0 >>> >> http://git-wip-us.apache.org/repos/asf?p=cordova-wp8.git;a=shortlog;h=refs/tags/3.2.0 >>> 073240e430198c6b266ecaf6800b75ac6b7ba6ab refs/tags/3.2.0 >>> >> http://git-wip-us.apache.org/repos/asf?p=cordova-firefoxos.git;a=shortlog;h=refs/tags/3.2.0 >>> 1091597a346e0debd6e5f4fc3e756973dce7e995 refs/tags/3.2.0 >>> >> http://git-wip-us.apache.org/repos/asf?p=cordova-ubuntu.git;a=shortlog;h=refs/tags/3.2.0 >>> 0a2e2476d69373dabc7452b4225ffd18dfb96fca refs/tags/3.2.0 >>> >> http://git-wip-us.apache.org/repos/asf?p=cordova-amazon-fireos.git;a=shortlog;h=refs/tags/3.2.0 >>> b3b7c0b9dbaa6017e7e78c59d06300360454f90b refs/tags/3.2.0 >>> >> http://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=shortlog;h=refs/tags/3.2.0 >>> fc683fbb04846ea54c8a173b9ad59361662f4c56 refs/tags/3.2.0 >>> >> http://git-wip-us.apache.org/repos/asf?p=cordova-mobile-spec.git;a=shortlog;h=refs/tags/3.2.0 >>> dfca43fd78c8cba06f88b67a5649e953a2b2795f refs/tags/3.2.0 >>> >> http://git-wip-us.apache.org/repos/asf?p=cordova-app-hello-world.git;a=shortlog;h=refs/tags/3.2.0 >>> ee9a8632247a23339221c7d894b7bd617bf39d2e refs/tags/3.2.0 >>> >> http://git-wip-us.apache.org/repos/asf?p=cordova-docs.git;a=shortlog;h=refs/tags/3.2.0 >>> 3ef0092b0c940855990102a50a905dc19241adeb refs/tags/3.2.0 >>> >>> >> http://git-wip-us.apache.org/repos/asf?p=cordova-cli.git;a=shortlog;h=refs/tags/3.2.0-0.1.0 >>> d7fde3ffca2feaf55cf064d19e5bfc90df398e71 refs/tags/3.2.0-0.1.0 >>> >>> Voting will go on for 48 hours. >> >>
Re: [Vote] Cordova 2.9.1
+1 -James Jong On Feb 25, 2014, at 9:04 PM, Jesse wrote: > +1 > > @purplecabbage > risingj.com > > > On Tue, Feb 25, 2014 at 2:08 PM, Michal Mocny wrote: > >> As answered elsewhere: >>> gpg --print-md SHA512 *.zip | diff - *.sha && echo "Exact match" >>> gpg --print-md MD5 *.zip | diff - *.md5 && echo "Exact match" >> >> The awkwardness comes from gpg's format (there are threads online >> complaining about this). We should switch coho to just use sha512sum, etc. >> >> +1! >> >> >> On Tue, Feb 25, 2014 at 4:57 PM, RUDD, Brett wrote: >> >>> +1 >>> >>> On Feb 25, 2014, at 13:17, Joe Bowser wrote: >>> >>>> +1 >>>> >>>> On Tue, Feb 25, 2014 at 1:16 PM, Joe Bowser wrote: >>>>> Coho should stop putting spaces. :( >>>>> >>>>> On Tue, Feb 25, 2014 at 1:13 PM, Steven Gill >>> wrote: >>>>>> Coho generates them >>>>>> On Feb 25, 2014 1:02 PM, "Mike Billau" >> wrote: >>>>>> >>>>>>> +1. >>>>>>> Steve, do you generate the SHAs? Just seems like a strange >> format...I >>> had >>>>>>> to remove whitespace to compare. But then again I use some crappy >>> Windows >>>>>>> Explorer extension... >>>>>>> >>>>>>> >>>>>>> On Tue, Feb 25, 2014 at 3:20 PM, Lorin Beer < >> lorin.beer@gmail.com >>>>>>>> wrote: >>>>>>> >>>>>>>> +1 >>>>>>>> >>>>>>>> >>>>>>>> On Tue, Feb 25, 2014 at 12:14 PM, Steven Gill < >>> stevengil...@gmail.com >>>>>>>>> wrote: >>>>>>>> >>>>>>>>> Please review and vote on our past release of Cordova 2.9.1. >>>>>>>>> >>>>>>>>> You can find the src + asc + md5 + sha at the following links: >>>>>>>>> * http://archive.apache.org/dist/cordova/cordova-2.9.1-src.zip >>>>>>>>> * >> http://archive.apache.org/dist/cordova/cordova-2.9.1-src.zip.asc >>>>>>>>> * >> http://archive.apache.org/dist/cordova/cordova-2.9.1-src.zip.md5 >>>>>>>>> * >> http://archive.apache.org/dist/cordova/cordova-2.9.1-src.zip.sha >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>> >> http://git-wip-us.apache.org/repos/asf?p=cordova-android.git;a=shortlog;h=refs/tags/2.9.1 >>>>>>>>> 2a68fd4394f78ad17d05debe34a37296f218df10 refs/tags/2.9.1 >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>> >> http://git-wip-us.apache.org/repos/asf?p=cordova-ios.git;a=shortlog;h=refs/tags/2.9.1 >>>>>>>>> 0f79933977213ed32f75690edfb1edcde679fcbe refs/tags/2.9.1 >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>> >> http://git-wip-us.apache.org/repos/asf?p=cordova-windows.git;a=shortlog;h=refs/tags/2.9.1 >>>>>>>>> 62f3d3025cb5f34bdb7bd8fa07bffce86d263f21 refs/tags/2.9.1 >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>> >> http://git-wip-us.apache.org/repos/asf?p=cordova-wp8.git;a=shortlog;h=refs/tags/2.9.1 >>>>>>>>> 10af4e40ad45889029766fa08aa0614332ea1071 refs/tags/2.9.1 >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>> >> http://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=shortlog;h=refs/tags/2.9.1 >>>>>>>>> 9d8009021083e063a7fd2280aebd3734d8d03843 refs/tags/2.9.1 >>>>>>>>> >>>>>>>>> Blackberry used 2.9.0 tag. >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>> >> http://git-wip-us.apache.org/repos/asf?p=cordova-blackberry.git;a=shortlog;h=refs/tags/2.9.0 >>>>>>>>> b98007cba30c3e4017671e10d7c8f463ddb87855 refs/tags/2.9.0 >>>>>>>>> >>>>>>>>> Voting will go on for 48 hours. >>>>>>>>> >>>>>>>> >>>>>>> >>> >>> >>
Re: [VOTE] Cordova 2.9.0
+1 -James Jong On Feb 26, 2014, at 10:02 AM, Ian Clelland wrote: > -- cordova-docs does not match the released tag. The documentation in the > release is from hash 9d152990701292fe7fb6e1961a3c5ba93b201a62, which is on > the same branch (3 commits behind the current tag) > > -- cordova-osx is also included in this archive. It matches the repository > at https://git-wip-us.apache.org/repos/asf/cordova-osx.git on tag 2.9.0 at > hash 80ee89d018e1f9bf7cc5745f45ab31f1c1435a9d. > > -- cordova-wp7 is also included in this archive. It matches the repository > at https://git-wip-us.apache.org/repos/asf/cordova-wp7.git on tag 2.9.0 at > hash 347b9f4d387d6048a8c515a350e03cd83e9d5bd6. > > > +1 to this release, despite the docs discrepancy (We can move the tag back > if it's important). > > > On Tue, Feb 25, 2014 at 4:55 PM, RUDD, Brett wrote: > >> +1 >> >> On Feb 25, 2014, at 12:08, Steven Gill wrote: >> >>> Please review and vote on our past release of Cordova 2.9.0. >>> >>> You can find the src + asc + md5 + sha at the following links: >>> * http://archive.apache.org/dist/cordova/cordova-2.9.0-src.zip >>> * http://archive.apache.org/dist/cordova/cordova-2.9.0-src.zip.asc >>> * http://archive.apache.org/dist/cordova/cordova-2.9.0-src.zip.md5 >>> * http://archive.apache.org/dist/cordova/cordova-2.9.0-src.zip.sha >>> >>> >> http://git-wip-us.apache.org/repos/asf?p=cordova-android.git;a=shortlog;h=refs/tags/2.9.0 >>> df1536ea77e97b7d362a19582f8beddd168c5ec3 refs/tags/2.9.0 >>> >> http://git-wip-us.apache.org/repos/asf?p=cordova-ios.git;a=shortlog;h=refs/tags/2.9.0 >>> 00e62aad4244ceac1f19193b1e0f2396f1ca41d9 refs/tags/2.9.0 >>> >> http://git-wip-us.apache.org/repos/asf?p=cordova-blackberry.git;a=shortlog;h=refs/tags/2.9.0 >>> b98007cba30c3e4017671e10d7c8f463ddb87855 refs/tags/2.9.0 >>> >> http://git-wip-us.apache.org/repos/asf?p=cordova-windows.git;a=shortlog;h=refs/tags/2.9.0 >>> 47fe25f3ad058515c0a309fbdbdb4ce0960052f4 refs/tags/2.9.0 >>> >> http://git-wip-us.apache.org/repos/asf?p=cordova-wp8.git;a=shortlog;h=refs/tags/2.9.0 >>> 770951b10de09419c8e3a223468e90c85f25adb7 refs/tags/2.9.0 >>> >> http://git-wip-us.apache.org/repos/asf?p=cordova-cli.git;a=shortlog;h=refs/tags/2.9.0 >>> 87db44d7ab3f952ba62501dbb8f47aa6356c8658 refs/tags/2.9.0 >>> >> http://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=shortlog;h=refs/tags/2.9.0 >>> 83dc4bd9010447ea9b93889481516c64a9a46cde refs/tags/2.9.0 >>> >> http://git-wip-us.apache.org/repos/asf?p=cordova-mobile-spec.git;a=shortlog;h=refs/tags/2.9.0 >>> 4cb28c7c511bfd677c5ab4a569ebf34657b4ef6a refs/tags/2.9.0 >>> >> http://git-wip-us.apache.org/repos/asf?p=cordova-app-hello-world.git;a=shortlog;h=refs/tags/2.9.0 >>> 64da512386af1248ca77262053ee8b2c3a99428b refs/tags/2.9.0 >>> >> http://git-wip-us.apache.org/repos/asf?p=cordova-docs.git;a=shortlog;h=refs/tags/2.9.0 >>> a71389b6351a1b237cd1f171f674c8f62a9e0778 refs/tags/2.9.0 >>> >>> Voting will go on for 48 hours. >> >>
Re: [VOTE] Cordova 2.8.1
+1 -James Jong On Feb 26, 2014, at 9:45 AM, Ian Clelland wrote: > A couple of points: > > -- The signature is good, and the hashes match the released zip file. I > can't reconstruct the enclosed zip files exactly from the repositories, but > I can compare their contents. (I can get close, but it seems that either > file dates are enough to throw off the compression, or my zip binary is > just different than the one Steven used at the time.) > > -- cordova-docs does not match the released tag. It appears to have been > build from hash db65dd69cbf4c967c27e0ed1994de90e6e244e25, with the 2.8.0rc1 > docs removed. (I can reproduce it exactly by cherry-picking commit bb95107 > on top of that hash.) If possible, I'd like to create a 2.8.1 tag in the > cordova-docs repo at a commit that matches these docs. > > -- cordova-osx is also included in this archive. It matches tag 2.8.0 at > hash f025cc06165a9aec9d7bccddd9ae03b3fbf8e4ab. Cordova-osx was > unfortunately missing a top-level LICENSE file, but all of the source > artifacts contain the proper license header, and the whole project is > enclosed in a zip file which *does* contain that license in full. > > -- cordova-wp7 is also included in this archive. Coho is no longer capable > of cloning this one. :( However, it matches the repository at > https://git-wip-us.apache.org/repos/asf/cordova-wp7.git on tag 2.8.0 at > hash 8ac37396354ee5764898179dd35f0eed2e82e271 > > > +1 to this release, warts and all. > > > On Tue, Feb 25, 2014 at 10:40 PM, Bryan Higgins wrote: > >> +1 >> >> >> On Tue, Feb 25, 2014 at 4:55 PM, RUDD, Brett wrote: >> >>> +1 >>> >>> On Feb 25, 2014, at 13:21, Steven Gill wrote: >>> >>>> 2.8.0 did. Figured might as well do the point release too >>>> On Feb 25, 2014 1:18 PM, "Joe Bowser" wrote: >>>> >>>>> +1 - This release had a vote, didn't it? >>>>> >>>>> On Tue, Feb 25, 2014 at 12:20 PM, Lorin Beer < >> lorin.beer@gmail.com> >>>>> wrote: >>>>>> +1 >>>>>> >>>>>> >>>>>> On Tue, Feb 25, 2014 at 12:03 PM, Steven Gill < >> stevengil...@gmail.com >>>>>> wrote: >>>>>> >>>>>>> Please review and vote on our past release of Cordova 2.8.1. >>>>>>> >>>>>>> You can find the src + asc + md5 + sha at the following links: >>>>>>> * http://archive.apache.org/dist/cordova/cordova-2.8.1-src.zip >>>>>>> * http://archive.apache.org/dist/cordova/cordova-2.8.1-src.zip.asc >>>>>>> * http://archive.apache.org/dist/cordova/cordova-2.8.1-src.zip.md5 >>>>>>> * http://archive.apache.org/dist/cordova/cordova-2.8.1-src.zip.sha >>>>>>> >>>>>>> The 2.8.1 tag was only applied to Android >>>>>>> >>>>>>> >>>>> >>> >> http://git-wip-us.apache.org/repos/asf?p=cordova-android.git;a=shortlog;h=refs/tags/2.8.1 >>>>>>> d8c755b95a85de95c51768a271aa2747bb5467b9 refs/tags/2.8.1 >>>>>>> >>>>>>> The 2.8.0 tag was used for other platforms >>>>>>> >>>>>>> >>>>> >>> >> http://git-wip-us.apache.org/repos/asf?p=cordova-ios.git;a=shortlog;h=refs/tags/2.8.0 >>>>>>> f93f7a5bad8b7f9d141852c8b1f369a262f0389e refs/tags/2.8.0 >>>>>>> >>>>>>> >>>>> >>> >> http://git-wip-us.apache.org/repos/asf?p=cordova-blackberry.git;a=shortlog;h=refs/tags/2.8.0 >>>>>>> a297ff557b93c30427a113af80620221c8a74f40 refs/tags/2.8.0 >>>>>>> >>>>>>> >>>>> >>> >> http://git-wip-us.apache.org/repos/asf?p=cordova-windows.git;a=shortlog;h=refs/tags/2.8.0 >>>>>>> 326130a182e5cd2d391e942efdf961cc6fa34040 refs/tags/2.8.0 >>>>>>> >>>>>>> >>>>> >>> >> http://git-wip-us.apache.org/repos/asf?p=cordova-wp8.git;a=shortlog;h=refs/tags/2.8.0 >>>>>>> 9176a0238c26ea1fd5edfe2e2b052607aca1b9ac refs/tags/2.8.0 >>>>>>> >>>>>>> >>>>> >>> >> http://git-wip-us.apache.org/repos/asf?p=cordova-cli.git;a=shortlog;h=refs/tags/2.8.0 >>>>>>> a2f158653f533ebbb5dfbfe136bfdf9e1a57f01c refs/tags/2.8.0 >>>>>>> >>>>>>> >>>>> >>> >> http://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=shortlog;h=refs/tags/2.8.0 >>>>>>> 6208c9593a0a472f3e04168c9d237a3121329c1a refs/tags/2.8.0 >>>>>>> >>>>>>> >>>>> >>> >> http://git-wip-us.apache.org/repos/asf?p=cordova-mobile-spec.git;a=shortlog;h=refs/tags/2.8.0 >>>>>>> 4fdfaad8fed1ea52bea5401ee1e1d2099d94f446 refs/tags/2.8.0 >>>>>>> >>>>>>> >>>>> >>> >> http://git-wip-us.apache.org/repos/asf?p=cordova-app-hello-world.git;a=shortlog;h=refs/tags/2.8.0 >>>>>>> 366f9843eb3d2172986d18cf370323ddd35117b8 refs/tags/2.8.0 >>>>>>> >>>>>>> >>>>> >>> >> http://git-wip-us.apache.org/repos/asf?p=cordova-docs.git;a=shortlog;h=refs/tags/2.8.0 >>>>>>> c222b586d286d2dd3a7ba67259d05d5f60e51d8f refs/tags/2.8.0 >>>>>>> >>>>>>> Voting will go on for 48 hours. >>>>>>> >>>>> >>> >>> >>
Re: [Vote] Cordova 3.4.0 release
+1 -James Jong On Feb 18, 2014, at 7:01 PM, Lisa Seacat DeLuca wrote: > +1 > > Lisa Seacat DeLuca > Mobile Engineer | t: +415.787.4589 | ldel...@apache.org | | > ldel...@us.ibm.com | lisaseacat.com | | +1 > > > > > > From:Brian LeRoux > To:"dev@cordova.apache.org" > Date:02/18/2014 06:54 PM > Subject:Re: [Vote] Cordova 3.4.0 release > Sent by:brian.ler...@gmail.com > > > > +1 > > > On Tue, Feb 18, 2014 at 3:45 PM, Joe Bowser wrote: > > > +1 > > > > On Tue, Feb 18, 2014 at 3:26 PM, Steven Gill > > wrote: > > > Please review and vote on the Cordova 3.4.0 release. > > > > > > You can find the sample release at http://people.apache.org/~steven/ > > > > > > Voting will go on for 24 hours. > > > > > > Cheers, > > > > > > -Steve > > >
[ios] 64-bit support
I recently compiled cordova-ios w the core plugins and found 40+ warnings. I’m starting to put that info into JIRA and looking at cleaning up those warnings. If there are others on the list looking at this, let’s coordinate efforts. Thanks. -James Jong
Re: Dropping iOS 5.0 support
Ally, Have you seen this (iOS 5 %) in your other apps as well? Or more so for the new releases? -James Jong On Feb 5, 2014, at 10:32 PM, Ally Ogilvie wrote: > Bump. > > Didn't see a solid statement here but... > > As a developer for the commercial machine we launched a game in Asia Q4 > 2013 and with a now sizeable amount of users: iOS 5.1 is 1% of total users. > > +1 drop support for version < 6.0. > > > > > On Sat, Dec 21, 2013 at 10:02 AM, Shazron wrote: > >> I think that last paragraph is key - let's provide instructions in a doc in >> cordova-ios/guides if they need this support. Not sure we need this in >> cordova-docs >> >> >> On Fri, Dec 20, 2013 at 6:15 AM, Andrew Grieve >> wrote: >> >>> I think we'd be fine to drop "official support" for iOS 5, but as has >> been >>> pointed out, there's very little code-wise that would change. >>> >>> If bug reports come that say "this function is being called and it >> doesn't >>> exist on iOS 5", then that's a trivial fix. Likely devs will just fix it >>> themselves anyways. >>> >>> If devs want to deploy for iOS 5, I think they'll be able to fiddle with >>> their Xcode deployment target settings and do so fairly easily even if we >>> "drop support for it". They are better at testing their own apps anyways. >>> >>> >>> >>> >>> >>> On Fri, Dec 20, 2013 at 7:00 AM, Josh Soref >> wrote: >>> >>>> Fwiw, If you have your installation media, getting 10.8/10.9 to install >>> in >>>> the latest version of VirtualBox is trivial. I believe that the same >>>> applies to 10.7, but I can't find my installation media :(. >>>> - >>>> 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. >>>> >>> >> > > > > -- > <http://www.wizcorp.jp/>Ally Ogilvie > Lead Developer - MobDev. | Wizcorp Inc. <http://www.wizcorp.jp/> > -- > TECH . GAMING . OPEN-SOURCE WIZARDS+ 81 (0)3-4550-1448 | > Website<http://www.wizcorp.jp/> > | Twitter <https://twitter.com/Wizcorp> | > Facebook<http://www.facebook.com/Wizcorp> > | LinkedIn <http://www.linkedin.com/company/wizcorp>
Re: Need to revert a CLI breaking change causing CB-5957
I just installed Win 8.1 with Visual Studio and would like to get a dev device for testing if possible. -James Jong On Feb 5, 2014, at 6:53 PM, Olivier Bloch (MS OPEN TECH) wrote: > I'd be more than happy to provision some WP8 dev devices. > Please let me know who would need one (I am not sure how many I can get but > will do my best) and didn't already get one at last phonegap day 😊 > Note that having actual devices for testing do not prevent from having to > install Visual Studio and the WP SDK. Also you can make the emulator work > within a VM. > I am working with Mike Sierra on getting the WP and Windows platforms doc > updated with instructions on how to get this to work. > > Olivier > > Sent from Windows Mail > > From: Tommy-Carlos Williams<mailto:to...@devgeeks.org> > Sent: Wednesday, February 5, 2014 2:16 PM > To: dev@cordova.apache.org<mailto:dev@cordova.apache.org> > > Andrew, > > Didn’t you get a phone at PhoneGap Day? > > Were you too much of a “presenter” at the workshop to get one? ;) > > If I ever get around to getting set up for WP8 I will try and help test… will > probably happen after I finish our Blackberry10 port. > > - tommy > > On 6 Feb 2014, at 9:00 am, Andrew Grieve wrote: > >> Just to be clear - it's not enough to test on windows, this breaks only for >> windows phone / win8 I think. >> >> That said, I've recently got set up with VMs and modern.ie. Is that enough >> to test out Hello World on a WP emulator? >> >> >> On Wed, Feb 5, 2014 at 4:03 PM, Michal Mocny wrote: >> >>> First off, Jesse I appreciate your respectable tone here, thank you. >>> >>> I agree, this is a sign that we generally don't test nearly enough on >>> windows, and should fix that. As someone who also reviewed the work Mark >>> was doing here, sorry this wasn't caught. >>> >>> I'll just add that I think the tests should have been run before the >>> *tooling release* (and even better, on a regular basis with CI as stated), >>> not necessarily before every patch to tip of tree lands. The majority of >>> changes do not affect specific platforms in subtle ways -- and while we >>> should absolutely have process to catch those that do -- any process that >>> involves manually testing in multiple configurations for every single patch >>> is prohibitive and I think unrealistic. >>> >>> That change was committed a month ago -- how did we not catch it before >>> release? >>> >>> To decrease the odds of this happening again, perhaps we need to amend the >>> steps for tooling release ( >>> http://wiki.apache.org/cordova/StepsForToolsRelease) to ensure testing on >>> all the platforms? >>> >>> -Michal >>> >>> >>> On Wed, Feb 5, 2014 at 2:34 PM, Jesse wrote: >>> >>>> I would think it would be enough to just make sure that : >>>> 1. our tests catch the issue >>>> 2. the tests are run on windows/mac/linux before an npm publish >>>> >>>> I agree Mark, the change is valuable, and I don't mean to single you >>> out. I >>>> am just concerned about how it made it to npm while obviously broken on >>>> windows devices. >>>> >>>> @purplecabbage >>>> risingj.com >>>> >>>> >>>> On Wed, Feb 5, 2014 at 11:22 AM, Mark Koudritsky >>>> wrote: >>>> >>>>> Some CI for plugman and CLI on Windows would be extremely useful. I >>> just >>>>> looked briefly at Travis-CI< >>>>> http://docs.travis-ci.com/user/getting-started/>, >>>>> but they only have Linux and OS >>>>> X<http://docs.travis-ci.com/user/osx-ci-environment/>. >>>>> Here is a random Windows based service I just found >>>>> http://www.appveyor.com/, >>>>> didn't check if it's usable for our case. Of course, this solution >>> would >>>>> only be for the host side tools, not for on-device tests which are the >>>> most >>>>> important ones. >>>>> >>>>> That commit was part of this review >>>>> <https://reviews.apache.org/r/15775/> dealing >>>>> with CB-4153 <https://issues.apache.org/jira/browse/CB-4153>. But >>> since >>>>> the >>>>> patch (probably prepared with git format-patch) contained two separate &g
Re: plugins.cordova.io: UX redesign
UX looks great!! Thanks for the efforts! 2. For search, perhaps the ability to add/remove filters? +1 to making it responsive -James Jong On Dec 11, 2013, at 10:26 PM, Joni Rustulka wrote: > Hi all, > > I'm Joni. I work at Adobe as a UX designer on the PhoneGap team, and I have > recently thrown some time at redesigning the http://plugins.cordova.io site. > I'm looking for feedback prior to implementation - your thoughts are > appreciated. > > The main screens that have been reworked are as follows: > > > 1. Home (http://cl.ly/image/2n3l1N0Z0g0w) > The primary goal for the site is to help users find the plugins they need. As > such, the main focus is on search/findability. > > 2. Search Results (http://cl.ly/image/0c3X3T1E1L0j) > Upon search for a plugin, the user is returned results. The user can filter > to include only desired platforms (http://cl.ly/image/3W2f321I211r), and the > results table can be sorted by number of downloads, or plugin ID. > > 3. Plugin Details (http://cl.ly/image/2n1p2s3E0a2t) > The details screen intends to provide all of the necessary information on a > plugin. > ** From what I understand, one piece of information that may be missing from > this screen is "Installation Instructions". This being, config.xml feature > tags. Is this something that you guys plan to automate, or should we be > telling plugin authors to put this information in their Read Me? Please > advise. > > Further, we do intend to make this a responsive site - so it will be easily > viewed on smaller screen sizes. > > Thanks for your input, > -joni > > > PS - big thanks and kudos to Yohei for putting together the pluggy robot! > >
Re: 3.3.0 Release
+1 FYI, I have been testing Cordova with iOS 7.1 beta. No new issues with it. -James Jong On Dec 10, 2013, at 1:40 PM, Joe Bowser wrote: > SGTM! > > On Tue, Dec 10, 2013 at 10:37 AM, Steven Gill wrote: >> Lets start the final round of tagging today! >> https://issues.apache.org/jira/browse/CB-5538
Re: JAVA_HOME
Don was asking for it to be in the 3.2.x stream. The fix is pretty small so it should be doable for the next point release. -James Jong On Dec 6, 2013, at 10:05 AM, Carlos Santana wrote: > The fix is located in cordova-android repo and was landed after last > release 3.2.0, it was picked up by 3.3.x branch, like Steve already > mentioned is going to be in 3.3.0 next week. > > https://github.com/apache/cordova-android/commit/2f66ec60db8749bc442095560d5713b7bb718527 > > This is not a fix on Cordova CLI, the fix in platform android 3.3.0 > > hope this clarifies > > > > > > On Fri, Dec 6, 2013 at 9:40 AM, Michal Mocny wrote: > >> Or maybe we didn't do a point release for android.. >> >> >> On Fri, Dec 6, 2013 at 9:36 AM, Michal Mocny wrote: >> >>> I think I marked that fix version, and it was before we did an android >>> 3.2.x point release. I was under the impression that the fix did already >>> make it out in that point release and so we can update JIRA, but I guess >> I >>> should make sure first. >>> >>> Are you saying that the fix isn't in the latest point release, or just >>> pointing out the JIRA metadata is wrong? >>> >>> >>> On Fri, Dec 6, 2013 at 1:03 AM, Joe Bowser wrote: >>> >>>> I blame Maven. Maven requires JAVA_HOME. (Yes, I had maven installed. >> I'm >>>> not proud of that.) >>>> On Dec 5, 2013 9:36 PM, "Steven Gill" wrote: >>>> >>>>> It is a bug with Cordova android. We could have tried to do a 3.2.1 >> for >>>>> android but instead are focusing on getting 3.3.0 out next week. >>>>> >>>>> On Thursday, December 5, 2013, Don Coleman wrote: >>>>> >>>>>> I was hoping this fix was going to make 3.2.0-0.4.0 but it looks >> like >>>>> it's >>>>>> marked as 3.3 in JIRA. Would it be difficult to get this fix >>>>>> into 3.2.0-0.5.0? >>>>>> >>>>>> https://issues.apache.org/jira/browse/CB-5422 >>>>>> >>>>>> >>>>>> On Tue, Dec 3, 2013 at 12:08 PM, Marcel Kinard >>>> > >>>>>> wrote: >>>>>> >>>>>>> Yeah. It's really cool what works in Cordova, but it's also >>>> embarrasing >>>>>>> what gets broken. Running real end-to-end (in the generic sense) >>>> tests >>>>>> like >>>>>>> a real consumer in a real app-dev workflow should help us catch >> the >>>> bad >>>>>>> parts. I don't think we are exercising end-to-end without >> automated >>>> CI. >>>>>>> >>>>>>> On Dec 3, 2013, at 1:36 AM, Brian LeRoux > > >>>>>> wrote: >>>>>>> >>>>>>>> This is really a symptom of how badly we need to get CI running >>>>> again. >>>>>>> The >>>>>>>> hello world workflow being broken is completely unacceptable. >>>>>>> >>>>>> >>>>> >>>> >>> >>> >> > > > > -- > Carlos Santana >
Re: iOS webview size
Are you targeting prior to iOS 5? -James Jong On Dec 6, 2013, at 9:49 AM, Maxime LUCE wrote: > By default, Cordova ios project targets iOS 5+, could it be blocking ?? > > > Cordialement. > > > Maxime LUCE > > > max...@touchit.fr > 06 28 60 72 34 > http://touchit.fr > > > -Original Message- > From: mmo...@google.com [mailto:mmo...@google.com] On Behalf Of Michal Mocny > Sent: vendredi 6 décembre 2013 15:45 > To: dev > Subject: Re: iOS webview size > > 320 sounds like the width of the first three generations of iphone (though > the height is not 240 but 480). Perhaps you are emulating an older device? > > > On Fri, Dec 6, 2013 at 9:28 AM, Maxime LUCE wrote: > >> Frame is fullscreen but frame content is sized >> >> >> Cordialement. >> >> >> Maxime LUCE >> >> >> max...@touchit.fr >> 06 28 60 72 34 >> http://touchit.fr >> >> >> -Original Message- >> From: James Jong [mailto:wjamesj...@gmail.com] >> Sent: vendredi 6 décembre 2013 14:47 >> To: dev@cordova.apache.org >> Subject: Re: iOS webview size >> >> Sounds like you have some customization in obj-c or the nib files. >> The frame should be fullscreen by default. >> -James Jong >> >> On Dec 6, 2013, at 8:25 AM, Maxime LUCE wrote: >> >>> Hi, >>> >>> I will try to explain the issue more precisely. >>> When I launch my app using XCode in the iOS emulator, I can see that >>> my >> app is resized in a 320x240 frame. This behavior force iOS to resize >> every DOM elements to adjust to an arbitrary 320x240. >>> >>> I checked the behavior by putting a "alert(document.width) on start up". >>> >>> Someone could help me override this behavior ? I'm not an iOS nor >> objective C expert. >>> >>> >>> Cordialement. >>> >>> Maxime LUCE >>> max...@touchit.fr >>> 06 28 60 72 34 >>> http://touchit.fr >>> >>> >>> Not sure what you mean. >>> >>> Are you saying you can only have a canvas with a max size of >>> 320x240? I >> have an app with a larger canvas than that. >>> >>> If that is what you are saying, be sure you are not trying to set >>> the >> canvas size just using CSS. >>> >>> For an example maybe have a look at my canvas demo: >>> >>> https://github.com/devgeeks/Canvas2ImageDemo >>> On 06/12/2013 12:06 pm, "Maxime LUCE" wrote: >>> >>>> Hi everyone, >>>> >>>> It appears that on iOS, webview is restricted to a 320x240 canvas. >>>> >>>> Is it possible to automatically set canvas size using device >>>> screen's >> one ? >>>> >>>> Why is it not the default scenario ? >>>> >>>> Cordialement. >>>> --- >>>> Maxime LUCE - Somatic >>>> maxime.l...@somatic.fr >>>> 06 28 60 72 34 >>>> >> >>
Re: iOS webview size
Sounds like you have some customization in obj-c or the nib files. The frame should be fullscreen by default. -James Jong On Dec 6, 2013, at 8:25 AM, Maxime LUCE wrote: > Hi, > > I will try to explain the issue more precisely. > When I launch my app using XCode in the iOS emulator, I can see that my app > is resized in a 320x240 frame. This behavior force iOS to resize every DOM > elements to adjust to an arbitrary 320x240. > > I checked the behavior by putting a "alert(document.width) on start up". > > Someone could help me override this behavior ? I'm not an iOS nor objective C > expert. > > > Cordialement. > > Maxime LUCE > max...@touchit.fr > 06 28 60 72 34 > http://touchit.fr > > > Not sure what you mean. > > Are you saying you can only have a canvas with a max size of 320x240? I have > an app with a larger canvas than that. > > If that is what you are saying, be sure you are not trying to set the canvas > size just using CSS. > > For an example maybe have a look at my canvas demo: > > https://github.com/devgeeks/Canvas2ImageDemo > On 06/12/2013 12:06 pm, "Maxime LUCE" wrote: > >> Hi everyone, >> >> It appears that on iOS, webview is restricted to a 320x240 canvas. >> >> Is it possible to automatically set canvas size using device screen's one ? >> >> Why is it not the default scenario ? >> >> Cordialement. >> --- >> Maxime LUCE - Somatic >> maxime.l...@somatic.fr >> 06 28 60 72 34 >>
Re: Camera targetWidth & targetHeight
For targetWidth = 2048 , targetHeight=768, does it make sense to have the result picture with width=768,height=1024? That seems odd to me. -James Jong On Dec 3, 2013, at 7:34 AM, John M. Wargo wrote: > It occurred to me this morning that I didn't test a scenario where an > application deliberately didn't maintain an appropriate aspect ratio with > targetWidth & targetHeight. > > I added a button to my app that set targetWidth to 2048 and targetHeight to > 768. > > On Android I got the following: > > Portrait: 768x1024 > Landscape: 1024x768 > > On iOS I got the following: > > Portrait: 576x768 > Landscape: 1024x768 > > Not what I expected. So apparently the API grabs the smaller property and > applies a set aspect ratio to the resulting photo rather than try to do > something weird. Notice again that on iOS the API applies the restriction > weirdly in portrait. > > On 12/2/2013 10:18 PM, Simon MacDonald wrote: >> IIRC on Android if you only specify the width or height it will determine >> what the other value should be by using the same aspect ration as the >> original image. >> >> >> Simon Mac Donald >> http://hi.im/simonmacdonald >> >> >> On Mon, Dec 2, 2013 at 10:15 PM, John M. Wargo wrote: >> >>> A while back I posted a question regarding Camera targetWidth & >>> targetHeight properties and how they worked. After some discussion, the >>> conclusion I reached was that the documentation couldn't be correct about >>> how it worked since there was no way to determine the camera's resolution >>> with the current API but the docs said I had to provide both parameters. I >>> said I'd do some testing and I have finally gotten around to completing it. >>> Here's what I discovered: >>> >>> I created an application that allowed me to pass in different values for >>> targetWidth & targetHeight when taking a picture. I tested at the following >>> image sizes: 640x480, 800x600, 1024x768 as well as setting only the >>> targetWidth to 1024 or only the targetHeight to 768. >>> >>> Here's the results: >>> >>> Android >>> PortraitLandscape >>> 480x640 640x480 >>> 600x800 800x600 >>> 768x10241024x768 >>> 768x10241024x768 >>> 768x10241024x768 >>> >>> >>> >>> iOS >>> PortraitLandscape >>> 360x480 640x480 >>> 450x600 800x600 >>> 576x768 1024x768 >>> 2448x3264 3264x2448 >>> 2448x3264 3264x2448 >>> >>> >>> >>> Windows Phone 8 >>> PortraitLandscape >>> 1836x3264 3264x1836 >>> 1836x3264 3264x1836 >>> 1836x3264 3264x1836 >>> 1836x3264 3264x1836 >>> 1836x3264 3264x1836 >>> >>> >>> As you can see, Android properly implements the targetWidth & targetHeight >>> properties. On iOS, it supports setting both properties, but not instances >>> where only one is specified. Windows Phone 8 ignores the parameters >>> completely. On iOS, when you turn the device on its side, the Camera API >>> applies the target width or height to the wrong axis (Android does this >>> well however). >>> >>> I'm trying to test this on a BlackBerry device, but my development >>> environment is giving me fits right now. I'll work on it in the morning and >>> publish my results when I get them. >>> >>> I would suggest that the android implementation is as expected and that >>> the other platforms need their implementations of targetWidth & >>> targetHeight adjusted so it works correctly. The documentation should be >>> updated as well as it's incorrect today specifying that both properties >>> must be provided. >>> >>> If the group doesn't want to support only providing one of the properties, >>> then I would expect that the onError callback is called when only one is >>> provided rather than simply ignoring them as is the case with iOS and >>> Windows Phone. >>> >>> I posted my sample application and a spreadsheet with my results to >>> https://github.com/johnwargo/camera_res_test >>> >>> -- >>> John M. Wargo >>> @johnwargo <http://twitter.com/johnwargo> >>> www.johnwargo.com <http://www.johnwargo.com> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> -- >>> >
Re: Introductory Email
nice work Josh! and a belated welcome :-) -James Jong On Dec 2, 2013, at 11:11 AM, Josh Soref wrote: > Hello, > > As people have probably noticed, I’m one of the BlackBerry developers working > on Cordova / cordova-blackberry as part of the WebWorks team. We just > released our WebWorks 2.0 Beta [1] last week. > > Before joining BlackBerry, I worked on the Mozilla project. > > Additionally, I’ve been involved with the W3C including the WebApps and DAP > Working Groups. > - WebApps created the Widgets-Packaging W3 Recommendation around which > config.xml is based. > - DAP is the group who wrote a Contacts API – which was never published as a > W3 Recommendation – which Cordova adopted. > > I also have experience w/ Windows, so there will be (and in fact are) pull > requests from me to improve the state of Cordova there as well. > > (Yes, I know it’s kind of late for me to send an introductory email. But we > figured it made more sense for me to start contributing and send something > like this later.) > > [1] > http://devblog.blackberry.com/2013/11/blackberry-webworks-sdk-2-0-beta-released-with-lots-of-apache-cordova-goodness/ > - > 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: [Camera Plugin] Add support to save unmodified image to photoalbum
IMO the behavior should be:
If I'm editing an image I expect the edited image to be saved.
If I don't edit it, I expect the unedited image to be saved.
-James Jong
On Nov 28, 2013, at 4:50 PM, Stephan Wezel wrote:
> I don't say that this feature should be only for iOS.
> I need this feature for my project which isn't iOS only. But iOS is the first
> target.
> I came up with this solution because i didn't knew it better.
>
> I'm also fine if we would redefine what the result is when the option
> saveToPhotoAlbum is active to mean that the original image is saved instead
> the image which is returned to the caller.
>
> - Stephan Wezel
>
> On Thursday 28 November 2013 13:05:32 James Jong wrote:
>> One consideration here is cross-platform consistency. Camera is an area
>> where we've had issues with platforms having different behaviors for the
>> same option. Currently, you can save the original image with the following
>> camera options:
>> { allowEdit : false,
>> correctOrientation : false,
>> saveToPhotoAlbum : true
>> }
>>
>> I'm also not sold that adding another save-to-photoalbum option
>> (saveUnmodifiedImageToPhotAlbum) is the best way. May be a bit confusing.
>> If we do add it, the behavior of the 2 options need to be documented
>> clearly. Perhaps it would be better to document the above options as the
>> way to get the unmodified image?
>>
>> -James Jong
>>
>> On Nov 28, 2013, at 11:18 AM, Stephan Wezel wrote:
>>
>>> Hi Andrew,
>>>
>>>> Have you signed the Apache CLA? http://www.apache.org/licenses/#clas You'll
>>>> need to do so before we can accept code from you.
>>> No not yet.
>>>
>>>> Could you clarify your intent with the new flag for me? Is it:
>>>> 1. To ensure the image isn't resized at all, or:
>>>> 2. To save the unmodified image to the camera roll, but then return a
>>>> resized image to the app.
>>>>
>>>> If it's #2, then I think that would be reasonable default behaviour
>>>> when saveToPhotoAlbum is set. WDYT?
>>> For me it is #2. First i thought that the option saveToPhotoAlbum would
>>> save the original image from the camera without any changes to it (scale,
>>> rotate).
>>> Because the description of this option doesn't say anything that the image,
>>> is saved to the photoalbum after a modification (if
>>> targetWidth/targetHeight, correctOrientation or quality is changed from its
>>> default value )
>>>
>>> But the current implementation (at least under iOS and Android) save the
>>> photo to the photoalbum after the image is scaled/rotated.
>>>
>>> So i came up with this patch vor iOS and created a jira entry
>>> (https://issues.apache.org/jira/browse/CB-5479)
>>>
>>> I also think that saving the original image would be a reasonable default
>>> behaviour.
>>>
>>> On Thursday 28 November 2013 10:47:24 Andrew Grieve wrote:
>>>> Thanks Stephan.
>>>>
>>>> Have you signed the Apache CLA? http://www.apache.org/licenses/#clas You'll
>>>> need to do so before we can accept code from you.
>>>>
>>>> Could you clarify your intent with the new flag for me? Is it:
>>>> 1. To ensure the image isn't resized at all, or:
>>>> 2. To save the unmodified image to the camera roll, but then return a
>>>> resized image to the app.
>>>>
>>>> If it's #2, then I think that would be reasonable default behaviour
>>>> when saveToPhotoAlbum is set. WDYT?
>>>>
>>>>
>>>> On Thu, Nov 28, 2013 at 4:36 AM, Stephan Wezel wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> for a project which I'm developing with cordova i need the possibility
>>>>> to save the unmodified image from the camera to the photoalbum.
>>>>>
>>>>> I have attached a patch which implements this new functionality for iOS.
>>>>>
>>>>> Regards
>>>>>
>>>>> Stephan Wezel
>>>>>
>>>
>>
>
Re: iOS Camera asking for Location
+1 to make it an option. -James Jong On Nov 29, 2013, at 3:43 PM, Andrew Grieve wrote: > Yep, makes sense. > > > > On Fri, Nov 29, 2013 at 3:23 PM, Tommy-Carlos Williams > wrote: > >> IIRC, Camera used to NOT keep the location and other data, then that was >> raised as an issue and it was added in… and now it’s being ripped out again? >> >> I agree with it being optional, but ripping it out again, not so much. >> >> +1 for >> https://issues.apache.org/jira/browse/CB-4003?focusedCommentId=13694956&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13694956 >> >> >> >> On 30 Nov 2013, at 6:43 am, Michal Mocny wrote: >> >>> Ah, thats a good point (us canadians do forget!), we will make sure to >>> factor that into silent consensus! (Land all the patches now, boys!) >>> >>> >>> On Fri, Nov 29, 2013 at 2:13 PM, Shazron wrote: >>> >>>> I believe Lorin is working on it being a preference, with it turned off >> by >>>> default. https://issues.apache.org/jira/browse/CB-4003 >>>> >>>> Also FYI Adobe US ppl are away for the turkey long weekend, so responses >>>> might be late >>>> >>>> >>>> On Fri, Nov 29, 2013 at 11:04 AM, Michal Mocny >>>> wrote: >>>> >>>>> I agree, rip it out. I'd love to see a plugin for editing EXIF data >>>> using >>>>> this code as a starting point perhaps, but I can't see how what we have >>>> now >>>>> is a good default. >>>>> >>>>> -Michal >>>>> >>>>> >>>>> On Fri, Nov 29, 2013 at 1:25 PM, Andrew Grieve >>>>> wrote: >>>>> >>>>>> On iOS, the Camera API has an undocumented feature where it injects >>>> your >>>>>> location into a photo's exif data. >>>>>> >>>>>> Although neat, I think this isn't desired in most cases and it causes >> a >>>>>> location permission dialog to appear. >>>>>> >>>>>> I'd like to delete this location logic. Any objections? >>>>>> >>>>> >>>> >> >>
Re: [Camera Plugin] Add support to save unmodified image to photoalbum
One consideration here is cross-platform consistency. Camera is an area where
we've had issues with platforms having different behaviors for the same option.
Currently, you can save the original image with the following camera options:
{ allowEdit : false,
correctOrientation : false,
saveToPhotoAlbum : true
}
I'm also not sold that adding another save-to-photoalbum option
(saveUnmodifiedImageToPhotAlbum) is the best way. May be a bit confusing. If
we do add it, the behavior of the 2 options need to be documented clearly.
Perhaps it would be better to document the above options as the way to get the
unmodified image?
-James Jong
On Nov 28, 2013, at 11:18 AM, Stephan Wezel wrote:
> Hi Andrew,
>
>> Have you signed the Apache CLA? http://www.apache.org/licenses/#clas You'll
>> need to do so before we can accept code from you.
> No not yet.
>
>> Could you clarify your intent with the new flag for me? Is it:
>> 1. To ensure the image isn't resized at all, or:
>> 2. To save the unmodified image to the camera roll, but then return a
>> resized image to the app.
>>
>> If it's #2, then I think that would be reasonable default behaviour
>> when saveToPhotoAlbum is set. WDYT?
> For me it is #2. First i thought that the option saveToPhotoAlbum would save
> the original image from the camera without any changes to it (scale, rotate).
> Because the description of this option doesn't say anything that the image,
> is saved to the photoalbum after a modification (if targetWidth/targetHeight,
> correctOrientation or quality is changed from its default value )
>
> But the current implementation (at least under iOS and Android) save the
> photo to the photoalbum after the image is scaled/rotated.
>
> So i came up with this patch vor iOS and created a jira entry
> (https://issues.apache.org/jira/browse/CB-5479)
>
> I also think that saving the original image would be a reasonable default
> behaviour.
>
> On Thursday 28 November 2013 10:47:24 Andrew Grieve wrote:
>> Thanks Stephan.
>>
>> Have you signed the Apache CLA? http://www.apache.org/licenses/#clas You'll
>> need to do so before we can accept code from you.
>>
>> Could you clarify your intent with the new flag for me? Is it:
>> 1. To ensure the image isn't resized at all, or:
>> 2. To save the unmodified image to the camera roll, but then return a
>> resized image to the app.
>>
>> If it's #2, then I think that would be reasonable default behaviour
>> when saveToPhotoAlbum is set. WDYT?
>>
>>
>> On Thu, Nov 28, 2013 at 4:36 AM, Stephan Wezel wrote:
>>
>>> Hi,
>>>
>>> for a project which I'm developing with cordova i need the possibility
>>> to save the unmodified image from the camera to the photoalbum.
>>>
>>> I have attached a patch which implements this new functionality for iOS.
>>>
>>> Regards
>>>
>>> Stephan Wezel
>>>
>
Re: plugins.cordova.io
+1 -James Jong On Nov 26, 2013, at 5:29 PM, Steven Gill wrote: > yeah I don't see why not. The core plugins all already have them, they are > just not exposed yet. I will see if I can get some of these showing before > US thanksgiving > > > On Tue, Nov 26, 2013 at 2:10 PM, Michal Mocny wrote: > >> In the meantime, could we publish the tags we expect to expose, so plugin >> releases can start including them? >> >> -micahl >> >> >> On Tue, Nov 26, 2013 at 2:06 PM, Steven Gill >> wrote: >> >>> Joni will be sharing some mockups soon of how the new site for some >>> feedback. I will begin implementing it shortly after. >>> >>> >>> On Tue, Nov 26, 2013 at 2:02 PM, Jesse wrote: >>> >>>> not just a zip, a .tgz which baffles most windows users... >>>> Every time I have clicked that link, I was expecting to see some more >>> info, >>>> not to download a file ... >>>> >>>> >>>> >>>> @purplecabbage >>>> risingj.com >>>> >>>> >>>> On Tue, Nov 26, 2013 at 1:56 PM, Tommy-Carlos Williams >>>> wrote: >>>> >>>>> +1 >>>>> >>>>> Seems crazy to only be able to download a zip... >>>>> >>>>> >>>>> On 27 Nov 2013, at 8:45 am, Jesse wrote: >>>>> >>>>>> yes, all relevant info from the plugin.xml should/will be surfaced. >>>>>> author, description, issue-tracker, license, repo >>>>>> platforms supported should also be linkable so you can see all >>> plugins >>>>>> supporting a platform, as well as what platforms each supports. >>>>>> >>>>>> @purplecabbage >>>>>> risingj.com >>>>>> >>>>>> >>>>>> On Tue, Nov 26, 2013 at 1:31 PM, Ken Wallis < >> kwal...@blackberry.com> >>>>> wrote: >>>>>> >>>>>>> Hey there. Just wondering if there are any more thoughts of >> exposing >>>> on >>>>>>> the web page what platforms a particular plugin supports? Would >> make >>>>>>> discovery much friendlier. >>>>>>> >>>>>>> Thanks! >>>>>>> >>>>>>> -- >>>>>>> Ken Wallis >>>>>>> Senior Product Manager - WebWorks >>>>>>> BlackBerry >>>>>>> 650-620-2404 >>>>>>> >>> - >>>>>>> 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: Intro email
Welcome Kyle! -James Jong On Nov 27, 2013, at 10:41 AM, Kyle Nitzsche wrote: > Hi, > > I am Kyle Nitzsche, and I work for Canonical on Ubuntu. > > I will be providing the docs for the Ubuntu platform support recently > submitted. > > Cheers, > Kyle
Re: plugin documentation: param onload
Yes. Please file a JIRA issue. Sounds like it will be a great help to others who hit this. -James Jong On Nov 15, 2013, at 3:16 PM, Shazron wrote: > Hi Axel, > File the issue and just copy in your email :) Someone will get to it > eventually. Perhaps you could send a pull-request as well. > > > > On Thu, Nov 14, 2013 at 6:20 AM, wrote: > >> Hi, >> >> I think this issue >> https://issues.apache.org/jira/browse/CB-4293?jql=text%20~%20%22onload%22 >> documents "onload" on IOS. >> >> I think that this is not a platform specific issue and "onload" should be >> documented in the platform independent documentation: >> >> https://cordova.apache.org/docs/en/3.0.0/plugin_ref_spec.md.html#Plugin%20Specification >> >> Should I create an issue? Who would take that? >> >> best regards >> Axel >> >> Ps: it took me hours to discover why my plugin's "onNewIntent" method was >> not called. It is only called if the >> >> My CordovaActivity is started from another activity in the same >> application and I catch the extras in onNewIntent. >>
Re: input type=file broken on Android 4.4
Ugh… hopefully there's a better solution. -James Jong On Nov 14, 2013, at 2:10 PM, Brian LeRoux wrote: > Ugly indeed but that is what we do! =) > > Probably just a docs issue doing what you describe. > > > On Thu, Nov 14, 2013 at 10:57 AM, Andrew Grieve wrote: > >> I'll ask around and see if anyone has ideas on fixing it. >> >> We could probably polyfill it though, by having a click handler on the body >> looking for clicks on , and then hijacking the onsubmit() >> of the form. Ugly. >> >> >> On Thu, Nov 14, 2013 at 12:09 PM, Brian LeRoux wrote: >> >>> I think it is reasonable that we choose to allow a polyfill for this >>> regardless of the Google stance. The change is very likely to break >>> existing users and just b/c it was 'private' doesn't mean that it wasn't >>> exposed. Maybe this is just a docs issue given we have the scaffolding to >>> fix this with File/FileTransfer. >>> >>> ?? >>> >>> >>> On Thu, Nov 14, 2013 at 8:39 AM, Joe Bowser wrote: >>> >>>> Apologize and say "Sorry, the Android team hates Cordova"? >>>> >>>> Honestly, was this a private API that was in the Android Browser code? >>>> If so, then we should assume that this would break, since this wasn't >>>> referenced in the Android APIs. This is outside our scope, and we >>>> really can't do anything more with this without even more breakage. >>>> >>>> On Thu, Nov 14, 2013 at 8:26 AM, Mike Billau >>>> wrote: >>>>> Hi everyone, >>>>> >>>>> This ticket[1] came in pretty recently talking about how input >>> type=file >>>>> does not work with Android 4.4 anymore, regardless of what your >> target >>>> SDK >>>>> is. >>>>> >>>>> Apparently this was a conscious design decision by Android [2]. >>>>> >>>>> Does anybody have ideas on how we can fix this? Is this even in our >>>> scope? >>>>> From what I can gather, we have always had to override certain >> 'hidden' >>>>> (yet public) methods on CordovaChromeClient [3] to enable input >>>> type=file. >>>>> I'm thinking that either Android made this a private method or they >>> just >>>>> changed the method signature again. If they just changed the method >>>>> signature, hopefully the new one will surface pretty soon and we can >>>> adjust >>>>> CordovaChromeClient (I tried looking around in Android source but got >>>>> pretty lost pretty quick...) >>>>> >>>>> Just wanted to get some more opinions on what we should do. This >> seems >>>> like >>>>> it could be a pretty breaking change for some of our users. >>>>> >>>>> >>>>> [1] https://issues.apache.org/jira/browse/CB-5294 >>>>> [2] http://code.google.com/p/android/issues/detail?id=62220 >>>>> [3] >>>>> >>>> >>> >> https://github.com/apache/cordova-android/blob/master/framework/src/org/apache/cordova/CordovaChromeClient.java#L367 >>>> >>> >>
Re: Andrew Going on Vacation
Enjoy Andrew! -James Jong On Nov 15, 2013, at 1:42 PM, Andrew Grieve wrote: > I was out last week for Full Frontal (talk slides if anyone's curious: > http://goo.gl/gtDkku) > > Starting tomorrow, I'll be on vacation until a week Tuesday (coming back > Nov 27). Going to New Orleans to soak up some warmth! :)
Re: CI failures - CLI & WP8
Could we do anything w sauce labs? I hear we may have a contact there... ;-) -James Jong On Nov 8, 2013, at 9:36 AM, Carlos Santana wrote: > My main dev system is Mac, but I run Windows 8 on a Virtual Machine (VM). > > The Windows Phone Emulator can be also run inside a VM [1] using VMware > Fusion or Parallels [2]. > > With recent problems with Cordova CLI, I will be setting up more VMs > (Windows 8.1, Windows 7) and VS 2013 for testing. > > Can we get a Windows VM from Apache to run some CI testing for CLIs? this > will allows to know faster when a commit breaks on windows. > > > > [1]: > http://developer.nokia.com/Community/Wiki/Windows_Phone_8_SDK_on_a_Virtual_Machine_with_Working_Emulator > [2]: http://kb.parallels.com/en/115211 > > > > On Thu, Nov 7, 2013 at 7:24 PM, Steven Gill wrote: > >> +1 >> >> We need to focus more on making sure tests pass on windows and mac as we >> make changes. >> >> >> On Thu, Nov 7, 2013 at 4:22 PM, Jesse wrote: >> >>> tests should be passing now. This is related to the fact that wp7/8 and >>> windows8 don't consider repo root to be platform root. >>> >>> It may make sense to to add another field to the platform objects to >>> specify this, but I simply modified the tests to allow for it. >>> >>> Incidentally, these tests would be much more useful if they worked on >>> windows. I unfortunately cannot manage wp7+wp8+windows8 and keep the >>> cli+tests up to date. Things are getting better with Sergey active and >> some >>> support from Steve, Tim and Carlos, but generally I think we should all >> be >>> able to jump onto a windows box and test/fix some stuff. As apache >>> contributors, everyone has an msdn subscription already. >>> >>> >>> >>> >>> @purplecabbage >>> risingj.com >>> >>> >>> On Thu, Nov 7, 2013 at 7:46 AM, David Kemp wrote: >>> >>>> last error output from npm test of CLI: >>>> >>>> >>>> Failures: >>>> >>>> 1) platform command success `add` should shell out to specified >>>> platform's bin/create, using the version that is specified in >>>> platforms manifest >>>> Message: >>>> [31mExpected '"lib/wp/cordova/3.1.0/wp8/wp8/bin/create" >>>> "some/path/platforms/wp8" "ca.filmaj.id" "magical mystery tour"' to >>>> match /lib.wp.cordova.\d.\d.\d[\d\w\-]*.wp8.bin.create/gi. [0m >>>> Stacktrace: >>>> Error: Expected '"lib/wp/cordova/3.1.0/wp8/wp8/bin/create" >>>> "some/path/platforms/wp8" "ca.filmaj.id" "magical mystery tour"' to >>>> match /lib.wp.cordova.\d.\d.\d[\d\w\-]*.wp8.bin.create/gi. >>>>at new jasmine.ExpectationResult >>>> >>>> >>> >> (/Users/drkemp/buildbot/slave_common/Tools_CLI/build/cordova-cli/node_modules/jasmine-node/lib/jasmine-node/jasmine-1.3.1.js:114:32) >>>>at null.toMatch >>>> >>>> >>> >> (/Users/drkemp/buildbot/slave_common/Tools_CLI/build/cordova-cli/node_modules/jasmine-node/lib/jasmine-node/jasmine-1.3.1.js:1235:29) >>>>at >>>> >>> >> /Users/drkemp/buildbot/slave_common/Tools_CLI/build/cordova-cli/spec/platform.spec.js:150:57 >>>>at _fulfilled >>>> >>>> >>> >> (/Users/drkemp/buildbot/slave_common/Tools_CLI/build/cordova-cli/node_modules/q/q.js:798:54) >>>>at self.promiseDispatch.done >>>> >>>> >>> >> (/Users/drkemp/buildbot/slave_common/Tools_CLI/build/cordova-cli/node_modules/q/q.js:827:30) >>>>at Promise.promise.promiseDispatch >>>> >>>> >>> >> (/Users/drkemp/buildbot/slave_common/Tools_CLI/build/cordova-cli/node_modules/q/q.js:760:13) >>>>at >>>> >>> >> /Users/drkemp/buildbot/slave_common/Tools_CLI/build/cordova-cli/node_modules/q/q.js:574:44 >>>>at flush >>>> >>> >> (/Users/drkemp/buildbot/slave_common/Tools_CLI/build/cordova-cli/node_modules/q/q.js:108:17) >>>>at process._tickCallback (node.js:415:13) >>>> >>>> 2) platform command success `add` should shell out to specified >>>> platform's bin/create, using the version that is specified in >>>> platforms manifest >>>>
Re: MSDN subscriptions for contributors
nice… thanks Jesse! -James Jong On Nov 7, 2013, at 9:04 PM, Jesse wrote: > I can't find the original email in my archives, but here is an email > mentioning the availability of MSDN to apache commiters.[1] > > You'll need to go to [2] with your svn credentials and fill out the form. > And I think you need to do it every year. > > > [1] > http://apache-database.10148.n7.nabble.com/Microsoft-MSDN-licenses-for-Apache-committers-td117850.html > [2] > https://svn.apache.org/repos/private/committers/donated-licenses/msdn-subscription.html > > > > > @purplecabbage > risingj.com
Re: Medic/CI
nice work Sergey and David! great to see CI running on the various platforms! -James Jong On Nov 7, 2013, at 2:04 PM, Sergey Grebnov (Akvelon) wrote: > Great news David, thank you! > > -Sergey > -Original Message- > From: drk...@google.com [mailto:drk...@google.com] On Behalf Of David Kemp > Sent: Thursday, November 7, 2013 10:55 PM > To: dev@cordova.apache.org > Subject: Medic/CI > > After a little turmoil, the medic repo is now up to date with the Windows > support added, and still working on mac/ios/android. > > Thanks for the additions Sergey! > > ** and everything except CLI is green **
Re: Apache Cordova 3 Programming
Congrats and thanks John!! -James Jong On Nov 6, 2013, at 5:42 PM, John Wargo wrote: > Hello Dev, > > I wanted to let you know that Apache Cordova 3 Programming is now available > (in rough cut online at Safari Books Online: > http://my.safaribooksonline.com/9780133521832. > > I hope to have the Amazon listing sorted out soon so people can pre-order on > Amazon. Should be available in about a month (hopefully).
Re: 2.9.1 + 3.2.0rc1
I'll help do some testing w 3.2 this week. -James Jong On Nov 4, 2013, at 2:41 PM, Shazron wrote: > +1 No OS X (no, don't do the 2.9.0 OS X) > > > On Mon, Nov 4, 2013 at 11:37 AM, Steven Gill wrote: > >> For 2.9.1 >> >> I am going to release: >> iOS >> Android >> Windows 8 >> WP 7/8 >> BlackBerry (no updates were made for 2.9.1. Just going to ship the 2.9.0 >> version) >> >> I will create 2.9.1 docs based of 2.9.0. We can always make changes to them >> if required. For now it will just be a reference for people to use who want >> to use 2.9.1 >> >> No CLI >> No OSX (could ship the 2.9.0 version if people want me to) >> >> Thoughts? >> -Steve >> >> >> >> >> On Mon, Nov 4, 2013 at 9:34 AM, Bryan Higgins >> wrote: >> >>> I will take care of BB10 >>> >>> >>> On Mon, Nov 4, 2013 at 11:43 AM, Steven Gill >>> wrote: >>> >>>> I'm going to work on getting 2.9.1 out today. It would be great if >> people >>>> could test + tag 3.2.0rc1 for their platforms. I'd love to get it out >> in >>>> the next two days. >>>> >>> >>
Re: iOS only cordova-labs plugins (keyboard and statusbar, in plugins branch) - move to cordova-ios repo
Shaz, thanks for the work not this! -James Jong On Nov 4, 2013, at 4:06 PM, Shazron wrote: > cordova-plugins repo created > https://git-wip-us.apache.org/repos/asf?p=cordova-plugins.git;a=summary > > I'll start migrating by EOD cordova-labs/#plugins > > > On Mon, Oct 21, 2013 at 9:13 AM, Shazron wrote: > >> INFRA request filed: https://issues.apache.org/jira/browse/INFRA-6902 >> >> >> On Sat, Oct 19, 2013 at 3:36 PM, Brian LeRoux wrote: >> >>> Discreet repos do have value for discreet issue tracking IMO even when you >>> use Jira. For example, feature branching is easier to reason about. >>> >>> /me shrugs >>> >>> One big repo to rule them all has created more problems than perceived >>> benifits in our past experience so maybe I'm just allergic. >>> >>> On Saturday, October 19, 2013, Michal Mocny wrote: >>> >>>> Anis, when we were first ripping out the plugins getting ready for 3.0 >>> we >>>> didn't yet have support for plugins in git repo subdirs. I think we had >>>> that functionality by 3.0 launch but by then we have created a bunch of >>>> repos and momentum followed through. We *could* merge them all into a >>>> cordova-plugins repo, but I'm not sure that has value. We *could* >>> graduate >>>> plugins out of cordova-plugins into discrete repos, but I'm not sure >>> that >>>> has value either. For end users, and for us devs, it really doesn't >>>> matter, so we should do whats most comfortable. >>>> >>>> Brian, at the moment we aren't using github for issue tracking anyway, >>> so >>>> "discrete issue tracking" doesn't need to mean "discrete git repo". >>> Likely >>>> we do want to create a JIRA component for "graduated" plugins. The only >>>> benefit to moving to discrete repos I can think of is consistency, which >>>> may very well have value (esp for tooling support like coho). >>>> >>>> -Michal >>>> >>>> >>>> On Fri, Oct 18, 2013 at 6:57 PM, Brian LeRoux wrote: >>>> >>>>> I think having a staging area for plugins is a good idea and leaving >>>>> cordova-labs as a prototyping area. Ideally we graduate plugins out of >>>>> cordova-plugins if they get any sort of traction at all and require >>>>> discreet issue tracking. >>>>> >>>>> >>>>> On Fri, Oct 18, 2013 at 1:31 PM, Anis KADRI >>>> wrote: >>>>> >>>>>> I am just curious. Why do that only for those plugins only and not >>>>>> every other plugins ? I know phonegap/phonegap-plugins was a bad >>> idea >>>>>> but since git 1.7 there is [1]. I've never used it but just figured >>> it >>>>>> might apply to our case. I also think namespacing is a bad idea. >>>>>> >>>>>> [1] >>> http://schacon.github.io/git/git-read-tree.html#_sparse_checkout >>>>>> >>>>>> On Fri, Oct 18, 2013 at 12:57 PM, Shazron >>> wrote: >>>>>>> Great -- i *think* we have consensus, but I will wait until >>> Monday to >>>>>> move >>>>>>> forward just in case. Here's my updated proposal on what has been >>>>>> discussed >>>>>>> today: >>>>>>> >>>>>>> 1. Ask INFRA to create a cordova-plugins repo >>>>>>> 2. Move (with history) the cordova-labs plugins branch to the >>> repo in >>>>> (1) >>>>>>> 3. Create a CordovaPreferences plugin in (1) with a generic API >>> (and >>>>>>> predefined constants) -- iOS to start >>>>>>> >>>>>>> >>>>>>> On Fri, Oct 18, 2013 at 11:46 AM, Michal Mocny < >>> mmo...@chromium.org> >>>>>> wrote: >>>>>>> >>>>>>>> Sure we can debate the exact interface when it comes to it. >>> Could >>>> use >>>>>>>> predefined constants instead of strings to help with >>>>>>>> typing/discoverability: >>>>>>>> >>>>>>>> navigator.cordovaPreferences.setPreference(win, fail, >>>>>>>> navigator.cordovaPreferences.P
Re: HTML 5 platform
thanks Michal! will have to try that out sometime. -James Jong On Nov 5, 2013, at 10:17 AM, Michal Mocny wrote: > http://en.wikipedia.org/wiki/Chromium_Embedded_Framework > > https://code.google.com/p/chromiumembedded/ > > -Michal > > > On Tue, Nov 5, 2013 at 10:06 AM, James Jong wrote: > >>> I use a custom application based on CEF for testing, this way I can >> still test my app without having to worry about CORS or other crappy >> browser security > concerns.. I like this more than ripple.. >> >> What's CEF? >> >> -James Jong >> >> On Nov 4, 2013, at 12:23 PM, Dick Van den Brink >> wrote: >> >>> I use a custom application based on CEF for testing, this way I can >> still test my app without having to worry about CORS or other crappy >> browser security concerns.. I like this more than ripple.. >>> >>> Sent from my Windows Phone >>> >>> From: Josh Soref<mailto:jso...@blackberry.com> >>> Sent: 11/4/2013 17:06 >>> To: dev@cordova.apache.org<mailto:dev@cordova.apache.org> >>> Subject: Re: HTML 5 platform >>> >>> https://issues.apache.org/jira/browse/CB-2062 >>> >>>> Any thoughts on adding html5 as a platform? >>> >>> Fil mentioned Ripple. While not endorsing it, have you tried it? >>> >>> Ripple is more or less what you want. It's a JavaScript shim to which >> you can deploy. It should also include API support for sensors and other >> features. >>> - >>> 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: HTML 5 platform
> I use a custom application based on CEF for testing, this way I can still > test my app without having to worry about CORS or other crappy browser > security > concerns.. I like this more than ripple.. What's CEF? -James Jong On Nov 4, 2013, at 12:23 PM, Dick Van den Brink wrote: > I use a custom application based on CEF for testing, this way I can still > test my app without having to worry about CORS or other crappy browser > security concerns.. I like this more than ripple.. > > Sent from my Windows Phone > > From: Josh Soref<mailto:jso...@blackberry.com> > Sent: 11/4/2013 17:06 > To: dev@cordova.apache.org<mailto:dev@cordova.apache.org> > Subject: Re: HTML 5 platform > > https://issues.apache.org/jira/browse/CB-2062 > >> Any thoughts on adding html5 as a platform? > > Fil mentioned Ripple. While not endorsing it, have you tried it? > > Ripple is more or less what you want. It's a JavaScript shim to which you can > deploy. It should also include API support for sensors and other features. > - > 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: Chromeview has arrived in Android 4.4!!!!
Awesome news!! -James Jong On Oct 31, 2013, at 2:34 PM, Steven Gill wrote: > Celebrate! https://developers.google.com/chrome/mobile/docs/webview/overview
Re: Medic/Buildbot - building release versions
+1 to fixing 3.1 MS -James Jong On Oct 17, 2013, at 12:23 PM, Steve Gill wrote: > Do it! > > > >> On Oct 17, 2013, at 7:36 AM, David Kemp wrote: >> >> FYI the commit that updated the plugin names (and would need to be >> cherrypicked into 3.1) is: >> >> https://github.com/apache/cordova-mobile-spec/commit/06262fa18baa625003a7e0dc25c740c82ef8baaa >> >> >> >> >>> On Thu, Oct 17, 2013 at 10:31 AM, Michal Mocny wrote: >>> >>> I think using MS at master with released platform/cli was a powder keg >>> waiting to explode. >>> >>> We shipped a broken 3.1 mobile spec, and so +1 to your suggestion of fixing >>> it and moving CI back to test testing cadence releases with the matching >>> MobileSpec. >>> >>> Side note: part of the problem seems to be that mobile spec is both an app >>> and a set of plugins, and those plugins (namely the dependency plugin) >>> weren't being updated on the plugin update schedule (weekly). We should >>> make a note to do so in the future (or even move MS plugins out to another >>> repo and add to registry?) >>> >>> -Michal >>> >>> >>>> On Thu, Oct 17, 2013 at 8:40 AM, David Kemp wrote: >>>> >>>> TL;DR : Android release 3.1 is hard to test again due to added tests (to >>>> master) that fail. patching 3.1 mobile-spec would be a good thing. >>>> >>>> Our plan here was to continuously build iOS and Android, both current >>>> release and master (4 builds). To do this we build: >>>> IOS_Master : iOS (master), plugins(dev), mobile-spec(master) >>>> IOS_Release : iOS (3.1), plugins(master), mobile-spec(master) >>>> Android_Master : iOS (master), plugins(dev), mobile-spec(master) >>>> Android_Release : iOS (3.1), plugins(master, mobile-spec(master) >>>> >>>> The reason that mobile-spec master is used for release branches is >>> because >>>> the plugins were renamed just before 3.1, but the dependencies listed in >>>> mobile-spec were not updated. >>>> (cordova-mobile-spec/dependencies-plugin/plugin.xml) >>>> >>>> To avoid that problem, we switched to testing 3.1 with master >>> mobile-spec. >>>> Until last night that worked. >>>> >>>> However, now mobile-spec (master) has new tests added that will always >>> fail >>>> for 3.1. >>>> >>>> SO, I would like to patch 3.1 mobilespec with the plugin dependencies >>> from >>>> master. >>>> >>>> Any concerns? >>>
Re: Post 3.1 release committer & community meeting
- Latest updates / strategic direction on medic & CI -James Jong On Oct 15, 2013, at 11:30 AM, Andrew Grieve wrote: > This is coming up this Thursday! What do people want to talk about? Here's > a couple to get us going: > > - Plugin registry download counts (Are these available yet) > - Idea: Split cordova-cli-lib from cordova-cli on NPM (have cordova-cli and > phonegap-cli depend on cordova-cli-lib) > - Michal's work on CDVTest > > > > On Tue, Oct 8, 2013 at 4:16 PM, Michal Mocny wrote: > >> Alright, Looks like Thu 17 is the clear winner, with not a single person >> having any complaints about that time. >> >> Brian cannot make it until 6pm EST, but I'm going to schedule start time >> for 5:30 for the inevitable hiccups and introductions and any agenda >> overview etc. It will very likely be 6pm before we get into the thick of >> things. >> >> We will send out exact details on this thread the day of, See you all then. >> >> -Michal >> >> >> On Mon, Oct 7, 2013 at 1:05 PM, Michal Mocny wrote: >> >>> Okay, options are updated for the poll ( >> http://doodle.com/2pmy2ptafmxsrna2 >>> ) >>> >>> For those who filled it out, sorry, you will need to do it again. >>> >>> >>> On Sun, Oct 6, 2013 at 7:27 PM, Michal Mocny wrote: >>> >>>> Ugh Sorry that was a misreading of course. I'll set up a new doodle >>>> tomorrow morning. >>>> On 2013-10-06 1:52 AM, "Tommy Williams" wrote: >>>> >>>>> +1 for post 16th for Joe availability. >>>>> >>>>> Also, thanks for thinking of Australia... One benefit of the time of >>>>> year, >>>>> the nasty time difference just got an hour better today... >>>>> >>>>> - tommy >>>>> On 5 Oct 2013 08:33, "Jesse" wrote: >>>>> >>>>>> I filled it out, however, Joe is not available until after the 15th. >>>>> Maybe >>>>>> we should aim for the 16-18th as a window. >>>>>> >>>>>> @purplecabbage >>>>>> risingj.com >>>>>> >>>>>> >>>>>> On Fri, Oct 4, 2013 at 3:09 PM, Michal Mocny >>>>> wrote: >>>>>> >>>>>>> http://www.doodle.com/2pmy2ptafmxsrna2 >>>>>>> >>>>>>> I put a lot of options for time (sorry) since I wasn't sure if we >>>>> should >>>>>> be >>>>>>> europe or australia friendly this time. >>>>>>> >>>>>>> There are also three options this time: yes, (yes), no, where the >>>>> middle >>>>>>> option is supposed to be a "prefer not, but if need be, fine" >>>>>>> >>>>>>> -Michal >>>>>>> >>>>>>> >>>>>>> On Fri, Oct 4, 2013 at 6:06 PM, Michal Mocny >>>>>> wrote: >>>>>>> >>>>>>>> 11-15 sounds like the range to shoot for. I'll set up a doodle.. >>>>>>>> >>>>>>>> >>>>>>>> On Fri, Oct 4, 2013 at 4:48 PM, Joe Bowser >>>>> wrote: >>>>>>>> >>>>>>>>> I'm unavailable until after the 15th. I'll be at Big Android >> BBQ. >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >>
Re: Node-Webkit
+1 Would love to see this as a new platform. -James Jong On Oct 15, 2013, at 2:11 PM, Shazron wrote: > This is interesting (I like the 3 platforms support) - if this gets in, I > propose retiring the cordova-osx repo. > > > On Tue, Oct 15, 2013 at 11:00 AM, Maxime LUCE wrote: > >> Yes Jesse, >> >> It's about supporting node-webkit as a new, different platform. >> I see some great value added to a desktop platform : >> >> - Really easy to debug (chromium dev tools integrated) >> - Allow kiosk mode and other desktop integration which can be usefull in >> touch aware application. >> - Allow packaging and distribution on 3 main desktop OS. >> >> I think Cordova is mostly a bridge between HTML and Native APIs. >> Node-webkit enable a bridged communication between Webkit and Node.JS so >> can be used as a command proxy for Cordova. >> >> You also have the new packaged Chrome Apps which can be great to support >> too, I think. >> >> I think a cordova-desktop repository could be a great place to try out >> theses platforms. >> >> >> Cordialement. >> >> >> Maxime LUCE >> >> >> max...@touchit.fr >> 06 28 60 72 34 >> http://touchit.fr >> >> >> -Original Message- >> From: Jesse [mailto:purplecabb...@gmail.com] >> Sent: mardi 15 octobre 2013 19:45 >> To: dev@cordova.apache.org >> Subject: Re: Node-Webkit >> >> No, we are talking about node-webkit OR appjs as another target platform >> to support, which would mean we could build for apps for Windows, Linux, >> OSX desktop applications. >> I think node-webkit is the more mature platform, but I have only glanced >> at both. Definitely interesting. >> >> >> @purplecabbage >> risingj.com >> >> >> On Tue, Oct 15, 2013 at 10:38 AM, Brian LeRoux wrote: >> >>> Cordova is mostly about phones (except when its OS X and Windows). >>> Node support is not a project goal though I would encourage you to >>> look at authoring plugins for iOS, Android, Windows Phone that mimic >>> Node APIs if that is something you're looking for. >>> >>> >>> On Tue, Oct 15, 2013 at 1:27 PM, Maxime LUCE wrote: >>> >>>> What about a node-webkit or appjs platform integration ? >>>> >>>> It could help debugging with Cordova related projects and permit to >>>> add three platform with one platform : "Windows", "Linux", "OSX". >>>> I'm thinking about a platform proxy for node-webkit and/or >>> appjs-deskshell. >>>> >>>> What do you think of this improvement ? >>>> Is there some node-webkit specialists which can helps in this project ? >>>> >>>> Cordialement. >>>> >>>> [Touch it] >>>> >>>> Maxime LUCE >>>> >>>> [Facebook]<http://www.facebook.com/pages/Touch-it/326622874049375> >>>> >>>> [Twitter]<https://twitter.com/#%21/Touchit_App> >>>> >>>> max...@touchit.fr >>>> 06 28 60 72 34 >>>> http://touchit.fr >>>> >>>> >>>> >>>> >>> >>
Re: officially supported plugins from the Cordova community
Instead of a static list, would it be better to point to our plugin registry and filter for org.apache.cordova? Also, does it make sense to reserve this namespace for Cordova use only? -James Jong On Oct 15, 2013, at 6:49 PM, "Smith, Peter" wrote: > +1 for some kind of list > > Whenever the documented API refers to plugins which are not found in > what I thought was the official set plugins at > https://github.com/search?q=%40apache+cordova-plugin my brain hurts. > e.g. https://issues.apache.org/jira/browse/CB-5090 > > Peter. > > > -----Original Message- > From: James Jong [mailto:wjamesj...@gmail.com] > Sent: Wednesday, 16 October 2013 5:17 AM > To: dev@cordova.apache.org > Subject: officially supported plugins from the Cordova community > > As we're breaking out and developing more and more plugins, one question > I have been getting is "what is the set of plugins officially supported > by the Cordova community?" It's unclear to me what defines this set. > Here's how I've been categorizing them. > > Supported > 1) Publicly documented APIs on cordova.apache.org/docs (Accelerometer, > Compass, etc...). These plugins fall under the org.apache.cordova > namespace. > > Unsupported > 2) plugins not under org.apache.cordova namespace > 3) org.apache.cordova plugins under cordova-labs (like the new iOS > keyboard, status bar plugins) > > Gray areas > 4) Undocumented plugins that were formerly part of the core. For > example, the console plugin. This is a org,apache.cordova plugin, but > not documented as part of public APIs. Also, not all platforms support > it. Should we support it? If we support it, should we document the API > in our Cordova docs? > > Thoughts? Should we have a list of supported plugins in our > documentation to point Cordova users to? > > -James Jong > >
officially supported plugins from the Cordova community
As we're breaking out and developing more and more plugins, one question I have been getting is "what is the set of plugins officially supported by the Cordova community?" It's unclear to me what defines this set. Here's how I've been categorizing them. Supported 1) Publicly documented APIs on cordova.apache.org/docs (Accelerometer, Compass, etc…). These plugins fall under the org.apache.cordova namespace. Unsupported 2) plugins not under org.apache.cordova namespace 3) org.apache.cordova plugins under cordova-labs (like the new iOS keyboard, status bar plugins) Gray areas 4) Undocumented plugins that were formerly part of the core. For example, the console plugin. This is a org,apache.cordova plugin, but not documented as part of public APIs. Also, not all platforms support it. Should we support it? If we support it, should we document the API in our Cordova docs? Thoughts? Should we have a list of supported plugins in our documentation to point Cordova users to? -James Jong
Re: [iOS] Moving setting of UIWebView properties to its own plugin from the core
In favor of moving it to a plugin but keeping it in cordova-ios (same as CDVLocalStorage). We can always move it out later. -James Jong On Oct 9, 2013, at 12:55 PM, Shazron wrote: > If we do that, might as well pluginize (well its already a plugin) the > CDVLocalStorage stuff as well into that process. But! The difference in the > CDVLocalStorage plugin is, it has to be loaded/run before the UIWebView is > created, so I don't think it would work (unless we have another feature > param attribute, or something) > > > On Wed, Oct 9, 2013 at 9:47 AM, Andrew Grieve wrote: > >> I think pluginerizing the settings is a good idea. A nice-to-have here >> would be to have the plugin installed by default for new projects. Maybe we >> can ship a version of the plugin with platforms, and then allow it to be >> upgraded via the registry? >> >> >> On Wed, Oct 9, 2013 at 11:43 AM, Brian LeRoux wrote: >> >>> I am all in favor of distilling platforms down to the very essence and >>> 'plugin all the things'. Way easier for issue tracking, maintenance, and >>> upgrading. >>> >>> >>> On Wed, Oct 9, 2013 at 7:23 AM, Shazron wrote: >>> >>>> See: https://issues.apache.org/jira/browse/CB-5026 >>>> >>>> >>>> Pros: >>>> - if iOS >= 8 adds more properties, and people want to stick to Cordova >>> 3.A >>>> and we only support it in 3.B or 4.x, they only have to update a plugin >>> and >>>> not the whole core. >>>> >>>> Cons: >>>> - if they rely on these settings, they will lose them when they upgrade >>> if >>>> they don't install a plugin, this won't be any different when they >> moved >>>> from 2.x to 3.x >>>> - Yet Another Repo? >>>> >>> >>
Re: buildbot failure in Cordova Testing on IOS_Master
Hi David, I have a theory but will need to work with your device to test it out. Let's try to get a call on Friday when you can get to the device. -James Jong On Oct 9, 2013, at 7:08 PM, David Kemp wrote: >
Re: buildbot failure in Cordova Testing on IOS_Master
Thanks Shaz. Does anyone else have an iOS 6.0 device they can run the tests on? -James Jong On Oct 9, 2013, at 6:23 PM, Shazron wrote: > Just tested on an iPad 3, iOS 7.0.2 with the dev branch of > cordova-plugin-device-motion, it passes all tests. > > > On Wed, Oct 9, 2013 at 2:45 PM, Shazron wrote: > >> I have an iPad 3 here with 7.0.2 - I'll test and verify soon. >> >> >> On Wed, Oct 9, 2013 at 2:29 PM, James Jong wrote: >> >>> I'm ok if you want to skip it. Right now the issue looks like it's >>> limited to iPad 3 and/or 6.0. >>> -James Jong >>> >>> On Oct 9, 2013, at 5:23 PM, Steven Gill wrote: >>> >>>> Should I skip this plugin for today's release until these issues get >>> sorted? >>>> >>>> >>>> On Wed, Oct 9, 2013 at 2:01 PM, James Jong >>> wrote: >>>> >>>>> Hmm... Let me check if I have an iPad at 6.0. I definitely don't >>> have >>>>> an iPad3 but may have an iPad2. >>>>> >>>>> -James Jong >>>>> >>>>> On Oct 9, 2013, at 4:53 PM, David Kemp wrote: >>>>> >>>>>> >>>>>> Hi James, >>>>>> >>>>>> That problem went away with the new commit, but now I am getting two >>>>> failures on one iPad (6.0__iPad3,1) >>>>>> the other iPad passes all tests (6.1.3 - iPad2,5): >>>>>> >>>>>> I tried it twice with the same results. >>>>>> >>>>>> failures >>>>>> 0 >>>>>> spec >>>>>> Accelerometer (navigator.accelerometer) getCurrentAcceleration >>>>> accelerometer.spec.5 success callback Acceleration object should >>> return a >>>>> rec... >>>>>> assertions >>>>>> 0 >>>>>> exception >>>>>> timeout: timed out after 7500 msec waiting for win never called >>>>>> trace >>>>>> 1 >>>>>> spec >>>>>> Accelerometer (navigator.accelerometer) watchAcceleration >>>>> accelerometer.spec.5 success callback Acceleration object should >>> return a >>>>> recent t... >>>>>> assertions >>>>>> 0 >>>>>> exception >>>>>> Expected 1381351391115.972 to be greater than 1381351399373. >>>>>> trace >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Wed, Oct 9, 2013 at 4:36 PM, Andrew Grieve >>>>> wrote: >>>>>> Awesome! >>>>>> >>>>>> >>>>>> On Wed, Oct 9, 2013 at 4:34 PM, James Jong >>> wrote: >>>>>> >>>>>>> Added. >>>>>>> -James Jong >>>>>>> >>>>>>> On Oct 9, 2013, at 4:23 PM, James Jong wrote: >>>>>>> >>>>>>>> Ah yes. Sorry. I need to add the new framework. >>>>>>>> >>>>>>>> -James Jong >>>>>>>> >>>>>>>> On Oct 9, 2013, at 4:08 PM, Andrew Grieve >>>>> wrote: >>>>>>>> >>>>>>>>> James - our build bot thinks you broke things! Sadly still haven't >>>>> got >>>>>>> it exposed, but the error is: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>> >>>>> >>> /Users/drkemp/buildbot/slave_ios2/IOS_Master/build/mobilespec/platforms/ios/build/emulator/mobilespec.app/mobilespec >>>>>>>>> Undefined symbols for architecture armv7: >>>>>>>>> "_OBJC_CLASS_$_CMMotionManager", referenced from: >>>>>>>>>objc-class-ref in CDVAccelerometer.o >>>>>>>>> ld: symbol(s) not found for architecture armv7 >>>>>>>>> clang: error: linker command failed with exit code 1 (use -v to see >>>>>>> invocation) >>>>>>>>> >>>>>>>>> >>>>>>>>> ** BUILD FAILED ** >>>>>>>>> >>>>>>>>> >>>>>>>>> The following build commands failed: >>>>>>>>>Ld build/emulator/mobilespec.app/mobilespec normal armv7 >>>>>>>>> (1 failure) >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Likely you need to add CoreMotion to the of the >>> plugin. >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>> >>> >>
Re: buildbot failure in Cordova Testing on IOS_Master
I'm ok if you want to skip it. Right now the issue looks like it's limited to iPad 3 and/or 6.0. -James Jong On Oct 9, 2013, at 5:23 PM, Steven Gill wrote: > Should I skip this plugin for today's release until these issues get sorted? > > > On Wed, Oct 9, 2013 at 2:01 PM, James Jong wrote: > >> Hmm... Let me check if I have an iPad at 6.0. I definitely don't have >> an iPad3 but may have an iPad2. >> >> -James Jong >> >> On Oct 9, 2013, at 4:53 PM, David Kemp wrote: >> >>> >>> Hi James, >>> >>> That problem went away with the new commit, but now I am getting two >> failures on one iPad (6.0__iPad3,1) >>> the other iPad passes all tests (6.1.3 - iPad2,5): >>> >>> I tried it twice with the same results. >>> >>> failures >>> 0 >>> spec >>> Accelerometer (navigator.accelerometer) getCurrentAcceleration >> accelerometer.spec.5 success callback Acceleration object should return a >> rec... >>> assertions >>> 0 >>> exception >>> timeout: timed out after 7500 msec waiting for win never called >>> trace >>> 1 >>> spec >>> Accelerometer (navigator.accelerometer) watchAcceleration >> accelerometer.spec.5 success callback Acceleration object should return a >> recent t... >>> assertions >>> 0 >>> exception >>> Expected 1381351391115.972 to be greater than 1381351399373. >>> trace >>> >>> >>> >>> >>> >>> On Wed, Oct 9, 2013 at 4:36 PM, Andrew Grieve >> wrote: >>> Awesome! >>> >>> >>> On Wed, Oct 9, 2013 at 4:34 PM, James Jong wrote: >>> >>>> Added. >>>> -James Jong >>>> >>>> On Oct 9, 2013, at 4:23 PM, James Jong wrote: >>>> >>>>> Ah yes. Sorry. I need to add the new framework. >>>>> >>>>> -James Jong >>>>> >>>>> On Oct 9, 2013, at 4:08 PM, Andrew Grieve >> wrote: >>>>> >>>>>> James - our build bot thinks you broke things! Sadly still haven't >> got >>>> it exposed, but the error is: >>>>>> >>>>>> >>>>>> >>>>>> >>>> >> /Users/drkemp/buildbot/slave_ios2/IOS_Master/build/mobilespec/platforms/ios/build/emulator/mobilespec.app/mobilespec >>>>>> Undefined symbols for architecture armv7: >>>>>> "_OBJC_CLASS_$_CMMotionManager", referenced from: >>>>>> objc-class-ref in CDVAccelerometer.o >>>>>> ld: symbol(s) not found for architecture armv7 >>>>>> clang: error: linker command failed with exit code 1 (use -v to see >>>> invocation) >>>>>> >>>>>> >>>>>> ** BUILD FAILED ** >>>>>> >>>>>> >>>>>> The following build commands failed: >>>>>> Ld build/emulator/mobilespec.app/mobilespec normal armv7 >>>>>> (1 failure) >>>>>> >>>>>> >>>>>> >>>>>> Likely you need to add CoreMotion to the of the plugin. >>>>>> >>>>>> >>>>> >>>> >>>> >>> >> >>
Re: buildbot failure in Cordova Testing on IOS_Master
The iPads I have are on 5.1 , 6.1.3 , and 7. I've just run the tests on each of them multiple times and they have passed. -James Jong On Oct 9, 2013, at 5:01 PM, James Jong wrote: > Hmm... Let me check if I have an iPad at 6.0. I definitely don't have an > iPad3 but may have an iPad2. > > -James Jong > > On Oct 9, 2013, at 4:53 PM, David Kemp wrote: > >> >> Hi James, >> >> That problem went away with the new commit, but now I am getting two >> failures on one iPad (6.0__iPad3,1) >> the other iPad passes all tests (6.1.3 - iPad2,5): >> >> I tried it twice with the same results. >> >> failures >> 0 >> spec >> Accelerometer (navigator.accelerometer) getCurrentAcceleration >> accelerometer.spec.5 success callback Acceleration object should return a >> rec... >> assertions >> 0 >> exception >> timeout: timed out after 7500 msec waiting for win never called >> trace >> 1 >> spec >> Accelerometer (navigator.accelerometer) watchAcceleration >> accelerometer.spec.5 success callback Acceleration object should return a >> recent t... >> assertions >> 0 >> exception >> Expected 1381351391115.972 to be greater than 1381351399373. >> trace >> >> >> >> >> >> On Wed, Oct 9, 2013 at 4:36 PM, Andrew Grieve wrote: >> Awesome! >> >> >> On Wed, Oct 9, 2013 at 4:34 PM, James Jong wrote: >> >> > Added. >> > -James Jong >> > >> > On Oct 9, 2013, at 4:23 PM, James Jong wrote: >> > >> > > Ah yes. Sorry. I need to add the new framework. >> > > >> > > -James Jong >> > > >> > > On Oct 9, 2013, at 4:08 PM, Andrew Grieve wrote: >> > > >> > >> James - our build bot thinks you broke things! Sadly still haven't got >> > it exposed, but the error is: >> > >> >> > >> >> > >> >> > >> >> > /Users/drkemp/buildbot/slave_ios2/IOS_Master/build/mobilespec/platforms/ios/build/emulator/mobilespec.app/mobilespec >> > >> Undefined symbols for architecture armv7: >> > >> "_OBJC_CLASS_$_CMMotionManager", referenced from: >> > >> objc-class-ref in CDVAccelerometer.o >> > >> ld: symbol(s) not found for architecture armv7 >> > >> clang: error: linker command failed with exit code 1 (use -v to see >> > invocation) >> > >> >> > >> >> > >> ** BUILD FAILED ** >> > >> >> > >> >> > >> The following build commands failed: >> > >> Ld build/emulator/mobilespec.app/mobilespec normal armv7 >> > >> (1 failure) >> > >> >> > >> >> > >> >> > >> Likely you need to add CoreMotion to the of the plugin. >> > >> >> > >> >> > > >> > >> > >> >
Re: buildbot failure in Cordova Testing on IOS_Master
Hmm... Let me check if I have an iPad at 6.0. I definitely don't have an iPad3 but may have an iPad2. -James Jong On Oct 9, 2013, at 4:53 PM, David Kemp wrote: > > Hi James, > > That problem went away with the new commit, but now I am getting two failures > on one iPad (6.0__iPad3,1) > the other iPad passes all tests (6.1.3 - iPad2,5): > > I tried it twice with the same results. > > failures > 0 > spec > Accelerometer (navigator.accelerometer) getCurrentAcceleration > accelerometer.spec.5 success callback Acceleration object should return a > rec... > assertions > 0 > exception > timeout: timed out after 7500 msec waiting for win never called > trace > 1 > spec > Accelerometer (navigator.accelerometer) watchAcceleration > accelerometer.spec.5 success callback Acceleration object should return a > recent t... > assertions > 0 > exception > Expected 1381351391115.972 to be greater than 1381351399373. > trace > > > > > > On Wed, Oct 9, 2013 at 4:36 PM, Andrew Grieve wrote: > Awesome! > > > On Wed, Oct 9, 2013 at 4:34 PM, James Jong wrote: > > > Added. > > -James Jong > > > > On Oct 9, 2013, at 4:23 PM, James Jong wrote: > > > > > Ah yes. Sorry. I need to add the new framework. > > > > > > -James Jong > > > > > > On Oct 9, 2013, at 4:08 PM, Andrew Grieve wrote: > > > > > >> James - our build bot thinks you broke things! Sadly still haven't got > > it exposed, but the error is: > > >> > > >> > > >> > > >> > > /Users/drkemp/buildbot/slave_ios2/IOS_Master/build/mobilespec/platforms/ios/build/emulator/mobilespec.app/mobilespec > > >> Undefined symbols for architecture armv7: > > >> "_OBJC_CLASS_$_CMMotionManager", referenced from: > > >> objc-class-ref in CDVAccelerometer.o > > >> ld: symbol(s) not found for architecture armv7 > > >> clang: error: linker command failed with exit code 1 (use -v to see > > invocation) > > >> > > >> > > >> ** BUILD FAILED ** > > >> > > >> > > >> The following build commands failed: > > >> Ld build/emulator/mobilespec.app/mobilespec normal armv7 > > >> (1 failure) > > >> > > >> > > >> > > >> Likely you need to add CoreMotion to the of the plugin. > > >> > > >> > > > > > > > >
Re: buildbot failure in Cordova Testing on IOS_Master
Just testing out the new buildbot system ;-) It works!! -James Jong On Oct 9, 2013, at 4:36 PM, Andrew Grieve wrote: > Awesome! > > > On Wed, Oct 9, 2013 at 4:34 PM, James Jong wrote: > Added. > -James Jong > > On Oct 9, 2013, at 4:23 PM, James Jong wrote: > > > Ah yes. Sorry. I need to add the new framework. > > > > -James Jong > > > > On Oct 9, 2013, at 4:08 PM, Andrew Grieve wrote: > > > >> James - our build bot thinks you broke things! Sadly still haven't got it > >> exposed, but the error is: > >> > >> > >> > >> /Users/drkemp/buildbot/slave_ios2/IOS_Master/build/mobilespec/platforms/ios/build/emulator/mobilespec.app/mobilespec > >> Undefined symbols for architecture armv7: > >> "_OBJC_CLASS_$_CMMotionManager", referenced from: > >> objc-class-ref in CDVAccelerometer.o > >> ld: symbol(s) not found for architecture armv7 > >> clang: error: linker command failed with exit code 1 (use -v to see > >> invocation) > >> > >> > >> ** BUILD FAILED ** > >> > >> > >> The following build commands failed: > >> Ld build/emulator/mobilespec.app/mobilespec normal armv7 > >> (1 failure) > >> > >> > >> > >> Likely you need to add CoreMotion to the of the plugin. > >> > >> > > > >
Re: Review Request 14450: CB-4825 Move to using CoreMotion framework for iOS accelerometer in place of deprecated UIAccelerometer.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/14450/ --- (Updated Oct. 2, 2013, 8:26 p.m.) Review request for cordova and Shazron Abdullah. Changes --- Use weak reference in update block (from Shaz's review). Bugs: CB-4825 https://issues.apache.org/jira/browse/CB-4825 Repository: cordova-plugin-device-motion Description --- Move to using CoreMotion framework for iOS accelerometer in place of deprecated UIAccelerometer. Diffs (updated) - src/ios/CDVAccelerometer.h 923d0c8 src/ios/CDVAccelerometer.m 33093d0 Diff: https://reviews.apache.org/r/14450/diff/ Testing --- Tested with 3.1 core. Thanks, James Jong
Re: Review Request 14450: CB-4825 Move to using CoreMotion framework for iOS accelerometer in place of deprecated UIAccelerometer.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/14450/ --- (Updated Oct. 2, 2013, 7:48 p.m.) Review request for cordova and Shazron Abdullah. Bugs: CB-4825 https://issues.apache.org/jira/browse/CB-4825 Repository: cordova-plugin-device-motion Description --- Move to using CoreMotion framework for iOS accelerometer in place of deprecated UIAccelerometer. Diffs - src/ios/CDVAccelerometer.h 923d0c8 src/ios/CDVAccelerometer.m 33093d0 Diff: https://reviews.apache.org/r/14450/diff/ Testing --- Tested with 3.1 core. Thanks, James Jong
Re: Updating plugin code on prepare
+1 This is a cleaner workflow and should reduce some confusion. -James Jong On Sep 24, 2013, at 3:09 PM, Michal Mocny wrote: > Just to add, the reason for the "if" statement in step (2) is that > uninstall & reinstall take a lot longer than just moving a few files, which > is the 99.9% case for most end users who aren't making modifications to > plugins. > > This way, we only do the heavy lifting if your plugin structure actually > changed. Doing it automatically means we no longer have to advise users > that making edits inside plugin/ folder is useless. Now we just advise > them to run "prepare" after making changes to either www/ or plugins/. > > This key insight was Braden's idea and I think its just an awesome change > for workflow. > > -Michal > > > On Tue, Sep 24, 2013 at 2:58 PM, Braden Shepherdson > wrote: > >> Michal and I were discussing how to make the plugin developer experience >> better, by having `cordova prepare` update the platform projects properly >> when you change a plugin in place. >> >> I propose the following changes: >> >> 1. On plugin install, we cache the plugin.xml in $PROJECT/.cordova >> somewhere. >> 2. On 'cordova prepare', compare each plugin's plugin.xml against the >> cached one. >>a. If they have changed, uninstall the plugin using the old plugin.xml, >> then reinstall using the new one (and update the cached plugin.xml). >>b. If they are identical, copy all the native code files from the >> plugin into the project again. >> >> The idea is that you can change your plugin's native code, JS modules, or >> assets, and after a prepare you'll be running the latest. We already have >> cordova plugin add foo --link, but it wasn't very useful. This will make >> plugin development a much smoother flow, without too much implementation >> effort. >> >> Checking for changes to plugin.xml lets us know that no files have been >> added or removed, that edits haven't changed, and so on, >> meaning that simply copying the native code again will be sufficient. >> >> What do people think? Any gotchas that I overlooked? >> >> Braden >>
Re: [iOS] Keyboard Preferences - move to a plugin for 3.2.0
+1 Separating this from the core into a plugin is a good idea. Not sure that this fits into any existing plugin though. -James Jong On Sep 24, 2013, at 2:37 PM, Shazron wrote: > Issue: https://issues.apache.org/jira/browse/CB-3020 > > I've got it mostly working but I'm thinking this really should move to a > plugin, perhaps reside in an existing one? > > The things we are doing with hiding the keyboard accessory bar and > shrinking the view etc are hackish and might break with any iOS update, and > imo fixes should not be tied to a core release. > > My proposal is to move the code for the two keyboard preferences to a > plugin.
[iOS 7] input on accelerometer plugin implementation
Seeking some input from my fellow iOS devs... Background: https://issues.apache.org/jira/browse/CB-4825 UIAccelerometer has been deprecated as of iOS 5 in favor of using CoreMotion framework. Our iOS core Accelerometer plugin uses UIAccelerometer and Xcode 5 shows warnings for using the deprecated class. Issue: I have a working implementation using CoreMotion but iOS 7 repeatedly issues an annoying debug message in Xcode when accelerometer is being watched. A workaround is discussed here by shimming stderr->_write to ignore the message. https://devforums.apple.com/message/866900#866900 What to do? I see 3 choices: 1) Leave current code as is with warnings in Xcode 5. Switch to CoreMotion when Apple fixes bug. 2) Implement with CoreMotion as is with debug message present. 3) Implement with CoreMotion with stderr->_write workaround. Any preferences on the above options? Suggestions? -James Jong
Re: no more commit, jira emails
Shaz, I'm still getting git and jira emails. Have some from 11pm Pacific for both. -James Jong On Sep 12, 2013, at 6:51 PM, Shazron wrote: > I don't seem to be getting any commit or jira emails anymore. The last > commit email was 11:15am Pacific, and the last JIRA email was 1:48pm > Pacific. > > There definitely has been more commits and updates to JIRA issues since > then. Anyone see this?
Re: 3.1 Release
Andrew, thanks for kicking it off. Also should note inclusion of iOS 7 support. -James Jong On Sep 9, 2013, at 10:42 AM, Andrew Grieve wrote: > I think it's time to get the ball rolling on this. It'll be the first > release post-3.0, so will likely have a few bumps to work through. > > How about: > > Friday 13th - Create release branches & tag RC of all repos > Monday 16th - Draft Release Blog Post (digest of changelogs) > Thurs 19th - Tag 3.1.0 for all repos > Fri 20th - Push 3.1.0-1.0.0 of CLI to npm & Post blog post > > The main feature of this release will be plugman-registry I think. That > said, since CLI / Plugman aren't tied to cadence releases, I think it's > just cordova-docs that is relevant.
Re: config.xml as a build artifact for less suffering and easier upgrades
Andrew - what I was thinking was pretty much what Michal wrote below. Perhaps it was my interpretation of the original note but I thought defaults was to be applied only in the CLI workflow. -James Jong On Sep 7, 2013, at 1:05 PM, Michal Mocny wrote: > With this proposal as it stands, I think that is already true (at least for > the initial contents, obviously user can make edits later). > > Ie, defaults.xml + app.xml = initial config.xml for both cases, which use > the same helloworld template's app.xml. > > If there are specific differences to the default values that we want, we > maybe will want to use a different app.xml for each, but defaults.xml > should be tied to a platform-version not to a workflow. > > -Michal > > > On Sat, Sep 7, 2013 at 7:56 AM, Andrew Grieve wrote: > >> James - that's a nice goal, but I don't think it's feasible. Did you have a >> way to do that in mind? >> >> >> On Fri, Sep 6, 2013 at 10:31 PM, James Jong wrote: >> >>> I would like to see the defaults be applied in all cases. For >>> consistency, less confusion, and easier documentation. If we add or >> change >>> the defaults in a release, both workflows should get it. In my mind, the >>> CLI platform config.xml should be equivalent to the bin/create one. >>> >>> -James Jong >>> >>> On Sep 6, 2013, at 11:06 AM, Michal Mocny wrote: >>> >>>> I thought we were adding support for the last bit (ie, app generic not >>>> platform specific preferences) to "app.xml" which the helloworld >> template >>>> should ship with and bin/create should apply. >>>> >>>> -Michal >>>> >>>> >>>> >>>> On Fri, Sep 6, 2013 at 10:52 AM, Ian Clelland >>> wrote: >>>> >>>>> The template version needs to be a complete config file for the sample >>> app, >>>>> though. You should be able to run bin/create and then build the Hello, >>>>> Cordova app immediately. >>>>> >>>>> defaults.xml is supposed to be stripped right down to just the >>>>> platform-specific options which, in theory, shouldn't need to be >>> specified >>>>> by every app. >>>>> >>>>> At least that's how it works in my head :) The distinction may be less >>>>> important than I'm imagining. >>>>> >>>>> Ian >>>>> >>>>> >>>>> On Fri, Sep 6, 2013 at 9:08 AM, Michal Mocny >>> wrote: >>>>> >>>>>> If the content or format of defaults.xml and the initial config.xml >>> will >>>>> be >>>>>> different then we should ship both -- but I don't think they will be, >>> so >>>>> I >>>>>> think we just ship the template with a defaults file. >>>>>> >>>>>> -Michal >>>>>> >>>>>> >>>>>> On Thu, Sep 5, 2013 at 11:19 PM, Ian Clelland < >> iclell...@chromium.org >>>>>>> wrote: >>>>>> >>>>>>> On Thu, Sep 5, 2013 at 5:16 PM, James Jong >>>>> wrote: >>>>>>> >>>>>>>> defaults.xml - Is that only used by CLI? And not used by >> bin/create >>>>>>>> scripts? >>>>>>>> It was bit unclear to me from the description since both were >>>>> mentioned >>>>>>>> regarding the 2 xml files. >>>>>>>> >>>>>>> >>>>>>> Yes, that's the idea. If you're using the bin/create scripts, then >>>>> there >>>>>> is >>>>>>> a complete "config.xml" file in the template that will be used for >>> your >>>>>> new >>>>>>> app. This is for strict backwards compatibility with anyone's >> workflow >>>>>> that >>>>>>> doesn't currently include CLI. >>>>>>> >>>>>>> If you are using CLI, then we will construct a new config.xml file >> for >>>>>> you >>>>>>> instead, from three sources: defaults.xml, which specifies all of >> the >>>>>>> platform defaults; the various plugin.xml files, and your app's >>>>>> confi
Re: config.xml as a build artifact for less suffering and easier upgrades
I would like to see the defaults be applied in all cases. For consistency, less confusion, and easier documentation. If we add or change the defaults in a release, both workflows should get it. In my mind, the CLI platform config.xml should be equivalent to the bin/create one. -James Jong On Sep 6, 2013, at 11:06 AM, Michal Mocny wrote: > I thought we were adding support for the last bit (ie, app generic not > platform specific preferences) to "app.xml" which the helloworld template > should ship with and bin/create should apply. > > -Michal > > > > On Fri, Sep 6, 2013 at 10:52 AM, Ian Clelland wrote: > >> The template version needs to be a complete config file for the sample app, >> though. You should be able to run bin/create and then build the Hello, >> Cordova app immediately. >> >> defaults.xml is supposed to be stripped right down to just the >> platform-specific options which, in theory, shouldn't need to be specified >> by every app. >> >> At least that's how it works in my head :) The distinction may be less >> important than I'm imagining. >> >> Ian >> >> >> On Fri, Sep 6, 2013 at 9:08 AM, Michal Mocny wrote: >> >>> If the content or format of defaults.xml and the initial config.xml will >> be >>> different then we should ship both -- but I don't think they will be, so >> I >>> think we just ship the template with a defaults file. >>> >>> -Michal >>> >>> >>> On Thu, Sep 5, 2013 at 11:19 PM, Ian Clelland >>> wrote: >>> >>>> On Thu, Sep 5, 2013 at 5:16 PM, James Jong >> wrote: >>>> >>>>> defaults.xml - Is that only used by CLI? And not used by bin/create >>>>> scripts? >>>>> It was bit unclear to me from the description since both were >> mentioned >>>>> regarding the 2 xml files. >>>>> >>>> >>>> Yes, that's the idea. If you're using the bin/create scripts, then >> there >>> is >>>> a complete "config.xml" file in the template that will be used for your >>> new >>>> app. This is for strict backwards compatibility with anyone's workflow >>> that >>>> doesn't currently include CLI. >>>> >>>> If you are using CLI, then we will construct a new config.xml file for >>> you >>>> instead, from three sources: defaults.xml, which specifies all of the >>>> platform defaults; the various plugin.xml files, and your app's >>> config.xml >>>> file. The end-result should be the same, but you have a clear place to >>>> override the defaults for your app that lives outside of your platforms >>>> directory, and the cordova team has a clear place to set those same >>>> defaults. >>>> >>>> Ian >>>> >>>> >>>>> >>>>> The new CLI prepare flow makes sense to me. >>>>> >>>>> -James Jong >>>>> >>>>> On Sep 5, 2013, at 2:21 PM, Michal Mocny >> wrote: >>>>> >>>>>> We briefly discussed JSON and the two thoughts were: >>>>>> >>>>>> (1) We like it, but really what does it buy us? >>>>>> (2) This change is at the moment 100% compatible with all current >>>>> workflows >>>>>> (including upgrades from 3.0->3.1), and we think that's important >> for >>>>>> headache-less adoption. JSON would obviously not be. >>>>>> >>>>>> >>>>>> Regarding where to store the defaults, we had thought it would be a >>>> file >>>>>> bundled with the platform, perhaps in bin/templates? >>>>>> >>>>>> -Michal >>>>>> >>>>>> >>>>>> On Thu, Sep 5, 2013 at 12:38 PM, Brian LeRoux wrote: >>>>>> >>>>>>> The logic flow is much safer in this method. Where do you think >>>>> default.xml >>>>>>> should live? (Maybe it doesn't have to exist and defaults can just >>> be >>>>> vars >>>>>>> in the logic that does the processing?) >>>>>>> >>>>>>> Is this our opportunity to move to JSON? >>>>>>> >>>>>>> >>>>>>> On Thu, Sep 5, 20
Re: What's your daily workflow for cordova development?
+1 create,add/watch workflow , IMO watch would be a nice addition -James Jong On Sep 4, 2013, at 10:46 PM, lmnbeyond wrote: > > >> I also think it should sub-shell to a platform script. We already have >> a `project template` folder in each platform. We can easily add a >> `plugin template` as well and write a quick create_plugin script. >> >> What do you guys think of the workflow I described above ? Any >> comments ? I can create jira issues for it and tackle it. >> >> -a >> > > Hi Anis, > > I just want to confirm whether or not this is the workflow we are talking > about : > > For a brand new plugin: > > $ cordova plugin create /path/to/myPlugin > $ cordova plugin add /path/to/myPlugin --watch > > > For an existing plugin: > > $ cordova plugin add /path/to/corePlugin --watch > > > Although, I'm not quite clear about the complexity behind this, I think the > above workflow is great for me! > > > > > >
Re: plugman / cli verbose by default?
+1 SGTM -James Jong On Sep 6, 2013, at 6:41 PM, Tommy-Carlos Williams wrote: > This. > > +1 > > On 07/09/2013, at 2:57 AM, Brian LeRoux wrote: > >> I think this is reasonable. So, default is 'light logging'. As a module it >> is no logging. As an option it is very verbose java style logging. >> > > > - tommy
Re: config.xml as a build artifact for less suffering and easier upgrades
defaults.xml - Is that only used by CLI? And not used by bin/create scripts? It was bit unclear to me from the description since both were mentioned regarding the 2 xml files. The new CLI prepare flow makes sense to me. -James Jong On Sep 5, 2013, at 2:21 PM, Michal Mocny wrote: > We briefly discussed JSON and the two thoughts were: > > (1) We like it, but really what does it buy us? > (2) This change is at the moment 100% compatible with all current workflows > (including upgrades from 3.0->3.1), and we think that's important for > headache-less adoption. JSON would obviously not be. > > > Regarding where to store the defaults, we had thought it would be a file > bundled with the platform, perhaps in bin/templates? > > -Michal > > > On Thu, Sep 5, 2013 at 12:38 PM, Brian LeRoux wrote: > >> The logic flow is much safer in this method. Where do you think default.xml >> should live? (Maybe it doesn't have to exist and defaults can just be vars >> in the logic that does the processing?) >> >> Is this our opportunity to move to JSON? >> >> >> On Thu, Sep 5, 2013 at 8:21 AM, Braden Shepherdson >> wrote: >> >>> config.xml as a build artifact for less suffering and easier upgrades >>> Terminology >>> >>> - >>> >>> “platform config.xml” refers to the platform-specific config.xml >> files, >>> eg. platforms/android/res/xml/config.xml. This is the final file read >> by >>> Cordova at runtime. >>> - >>> >>> “app config.xml” refers to the top-level config.xml found in >>> www/config.xml. >>> >>> Why the current situation is suffering >>> >>> - >>> >>> Chiefly, the platforms/foo/.../config.xml files are both the input and >>> output of munging by Plugman and the user. This sucks. It makes >>> automatic upgrades difficult because everybody has a customized >>> config.xml >>> file in their platforms. It also makes plugin rm harder and less >> robust >>> in >>> CLI than it needs to be. >>> - >>> >>> Currently only some tags in the app config.xml are actually honoured. >>> Others are ignored, and this has tripped up our users. >>> >>> >>> Goals >>> >>> - >>> >>> bin/create workflow is unchanged. >>> - >>> >>> Final content of the platform config.xml file is unchanged, though the >>> method of building it in the CLI can change. >>> - >>> >>> CLI workflow is unchanged, in terms of what a user types. >>> - >>> >>> platform config.xml stops being both input and output under CLI. Less >>> munging, and easier upgrades. In short, platform config.xml files >> become >>> build artifacts. >>> >>> What we propose to do about it >>> >>> - >>> >>> First, adjust the platform template (used by bin/create) to contain >> two >>> files: >>> - >>> >>> defaults.xml, which is versioned, immutable, and tucked away >>> somewhere (only CLI accesses it) and contains only the >>> Cordova-specified >>> platform defaults, such as the preferences, any default >>> whitelist entries, >>> etc. It does NOT contain any , or other such tags. >>> - >>> >>> platform config.xml, which is the same as it currently is, a >> complete >>> config.xml for the HelloWorld app. This means behavior is unchanged >>> for people who are not using CLI. Plugman still munges this file >> and >>> outputs back to it, same as now. >>> - >>> >>> Second, adjust the CLI’s cordova create template so that its top-level >>> app config.xml contains , , , etc. - tags the >>> user is likely to edit. >>> - >>> >>> Third, modify the CLI so that the new cordova prepare flow is: >>> - >>> >>> Delete the old platform config.xml. >>> - >>> >>> Copy the defaults.xml to config.xml. >>> - >>> >>> Re-run the Plugman config munging for every plugin, modifying the >>> fresh platform config.xml. (The order here is deliberately >> undefined; >>> plugins should already not be relying on this.) >>> - >>> >>> Run the config munging for the app’s config.xml as well. >>> - >>> >>> This results in a freshly built, build-artifact platform >> config.xml. >>> Users should not be editing it; their top-level app config.xml >>> has the last >>> word and will override any settings the defaults or plugins might >>> make. >>> - >>> >>> Note that this means we shouldn’t be needlessly setting defaults >>> in the app config.xml, since this might prevent plugins from >>> changing >>> things that need changing. >>> - >>> >>> Fourth, extend the app config.xml format so that it can have >>> tags, like a plugin.xml. >>> - >>> >>> Into this it can put platform-specific things like splashscreens, >>> preferences and other things, rather than mixing these together in >>> the >>> config. >>> - >>> >>> In particular, it can have tags in the usual format >>> >>
Re: Moving on
Best of luck Fil! Glad to see you'll still be involved with Medic. -James Jong On Aug 30, 2013, at 3:14 PM, Brian LeRoux wrote: > Wherein I wish I could favstar an email. > > Truth hurts Gord! > On Aug 30, 2013 12:13 PM, "Gord Tanner" wrote: > >> Oh that is low Michal ;) >> >> Don't make me walk the 2 blocks to break my foot off in your ass. >> >> >> On Fri, Aug 30, 2013 at 2:58 PM, Michal Mocny wrote: >> >>> Bah! Nonsense! Inconceivable! >>> >>> You will be missed, Fil, but do have fun in your new adventure. >>> >>> Also, speak up more often than Gord here on this lists, will ya? ;) >>> >>> -Michal >>> >>> >>> On Fri, Aug 30, 2013 at 2:50 PM, Max Woghiren wrote: >>> >>>> Best of luck, Fil! >>>> >>>> >>>> On Fri, Aug 30, 2013 at 2:48 PM, Gord Tanner >> wrote: >>>> >>>>> Best of luck dude! >>>>> >>>>> >>>>> On Fri, Aug 30, 2013 at 2:45 PM, Filip Maj >> wrote: >>>>> >>>>>> Sweet, glad there are volunteers willing to take on stuff right >> away! >>>>>> >>>>>> And yes: I've got my phonegapday EU ticket and will be booking >> travel >>>>> this >>>>>> weekend. Hopefully I'll see most of you there! >>>>>> >>>>>> P.S. who's going to lxjs? I'm going to be there along with a few >> good >>>>> folk >>>>>> from the Adobe Cordova team :) >>>>>> >>>>>> >>>>>> On Fri, Aug 30, 2013 at 11:42 AM, Ian Clelland < >> iclell...@google.com >>>> >>>>>> wrote: >>>>>> >>>>>>> Best of luck, Fil! >>>>>>> >>>>>>> Glad to hear you're not stepping away from the project entirely, >>> but >>>>> your >>>>>>> CLI and Plugman efforts will be missed, for sure. >>>>>>> >>>>>>> Will we still see you at PGDay? >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Fri, Aug 30, 2013 at 2:33 PM, Lucas Holmquist < >>>> lholm...@redhat.com >>>>>>>> wrote: >>>>>>> >>>>>>>> good luck dude >>>>>>>> On Aug 30, 2013, at 2:31 PM, Filip Maj >>> wrote: >>>>>>>> >>>>>>>>> Hey everyone, >>>>>>>>> >>>>>>>>> Wanted to let the community know that I'm moving on from >> Adobe. >>>>>> Tuesday >>>>>>>>> I'll be starting at Saucelabs, working on mobile automation >> on >>>> the >>>>>> R&D >>>>>>>> team. >>>>>>>>> >>>>>>>>> My focus is going to shift away from cordova a little bit, >> but >>>> not >>>>>>>>> entirely. My plan is to be involved a lot more in >> cordova-medic >>>>>> moving >>>>>>>>> forward, but stepping away from the tooling (plugman + cli), >>> JS, >>>>> spec >>>>>>> and >>>>>>>>> platform work. >>>>>>>>> >>>>>>>>> As such, I'll be removing myself as "lead" in JIRA on the >>>>> cordovaJS, >>>>>>>>> mobile-spec, cli and plugman components. If any committers >> want >>>> to >>>>>> step >>>>>>>> up >>>>>>>>> and take on a more involved role on those components, I'd >>>> recommend >>>>>>>>> assigning yourself as lead in JIRA to those, that's always an >>>> easy >>>>>> way >>>>>>> to >>>>>>>>> be intimately familiar with issues coming down the pipeline >> :) >>>>>>>>> >>>>>>>>> Looking forward to working more on medic with you all! >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> Fil >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >>
Re: config.xml refactoring
Michal, Yes. That would be a fairly common scenario for non-CLI users. I download a new Cordova version and migrate my app. In the development cycle, I may also want to have different versions of the same app. That could be because of different Cordova versions or even platform versions (iOS 6 vs iOS 7). Even using CLI, I am thinking I may still run multiple versions. Right now, mainly to keep a consistent version across the platforms & plug-ins. Maybe that will go away when we get the versioning strategy figured out. -James Jong On Aug 28, 2013, at 5:09 PM, Michal Mocny wrote: > James, > > I think that sounds like what we've been thinking -- but, why do you expect > to need to copy something when doing an upgrade? Is it because you think > upgrade means re-creating a new workspace (which is kinda true right now)? > We are hoping to support in-place upgrades, with no copies needed. > > -Michal > > > On Wed, Aug 28, 2013 at 4:34 PM, James Jong wrote: > >> I think you have covered the common workflows. Some developers will have >> their own workflow but it should resemble the bin script method in the end. >> >> What I'd like to see is the ability to have my app's user config.xml (1 >> per platform would be fine) and have defaults for what is not specified >> there. The user specified config.xml takes precedence. So when I upgrade, >> I just need to copy over the config.xml. >> >> -James Jong >> >> On Aug 28, 2013, at 2:56 PM, Michal Mocny wrote: >> >>> supporting platforms/ as generated content (aka "build artifact") is >>> certainly an ultimate goal, but only for the CLI workflow, and even then >> we >>> would love to suport fallback to sane actions when users don't see it >> that >>> way and do modify platforms/. >>> >>> Second, a single config.xml shared for all platforms, modified directly >> by >>> the user maybe might be possible (may involve tags or just >>> whitelisted tag per platform), but I'm not sure thats really what we >> want: >>> * Plugins modify it anyway, so its not really the final version >>> * When we upgrade platforms we may want to add/remove/change default >>> values, so its better to separate platform defaults from user explicit >>> choices >>> >>> -Michal >>> >>> On Wed, Aug 28, 2013 at 2:30 PM, Gorkem Ercan >> wrote: >>> >>>> We (JBoss Tools) have been playing with ideas on how to work with >>>> config.xml. One thing we do right now is to have only one config.xml >> file, >>>> we try to treat config.xml as a universal way of defining cordova >>>> applications. We do not have platform versions of config,xml (l think >> cli >>>> massages them per platform right now) but rather copy the config.xml to >>>> platform directory (I guess on CLI this would be at the prepare stage) >> . I >>>> think what the developer works with and what gets deployed in the >>>> application should be same. It prevents any surprises to developer when >>>> he/she is trying to debug a problem. I guess use case/requirement here >> is >>>> not to have config.xml differences between platforms. >>>> >>>> As a note we treat platforms/... directory as generated content (and >>>> regenerate them when needed). >>>> -- >>>> Gorkem >>>> >>>> >>>> On Wed, Aug 28, 2013 at 1:49 PM, Braden Shepherdson < >> bra...@chromium.org >>>>> wrote: >>>> >>>>> So we have several bugs[1][2][3] about fixing the handling of >> config.xml >>>>> and of upgrading CLI projects. Upgrading platforms is hard because the >>>> user >>>>> might have been modifying files in the platforms/foo directory, and we >>>>> don't want to go overwriting them. Most of the time the file that's >> been >>>>> changed is the platform's config.xml. >>>>> >>>>> So we (the Google team) are working on a proposal for rearranging how >> we >>>>> handle config.xml files in order to make upgrades easier, and solving >>>> some >>>>> of these other problems (splash screens) easier. Also to make the CLI >>>>> tooling simpler, because currently the platform config.xml file is both >>>> the >>>>> input and output of several processes (mainly adding and removing >>>> plugins, >>>>> as well as cordova prepare). >>>>> >>>>> What we want to know, in writing this proposal is: what use-cases for >> the >>>>> config.xml files are there? There seem to be two: >>>>> 1. Not using CLI, just bin/create and maybe Plugman. >>>>> 2. Using CLI, and needing to upgrade smoothly from the 3.0 world to 3.1 >>>>> with these changes to the files. >>>>> >>>>> Is there anything else we should be thinking about? If not, we'll have >>>> the >>>>> proposal sent around tomorrow. >>>>> >>>>> >>>>> Braden >>>>> >>>>> [1] https://issues.apache.org/jira/browse/CB-4624 >>>>> [2] https://issues.apache.org/jira/browse/CB-3216 >>>>> [3] https://issues.apache.org/jira/browse/CB-3571 >>>>> >>>> >> >>
Re: AIDE Phonegap - develop cordova apps on android
Yeah, an external keyboard would be needed to make it efficient for me. -James Jong On Aug 28, 2013, at 3:04 PM, Joe Bowser wrote: > I'd use this if i had one of those ASUS Transformer devices. Those > things are awesome! > > On Wed, Aug 28, 2013 at 12:01 PM, Anis KADRI wrote: >> It looks pretty cool. However, not sure if I would use something like >> this as I am completely hopeless when it comes to typing on >> touchscreen devices. It might be good for quick testing/edits. >> >> On Wed, Aug 28, 2013 at 10:33 AM, David Kemp wrote: >>> I have never looked, but it's my understanding that building and running >>> code on an iOS device is not really supported. >>> The part that makes this tool interesting is the edit - compile - run >>> cycle right on the device. >>> On Aug 28, 2013 1:01 PM, "Carlos Santana" wrote: >>> >>>> wow this is mind blowing. >>>> >>>> Do you know if something similar for iOS? >>>> >>>> --Carlos >>>> >>>> >>>> On Wed, Aug 28, 2013 at 11:55 AM, David Kemp wrote: >>>> >>>>> I have used AIDE previously and found it quite fast and handy. >>>>> >>>>> This Phonegap version was released Aug 14th. I bought it on the weekend >>>> to >>>>> see how it stacked up against the previous AIDE offering. Pretty slick >>>>> actually. >>>>> >>>>> https://play.google.com/store/apps/details?id=com.aide.phonegap >>>>> >>>> >>>> >>>> >>>> -- >>>> Carlos Santana >>>> >>>>
Re: config.xml refactoring
I think you have covered the common workflows. Some developers will have their own workflow but it should resemble the bin script method in the end. What I'd like to see is the ability to have my app's user config.xml (1 per platform would be fine) and have defaults for what is not specified there. The user specified config.xml takes precedence. So when I upgrade, I just need to copy over the config.xml. -James Jong On Aug 28, 2013, at 2:56 PM, Michal Mocny wrote: > supporting platforms/ as generated content (aka "build artifact") is > certainly an ultimate goal, but only for the CLI workflow, and even then we > would love to suport fallback to sane actions when users don't see it that > way and do modify platforms/. > > Second, a single config.xml shared for all platforms, modified directly by > the user maybe might be possible (may involve tags or just > whitelisted tag per platform), but I'm not sure thats really what we want: > * Plugins modify it anyway, so its not really the final version > * When we upgrade platforms we may want to add/remove/change default > values, so its better to separate platform defaults from user explicit > choices > > -Michal > > On Wed, Aug 28, 2013 at 2:30 PM, Gorkem Ercan wrote: > >> We (JBoss Tools) have been playing with ideas on how to work with >> config.xml. One thing we do right now is to have only one config.xml file, >> we try to treat config.xml as a universal way of defining cordova >> applications. We do not have platform versions of config,xml (l think cli >> massages them per platform right now) but rather copy the config.xml to >> platform directory (I guess on CLI this would be at the prepare stage) . I >> think what the developer works with and what gets deployed in the >> application should be same. It prevents any surprises to developer when >> he/she is trying to debug a problem. I guess use case/requirement here is >> not to have config.xml differences between platforms. >> >> As a note we treat platforms/... directory as generated content (and >> regenerate them when needed). >> -- >> Gorkem >> >> >> On Wed, Aug 28, 2013 at 1:49 PM, Braden Shepherdson >> wrote: >> >>> So we have several bugs[1][2][3] about fixing the handling of config.xml >>> and of upgrading CLI projects. Upgrading platforms is hard because the >> user >>> might have been modifying files in the platforms/foo directory, and we >>> don't want to go overwriting them. Most of the time the file that's been >>> changed is the platform's config.xml. >>> >>> So we (the Google team) are working on a proposal for rearranging how we >>> handle config.xml files in order to make upgrades easier, and solving >> some >>> of these other problems (splash screens) easier. Also to make the CLI >>> tooling simpler, because currently the platform config.xml file is both >> the >>> input and output of several processes (mainly adding and removing >> plugins, >>> as well as cordova prepare). >>> >>> What we want to know, in writing this proposal is: what use-cases for the >>> config.xml files are there? There seem to be two: >>> 1. Not using CLI, just bin/create and maybe Plugman. >>> 2. Using CLI, and needing to upgrade smoothly from the 3.0 world to 3.1 >>> with these changes to the files. >>> >>> Is there anything else we should be thinking about? If not, we'll have >> the >>> proposal sent around tomorrow. >>> >>> >>> Braden >>> >>> [1] https://issues.apache.org/jira/browse/CB-4624 >>> [2] https://issues.apache.org/jira/browse/CB-3216 >>> [3] https://issues.apache.org/jira/browse/CB-3571 >>> >>
Re: Camera API
Several ways we could go here. One is to improve the documentation. iOS chooses the larger image size. I'm not sure if all the platforms do it the same way. I'd be happy to update the doc if it's all the same. Second is to modify the implementation to only require either W or H. Note that we would break backwards compatibility there. -James Jong On Aug 28, 2013, at 10:16 AM, Ray Camden wrote: > As a user though, that doesn't necessarily make sense. You are saying, > "You must give me a H and W, but I'm going to maintain the aspect ratio no > matter what." Given that, which side is "corrected" if I pass a H and W > that do not maintain the aspect ratio? Do we document it? I've worked on > another platform that provides a way to pass a H and W that act as a > bounding box, so if I use 150x150, my final result will be no bigger than > 150x150, but possibly smaller in order to maintain aspect ratio. If that > is what PG is doing, then the docs should clearly spell that out. Maybe it > is assumed by "Aspect ratio remains constant", but I think it could be > clearer. > > On 8/28/13 9:04 AM, "James Jong" wrote: > >> You're right that it could be calculated based on one or the other. The >> code expects both today. I think the point is to be clear that the >> aspect ratio is maintained, so that the user does not expect to be able >> to arbitrarily set both. >> >> -James Jong >> >> On Aug 28, 2013, at 7:15 AM, John Wargo wrote: >> >>> I've got another silly question. In looking at the Camera API, I see >>> the following: >>> >>> targetWidth: Width in pixels to scale image. Must be used with >>> targetHeight. Aspect ratio remains constant. (Number) >>> >>> targetHeight: Height in pixels to scale image. Must be used with >>> targetWidth. Aspect ratio remains constant. (Number) >>> >>> I'm not getting why targetWidth MUST be used with targetHeight (and >>> visa versa) when aspect ratio remains constant. If aspect ratio remains >>> constant, then setting one automatically forces the other - that's the >>> whole point of maintaining aspect ratio, right? If the API is >>> maintaining aspect ratio while sizing the image, then forcing the >>> developer to specify both parameters is simply wasted work. >>> >>> What am I missing here? >> >
Re: Camera API
You're right that it could be calculated based on one or the other. The code expects both today. I think the point is to be clear that the aspect ratio is maintained, so that the user does not expect to be able to arbitrarily set both. -James Jong On Aug 28, 2013, at 7:15 AM, John Wargo wrote: > I've got another silly question. In looking at the Camera API, I see the > following: > > targetWidth: Width in pixels to scale image. Must be used with targetHeight. > Aspect ratio remains constant. (Number) > > targetHeight: Height in pixels to scale image. Must be used with targetWidth. > Aspect ratio remains constant. (Number) > > I'm not getting why targetWidth MUST be used with targetHeight (and visa > versa) when aspect ratio remains constant. If aspect ratio remains constant, > then setting one automatically forces the other - that's the whole point of > maintaining aspect ratio, right? If the API is maintaining aspect ratio while > sizing the image, then forcing the developer to specify both parameters is > simply wasted work. > > What am I missing here?
Re: iOS 7
I've run mobile-spec on the last few betas without any issues too. There may need to be some adjustments for the transparent status bar. Weclome back Shaz! -James Jong On Aug 27, 2013, at 9:11 AM, Ian Clelland wrote: > I checked out mobile spec yesterday on a couple of iOS 7 devices (beta 3 > and beta 6), running a 6.1-target build as well as a fresh build with the > latest 7 sdk. I didn't see any regressions; all of the auto tests pass, and > the manual tests behave sanely. Some of the UI "felt" less responsive than > I'm used to, but that's entirely unscientific, so I'm going to try to do a > side-by-side comparison today or tomorrow, to see if it's real. > > > On Tuesday, August 27, 2013, Shazron wrote: > >> Thanks! >> >> I re-looked at the API diffs again since its probably close to stable by >> now: >> >> https://developer.apple.com/library/prerelease/ios/releasenotes/General/iOS70APIDiffs/index.html >> >> I see some changes we could do, but not critical: >> >> - CoreTelephony, we can detect what sort of cellular connection is >> available now (Connection core plugin) >> - ImageIO.framework/CGImageMetadata - we can manipulate metadata better now >> (Camera core plugin) >> - UIWebView has various new properties we might need to support to turn >> off/on >> - JavaScriptCore might allow a lot more scenarios for plugin development, >> not sure yet but super minor priority just FYI >> >> >> >> >> On Tue, Aug 27, 2013 at 1:44 AM, Brian LeRoux > >> wrote: >> >>> welcome back mang! >>> >>> >>> On Mon, Aug 26, 2013 at 12:05 AM, Shazron > >> wrote: >>> >>>> Getting back into the saddle after vacation (but at +8GMT not SF time). >>>> >>>> Since Apple already announced a Sep 10 event, it is without a doubt >>>> regarding new phones which means the new iOS release. So since there is >>> not >>>> much time I will focus on that first so there are no surprises, if >> there >>>> are I hope to write workarounds or guidance on how to upgrade etc. >>>> >>> >>
Re: Introduction
Welcome Mark! Great to have you join! -James Jong On Aug 27, 2013, at 12:57 PM, Lorin Beer wrote: > welcome, Mark! > > > On Tue, Aug 27, 2013 at 9:25 AM, Brian LeRoux wrote: > >> Welcome to the battle Mark! >> >> >> On Tue, Aug 27, 2013 at 7:52 AM, Filip Maj wrote: >> >>> Welcome Mark! >>> On 2013-08-27 7:49 AM, "Mark Koudritsky" wrote: >>> >>>> Hi All, >>>> >>>> I just wanted to introduce myself. I'm joining the Cordova team at >>> Google. >>>> So far signed the ICLA, signed up for a JIRA account and got this bug >> to >>>> start from: >>>> https://issues.apache.org/jira/browse/CB-4622 >>>> >>>> My previous project was with the ChromeOS AutoTest lab. >>>> Looking forward to contributing to Cordova. >>>> >>>> - Mark >>>> >>> >>
Re: core APIs and the CLI
I agree. It seems that the 2 should be consistent. -James Jong On Aug 23, 2013, at 8:45 AM, "Wargo, John" wrote: > Thanks. I was simply following the documentation - it's not clear on the file > location I guess. > > John M. Wargo > SAP | Charlotte, NC | USA > Office: +1 704.321.0265 | Mobile: +1 704.249.7476 > Email: john.wa...@sap.com > Twitter: @johnwargo > > > -Original Message- > From: James Jong [mailto:wjamesj...@gmail.com] > Sent: Thursday, August 22, 2013 9:16 PM > To: dev@cordova.apache.org > Subject: Re: core APIs and the CLI > > I believe you are looking at the wrong config.xml file. You should see it > with the plugin feature definitions under the folder. It's a bit > confusing but the one you see under www is just likely copied during prepare > by the CLI from the top-level www. > > -James Jong > > On Aug 22, 2013, at 7:42 PM, John M. Wargo wrote: > >> OK, I just whacked everything and started over. I opened a terminal window >> on Macintosh and issued the following commands: >> >> jmw-mini:~ jwargo$ cd dev >> jmw-mini:dev jwargo$ cordova create test >> jmw-mini:dev jwargo$ cd test >> jmw-mini:test jwargo$ cordova platform add android ios >> jmw-mini:test jwargo$ cordova plugin add >> https://git-wip-us.apache.org/repos/asf/cordova-plugin-camera.git >> jmw-mini:test jwargo$ cordova prepare android >> jmw-mini:test jwargo$ cordova prepare ios >> >> At the end of the process, I looked at the config.xml in the iOS project's >> www folder and found the following: >> >> >> > xmlns="http://www.w3.org/ns/widgets"; >> xmlns:cdv="http://cordova.apache.org/ns/1.0";> >> HelloCordova >> >> A sample Apache Cordova application that responds to the deviceready >> event. >> >> http://cordova.io";> >> Apache Cordova Team >> >> >> >> >> >> >> >> I even went in and forced an update to the config.xml in the cordova >> project's config.xml file and did another cordova prepare. >> >> My changes came over to the config.xml, but no camera entry. >> >> I'm running CLI 3.0.6. >> >> On 8/22/2013 1:46 PM, Ian Clelland wrote: >>> On Thu, Aug 22, 2013 at 11:11 AM, Braden Shepherdson >>> wrote: >>> >>>> Are you sure you ran a "cordova prepare" in both cases? There should be a >>>> tag for Camera on both platforms, as far as I know. >>>> >>>> >>> That was my thinking as well. I checked earlier, and there definitely is a >>> feature tag for iOS. (It's the only tag specified in plugin.xml, and it's >>> the only required change, according to the docs). I don't think plugin add >>> / plugin remove should be manipulating config.xml in the platforms >>> directories -- that should be the job of `cordova prepare`. >>> >>> Ian >>> >>> On Thu, Aug 22, 2013 at 7:46 AM, John Wargo wrote: >>>>> I'm working on the part of my book that deals with the core APIs and I >>>>> need some guidance on how things are supposed to work. >>>>> >>>>> I noticed that if I added the Camera API plugin to a project, that the >>>> CLI >>>>> manages adding the camera feature to the android project's config.xml >>>> file >>>>> in res/xml/config.xml. If I remove the plugin, the settings are removed >>>>> from the config.xml. >>>>> >>>>> The documentation says that a setting is also required for the iOS >>>>> config.xml, but in my testing, the CLI doesn't make that change for me. >>>> The >>>>> Xcode project's config.xml doesn't change as I add and remove the Camera >>>>> plugin. >>>>> >>>>> So am I seeing an anomaly here or is this behavior as expected? I >>>> assumed >>>>> the CLI would take care of everything, but my testing here says >>>> otherwise. >>>>> How's this supposed to work or what must the developer do? It doesn't >>>> make >>>>> sense that the CLI would do this for Android and not iOS. >>>>> >> >
Re: Cordova CLI
Good to know. Thanks Steve. -James Jong On Aug 22, 2013, at 10:14 PM, Steven Gill wrote: > I think Shaz was working on this before he went on vacation. > > > On Thu, Aug 22, 2013 at 7:08 PM, David Kemp wrote: > >> I have not looked at changing the iOS run script. Right now I believe it >> only handles the emulator. >> Medic uses fruitstrap for deployment. No reason it can't be adapted for >> clients run. >> On Aug 22, 2013 1:40 PM, "Ian Clelland" wrote: >> >>> On Thu, Aug 22, 2013 at 11:17 AM, Braden Shepherdson < >> bra...@chromium.org >>>> wrote: >>> >>>> On Thu, Aug 22, 2013 at 9:06 AM, Jan Becicka >>>> wrote: >>>> >>> >>> >>>>> >>>>> * Cordova CLI does not support iOS Devices. (cordova run ios). Are >>> there >>>>> any plans to support it in near future? >>>>> >>>> >>>> Platform parity is a goal for sure. I don't work on iOS much, so I >> can't >>>> speak as to the state and future of cordova run ios support. >>>> >>> >>> I don't know if anyone is working on this specifically right now, but I >>> suspect that something like this could easily shake out of the work that >> is >>> going into the automated build/test system. David can probably speak to >> how >>> easy it will be to get that working as part of CLI. >>> >>> Ian >>> >>
Re: Cordova CLI
Shaz had recently put in a change using ios-deploy (which I believed is based on fruitstrap). He also pointed to another method project that could deploy to ios, so I think we have a couple of options. -James Jong On Aug 22, 2013, at 10:08 PM, David Kemp wrote: > I have not looked at changing the iOS run script. Right now I believe it > only handles the emulator. > Medic uses fruitstrap for deployment. No reason it can't be adapted for > clients run. > On Aug 22, 2013 1:40 PM, "Ian Clelland" wrote: > >> On Thu, Aug 22, 2013 at 11:17 AM, Braden Shepherdson >> wrote: >> >>> On Thu, Aug 22, 2013 at 9:06 AM, Jan Becicka >>> wrote: >>> >> >> >>>> >>>> * Cordova CLI does not support iOS Devices. (cordova run ios). Are >> there >>>> any plans to support it in near future? >>>> >>> >>> Platform parity is a goal for sure. I don't work on iOS much, so I can't >>> speak as to the state and future of cordova run ios support. >>> >> >> I don't know if anyone is working on this specifically right now, but I >> suspect that something like this could easily shake out of the work that is >> going into the automated build/test system. David can probably speak to how >> easy it will be to get that working as part of CLI. >> >> Ian >>
Re: Cordova CLI
I don't see any reason why we wouldn't have a CLI run for iOS. There is already a run script in the current ios repo. -James Jong On Aug 22, 2013, at 1:39 PM, Ian Clelland wrote: > On Thu, Aug 22, 2013 at 11:17 AM, Braden Shepherdson > wrote: > >> On Thu, Aug 22, 2013 at 9:06 AM, Jan Becicka >> wrote: >> > > >>> >>> * Cordova CLI does not support iOS Devices. (cordova run ios). Are there >>> any plans to support it in near future? >>> >> >> Platform parity is a goal for sure. I don't work on iOS much, so I can't >> speak as to the state and future of cordova run ios support. >> > > I don't know if anyone is working on this specifically right now, but I > suspect that something like this could easily shake out of the work that is > going into the automated build/test system. David can probably speak to how > easy it will be to get that working as part of CLI. > > Ian
Re: Post 3.0.0 Releases - Plugins
+1 to specifying plugins via tag/branch/hash. Having master be the stable always felt a bit odd to me. I think once we have the ability to do this, we could set when to bump the version at stable release points. I don't think we should be bumping for every single commit. -James Jong On Aug 22, 2013, at 1:48 PM, Michal Mocny wrote: > I'm concerned about who decides when to bump semver version numbers for > plugins? How do you define a feature, vs a bugfix? > non-backwards-compatible changes are easier to spot, but is a non-user > facing improvement a feature or bugfix, say, an api-compatible perf > improvement? Plugging a stub implementation? Adding error handling? > > Do we bump the version as part of each patch, or do we bump the version > once a week based on the changelog for the week prior? > > -Michal > > > On Mon, Aug 19, 2013 at 2:51 PM, Andrew Grieve wrote: > >> Made an issue for this: https://issues.apache.org/jira/browse/CB-4622 >> >> >> On Mon, Aug 19, 2013 at 9:55 AM, Ian Clelland >> wrote: >> >>> On Mon, Aug 19, 2013 at 9:46 AM, Andrew Grieve >>> wrote: >>> >>>> Yes, sorry for not being clear - this is all entirely about our own >>>> plugins. >>>> >>>> I liked everything you said Jesse. Only reason I'm suggesting dev vs >>> master >>>> is because right now that's how plugman works (pulls from master). If >> we >>>> change plugman to look for a tag (like npm >>>> install<https://npmjs.org/doc/cli/npm-install.html>does), then we can >>>> change our branch structure. >>>> >>> >>> I think this is worth doing -- Jesse's point is valid, that *always* >>> requiring master to be stable imposes a lot on third-party developers. >>> >>> If we can't pull anything but master, then we can't properly depend on >>> specific plugin revisions anyway, so it's going to be useful all around >> to >>> be able to name branches/tags. >>> >>> And then we can decide for core plugins whether it makes sense to have >> the >>> master/dev split, or to do something different. >>> >>> Ian >>> >>> >>>> >>>> On Mon, Aug 19, 2013 at 9:23 AM, Ian Clelland >>>> wrote: >>>> >>>>> On Mon, Aug 19, 2013 at 4:29 AM, Jesse >>> wrote: >>>>> >>>>>> Okay, took me awhile to get this out, I should know better than to >>>>> promise >>>>>> to start a new threads on Friday afternoon. XD >>>>>> >>>>>> Split from 'Releases in a 3.0 World' >>>>>> >>>>>> RE: Pasted => >>>>>> >>>>>>> cordova-plugins: >>>>>>> - Commit only to the `dev` branch >>>>>>> - Use semver for them. >>>>>> ... >>>>> >>>>> I don't think that we should dictate what we expect the community to >> do >>>>>> with their own plugins. Here's some alternative thoughts: >>>>>> >>>>> >>>>> All good ideas, I think. To be fair, though, I think that Andrew's >>>> original >>>>> proposal was specifically about core plugins, and how we version / >>>> release >>>>> those. >>>>> >>>>>> >>>>>> a) versioning is done however the developer of the plugin wants to >> do >>>> it, >>>>>> for core plugins, because they are within our control and we ARE >> 'the >>>>>> developer' we will use semver. >>>>>> >>>>> >>>>> Agreed. See above. >>>>> >>>>> >>>>>> b) plugman needs to gain the ability to install any particular >>> version >>>>> of a >>>>>> plugin, just like a plugin can depend on a specific version of >>> another >>>>>> plugin, we need to be able do this directly. >>>>>> >>>>> >>>>> Probably some kind of standard git url that names both the repo and >> the >>>>> branch / tag. >>>>> >>>>> >>>>>> c) do not enforce the use of a dev branch, master should be >>> considered >>>> a >>>>>> work in progress, we have already had
Re: core APIs and the CLI
I believe you are looking at the wrong config.xml file. You should see it with the plugin feature definitions under the folder. It's a bit confusing but the one you see under www is just likely copied during prepare by the CLI from the top-level www. -James Jong On Aug 22, 2013, at 7:42 PM, John M. Wargo wrote: > OK, I just whacked everything and started over. I opened a terminal window on > Macintosh and issued the following commands: > > jmw-mini:~ jwargo$ cd dev > jmw-mini:dev jwargo$ cordova create test > jmw-mini:dev jwargo$ cd test > jmw-mini:test jwargo$ cordova platform add android ios > jmw-mini:test jwargo$ cordova plugin add > https://git-wip-us.apache.org/repos/asf/cordova-plugin-camera.git > jmw-mini:test jwargo$ cordova prepare android > jmw-mini:test jwargo$ cordova prepare ios > > At the end of the process, I looked at the config.xml in the iOS project's > www folder and found the following: > > > xmlns="http://www.w3.org/ns/widgets"; > xmlns:cdv="http://cordova.apache.org/ns/1.0";> >HelloCordova > >A sample Apache Cordova application that responds to the deviceready > event. > >http://cordova.io";> >Apache Cordova Team > > > > > > > > I even went in and forced an update to the config.xml in the cordova > project's config.xml file and did another cordova prepare. > > My changes came over to the config.xml, but no camera entry. > > I'm running CLI 3.0.6. > > On 8/22/2013 1:46 PM, Ian Clelland wrote: >> On Thu, Aug 22, 2013 at 11:11 AM, Braden Shepherdson >> wrote: >> >>> Are you sure you ran a "cordova prepare" in both cases? There should be a >>> tag for Camera on both platforms, as far as I know. >>> >>> >> That was my thinking as well. I checked earlier, and there definitely is a >> feature tag for iOS. (It's the only tag specified in plugin.xml, and it's >> the only required change, according to the docs). I don't think plugin add >> / plugin remove should be manipulating config.xml in the platforms >> directories -- that should be the job of `cordova prepare`. >> >> Ian >> >> On Thu, Aug 22, 2013 at 7:46 AM, John Wargo wrote: >>>> I'm working on the part of my book that deals with the core APIs and I >>>> need some guidance on how things are supposed to work. >>>> >>>> I noticed that if I added the Camera API plugin to a project, that the >>> CLI >>>> manages adding the camera feature to the android project's config.xml >>> file >>>> in res/xml/config.xml. If I remove the plugin, the settings are removed >>>> from the config.xml. >>>> >>>> The documentation says that a setting is also required for the iOS >>>> config.xml, but in my testing, the CLI doesn't make that change for me. >>> The >>>> Xcode project's config.xml doesn't change as I add and remove the Camera >>>> plugin. >>>> >>>> So am I seeing an anomaly here or is this behavior as expected? I >>> assumed >>>> the CLI would take care of everything, but my testing here says >>> otherwise. >>>> How's this supposed to work or what must the developer do? It doesn't >>> make >>>> sense that the CLI would do this for Android and not iOS. >>>> >
