Re: [cordova-cli] Merges Directory
The naming convention seems confusing also to me especially on big projects. On 3/25/13 10:46 PM, Brian LeRoux b...@brian.io wrote: I'm apprehensive about returning to a naming convention. In a larger app this would lead to a very cluttered dir. The other consideration for ./merges are other assets: icons, and splashscreens. (Which would then require 2x or something for retina/hdpi situations.) On Mon, Mar 25, 2013 at 2:34 PM, Michael Brooks mich...@michaelbrooks.ca wrote: Just like to provide an alternative suggestion to the merges/ directory and here everyone's thoughts. While doing client work at Nitobi, each of our build scripts had similar functionality to merging platform-specific web assets. Below, I'll describe what I've experienced and make a suggestion on an improvement. 1. Separate Merges Directory app |__ merges/ ||__ android/ |__ www/ In the above structure, the android/ directory is a mirror of the www/ directory. When a file exists in the android/ directory, it will replace the file in the www/. I believe this is how the merges/ directory in `cordova-cli` works. I've experienced two main problems with this approach: - difficult to keep track of what files are replaced, since you need to cross-reference between directories - too easy to start developing in the merges/android/ directory instead of www/ 2. Unified Merges Approach app |__ www/ |__ index.html |__ myfile.js |__ myfile.android.js |__ myfolder/ |__ myfolder.android/ I've had much greater success with this approach. When a file ends with a dot platform (optional extension) name (e.g. myfile.android.js), it will be renamed to remove the platform name (e.g. myfile.js). This will work on both files and directories. This makes it extremely easy to keep track of what files and directories are generic or platform specific. I haven't actually noticed any downside to this approach and I used it for 2 years. Thoughts? Michael
Re: [Android] Plugins to send on the ice flows to die
Ah. Then I'll shut up ;) Please don't! The input is appreciated, and the clarification worth mentioning. Mmm ice floes as a canadian, I can vouch for the complete accuracy of everything in that video. Make sure to go see our national igloo on your next visit to downtown Canada! On Mon, Mar 25, 2013 at 10:26 PM, Shazron shaz...@gmail.com wrote: Mmm ice floes (9m21s in): http://www.youtube.com/watch?v=KKh0P9o6y18t=9m21s On Mon, Mar 25, 2013 at 6:02 PM, Tommy-Carlos Williams to...@devgeeks.orgwrote: Ah. Then I'll shut up ;) On 26/03/2013, at 11:56 AM, Filip Maj f...@adobe.com wrote: In this particular case Joe was just speaking about Android. On 3/25/13 5:45 PM, Tommy-Carlos Williams to...@devgeeks.org wrote: RE: GeolocationŠ wouldn't moving to the browser implementation lead to a sub par experience when (as I have mentioned) the end user is asked for permission (in iOS as an example)? I really wouldn't want users of my apps to have a dialog pop up telling them that index.html wants something :) Isn't the Cordova implementation what is making that nicer and allowing for the app to ask for permission? On 26/03/2013, at 3:12 AM, Lorin Beer lorin.beer@gmail.com wrote: +1 for Geolocation Joe's reasoning is convincing: when native functionality exceeds/matches what were providing, what's the point? and a huge +1 for WebSQL, I believe W3C deprecated the spec in November 2011? 2010?! http://www.w3.org/TR/webdatabase/ Being proactive about this and deprecating/removing our own support for this api now strikes me as a far better move than waiting for WebKits to break it. Not to mention the brittleness and exception issues Joe mentioned. On Mon, Mar 25, 2013 at 7:22 AM, Braden Shepherdson bra...@chromium.orgwrote: +1 to killing WebSQL after we have IndexedDB support. It's no longer the standard and only exists in Webkit. The IndexedDB support doesn't exist at all in Android browser or iOS Safari though (a surprise to me, at least), according to caniuse.com[1] It isn't our job to maintain APIs that have been deprecated for a year, though we can keep WebSQL around if we want. Braden On Sun, Mar 24, 2013 at 2:05 PM, Shazron shaz...@gmail.com wrote: It was - but then the draft spec changed, inevitably :) On Sun, Mar 24, 2013 at 9:35 AM, Ken Wallis kwal...@blackberry.com wrote: Thanks Shaz. I had thought that the Cordova Capture API was already based on the Media Capture spec, should have looked closer. ;) Sent from my BlackBerry Z10 smartphone. From: Shazron Sent: Saturday, March 23, 2013 9:20 PM To: dev@cordova.apache.org Reply To: dev@cordova.apache.org Subject: Re: [Android] Plugins to send on the ice flows to die Ken, From here: http://wiki.apache.org/cordova/Core%20API%20Audit It will bring you eventually to here (Media Capture - getusermedia): http://dev.w3.org/2011/webrtc/editor/getusermedia.html and there's also HTML Media Capture: http://www.w3.org/TR/html-media-capture/ On Fri, Mar 22, 2013 at 7:16 PM, Ken Wallis kwal...@blackberry.com wrote: What spec is that? I would like to research that, I was not aware there was a new one. Thanks! Sent from my BlackBerry Z10 smartphone. From: Shazron Sent: Friday, March 22, 2013 8:43 PM To: dev@cordova.apache.org Reply To: dev@cordova.apache.org Subject: Re: [Android] Plugins to send on the ice flows to die Andrew: Capture API. But that's going away I reckon as well (there is a new spec) On Fri, Mar 22, 2013 at 5:29 PM, Andrew Grieve agri...@chromium.org wrote: What's the alternative to Camera? On Fri, Mar 22, 2013 at 6:04 PM, Filip Maj f...@adobe.com wrote: +1 geo and websql deprecation I would wait on camera until we actually do the api audit On 3/22/13 2:54 PM, Joe Bowser bows...@gmail.com wrote: Hey I'm currently looking through the plugins, and I'm thinking more and more that Android has at least two plugins that I would like to see no longer maintained once we break them off of the main repository. Geolocation: --- Our Geolocation doesn't actually give us anything that the browser doesn't do. I think that GPS could be done better, and that the spec sucks. However our core plugins are supposed to follow the spec, and since the browser on Android does this much better, there's no point for this plugin to exist. WebSQL Storage: Our WebSQL storage is pretty brittle and is just a shim to the raw SQLite that Android creates. There's no real exception handling, and this could easily crash. I would like to deprecate this and point people to a third party
Re: [Android] Plugins to send on the ice flows to die
On Mon, Mar 25, 2013 at 12:53 PM, Lorin Beer lorin.beer@gmail.com wrote: Simon, is the concern that users will continue to use WebSQL in Cordova/PhoneGap apps after the polyfill is removed, which will then break on specific releases of Android? Exactly! Simon Mac Donald http://hi.im/simonmacdonald
Re: [windows] Scripts for Windows Phone
Benn, Leave it for now, there are deeper implications to removing it. We can discuss more here once I am back to work. Cheers, Jesse Sent from my iPhone5 On 2013-03-25, at 10:36 PM, Benn Mapes benn.ma...@gmail.com wrote: Yah, the difference is that Windows Phone has multiple of these templates so that's why i wanted to pull the cordova folder it out. Sounds like we're on the same page now so i'll go ahead and do that. On Mon, Mar 25, 2013 at 8:24 PM, Filip Maj f...@adobe.com wrote: Yes sounds good. Most other platforms implement it in this way: - Android's create script [1] uses a templates folder [2] that it makes copies of on-create, which contains (among other things) the cordova folder [3]. - Blackberry does a similar thing [4] - so does iOS [5] [1] https://github.com/apache/cordova-android/blob/master/bin/create#L159 [2] https://github.com/apache/cordova-android/tree/master/bin/templates [3] https://github.com/apache/cordova-android/tree/master/bin/templates/cordova [4] https://github.com/apache/cordova-blackberry/tree/master/bin/templates [5] https://github.com/apache/cordova-ios/tree/master/bin/templates On 3/25/13 5:45 PM, Benn Mapes benn.ma...@gmail.com wrote: I could be reading your responses wrong but, this does not answer my proposal, maybe I wasn't clear enough. For the windows platform there are multiple templates, there is the full template which includes a dll of the cordovaLib(native code) and a standalone template which uses the source code. Right now there cordova folders within each of these containing all the project scripts (when you create a project it will use one of these templates - default is full template). My proposal was to pull the cordova folder out of the templates and put it in one spot so there isn't any duplication of these scripts which will add more consistency. Then when create is called, it will just copy that single cordova folder containing all the scripts into the created project folder. Does that make sense? On Mon, Mar 25, 2013 at 1:48 PM, Filip Maj f...@adobe.com wrote: We already have established spots for scripts. Global scripts: cordova-platform/bin/create cordova-platform/bin/check_reqs (in the works) Project-level scripts: Myapp/cordova Myapp/cordova/lib (soon to come) On 3/25/13 1:38 PM, Benn Mapes benn.ma...@gmail.com wrote: Right now most of the scripts for windows phone except create are in /tooling/scripts/ and there are duplicate cordova folders in each template (/templates/*) folder with the emulate and debug scripts for deploying to emulator/device respectively. In light of the recent scripting discussion I would like to propose moving all the scripts that will go into the cordova folder of a project into /framework/cordova/ (or maybe /tooling/cordova/). This folder can then be copied into a new project when the create command is called. That way we only have one place where all these scripts reside, instead of having a cordova folder for each template. Thoughts?
Re: [windows] Scripts for Windows Phone
[?] On Tue, Mar 26, 2013 at 11:29 AM, Jesse MacFadyen purplecabb...@gmail.comwrote: Benn, Leave it for now, there are deeper implications to removing it. We can discuss more here once I am back to work. Cheers, Jesse Sent from my iPhone5 On 2013-03-25, at 10:36 PM, Benn Mapes benn.ma...@gmail.com wrote: Yah, the difference is that Windows Phone has multiple of these templates so that's why i wanted to pull the cordova folder it out. Sounds like we're on the same page now so i'll go ahead and do that. On Mon, Mar 25, 2013 at 8:24 PM, Filip Maj f...@adobe.com wrote: Yes sounds good. Most other platforms implement it in this way: - Android's create script [1] uses a templates folder [2] that it makes copies of on-create, which contains (among other things) the cordova folder [3]. - Blackberry does a similar thing [4] - so does iOS [5] [1] https://github.com/apache/cordova-android/blob/master/bin/create#L159 [2] https://github.com/apache/cordova-android/tree/master/bin/templates [3] https://github.com/apache/cordova-android/tree/master/bin/templates/cordova [4] https://github.com/apache/cordova-blackberry/tree/master/bin/templates [5] https://github.com/apache/cordova-ios/tree/master/bin/templates On 3/25/13 5:45 PM, Benn Mapes benn.ma...@gmail.com wrote: I could be reading your responses wrong but, this does not answer my proposal, maybe I wasn't clear enough. For the windows platform there are multiple templates, there is the full template which includes a dll of the cordovaLib(native code) and a standalone template which uses the source code. Right now there cordova folders within each of these containing all the project scripts (when you create a project it will use one of these templates - default is full template). My proposal was to pull the cordova folder out of the templates and put it in one spot so there isn't any duplication of these scripts which will add more consistency. Then when create is called, it will just copy that single cordova folder containing all the scripts into the created project folder. Does that make sense? On Mon, Mar 25, 2013 at 1:48 PM, Filip Maj f...@adobe.com wrote: We already have established spots for scripts. Global scripts: cordova-platform/bin/create cordova-platform/bin/check_reqs (in the works) Project-level scripts: Myapp/cordova Myapp/cordova/lib (soon to come) On 3/25/13 1:38 PM, Benn Mapes benn.ma...@gmail.com wrote: Right now most of the scripts for windows phone except create are in /tooling/scripts/ and there are duplicate cordova folders in each template (/templates/*) folder with the emulate and debug scripts for deploying to emulator/device respectively. In light of the recent scripting discussion I would like to propose moving all the scripts that will go into the cordova folder of a project into /framework/cordova/ (or maybe /tooling/cordova/). This folder can then be copied into a new project when the create command is called. That way we only have one place where all these scripts reside, instead of having a cordova folder for each template. Thoughts?
Re: [cordova-cli] Merges Directory
So, what would be better? On Tuesday, March 26, 2013, Giorgio Natili wrote: The naming convention seems confusing also to me especially on big projects. On 3/25/13 10:46 PM, Brian LeRoux b...@brian.io javascript:; wrote: I'm apprehensive about returning to a naming convention. In a larger app this would lead to a very cluttered dir. The other consideration for ./merges are other assets: icons, and splashscreens. (Which would then require 2x or something for retina/hdpi situations.) On Mon, Mar 25, 2013 at 2:34 PM, Michael Brooks mich...@michaelbrooks.ca javascript:; wrote: Just like to provide an alternative suggestion to the merges/ directory and here everyone's thoughts. While doing client work at Nitobi, each of our build scripts had similar functionality to merging platform-specific web assets. Below, I'll describe what I've experienced and make a suggestion on an improvement. 1. Separate Merges Directory app |__ merges/ ||__ android/ |__ www/ In the above structure, the android/ directory is a mirror of the www/ directory. When a file exists in the android/ directory, it will replace the file in the www/. I believe this is how the merges/ directory in `cordova-cli` works. I've experienced two main problems with this approach: - difficult to keep track of what files are replaced, since you need to cross-reference between directories - too easy to start developing in the merges/android/ directory instead of www/ 2. Unified Merges Approach app |__ www/ |__ index.html |__ myfile.js |__ myfile.android.js |__ myfolder/ |__ myfolder.android/ I've had much greater success with this approach. When a file ends with a dot platform (optional extension) name (e.g. myfile.android.js), it will be renamed to remove the platform name (e.g. myfile.js). This will work on both files and directories. This makes it extremely easy to keep track of what files and directories are generic or platform specific. I haven't actually noticed any downside to this approach and I used it for 2 years. Thoughts? Michael
Re: [cordova-cli] Merges Directory
I can see the benefits, but they seem somewhat minor, so I'd prefer the compartmentalization of platform files. If I'm working on a specific platform, I can work in that platform's directory. Having the files spread out in a monolithic directory—especially once an app supports more than a couple of platforms—might get a little cumbersome. On Mon, Mar 25, 2013 at 5:34 PM, Michael Brooks mich...@michaelbrooks.cawrote: Just like to provide an alternative suggestion to the merges/ directory and here everyone's thoughts. While doing client work at Nitobi, each of our build scripts had similar functionality to merging platform-specific web assets. Below, I'll describe what I've experienced and make a suggestion on an improvement. 1. Separate Merges Directory app |__ merges/ ||__ android/ |__ www/ In the above structure, the android/ directory is a mirror of the www/ directory. When a file exists in the android/ directory, it will replace the file in the www/. I believe this is how the merges/ directory in `cordova-cli` works. I've experienced two main problems with this approach: - difficult to keep track of what files are replaced, since you need to cross-reference between directories - too easy to start developing in the merges/android/ directory instead of www/ 2. Unified Merges Approach app |__ www/ |__ index.html |__ myfile.js |__ myfile.android.js |__ myfolder/ |__ myfolder.android/ I've had much greater success with this approach. When a file ends with a dot platform (optional extension) name (e.g. myfile.android.js), it will be renamed to remove the platform name (e.g. myfile.js). This will work on both files and directories. This makes it extremely easy to keep track of what files and directories are generic or platform specific. I haven't actually noticed any downside to this approach and I used it for 2 years. Thoughts? Michael
Re: Plugin Repos Created!
Sounds good to add them - but I'd actually prefer not to encourage contributions until we've at least got one plugin fully working. On Tue, Mar 26, 2013 at 12:18 AM, Brian LeRoux b...@brian.io wrote: Hate to 'make work' but we might want to drop a README in them explaining what is supposed to go there (maybe a link to plugman) and the mailing list before we open those up to speculation. On Mon, Mar 25, 2013 at 7:21 PM, Michael Brooks mich...@michaelbrooks.ca wrote: Would it make sense to add these new repos to the list on http://cordova.apache.org? The intent is to encourage contributions. I'd be fine to do that, but wanted to get a sanity check on that first. I think that makes sense. Originally, we tried to keep platforms on the left column and supporting projects on the right column. It makes sense to have the plugins on the right - hopefully that wouldn't make the site look unbalanced. I know the site is configured to support 3 columns, so we ask our designer to tweak the template if it looks weird. Thanks for volunteering Marcel! On Mon, Mar 25, 2013 at 7:04 PM, Marcel Kinard cmarc...@gmail.com wrote: Would it make sense to add these new repos to the list on http://cordova.apache.org? The intent is to encourage contributions. I'd be fine to do that, but wanted to get a sanity check on that first. -- Marcel On Mar 22, 2013, at 8:54 PM, Andrew Grieve agri...@google.com wrote: https://issues.apache.org/jira/browse/INFRA-5839
Re: Plugin Repos Created!
I'm somewhat agonizing this. On one hand: we need all the help we can get! On the other: its complicated. We need to extract each plugin from their respective native platform, and cordova-js, and then ensure gluing it all together still works. Ideally we start extracting mobile-spec too but maybe thats a little later. I'm thinking we kick up a thread dedicated to prioritizing this. Thoughts? On Tue, Mar 26, 2013 at 8:44 AM, Andrew Grieve agri...@chromium.org wrote: Sounds good to add them - but I'd actually prefer not to encourage contributions until we've at least got one plugin fully working. On Tue, Mar 26, 2013 at 12:18 AM, Brian LeRoux b...@brian.io wrote: Hate to 'make work' but we might want to drop a README in them explaining what is supposed to go there (maybe a link to plugman) and the mailing list before we open those up to speculation. On Mon, Mar 25, 2013 at 7:21 PM, Michael Brooks mich...@michaelbrooks.ca wrote: Would it make sense to add these new repos to the list on http://cordova.apache.org? The intent is to encourage contributions. I'd be fine to do that, but wanted to get a sanity check on that first. I think that makes sense. Originally, we tried to keep platforms on the left column and supporting projects on the right column. It makes sense to have the plugins on the right - hopefully that wouldn't make the site look unbalanced. I know the site is configured to support 3 columns, so we ask our designer to tweak the template if it looks weird. Thanks for volunteering Marcel! On Mon, Mar 25, 2013 at 7:04 PM, Marcel Kinard cmarc...@gmail.com wrote: Would it make sense to add these new repos to the list on http://cordova.apache.org? The intent is to encourage contributions. I'd be fine to do that, but wanted to get a sanity check on that first. -- Marcel On Mar 22, 2013, at 8:54 PM, Andrew Grieve agri...@google.com wrote: https://issues.apache.org/jira/browse/INFRA-5839
Re: [windows] Scripts for Windows Phone
Jesse, while I respect our mutual disdain for the Bruins fan that is Mapes, it would be more helpful for all of us to know those implications so we can help while you're out! On Tue, Mar 26, 2013 at 8:34 AM, Shirley Adams shirleya.fu...@gmail.comwrote: [?] On Tue, Mar 26, 2013 at 11:29 AM, Jesse MacFadyen purplecabb...@gmail.com wrote: Benn, Leave it for now, there are deeper implications to removing it. We can discuss more here once I am back to work. Cheers, Jesse Sent from my iPhone5 On 2013-03-25, at 10:36 PM, Benn Mapes benn.ma...@gmail.com wrote: Yah, the difference is that Windows Phone has multiple of these templates so that's why i wanted to pull the cordova folder it out. Sounds like we're on the same page now so i'll go ahead and do that. On Mon, Mar 25, 2013 at 8:24 PM, Filip Maj f...@adobe.com wrote: Yes sounds good. Most other platforms implement it in this way: - Android's create script [1] uses a templates folder [2] that it makes copies of on-create, which contains (among other things) the cordova folder [3]. - Blackberry does a similar thing [4] - so does iOS [5] [1] https://github.com/apache/cordova-android/blob/master/bin/create#L159 [2] https://github.com/apache/cordova-android/tree/master/bin/templates [3] https://github.com/apache/cordova-android/tree/master/bin/templates/cordova [4] https://github.com/apache/cordova-blackberry/tree/master/bin/templates [5] https://github.com/apache/cordova-ios/tree/master/bin/templates On 3/25/13 5:45 PM, Benn Mapes benn.ma...@gmail.com wrote: I could be reading your responses wrong but, this does not answer my proposal, maybe I wasn't clear enough. For the windows platform there are multiple templates, there is the full template which includes a dll of the cordovaLib(native code) and a standalone template which uses the source code. Right now there cordova folders within each of these containing all the project scripts (when you create a project it will use one of these templates - default is full template). My proposal was to pull the cordova folder out of the templates and put it in one spot so there isn't any duplication of these scripts which will add more consistency. Then when create is called, it will just copy that single cordova folder containing all the scripts into the created project folder. Does that make sense? On Mon, Mar 25, 2013 at 1:48 PM, Filip Maj f...@adobe.com wrote: We already have established spots for scripts. Global scripts: cordova-platform/bin/create cordova-platform/bin/check_reqs (in the works) Project-level scripts: Myapp/cordova Myapp/cordova/lib (soon to come) On 3/25/13 1:38 PM, Benn Mapes benn.ma...@gmail.com wrote: Right now most of the scripts for windows phone except create are in /tooling/scripts/ and there are duplicate cordova folders in each template (/templates/*) folder with the emulate and debug scripts for deploying to emulator/device respectively. In light of the recent scripting discussion I would like to propose moving all the scripts that will go into the cordova folder of a project into /framework/cordova/ (or maybe /tooling/cordova/). This folder can then be copied into a new project when the create command is called. That way we only have one place where all these scripts reside, instead of having a cordova folder for each template. Thoughts?
Re: Plugin Repos Created!
Here is what I suggest: There is no content in those repos now (except for device-motion), not even a README.md. So instead of pointing people to an empty repo, the folks here can do the initial extraction, then we can advertise them and ask for help. The folks skilled at doing the initial extraction are already here on the dev mailing list. So defer advertising the empty plugin repos until they aren't empty. -- Marcel On Mar 26, 2013, at 11:54 AM, Brian LeRoux b...@brian.io wrote: I'm somewhat agonizing this. On one hand: we need all the help we can get! On the other: its complicated. We need to extract each plugin from their respective native platform, and cordova-js, and then ensure gluing it all together still works. Ideally we start extracting mobile-spec too but maybe thats a little later. I'm thinking we kick up a thread dedicated to prioritizing this. Thoughts? On Tue, Mar 26, 2013 at 8:44 AM, Andrew Grieve agri...@chromium.org wrote: Sounds good to add them - but I'd actually prefer not to encourage contributions until we've at least got one plugin fully working. On Tue, Mar 26, 2013 at 12:18 AM, Brian LeRoux b...@brian.io wrote: Hate to 'make work' but we might want to drop a README in them explaining what is supposed to go there (maybe a link to plugman) and the mailing list before we open those up to speculation. On Mon, Mar 25, 2013 at 7:21 PM, Michael Brooks mich...@michaelbrooks.ca wrote: Would it make sense to add these new repos to the list on http://cordova.apache.org? The intent is to encourage contributions. I'd be fine to do that, but wanted to get a sanity check on that first. I think that makes sense. Originally, we tried to keep platforms on the left column and supporting projects on the right column. It makes sense to have the plugins on the right - hopefully that wouldn't make the site look unbalanced. I know the site is configured to support 3 columns, so we ask our designer to tweak the template if it looks weird. Thanks for volunteering Marcel! On Mon, Mar 25, 2013 at 7:04 PM, Marcel Kinard cmarc...@gmail.com wrote: Would it make sense to add these new repos to the list on http://cordova.apache.org? The intent is to encourage contributions. I'd be fine to do that, but wanted to get a sanity check on that first. -- Marcel On Mar 22, 2013, at 8:54 PM, Andrew Grieve agri...@google.com wrote: https://issues.apache.org/jira/browse/INFRA-5839
Re: Plugin Repos Created!
Hello. Although I'm new to Appache... I've been programming since the 1980s.. I've always found foo much information can slow the programming process down.. so I agree with Andrew Grieves... best to get thins up and running. Thanks. Shirley On Tue, Mar 26, 2013 at 11:54 AM, Brian LeRoux b...@brian.io wrote: I'm somewhat agonizing this. On one hand: we need all the help we can get! On the other: its complicated. We need to extract each plugin from their respective native platform, and cordova-js, and then ensure gluing it all together still works. Ideally we start extracting mobile-spec too but maybe thats a little later. I'm thinking we kick up a thread dedicated to prioritizing this. Thoughts? On Tue, Mar 26, 2013 at 8:44 AM, Andrew Grieve agri...@chromium.org wrote: Sounds good to add them - but I'd actually prefer not to encourage contributions until we've at least got one plugin fully working. On Tue, Mar 26, 2013 at 12:18 AM, Brian LeRoux b...@brian.io wrote: Hate to 'make work' but we might want to drop a README in them explaining what is supposed to go there (maybe a link to plugman) and the mailing list before we open those up to speculation. On Mon, Mar 25, 2013 at 7:21 PM, Michael Brooks mich...@michaelbrooks.ca wrote: Would it make sense to add these new repos to the list on http://cordova.apache.org? The intent is to encourage contributions. I'd be fine to do that, but wanted to get a sanity check on that first. I think that makes sense. Originally, we tried to keep platforms on the left column and supporting projects on the right column. It makes sense to have the plugins on the right - hopefully that wouldn't make the site look unbalanced. I know the site is configured to support 3 columns, so we ask our designer to tweak the template if it looks weird. Thanks for volunteering Marcel! On Mon, Mar 25, 2013 at 7:04 PM, Marcel Kinard cmarc...@gmail.com wrote: Would it make sense to add these new repos to the list on http://cordova.apache.org? The intent is to encourage contributions. I'd be fine to do that, but wanted to get a sanity check on that first. -- Marcel On Mar 22, 2013, at 8:54 PM, Andrew Grieve agri...@google.com wrote: https://issues.apache.org/jira/browse/INFRA-5839
Re: [cordova-cli] Merges Directory
As a heads up, I'm not trying to sell the naming convention approach. Simply, I've used both approaches for multiple projects between 2009-2012. I've found the merges/ to become confusing, error prone, and encouraging a platform-specific coding mindset. I can see the benefits, but they seem somewhat minor, so I'd prefer the compartmentalization of platform files. If I'm working on a specific platform, I can work in that platform's directory. Having the files spread out in a monolithic directory—especially once an app supports more than a couple of platforms—might get a little cumbersome. Arguments for or against either approach can usually be countered, because they solve the exact same problem. The main difference is organization and being able to quickly eyeball whether a given file/folder will be replaced by a platform-specific one. This important when you a generic www/ file that is overwritten by only one platform. Too many times, I've edited the generic file only to realize that there was also a platform-specific implementation of it. The other consideration for ./merges are other assets: icons, and splashscreens. (Which would then require 2x or something for retina/hdpi situations.) The platform resource problem should not be solved with the merges directory. The config.xml parser should move the platform's resources and delete the other platforms' resources. Michael On Tue, Mar 26, 2013 at 8:36 AM, Max Woghiren m...@chromium.org wrote: I can see the benefits, but they seem somewhat minor, so I'd prefer the compartmentalization of platform files. If I'm working on a specific platform, I can work in that platform's directory. Having the files spread out in a monolithic directory—especially once an app supports more than a couple of platforms—might get a little cumbersome. On Mon, Mar 25, 2013 at 5:34 PM, Michael Brooks mich...@michaelbrooks.ca wrote: Just like to provide an alternative suggestion to the merges/ directory and here everyone's thoughts. While doing client work at Nitobi, each of our build scripts had similar functionality to merging platform-specific web assets. Below, I'll describe what I've experienced and make a suggestion on an improvement. 1. Separate Merges Directory app |__ merges/ ||__ android/ |__ www/ In the above structure, the android/ directory is a mirror of the www/ directory. When a file exists in the android/ directory, it will replace the file in the www/. I believe this is how the merges/ directory in `cordova-cli` works. I've experienced two main problems with this approach: - difficult to keep track of what files are replaced, since you need to cross-reference between directories - too easy to start developing in the merges/android/ directory instead of www/ 2. Unified Merges Approach app |__ www/ |__ index.html |__ myfile.js |__ myfile.android.js |__ myfolder/ |__ myfolder.android/ I've had much greater success with this approach. When a file ends with a dot platform (optional extension) name (e.g. myfile.android.js), it will be renamed to remove the platform name (e.g. myfile.js). This will work on both files and directories. This makes it extremely easy to keep track of what files and directories are generic or platform specific. I haven't actually noticed any downside to this approach and I used it for 2 years. Thoughts? Michael
Re: App-Harness Description
Looks great Andrew. I'd add Ripple and device mirroring as part of this. (More than one device navigates in concert.) What is this thing going to be called? cordova-app-harness sounds kinky. On Mon, Mar 25, 2013 at 5:59 PM, Andrew Grieve agri...@chromium.org wrote: Hey Michael (and anyone else interested), I've written up a requirements doc for this: https://docs.google.com/document/d/14LG1IiEiQ9npc2RmPo5_UEKQTfsg-3ivJu7R2iPBmsw/edit?usp=sharing It's a bit biased towards hosting Chrome Apps, but I think the majority of the app will be generic. The chrome bits will be implemented as a combination of extra plugins that are installed in, and some UI tweaks. Would definitely love feedback to know if this describes the same type of thing you were thinking of. Shravan will likely be starting on this this week.
Re: device motion plugin
Unfortunate as we thought 2.6 was realistic a few weeks ago but I echo the sentiment. Too soon! Going to kick up a fresh thread on JS. On Mon, Mar 25, 2013 at 4:05 PM, Shazron shaz...@gmail.com wrote: I don't think it should go in for 2.6.0 as well, for the already mentioned reasons. On Mon, Mar 25, 2013 at 3:38 PM, Andrew Grieve agri...@chromium.org wrote: I feel pretty strongly that we shouldn't try to shove this in for 2.6.0. Regressions only at this point (since the branches have been cut). Excited to see progress here though! by namespace - are you referring to Java namespaces? or plugin IDs? To answer your question about the JS, refer to this thread: http://callback.markmail.org/thread/vxmd3yrr5i5q27w3 On Mon, Mar 25, 2013 at 6:14 PM, Steven Gill stevengil...@gmail.com wrote: Hey All, Last week I did some work around pulling out the Accelerometer plugin from the cordova-android code and setting up how the plugin repo would look. I have gone ahead and pushed my work onto the newly created device motion repo ( https://git-wip-us.apache.org/repos/asf?p=cordova-plugin-device-motion.git;a=summary ). A couple questions have arisen from this work: 1) How are we handling the JS? I assume we will be pulling it out of cordova.js and packaging it with the plugin. 2) How are we namespacing the plugins? core.name vs name.name? A discussion about this was happening in a earlier thread. ( http://callback.markmail.org/message/pbeovtkzi3a2tfkw?q=list:org%2Eapache%2Eincubator%2Ecallback-dev+moving+plugins+to+core+namespace ). Once we come to a consensus about these two questions, I can start ripping out more plugins from cordova-android and start populating our new plugin repos. Durring releases, I would just run plugman to include the api back into the release (tests required). I am going to work with Shaz this week to rip out the Accel plugin from iOS and get it setup on the same repo. I know there was some talk about ripping out this plugin for 2.6.0 release. How do you guys feel about this? 2.6.0 is schedule to go out end of this week? Cheers, -Steve
Welcome to our new committers!
Just wanted to send out a quick congratulatory note to the public dev list. We've voted in four new committers in the past week or two, I'm very excited about this! Don Coleman, Max Woghiren, James Jong, and Tommy Carlos-Williams: welcome, stoked to have you folks join, and congratulations!
[plugman] js install
Steve has plugman working with devicemotion plugin. Happy days! Its time he ripped the JS out of cordova-js and put it in the plugin. But does plugman support js installation? What needs happening to make it so?
Re: Plugin Repos Created!
sounds good On Tue, Mar 26, 2013 at 9:02 AM, Marcel Kinard cmarc...@gmail.com wrote: Here is what I suggest: There is no content in those repos now (except for device-motion), not even a README.md. So instead of pointing people to an empty repo, the folks here can do the initial extraction, then we can advertise them and ask for help. The folks skilled at doing the initial extraction are already here on the dev mailing list. So defer advertising the empty plugin repos until they aren't empty. -- Marcel On Mar 26, 2013, at 11:54 AM, Brian LeRoux b...@brian.io wrote: I'm somewhat agonizing this. On one hand: we need all the help we can get! On the other: its complicated. We need to extract each plugin from their respective native platform, and cordova-js, and then ensure gluing it all together still works. Ideally we start extracting mobile-spec too but maybe thats a little later. I'm thinking we kick up a thread dedicated to prioritizing this. Thoughts? On Tue, Mar 26, 2013 at 8:44 AM, Andrew Grieve agri...@chromium.org wrote: Sounds good to add them - but I'd actually prefer not to encourage contributions until we've at least got one plugin fully working. On Tue, Mar 26, 2013 at 12:18 AM, Brian LeRoux b...@brian.io wrote: Hate to 'make work' but we might want to drop a README in them explaining what is supposed to go there (maybe a link to plugman) and the mailing list before we open those up to speculation. On Mon, Mar 25, 2013 at 7:21 PM, Michael Brooks mich...@michaelbrooks.ca wrote: Would it make sense to add these new repos to the list on http://cordova.apache.org? The intent is to encourage contributions. I'd be fine to do that, but wanted to get a sanity check on that first. I think that makes sense. Originally, we tried to keep platforms on the left column and supporting projects on the right column. It makes sense to have the plugins on the right - hopefully that wouldn't make the site look unbalanced. I know the site is configured to support 3 columns, so we ask our designer to tweak the template if it looks weird. Thanks for volunteering Marcel! On Mon, Mar 25, 2013 at 7:04 PM, Marcel Kinard cmarc...@gmail.com wrote: Would it make sense to add these new repos to the list on http://cordova.apache.org? The intent is to encourage contributions. I'd be fine to do that, but wanted to get a sanity check on that first. -- Marcel On Mar 22, 2013, at 8:54 PM, Andrew Grieve agri...@google.com wrote: https://issues.apache.org/jira/browse/INFRA-5839
Re: App-Harness Description
Hey Andrew, This is exactly what I had planned as well. It's as if we read each other's minds. I'll go through the document a second time and add some comments. Do you mind if I edit the document? What is this thing going to be called? cordova-app-harness sounds kinky. For naming, my stance has been the Cordova App. There is no reason to make it complicated. If the app stores, users would install Cordova. If you think this is confusing users with downloading the Cordova framework (which they sort of are), then call it Cordova DX (DX is developer experience). Michael On Tue, Mar 26, 2013 at 9:06 AM, Brian LeRoux b...@brian.io wrote: Looks great Andrew. I'd add Ripple and device mirroring as part of this. (More than one device navigates in concert.) What is this thing going to be called? cordova-app-harness sounds kinky. On Mon, Mar 25, 2013 at 5:59 PM, Andrew Grieve agri...@chromium.org wrote: Hey Michael (and anyone else interested), I've written up a requirements doc for this: https://docs.google.com/document/d/14LG1IiEiQ9npc2RmPo5_UEKQTfsg-3ivJu7R2iPBmsw/edit?usp=sharing It's a bit biased towards hosting Chrome Apps, but I think the majority of the app will be generic. The chrome bits will be implemented as a combination of extra plugins that are installed in, and some UI tweaks. Would definitely love feedback to know if this describes the same type of thing you were thinking of. Shravan will likely be starting on this this week.
Re: [plugman] js install
Use the future branch of plugman. That's where braden is putting the symbol mapping work into. On 3/26/13 9:09 AM, Brian LeRoux b...@brian.io wrote: Steve has plugman working with devicemotion plugin. Happy days! Its time he ripped the JS out of cordova-js and put it in the plugin. But does plugman support js installation? What needs happening to make it so?
Re: Welcome to our new committers!
\o/ On Tue, Mar 26, 2013 at 9:08 AM, Filip Maj f...@adobe.com wrote: Just wanted to send out a quick congratulatory note to the public dev list. We've voted in four new committers in the past week or two, I'm very excited about this! Don Coleman, Max Woghiren, James Jong, and Tommy Carlos-Williams: welcome, stoked to have you folks join, and congratulations!
Re: Welcome to our new committers!
Congratulations! On Tue, Mar 26, 2013 at 12:27 PM, Brian LeRoux b...@brian.io wrote: \o/ On Tue, Mar 26, 2013 at 9:08 AM, Filip Maj f...@adobe.com wrote: Just wanted to send out a quick congratulatory note to the public dev list. We've voted in four new committers in the past week or two, I'm very excited about this! Don Coleman, Max Woghiren, James Jong, and Tommy Carlos-Williams: welcome, stoked to have you folks join, and congratulations!
Re: [plugman] js install
You'll need the future branch of cordova-cli and plugman, and to go through a bit of a dance to get those two installed and npm linked properly. The dance is as follows: cd plugman npm install sudo npm link cd ../cordova-cli npm install sudo npm link npm link plugman Now when you run 'cordova' you get the git version, and 'plugman' likewise. You can skip everything after the first three lines if you're only using plugman and not CLI. Note that the master branch is currently broken with cordova-js 2.6.0; you'll have to use the future branch. Unfortunately that branch is under heavy development right now, but I'm trying to keep it in a working state. Braden On Tue, Mar 26, 2013 at 12:16 PM, Filip Maj f...@adobe.com wrote: Use the future branch of plugman. That's where braden is putting the symbol mapping work into. On 3/26/13 9:09 AM, Brian LeRoux b...@brian.io wrote: Steve has plugman working with devicemotion plugin. Happy days! Its time he ripped the JS out of cordova-js and put it in the plugin. But does plugman support js installation? What needs happening to make it so?
Re: App-Harness Description
Awesome! Yep - it's editable so that you can edit it :) I like Cordova DX, or maybe Cordova DevTool On Tue, Mar 26, 2013 at 12:10 PM, Michael Brooks mich...@michaelbrooks.cawrote: Hey Andrew, This is exactly what I had planned as well. It's as if we read each other's minds. I'll go through the document a second time and add some comments. Do you mind if I edit the document? What is this thing going to be called? cordova-app-harness sounds kinky. For naming, my stance has been the Cordova App. There is no reason to make it complicated. If the app stores, users would install Cordova. If you think this is confusing users with downloading the Cordova framework (which they sort of are), then call it Cordova DX (DX is developer experience). Michael On Tue, Mar 26, 2013 at 9:06 AM, Brian LeRoux b...@brian.io wrote: Looks great Andrew. I'd add Ripple and device mirroring as part of this. (More than one device navigates in concert.) What is this thing going to be called? cordova-app-harness sounds kinky. On Mon, Mar 25, 2013 at 5:59 PM, Andrew Grieve agri...@chromium.org wrote: Hey Michael (and anyone else interested), I've written up a requirements doc for this: https://docs.google.com/document/d/14LG1IiEiQ9npc2RmPo5_UEKQTfsg-3ivJu7R2iPBmsw/edit?usp=sharing It's a bit biased towards hosting Chrome Apps, but I think the majority of the app will be generic. The chrome bits will be implemented as a combination of extra plugins that are installed in, and some UI tweaks. Would definitely love feedback to know if this describes the same type of thing you were thinking of. Shravan will likely be starting on this this week.
Re: Welcome to our new committers!
Yes! Awesome to have you all on the team! http://www.youtube.com/watch?v=KMU0tzLwhbE On Tue, Mar 26, 2013 at 12:31 PM, Braden Shepherdson bra...@chromium.orgwrote: Congratulations! On Tue, Mar 26, 2013 at 12:27 PM, Brian LeRoux b...@brian.io wrote: \o/ On Tue, Mar 26, 2013 at 9:08 AM, Filip Maj f...@adobe.com wrote: Just wanted to send out a quick congratulatory note to the public dev list. We've voted in four new committers in the past week or two, I'm very excited about this! Don Coleman, Max Woghiren, James Jong, and Tommy Carlos-Williams: welcome, stoked to have you folks join, and congratulations!
Re: InAppBrowser support on BlackBerry Windows Phone
The first email said that the docs say it does, but Andrew wanted to confirm (not sure what had him questioning the docs). -Michal On Mon, Mar 25, 2013 at 7:20 PM, Jesse MacFadyen purplecabb...@gmail.comwrote: The docs should be a strong suggestion as well. Cheers, Jesse Sent from my iPhone5 On 2013-03-25, at 4:05 PM, Shazron shaz...@gmail.com wrote: I think Jesse is away - but: 1. https://github.com/apache/cordova-wp8/commit/d9bd6abece9821201b2784799337430d29247035 2. https://github.com/apache/cordova-wp7/commit/2a94c1279d929191857ebb2fefca00359823d3ea ... seems to suggest it is supported on WP7 and WP8. On Mon, Mar 25, 2013 at 3:27 PM, Andrew Grieve agri...@chromium.org wrote: Awesome. So the docs should be updated to say that BB supports close(). Jesse - do you know if WP supports IAB? On Mon, Mar 25, 2013 at 5:33 PM, Tim Kim timki...@gmail.com wrote: Ok, I just checked on my blackberry z10. The close() function works but not events. It seems like there might be a way to get events working - I can get a reference to the object that window.open returns that includes the loadstart/loadstop/loaderror events, but can't get them to fire. On 23 March 2013 12:11, Tim Kim timki...@gmail.com wrote: Hrm, not sure. I'll have to check on monday on device. On 23 March 2013 11:11, Andrew Grieve agri...@google.com wrote: bump On Wed, Mar 20, 2013 at 4:16 PM, Andrew Grieve agri...@google.com wrote: The docs: http://cordova.apache.org/docs/en/edge/cordova_inappbrowser_inappbrowser.md.html#InAppBrowser 1. Say that Blackberry does not support events, nor the close() function 2. Say that windowsphone 7 8 support IAB. Are both of these statements correct? I don't see IAB in the WP JS... -- Timothy Kim -- Timothy Kim
Re: Welcome to our new committers!
Welcome to the team! On Tue, Mar 26, 2013 at 9:41 AM, Andrew Grieve agri...@chromium.org wrote: Yes! Awesome to have you all on the team! http://www.youtube.com/watch?v=KMU0tzLwhbE On Tue, Mar 26, 2013 at 12:31 PM, Braden Shepherdson bra...@chromium.org wrote: Congratulations! On Tue, Mar 26, 2013 at 12:27 PM, Brian LeRoux b...@brian.io wrote: \o/ On Tue, Mar 26, 2013 at 9:08 AM, Filip Maj f...@adobe.com wrote: Just wanted to send out a quick congratulatory note to the public dev list. We've voted in four new committers in the past week or two, I'm very excited about this! Don Coleman, Max Woghiren, James Jong, and Tommy Carlos-Williams: welcome, stoked to have you folks join, and congratulations!
Re: App-Harness Description
Heh, DX sounds *very* Adobe. (Remember Flash MX?) Meanwhile Devtool sounds very Google. Either way I like both more than calling it a harness. ;) On Tue, Mar 26, 2013 at 9:39 AM, Andrew Grieve agri...@chromium.org wrote: Awesome! Yep - it's editable so that you can edit it :) I like Cordova DX, or maybe Cordova DevTool On Tue, Mar 26, 2013 at 12:10 PM, Michael Brooks mich...@michaelbrooks.ca wrote: Hey Andrew, This is exactly what I had planned as well. It's as if we read each other's minds. I'll go through the document a second time and add some comments. Do you mind if I edit the document? What is this thing going to be called? cordova-app-harness sounds kinky. For naming, my stance has been the Cordova App. There is no reason to make it complicated. If the app stores, users would install Cordova. If you think this is confusing users with downloading the Cordova framework (which they sort of are), then call it Cordova DX (DX is developer experience). Michael On Tue, Mar 26, 2013 at 9:06 AM, Brian LeRoux b...@brian.io wrote: Looks great Andrew. I'd add Ripple and device mirroring as part of this. (More than one device navigates in concert.) What is this thing going to be called? cordova-app-harness sounds kinky. On Mon, Mar 25, 2013 at 5:59 PM, Andrew Grieve agri...@chromium.org wrote: Hey Michael (and anyone else interested), I've written up a requirements doc for this: https://docs.google.com/document/d/14LG1IiEiQ9npc2RmPo5_UEKQTfsg-3ivJu7R2iPBmsw/edit?usp=sharing It's a bit biased towards hosting Chrome Apps, but I think the majority of the app will be generic. The chrome bits will be implemented as a combination of extra plugins that are installed in, and some UI tweaks. Would definitely love feedback to know if this describes the same type of thing you were thinking of. Shravan will likely be starting on this this week.
Re: [plugman] js install
Braden: whats happening in cordova-js that is broken/being heavily refactored? On Tue, Mar 26, 2013 at 9:36 AM, Braden Shepherdson bra...@chromium.org wrote: You'll need the future branch of cordova-cli and plugman, and to go through a bit of a dance to get those two installed and npm linked properly. The dance is as follows: cd plugman npm install sudo npm link cd ../cordova-cli npm install sudo npm link npm link plugman Now when you run 'cordova' you get the git version, and 'plugman' likewise. You can skip everything after the first three lines if you're only using plugman and not CLI. Note that the master branch is currently broken with cordova-js 2.6.0; you'll have to use the future branch. Unfortunately that branch is under heavy development right now, but I'm trying to keep it in a working state. Braden On Tue, Mar 26, 2013 at 12:16 PM, Filip Maj f...@adobe.com wrote: Use the future branch of plugman. That's where braden is putting the symbol mapping work into. On 3/26/13 9:09 AM, Brian LeRoux b...@brian.io wrote: Steve has plugman working with devicemotion plugin. Happy days! Its time he ripped the JS out of cordova-js and put it in the plugin. But does plugman support js installation? What needs happening to make it so?
Re: Welcome to our new committers!
Welcome! Now get back to work :) On Tue, Mar 26, 2013 at 12:50 PM, Michael Brooks mich...@michaelbrooks.cawrote: Welcome to the team! On Tue, Mar 26, 2013 at 9:41 AM, Andrew Grieve agri...@chromium.org wrote: Yes! Awesome to have you all on the team! http://www.youtube.com/watch?v=KMU0tzLwhbE On Tue, Mar 26, 2013 at 12:31 PM, Braden Shepherdson bra...@chromium.org wrote: Congratulations! On Tue, Mar 26, 2013 at 12:27 PM, Brian LeRoux b...@brian.io wrote: \o/ On Tue, Mar 26, 2013 at 9:08 AM, Filip Maj f...@adobe.com wrote: Just wanted to send out a quick congratulatory note to the public dev list. We've voted in four new committers in the past week or two, I'm very excited about this! Don Coleman, Max Woghiren, James Jong, and Tommy Carlos-Williams: welcome, stoked to have you folks join, and congratulations!
Re: App-Harness Description
I like the kinky version. On Tue, Mar 26, 2013 at 12:52 PM, Brian LeRoux b...@brian.io wrote: Heh, DX sounds *very* Adobe. (Remember Flash MX?) Meanwhile Devtool sounds very Google. Either way I like both more than calling it a harness. ;) On Tue, Mar 26, 2013 at 9:39 AM, Andrew Grieve agri...@chromium.org wrote: Awesome! Yep - it's editable so that you can edit it :) I like Cordova DX, or maybe Cordova DevTool On Tue, Mar 26, 2013 at 12:10 PM, Michael Brooks mich...@michaelbrooks.ca wrote: Hey Andrew, This is exactly what I had planned as well. It's as if we read each other's minds. I'll go through the document a second time and add some comments. Do you mind if I edit the document? What is this thing going to be called? cordova-app-harness sounds kinky. For naming, my stance has been the Cordova App. There is no reason to make it complicated. If the app stores, users would install Cordova. If you think this is confusing users with downloading the Cordova framework (which they sort of are), then call it Cordova DX (DX is developer experience). Michael On Tue, Mar 26, 2013 at 9:06 AM, Brian LeRoux b...@brian.io wrote: Looks great Andrew. I'd add Ripple and device mirroring as part of this. (More than one device navigates in concert.) What is this thing going to be called? cordova-app-harness sounds kinky. On Mon, Mar 25, 2013 at 5:59 PM, Andrew Grieve agri...@chromium.org wrote: Hey Michael (and anyone else interested), I've written up a requirements doc for this: https://docs.google.com/document/d/14LG1IiEiQ9npc2RmPo5_UEKQTfsg-3ivJu7R2iPBmsw/edit?usp=sharing It's a bit biased towards hosting Chrome Apps, but I think the majority of the app will be generic. The chrome bits will be implemented as a combination of extra plugins that are installed in, and some UI tweaks. Would definitely love feedback to know if this describes the same type of thing you were thinking of. Shravan will likely be starting on this this week.
Re: App-Harness Description
[?] On Tue, Mar 26, 2013 at 1:03 PM, Michal Mocny mmo...@chromium.org wrote: I like the kinky version. On Tue, Mar 26, 2013 at 12:52 PM, Brian LeRoux b...@brian.io wrote: Heh, DX sounds *very* Adobe. (Remember Flash MX?) Meanwhile Devtool sounds very Google. Either way I like both more than calling it a harness. ;) On Tue, Mar 26, 2013 at 9:39 AM, Andrew Grieve agri...@chromium.org wrote: Awesome! Yep - it's editable so that you can edit it :) I like Cordova DX, or maybe Cordova DevTool On Tue, Mar 26, 2013 at 12:10 PM, Michael Brooks mich...@michaelbrooks.ca wrote: Hey Andrew, This is exactly what I had planned as well. It's as if we read each other's minds. I'll go through the document a second time and add some comments. Do you mind if I edit the document? What is this thing going to be called? cordova-app-harness sounds kinky. For naming, my stance has been the Cordova App. There is no reason to make it complicated. If the app stores, users would install Cordova. If you think this is confusing users with downloading the Cordova framework (which they sort of are), then call it Cordova DX (DX is developer experience). Michael On Tue, Mar 26, 2013 at 9:06 AM, Brian LeRoux b...@brian.io wrote: Looks great Andrew. I'd add Ripple and device mirroring as part of this. (More than one device navigates in concert.) What is this thing going to be called? cordova-app-harness sounds kinky. On Mon, Mar 25, 2013 at 5:59 PM, Andrew Grieve agri...@chromium.org wrote: Hey Michael (and anyone else interested), I've written up a requirements doc for this: https://docs.google.com/document/d/14LG1IiEiQ9npc2RmPo5_UEKQTfsg-3ivJu7R2iPBmsw/edit?usp=sharing It's a bit biased towards hosting Chrome Apps, but I think the majority of the app will be generic. The chrome bits will be implemented as a combination of extra plugins that are installed in, and some UI tweaks. Would definitely love feedback to know if this describes the same type of thing you were thinking of. Shravan will likely be starting on this this week.
Re: [plugman] js install
I added the plugin-loading code there (see scripts/plugin_loader.js) but I wasn't aware that XHRs to file:// URLs always have status 0 instead of 200/404/etc. Andrew fixed that today, but we decided not to try to cherry-pick that change into 2.6.x. It's harmless for the main function of cordova-js, but it means that the future branch of the CLI tools won't work with the released 2.6. Braden On Tue, Mar 26, 2013 at 12:57 PM, Brian LeRoux b...@brian.io wrote: Braden: whats happening in cordova-js that is broken/being heavily refactored? On Tue, Mar 26, 2013 at 9:36 AM, Braden Shepherdson bra...@chromium.org wrote: You'll need the future branch of cordova-cli and plugman, and to go through a bit of a dance to get those two installed and npm linked properly. The dance is as follows: cd plugman npm install sudo npm link cd ../cordova-cli npm install sudo npm link npm link plugman Now when you run 'cordova' you get the git version, and 'plugman' likewise. You can skip everything after the first three lines if you're only using plugman and not CLI. Note that the master branch is currently broken with cordova-js 2.6.0; you'll have to use the future branch. Unfortunately that branch is under heavy development right now, but I'm trying to keep it in a working state. Braden On Tue, Mar 26, 2013 at 12:16 PM, Filip Maj f...@adobe.com wrote: Use the future branch of plugman. That's where braden is putting the symbol mapping work into. On 3/26/13 9:09 AM, Brian LeRoux b...@brian.io wrote: Steve has plugman working with devicemotion plugin. Happy days! Its time he ripped the JS out of cordova-js and put it in the plugin. But does plugman support js installation? What needs happening to make it so?
Re: App-Harness Description
cordova-kink PROS: would probably get lots of downloads in the app store CONS: would probably not get accepted into the app store On Tue, Mar 26, 2013 at 10:03 AM, Michal Mocny mmo...@chromium.org wrote: I like the kinky version. On Tue, Mar 26, 2013 at 12:52 PM, Brian LeRoux b...@brian.io wrote: Heh, DX sounds *very* Adobe. (Remember Flash MX?) Meanwhile Devtool sounds very Google. Either way I like both more than calling it a harness. ;) On Tue, Mar 26, 2013 at 9:39 AM, Andrew Grieve agri...@chromium.org wrote: Awesome! Yep - it's editable so that you can edit it :) I like Cordova DX, or maybe Cordova DevTool On Tue, Mar 26, 2013 at 12:10 PM, Michael Brooks mich...@michaelbrooks.ca wrote: Hey Andrew, This is exactly what I had planned as well. It's as if we read each other's minds. I'll go through the document a second time and add some comments. Do you mind if I edit the document? What is this thing going to be called? cordova-app-harness sounds kinky. For naming, my stance has been the Cordova App. There is no reason to make it complicated. If the app stores, users would install Cordova. If you think this is confusing users with downloading the Cordova framework (which they sort of are), then call it Cordova DX (DX is developer experience). Michael On Tue, Mar 26, 2013 at 9:06 AM, Brian LeRoux b...@brian.io wrote: Looks great Andrew. I'd add Ripple and device mirroring as part of this. (More than one device navigates in concert.) What is this thing going to be called? cordova-app-harness sounds kinky. On Mon, Mar 25, 2013 at 5:59 PM, Andrew Grieve agri...@chromium.org wrote: Hey Michael (and anyone else interested), I've written up a requirements doc for this: https://docs.google.com/document/d/14LG1IiEiQ9npc2RmPo5_UEKQTfsg-3ivJu7R2iPBmsw/edit?usp=sharing It's a bit biased towards hosting Chrome Apps, but I think the majority of the app will be generic. The chrome bits will be implemented as a combination of extra plugins that are installed in, and some UI tweaks. Would definitely love feedback to know if this describes the same type of thing you were thinking of. Shravan will likely be starting on this this week.
Mobile Spec File Tests Query string
Hey guys, In file.tests.js, line 267: https://github.com/apache/cordova-mobile-spec/blob/master/autotest/tests/file.tests.js#L267 there is a URI passed to resolveLocalFileSystemURI with a query string appended to the end. The test is meant to return a valid entry. BB7 and BB10 currently flunk the test, returning with an Invalid Symbol type error. I checked the iOS handling of this: https://github.com/apache/cordova-ios/blob/master/CordovaLib/Classes/CDVFile.m#L218 and the query string is stripped out with the call to NSUrl path. Questions: 1. what's the point of the test? Just to test handling of valid URI with syntactically but semantically meaningless query string? 2. is there any purpose to a query string on a URI mean to be resolved to a file path? Just want to understand this fully before implementing the handling on BB
Re: Moving www into an app folder
I'm into this proposal fwiw too. Think we need to get plugman/jsinstall/plugins for all things covered before we tread back into CLI land. On Mon, Mar 25, 2013 at 3:44 PM, Michal Mocny mmo...@chromium.org wrote: Thanks Fil. Theres a long list of feature requests we've just pushed on y'all so I understand. On Mon, Mar 25, 2013 at 6:31 PM, Filip Maj f...@adobe.com wrote: Not at all, I think it would be a great feature to land. Agree that specifying dependencies in the app manifest, config.xml currently, is the way to go. I'm trying to organize the goal/direction of moving to this approach in my head together with all the other moves we are making. Keeping the objectives high level and working on iterating to reach those objectives is what I want to keep clear in my mind. On 3/25/13 3:22 PM, Michal Mocny mmo...@chromium.org wrote: Precisely! I thought plugin dependancies for apps was already on the roadmap. Is that request still debatable? On Mon, Mar 25, 2013 at 6:01 PM, Braden Shepherdson bra...@chromium.orgwrote: I agree that this recreation is a goal, but I don't think moving plugins/ under app/ is the right way to do it. I think the right way to do it is to specify the plugin dependencies of the app in app/. Currently that means in the documentation or a script, in the future probably in config.xml. Braden On Mon, Mar 25, 2013 at 4:09 PM, Filip Maj f...@adobe.com wrote: I think the issue here is: how far do we want to dictate the project structure for a cordova-cli-generated app? Merges kind of evolved out of an actual user who needed a viable use case covered (thanks Michael Wolf!). It is where it is for really no reason other than this is a good feature to have. Consider it like a first pass at an implementation. We can iterate on it to make it better. One thing about the app/ proposal is that the stated objective is to enable shipping a single directory to be able to recreate the native projects. If that is the case, wouldn't we also have to move the plugins into app/ ? On 3/25/13 11:25 AM, Braden Shepherdson bra...@chromium.org wrote: They are, right now, a kind of middle ground. If you rm -rf'd the directory, it wouldn't be all better on the next cordova prepare; that's where we hope to reach soon. On the other hand, you definitely shouldn't be having code in them - native or otherwise - that didn't come from a plugin or from www/. So they could be reconstructed from data stored elsewhere, which makes them mostly a build artifact, and certainly not necessary to store in your source control. Braden On Mon, Mar 25, 2013 at 2:17 PM, Brian LeRoux b...@brian.io wrote: While this might be our goal it is in no way true that ./platforms ia build artifact today or anytime soon. On Mon, Mar 25, 2013 at 10:55 AM, Braden Shepherdson bra...@chromium.org wrote: The same is /not/ true of the current structure, because one (probably) doesn't want to be committing build artifacts like platforms/, or cached third-party data like plugins/ into your git repo. The idea here is that everything under app/ is what you would keep in git for a team working on an app: www, config.xml, docs, samples, etc. Putting that content at the top-level instead means you have lots of extra build artifact cruft in your git repo, or your devs just have to know that platforms/ and plugins/ are in .gitignore. Braden On Mon, Mar 25, 2013 at 1:45 PM, Brian LeRoux b...@brian.io wrote: But, if you go up one level, the same is true w/ the current structure. Its just an organizational difference? (Thats a perfectly ok answer of course. Aesthetics and symmetry are plenty convincing arguments.) In my view ./merges isn't your app. The ./merges dir is in parts of your app on a per platform basis. Hence the logic for having it exist at the same level as ./platforms. Having config.xml exist in the ../www does bother me. On Mon, Mar 25, 2013 at 10:33 AM, Braden Shepherdson bra...@chromium.org wrote: It allows easier cloning of your app (meaning the www, config.xml, and any samples and so on) into a self-contained directory. It also lets us keep the user's app within a single top-level directory (rather than www and merges and potentially more later). Because only the www (and merges) would get pulled into the actual app, any docs, samples, tests, or other miscellany in the git repo won't be part of the app. On Mon, Mar 25, 2013 at 1:19 PM, Brian LeRoux b...@brian.io wrote: Ok, let me try again. What is precisely problem we are solving by changing the structure? To be
Re: Welcome to our new committers!
Congratulations! On Tue, Mar 26, 2013 at 9:59 AM, Michal Mocny mmo...@chromium.org wrote: Welcome! Now get back to work :) On Tue, Mar 26, 2013 at 12:50 PM, Michael Brooks mich...@michaelbrooks.cawrote: Welcome to the team! On Tue, Mar 26, 2013 at 9:41 AM, Andrew Grieve agri...@chromium.org wrote: Yes! Awesome to have you all on the team! http://www.youtube.com/watch?v=KMU0tzLwhbE On Tue, Mar 26, 2013 at 12:31 PM, Braden Shepherdson bra...@chromium.org wrote: Congratulations! On Tue, Mar 26, 2013 at 12:27 PM, Brian LeRoux b...@brian.io wrote: \o/ On Tue, Mar 26, 2013 at 9:08 AM, Filip Maj f...@adobe.com wrote: Just wanted to send out a quick congratulatory note to the public dev list. We've voted in four new committers in the past week or two, I'm very excited about this! Don Coleman, Max Woghiren, James Jong, and Tommy Carlos-Williams: welcome, stoked to have you folks join, and congratulations!
Re: [cordova-cli] versioning
Ok. I really like Mike's proposal. Think we should do this. Its solves most of our woe. Slight caveat that I would like the cache to be in the format of: ~/.cordova/thing/name/version (To prevent weird string splitting logic/bugs emerging.) Fil: can you backlog this? I think it should come AFTER we finish fixing up plugman/jsinstall and at least one plugin xplatform done. On Mon, Mar 25, 2013 at 3:26 PM, Michael Brooks mich...@michaelbrooks.ca wrote: With respect to the lazy-loading suggestion, I know Brian has raised the offline scenario on a previous thread. At install time of the CLI (`npm install -g cordova`), we can lazy-load all platforms and sample app(s) for a given version. At install time of the CLI as a library (`npm install cordova`), we can not lazy-load the platforms. This allows other distributions (e.g. `phonegap-cli`) to not be forced to download a large number of unnecessary files. Michael On Mon, Mar 25, 2013 at 3:18 PM, Filip Maj f...@adobe.com wrote: Really like this. It a) slims down the cli tools by lazy loading the libraries as they are needed and b) solves the upgrade/downgrade story, since eventually you'll be able to simply change the version of the cordova npm dependency at a project-level. The only downside (not really) is that every generated cordova-cli project now is implicitly an npm project as it needs a package.json at the top-level. On 3/25/13 11:06 AM, Michael Brooks mich...@michaelbrooks.ca wrote: +1 to locking the CLI to a version +1 to the Grunt vision However, I'd like to propose a different approach to the CLI versioning and it can also solve the `create` command issue to help move towards a dumb global `cordova`. ## Cordova-CLI - npm version is still associated with a Cordova distribution - Cordova-CLI does not vendor the Cordova distribution - Adding a platform will lazy load the platform distribution into ~/.cordova/platform/name-version/ - We can lazy load by downloading a gzip from the Apache Git web server - Next time the platform is needed, it is copied from ~/.cordova/platform/name-version/ ## Cordova Create - Creating an app should be a lazy load of the Hello World app - Cached in ~/.cordova/app/name-version/ - We can update the Hello World app to match a standard Cordova CLI project - Now the global Cordova CLI is a dumb tool - On create: lazy loading or copying the hello world app - On project command: shelling to ./node_modules/bin/cordova command On Fri, Mar 22, 2013 at 1:08 PM, Filip Maj f...@adobe.com wrote: As Tommay pointed out, you need to create the cordova project structure in the first place with some manner of tool.. On 3/22/13 11:58 AM, tommy-carlos Williams to...@devgeeks.org wrote: I don't have much to add except that I really like this about Grunt. However, it would get interesting with Cordova since the global is what creates a project in the first place. I still think it could work and have the global only responsible for creating dirs and setting up package.json stuff etc... +1 for looking into this. On 23/03/2013, at 4:53, Brian LeRoux b...@brian.io wrote: Right now the global executable is version locked to a Cordova release. If you have a project running 2.5 you are required to have Cordova/CLI 2.5. If you need to then work in Cordova 2.4 you need to downgrade (not really but you would to be safe). In Grunt .4 the global executable is dumb. It just shells to locally installed ./node_module version of Grunt. This enables project level versioning of Grunt. Nice feature. We can do the same thing: with the caveat that you would then require a package.json and ./node_modules folder in our Cordova projects. Discuss.
Re: [plugman] js install
fuckin eh, sounds awesome---thx man On Tue, Mar 26, 2013 at 10:14 AM, Braden Shepherdson bra...@chromium.org wrote: I added the plugin-loading code there (see scripts/plugin_loader.js) but I wasn't aware that XHRs to file:// URLs always have status 0 instead of 200/404/etc. Andrew fixed that today, but we decided not to try to cherry-pick that change into 2.6.x. It's harmless for the main function of cordova-js, but it means that the future branch of the CLI tools won't work with the released 2.6. Braden On Tue, Mar 26, 2013 at 12:57 PM, Brian LeRoux b...@brian.io wrote: Braden: whats happening in cordova-js that is broken/being heavily refactored? On Tue, Mar 26, 2013 at 9:36 AM, Braden Shepherdson bra...@chromium.org wrote: You'll need the future branch of cordova-cli and plugman, and to go through a bit of a dance to get those two installed and npm linked properly. The dance is as follows: cd plugman npm install sudo npm link cd ../cordova-cli npm install sudo npm link npm link plugman Now when you run 'cordova' you get the git version, and 'plugman' likewise. You can skip everything after the first three lines if you're only using plugman and not CLI. Note that the master branch is currently broken with cordova-js 2.6.0; you'll have to use the future branch. Unfortunately that branch is under heavy development right now, but I'm trying to keep it in a working state. Braden On Tue, Mar 26, 2013 at 12:16 PM, Filip Maj f...@adobe.com wrote: Use the future branch of plugman. That's where braden is putting the symbol mapping work into. On 3/26/13 9:09 AM, Brian LeRoux b...@brian.io wrote: Steve has plugman working with devicemotion plugin. Happy days! Its time he ripped the JS out of cordova-js and put it in the plugin. But does plugman support js installation? What needs happening to make it so?
Re: Welcome to our new committers!
O yeah and welcome Lorin Beer too :P On 3/26/13 10:21 AM, Lorin Beer lorin.beer@gmail.com wrote: Congratulations! On Tue, Mar 26, 2013 at 9:59 AM, Michal Mocny mmo...@chromium.org wrote: Welcome! Now get back to work :) On Tue, Mar 26, 2013 at 12:50 PM, Michael Brooks mich...@michaelbrooks.cawrote: Welcome to the team! On Tue, Mar 26, 2013 at 9:41 AM, Andrew Grieve agri...@chromium.org wrote: Yes! Awesome to have you all on the team! http://www.youtube.com/watch?v=KMU0tzLwhbE On Tue, Mar 26, 2013 at 12:31 PM, Braden Shepherdson bra...@chromium.org wrote: Congratulations! On Tue, Mar 26, 2013 at 12:27 PM, Brian LeRoux b...@brian.io wrote: \o/ On Tue, Mar 26, 2013 at 9:08 AM, Filip Maj f...@adobe.com wrote: Just wanted to send out a quick congratulatory note to the public dev list. We've voted in four new committers in the past week or two, I'm very excited about this! Don Coleman, Max Woghiren, James Jong, and Tommy Carlos-Williams: welcome, stoked to have you folks join, and congratulations!
Re: Mobile Spec File Tests Query string
I'm pretty sure the test simply follows the spec.. Which I can't find (where the f is resolvelocalfilesystemuri spec'ed?) On 3/26/13 10:18 AM, Lorin Beer lorin.beer@gmail.com wrote: Hey guys, In file.tests.js, line 267: https://github.com/apache/cordova-mobile-spec/blob/master/autotest/tests/f ile.tests.js#L267 there is a URI passed to resolveLocalFileSystemURI with a query string appended to the end. The test is meant to return a valid entry. BB7 and BB10 currently flunk the test, returning with an Invalid Symbol type error. I checked the iOS handling of this: https://github.com/apache/cordova-ios/blob/master/CordovaLib/Classes/CDVFi le.m#L218 and the query string is stripped out with the call to NSUrl path. Questions: 1. what's the point of the test? Just to test handling of valid URI with syntactically but semantically meaningless query string? 2. is there any purpose to a query string on a URI mean to be resolved to a file path? Just want to understand this fully before implementing the handling on BB
Re: [cordova-cli] versioning
Yep, on it, and agree. One thing, though: cordova-cli currently runs up the file tree searching for '.cordova' to identify a cordova-cli-generated project root (like git). Can we rename the cache folder to something other than .cordova? .cordovalibs or something? On 3/26/13 10:22 AM, Brian LeRoux b...@brian.io wrote: Ok. I really like Mike's proposal. Think we should do this. Its solves most of our woe. Slight caveat that I would like the cache to be in the format of: ~/.cordova/thing/name/version (To prevent weird string splitting logic/bugs emerging.) Fil: can you backlog this? I think it should come AFTER we finish fixing up plugman/jsinstall and at least one plugin xplatform done. On Mon, Mar 25, 2013 at 3:26 PM, Michael Brooks mich...@michaelbrooks.ca wrote: With respect to the lazy-loading suggestion, I know Brian has raised the offline scenario on a previous thread. At install time of the CLI (`npm install -g cordova`), we can lazy-load all platforms and sample app(s) for a given version. At install time of the CLI as a library (`npm install cordova`), we can not lazy-load the platforms. This allows other distributions (e.g. `phonegap-cli`) to not be forced to download a large number of unnecessary files. Michael On Mon, Mar 25, 2013 at 3:18 PM, Filip Maj f...@adobe.com wrote: Really like this. It a) slims down the cli tools by lazy loading the libraries as they are needed and b) solves the upgrade/downgrade story, since eventually you'll be able to simply change the version of the cordova npm dependency at a project-level. The only downside (not really) is that every generated cordova-cli project now is implicitly an npm project as it needs a package.json at the top-level. On 3/25/13 11:06 AM, Michael Brooks mich...@michaelbrooks.ca wrote: +1 to locking the CLI to a version +1 to the Grunt vision However, I'd like to propose a different approach to the CLI versioning and it can also solve the `create` command issue to help move towards a dumb global `cordova`. ## Cordova-CLI - npm version is still associated with a Cordova distribution - Cordova-CLI does not vendor the Cordova distribution - Adding a platform will lazy load the platform distribution into ~/.cordova/platform/name-version/ - We can lazy load by downloading a gzip from the Apache Git web server - Next time the platform is needed, it is copied from ~/.cordova/platform/name-version/ ## Cordova Create - Creating an app should be a lazy load of the Hello World app - Cached in ~/.cordova/app/name-version/ - We can update the Hello World app to match a standard Cordova CLI project - Now the global Cordova CLI is a dumb tool - On create: lazy loading or copying the hello world app - On project command: shelling to ./node_modules/bin/cordova command On Fri, Mar 22, 2013 at 1:08 PM, Filip Maj f...@adobe.com wrote: As Tommay pointed out, you need to create the cordova project structure in the first place with some manner of tool.. On 3/22/13 11:58 AM, tommy-carlos Williams to...@devgeeks.org wrote: I don't have much to add except that I really like this about Grunt. However, it would get interesting with Cordova since the global is what creates a project in the first place. I still think it could work and have the global only responsible for creating dirs and setting up package.json stuff etc... +1 for looking into this. On 23/03/2013, at 4:53, Brian LeRoux b...@brian.io wrote: Right now the global executable is version locked to a Cordova release. If you have a project running 2.5 you are required to have Cordova/CLI 2.5. If you need to then work in Cordova 2.4 you need to downgrade (not really but you would to be safe). In Grunt .4 the global executable is dumb. It just shells to locally installed ./node_module version of Grunt. This enables project level versioning of Grunt. Nice feature. We can do the same thing: with the caveat that you would then require a package.json and ./node_modules folder in our Cordova projects. Discuss.
Re: Welcome to our new committers!
oh sure, just throw me on at the end :) You owe me a beer, Fil. On Tue, Mar 26, 2013 at 10:22 AM, Filip Maj f...@adobe.com wrote: O yeah and welcome Lorin Beer too :P On 3/26/13 10:21 AM, Lorin Beer lorin.beer@gmail.com wrote: Congratulations! On Tue, Mar 26, 2013 at 9:59 AM, Michal Mocny mmo...@chromium.org wrote: Welcome! Now get back to work :) On Tue, Mar 26, 2013 at 12:50 PM, Michael Brooks mich...@michaelbrooks.cawrote: Welcome to the team! On Tue, Mar 26, 2013 at 9:41 AM, Andrew Grieve agri...@chromium.org wrote: Yes! Awesome to have you all on the team! http://www.youtube.com/watch?v=KMU0tzLwhbE On Tue, Mar 26, 2013 at 12:31 PM, Braden Shepherdson bra...@chromium.org wrote: Congratulations! On Tue, Mar 26, 2013 at 12:27 PM, Brian LeRoux b...@brian.io wrote: \o/ On Tue, Mar 26, 2013 at 9:08 AM, Filip Maj f...@adobe.com wrote: Just wanted to send out a quick congratulatory note to the public dev list. We've voted in four new committers in the past week or two, I'm very excited about this! Don Coleman, Max Woghiren, James Jong, and Tommy Carlos-Williams: welcome, stoked to have you folks join, and congratulations!
Re: App-Harness Description
haha, so Harness it is? ;) On Tue, Mar 26, 2013 at 10:17 AM, Brian LeRoux b...@brian.io wrote: cordova-kink PROS: would probably get lots of downloads in the app store CONS: would probably not get accepted into the app store On Tue, Mar 26, 2013 at 10:03 AM, Michal Mocny mmo...@chromium.org wrote: I like the kinky version. On Tue, Mar 26, 2013 at 12:52 PM, Brian LeRoux b...@brian.io wrote: Heh, DX sounds *very* Adobe. (Remember Flash MX?) Meanwhile Devtool sounds very Google. Either way I like both more than calling it a harness. ;) On Tue, Mar 26, 2013 at 9:39 AM, Andrew Grieve agri...@chromium.org wrote: Awesome! Yep - it's editable so that you can edit it :) I like Cordova DX, or maybe Cordova DevTool On Tue, Mar 26, 2013 at 12:10 PM, Michael Brooks mich...@michaelbrooks.ca wrote: Hey Andrew, This is exactly what I had planned as well. It's as if we read each other's minds. I'll go through the document a second time and add some comments. Do you mind if I edit the document? What is this thing going to be called? cordova-app-harness sounds kinky. For naming, my stance has been the Cordova App. There is no reason to make it complicated. If the app stores, users would install Cordova. If you think this is confusing users with downloading the Cordova framework (which they sort of are), then call it Cordova DX (DX is developer experience). Michael On Tue, Mar 26, 2013 at 9:06 AM, Brian LeRoux b...@brian.io wrote: Looks great Andrew. I'd add Ripple and device mirroring as part of this. (More than one device navigates in concert.) What is this thing going to be called? cordova-app-harness sounds kinky. On Mon, Mar 25, 2013 at 5:59 PM, Andrew Grieve agri...@chromium.org wrote: Hey Michael (and anyone else interested), I've written up a requirements doc for this: https://docs.google.com/document/d/14LG1IiEiQ9npc2RmPo5_UEKQTfsg-3ivJu7R2iPBmsw/edit?usp=sharing It's a bit biased towards hosting Chrome Apps, but I think the majority of the app will be generic. The chrome bits will be implemented as a combination of extra plugins that are installed in, and some UI tweaks. Would definitely love feedback to know if this describes the same type of thing you were thinking of. Shravan will likely be starting on this this week.
Re: Mobile Spec File Tests Query string
yeah, couldn't track that down either? Anyone? Paging resolveLocalFileSystemURI spec? the W3 spec has resolveLocalFileSystemURL only http://www.w3.org/TR/file-system-api/#widl-LocalFileSystem-resolveLocalFileSystemURL-void-DOMString-url-EntryCallback-successCallback-ErrorCallback-errorCallback On Tue, Mar 26, 2013 at 10:23 AM, Filip Maj f...@adobe.com wrote: I'm pretty sure the test simply follows the spec.. Which I can't find (where the f is resolvelocalfilesystemuri spec'ed?) On 3/26/13 10:18 AM, Lorin Beer lorin.beer@gmail.com wrote: Hey guys, In file.tests.js, line 267: https://github.com/apache/cordova-mobile-spec/blob/master/autotest/tests/f ile.tests.js#L267 there is a URI passed to resolveLocalFileSystemURI with a query string appended to the end. The test is meant to return a valid entry. BB7 and BB10 currently flunk the test, returning with an Invalid Symbol type error. I checked the iOS handling of this: https://github.com/apache/cordova-ios/blob/master/CordovaLib/Classes/CDVFi le.m#L218 and the query string is stripped out with the call to NSUrl path. Questions: 1. what's the point of the test? Just to test handling of valid URI with syntactically but semantically meaningless query string? 2. is there any purpose to a query string on a URI mean to be resolved to a file path? Just want to understand this fully before implementing the handling on BB
Re: Welcome to our new committers!
Congrats! More committers! On Tue, Mar 26, 2013 at 10:25 AM, Lorin Beer lorin.beer@gmail.comwrote: oh sure, just throw me on at the end :) You owe me a beer, Fil. On Tue, Mar 26, 2013 at 10:22 AM, Filip Maj f...@adobe.com wrote: O yeah and welcome Lorin Beer too :P On 3/26/13 10:21 AM, Lorin Beer lorin.beer@gmail.com wrote: Congratulations! On Tue, Mar 26, 2013 at 9:59 AM, Michal Mocny mmo...@chromium.org wrote: Welcome! Now get back to work :) On Tue, Mar 26, 2013 at 12:50 PM, Michael Brooks mich...@michaelbrooks.cawrote: Welcome to the team! On Tue, Mar 26, 2013 at 9:41 AM, Andrew Grieve agri...@chromium.org wrote: Yes! Awesome to have you all on the team! http://www.youtube.com/watch?v=KMU0tzLwhbE On Tue, Mar 26, 2013 at 12:31 PM, Braden Shepherdson bra...@chromium.org wrote: Congratulations! On Tue, Mar 26, 2013 at 12:27 PM, Brian LeRoux b...@brian.io wrote: \o/ On Tue, Mar 26, 2013 at 9:08 AM, Filip Maj f...@adobe.com wrote: Just wanted to send out a quick congratulatory note to the public dev list. We've voted in four new committers in the past week or two, I'm very excited about this! Don Coleman, Max Woghiren, James Jong, and Tommy Carlos-Williams: welcome, stoked to have you folks join, and congratulations!
Re: Mobile Spec File Tests Query string
O that¹s the one! On 3/26/13 10:29 AM, Lorin Beer lorin.beer@gmail.com wrote: yeah, couldn't track that down either? Anyone? Paging resolveLocalFileSystemURI spec? the W3 spec has resolveLocalFileSystemURL only http://www.w3.org/TR/file-system-api/#widl-LocalFileSystem-resolveLocalFi leSystemURL-void-DOMString-url-EntryCallback-successCallback-ErrorCallback -errorCallback On Tue, Mar 26, 2013 at 10:23 AM, Filip Maj f...@adobe.com wrote: I'm pretty sure the test simply follows the spec.. Which I can't find (where the f is resolvelocalfilesystemuri spec'ed?) On 3/26/13 10:18 AM, Lorin Beer lorin.beer@gmail.com wrote: Hey guys, In file.tests.js, line 267: https://github.com/apache/cordova-mobile-spec/blob/master/autotest/tests/ f ile.tests.js#L267 there is a URI passed to resolveLocalFileSystemURI with a query string appended to the end. The test is meant to return a valid entry. BB7 and BB10 currently flunk the test, returning with an Invalid Symbol type error. I checked the iOS handling of this: https://github.com/apache/cordova-ios/blob/master/CordovaLib/Classes/CDVF i le.m#L218 and the query string is stripped out with the call to NSUrl path. Questions: 1. what's the point of the test? Just to test handling of valid URI with syntactically but semantically meaningless query string? 2. is there any purpose to a query string on a URI mean to be resolved to a file path? Just want to understand this fully before implementing the handling on BB
Re: Moving www into an app folder
I like this proposal too :-P On Tue, Mar 26, 2013 at 10:19 AM, Brian LeRoux b...@brian.io wrote: I'm into this proposal fwiw too. Think we need to get plugman/jsinstall/plugins for all things covered before we tread back into CLI land. On Mon, Mar 25, 2013 at 3:44 PM, Michal Mocny mmo...@chromium.org wrote: Thanks Fil. Theres a long list of feature requests we've just pushed on y'all so I understand. On Mon, Mar 25, 2013 at 6:31 PM, Filip Maj f...@adobe.com wrote: Not at all, I think it would be a great feature to land. Agree that specifying dependencies in the app manifest, config.xml currently, is the way to go. I'm trying to organize the goal/direction of moving to this approach in my head together with all the other moves we are making. Keeping the objectives high level and working on iterating to reach those objectives is what I want to keep clear in my mind. On 3/25/13 3:22 PM, Michal Mocny mmo...@chromium.org wrote: Precisely! I thought plugin dependancies for apps was already on the roadmap. Is that request still debatable? On Mon, Mar 25, 2013 at 6:01 PM, Braden Shepherdson bra...@chromium.orgwrote: I agree that this recreation is a goal, but I don't think moving plugins/ under app/ is the right way to do it. I think the right way to do it is to specify the plugin dependencies of the app in app/. Currently that means in the documentation or a script, in the future probably in config.xml. Braden On Mon, Mar 25, 2013 at 4:09 PM, Filip Maj f...@adobe.com wrote: I think the issue here is: how far do we want to dictate the project structure for a cordova-cli-generated app? Merges kind of evolved out of an actual user who needed a viable use case covered (thanks Michael Wolf!). It is where it is for really no reason other than this is a good feature to have. Consider it like a first pass at an implementation. We can iterate on it to make it better. One thing about the app/ proposal is that the stated objective is to enable shipping a single directory to be able to recreate the native projects. If that is the case, wouldn't we also have to move the plugins into app/ ? On 3/25/13 11:25 AM, Braden Shepherdson bra...@chromium.org wrote: They are, right now, a kind of middle ground. If you rm -rf'd the directory, it wouldn't be all better on the next cordova prepare; that's where we hope to reach soon. On the other hand, you definitely shouldn't be having code in them - native or otherwise - that didn't come from a plugin or from www/. So they could be reconstructed from data stored elsewhere, which makes them mostly a build artifact, and certainly not necessary to store in your source control. Braden On Mon, Mar 25, 2013 at 2:17 PM, Brian LeRoux b...@brian.io wrote: While this might be our goal it is in no way true that ./platforms ia build artifact today or anytime soon. On Mon, Mar 25, 2013 at 10:55 AM, Braden Shepherdson bra...@chromium.org wrote: The same is /not/ true of the current structure, because one (probably) doesn't want to be committing build artifacts like platforms/, or cached third-party data like plugins/ into your git repo. The idea here is that everything under app/ is what you would keep in git for a team working on an app: www, config.xml, docs, samples, etc. Putting that content at the top-level instead means you have lots of extra build artifact cruft in your git repo, or your devs just have to know that platforms/ and plugins/ are in .gitignore. Braden On Mon, Mar 25, 2013 at 1:45 PM, Brian LeRoux b...@brian.io wrote: But, if you go up one level, the same is true w/ the current structure. Its just an organizational difference? (Thats a perfectly ok answer of course. Aesthetics and symmetry are plenty convincing arguments.) In my view ./merges isn't your app. The ./merges dir is in parts of your app on a per platform basis. Hence the logic for having it exist at the same level as ./platforms. Having config.xml exist in the ../www does bother me. On Mon, Mar 25, 2013 at 10:33 AM, Braden Shepherdson bra...@chromium.org wrote: It allows easier cloning of your app (meaning the www, config.xml, and any samples and so on) into a self-contained directory. It also lets us keep the user's app within a single top-level directory (rather than www and merges and potentially more later). Because only the www (and merges) would get pulled into the actual app, any docs, samples, tests, or other
Re: [cordova-cli] versioning
~/.cordova/thing/name/version I originally wrote this but expected some backlash on breaking our name-version convention. I agree, it makes the tool parsing easier. One thing, though: cordova-cli currently runs up the file tree searching for '.cordova' to identify a cordova-cli-generated project root (like git). Can we rename the cache folder to something other than .cordova? .cordovalibs or something? I think we can solve this without renaming: if .cordova path is HOME_DIR then path is not a project Thoughts? Michael On Tue, Mar 26, 2013 at 10:24 AM, Filip Maj f...@adobe.com wrote: Yep, on it, and agree. One thing, though: cordova-cli currently runs up the file tree searching for '.cordova' to identify a cordova-cli-generated project root (like git). Can we rename the cache folder to something other than .cordova? .cordovalibs or something? On 3/26/13 10:22 AM, Brian LeRoux b...@brian.io wrote: Ok. I really like Mike's proposal. Think we should do this. Its solves most of our woe. Slight caveat that I would like the cache to be in the format of: ~/.cordova/thing/name/version (To prevent weird string splitting logic/bugs emerging.) Fil: can you backlog this? I think it should come AFTER we finish fixing up plugman/jsinstall and at least one plugin xplatform done. On Mon, Mar 25, 2013 at 3:26 PM, Michael Brooks mich...@michaelbrooks.ca wrote: With respect to the lazy-loading suggestion, I know Brian has raised the offline scenario on a previous thread. At install time of the CLI (`npm install -g cordova`), we can lazy-load all platforms and sample app(s) for a given version. At install time of the CLI as a library (`npm install cordova`), we can not lazy-load the platforms. This allows other distributions (e.g. `phonegap-cli`) to not be forced to download a large number of unnecessary files. Michael On Mon, Mar 25, 2013 at 3:18 PM, Filip Maj f...@adobe.com wrote: Really like this. It a) slims down the cli tools by lazy loading the libraries as they are needed and b) solves the upgrade/downgrade story, since eventually you'll be able to simply change the version of the cordova npm dependency at a project-level. The only downside (not really) is that every generated cordova-cli project now is implicitly an npm project as it needs a package.json at the top-level. On 3/25/13 11:06 AM, Michael Brooks mich...@michaelbrooks.ca wrote: +1 to locking the CLI to a version +1 to the Grunt vision However, I'd like to propose a different approach to the CLI versioning and it can also solve the `create` command issue to help move towards a dumb global `cordova`. ## Cordova-CLI - npm version is still associated with a Cordova distribution - Cordova-CLI does not vendor the Cordova distribution - Adding a platform will lazy load the platform distribution into ~/.cordova/platform/name-version/ - We can lazy load by downloading a gzip from the Apache Git web server - Next time the platform is needed, it is copied from ~/.cordova/platform/name-version/ ## Cordova Create - Creating an app should be a lazy load of the Hello World app - Cached in ~/.cordova/app/name-version/ - We can update the Hello World app to match a standard Cordova CLI project - Now the global Cordova CLI is a dumb tool - On create: lazy loading or copying the hello world app - On project command: shelling to ./node_modules/bin/cordova command On Fri, Mar 22, 2013 at 1:08 PM, Filip Maj f...@adobe.com wrote: As Tommay pointed out, you need to create the cordova project structure in the first place with some manner of tool.. On 3/22/13 11:58 AM, tommy-carlos Williams to...@devgeeks.org wrote: I don't have much to add except that I really like this about Grunt. However, it would get interesting with Cordova since the global is what creates a project in the first place. I still think it could work and have the global only responsible for creating dirs and setting up package.json stuff etc... +1 for looking into this. On 23/03/2013, at 4:53, Brian LeRoux b...@brian.io wrote: Right now the global executable is version locked to a Cordova release. If you have a project running 2.5 you are required to have Cordova/CLI 2.5. If you need to then work in Cordova 2.4 you need to downgrade (not really but you would to be safe). In Grunt .4 the global executable is dumb. It just shells to locally installed ./node_module version of Grunt. This enables project level versioning of Grunt. Nice feature. We can do the same thing: with the caveat that you would then require a package.json and ./node_modules folder in our Cordova projects. Discuss.
Re: Mobile Spec File Tests Query string
just went over this briefly with Brian, resolveLocalFileSystemURI is our desired inclusion to or form of the w3 spec due to our use case being outside the browser sandbox. So we just make sure URI conforms to URL? in which case, original question: is there any semantic reason for a query tag at the end of a file resource identifier? Or are we just making sure it can handle the breadth of the URL/URI syntax gracefully? On Tue, Mar 26, 2013 at 10:33 AM, Filip Maj f...@adobe.com wrote: O that¹s the one! On 3/26/13 10:29 AM, Lorin Beer lorin.beer@gmail.com wrote: yeah, couldn't track that down either? Anyone? Paging resolveLocalFileSystemURI spec? the W3 spec has resolveLocalFileSystemURL only http://www.w3.org/TR/file-system-api/#widl-LocalFileSystem-resolveLocalFi leSystemURL-void-DOMString-url-EntryCallback-successCallback-ErrorCallback -errorCallback On Tue, Mar 26, 2013 at 10:23 AM, Filip Maj f...@adobe.com wrote: I'm pretty sure the test simply follows the spec.. Which I can't find (where the f is resolvelocalfilesystemuri spec'ed?) On 3/26/13 10:18 AM, Lorin Beer lorin.beer@gmail.com wrote: Hey guys, In file.tests.js, line 267: https://github.com/apache/cordova-mobile-spec/blob/master/autotest/tests/ f ile.tests.js#L267 there is a URI passed to resolveLocalFileSystemURI with a query string appended to the end. The test is meant to return a valid entry. BB7 and BB10 currently flunk the test, returning with an Invalid Symbol type error. I checked the iOS handling of this: https://github.com/apache/cordova-ios/blob/master/CordovaLib/Classes/CDVF i le.m#L218 and the query string is stripped out with the call to NSUrl path. Questions: 1. what's the point of the test? Just to test handling of valid URI with syntactically but semantically meaningless query string? 2. is there any purpose to a query string on a URI mean to be resolved to a file path? Just want to understand this fully before implementing the handling on BB
Re: [cordova-cli] - config.xml handling: should that move into ./bin scripts?
Yeah. I've talking about that specific problem with one of the PhoneGap::Build guys. It's not easy. It is also not limited to permissions but to every possible configuration entry including configuration that has runtime variables in them (package names, api keys, etc...). The easy and obvious solution would be to not delete configuration entries and leave it up the to user but it's definitely not the cleanest solution ;-) On Mon, Mar 25, 2013 at 7:17 AM, Braden Shepherdson bra...@chromium.orgwrote: Permissions require more clever handling than naive XML injection. I'll be talking about that somewhat later. Permissions on Android need de-duping, and making sure that deleting one plugin that requires permission X doesn't remove that permission if another plugin still needs it. Braden On Sun, Mar 24, 2013 at 2:57 AM, tommy-carlos Williams to...@devgeeks.orgwrote: +1 On 24/03/2013, at 16:52, Dave Johnson dave.c.john...@gmail.com wrote: it would make sense to have a separate project-level script that would (for android for example) contain stuff like setting the activity name rather than doing it all in create [1]. Ideally it would enable changing of app package/id etc in an already existing project too. [1] https://github.com/apache/cordova-android/blob/master/bin/create.js#L216 On Sat, Mar 23, 2013 at 7:20 PM, Filip Maj f...@adobe.com wrote: In the future when we ship without core plugins it should also, on android at least, add appropriate permissions for the various plugins. This is already handled by the plugin.xml spec, where you can attach arbitrary xml to any xml document that is platform-specific (such as android manifest).
Re: [cordova-cli] - config.xml handling: should that move into ./bin scripts?
What if plugman worked a little more naively: on uninstall of plugin A, it runs through all plugins and uninstalls them, then runs through and installs all plugins except for plugin A again. On 3/26/13 10:52 AM, Anis KADRI anis.ka...@gmail.com wrote: Yeah. I've talking about that specific problem with one of the PhoneGap::Build guys. It's not easy. It is also not limited to permissions but to every possible configuration entry including configuration that has runtime variables in them (package names, api keys, etc...). The easy and obvious solution would be to not delete configuration entries and leave it up the to user but it's definitely not the cleanest solution ;-) On Mon, Mar 25, 2013 at 7:17 AM, Braden Shepherdson bra...@chromium.orgwrote: Permissions require more clever handling than naive XML injection. I'll be talking about that somewhat later. Permissions on Android need de-duping, and making sure that deleting one plugin that requires permission X doesn't remove that permission if another plugin still needs it. Braden On Sun, Mar 24, 2013 at 2:57 AM, tommy-carlos Williams to...@devgeeks.orgwrote: +1 On 24/03/2013, at 16:52, Dave Johnson dave.c.john...@gmail.com wrote: it would make sense to have a separate project-level script that would (for android for example) contain stuff like setting the activity name rather than doing it all in create [1]. Ideally it would enable changing of app package/id etc in an already existing project too. [1] https://github.com/apache/cordova-android/blob/master/bin/create.js#L216 On Sat, Mar 23, 2013 at 7:20 PM, Filip Maj f...@adobe.com wrote: In the future when we ship without core plugins it should also, on android at least, add appropriate permissions for the various plugins. This is already handled by the plugin.xml spec, where you can attach arbitrary xml to any xml document that is platform-specific (such as android manifest).
Re: [cordova-cli] - config.xml handling: should that move into ./bin scripts?
Yeah that works but it's expensive and also would require users to re-enter some variables (in the case of C2M, facebook-connect and maps). On Tue, Mar 26, 2013 at 10:55 AM, Filip Maj f...@adobe.com wrote: What if plugman worked a little more naively: on uninstall of plugin A, it runs through all plugins and uninstalls them, then runs through and installs all plugins except for plugin A again. On 3/26/13 10:52 AM, Anis KADRI anis.ka...@gmail.com wrote: Yeah. I've talking about that specific problem with one of the PhoneGap::Build guys. It's not easy. It is also not limited to permissions but to every possible configuration entry including configuration that has runtime variables in them (package names, api keys, etc...). The easy and obvious solution would be to not delete configuration entries and leave it up the to user but it's definitely not the cleanest solution ;-) On Mon, Mar 25, 2013 at 7:17 AM, Braden Shepherdson bra...@chromium.orgwrote: Permissions require more clever handling than naive XML injection. I'll be talking about that somewhat later. Permissions on Android need de-duping, and making sure that deleting one plugin that requires permission X doesn't remove that permission if another plugin still needs it. Braden On Sun, Mar 24, 2013 at 2:57 AM, tommy-carlos Williams to...@devgeeks.orgwrote: +1 On 24/03/2013, at 16:52, Dave Johnson dave.c.john...@gmail.com wrote: it would make sense to have a separate project-level script that would (for android for example) contain stuff like setting the activity name rather than doing it all in create [1]. Ideally it would enable changing of app package/id etc in an already existing project too. [1] https://github.com/apache/cordova-android/blob/master/bin/create.js#L216 On Sat, Mar 23, 2013 at 7:20 PM, Filip Maj f...@adobe.com wrote: In the future when we ship without core plugins it should also, on android at least, add appropriate permissions for the various plugins. This is already handled by the plugin.xml spec, where you can attach arbitrary xml to any xml document that is platform-specific (such as android manifest).
Re: Welcome to our new committers!
lulz On Tue, Mar 26, 2013 at 10:22 AM, Filip Maj f...@adobe.com wrote: O yeah and welcome Lorin Beer too :P On 3/26/13 10:21 AM, Lorin Beer lorin.beer@gmail.com wrote: Congratulations! On Tue, Mar 26, 2013 at 9:59 AM, Michal Mocny mmo...@chromium.org wrote: Welcome! Now get back to work :) On Tue, Mar 26, 2013 at 12:50 PM, Michael Brooks mich...@michaelbrooks.cawrote: Welcome to the team! On Tue, Mar 26, 2013 at 9:41 AM, Andrew Grieve agri...@chromium.org wrote: Yes! Awesome to have you all on the team! http://www.youtube.com/watch?v=KMU0tzLwhbE On Tue, Mar 26, 2013 at 12:31 PM, Braden Shepherdson bra...@chromium.org wrote: Congratulations! On Tue, Mar 26, 2013 at 12:27 PM, Brian LeRoux b...@brian.io wrote: \o/ On Tue, Mar 26, 2013 at 9:08 AM, Filip Maj f...@adobe.com wrote: Just wanted to send out a quick congratulatory note to the public dev list. We've voted in four new committers in the past week or two, I'm very excited about this! Don Coleman, Max Woghiren, James Jong, and Tommy Carlos-Williams: welcome, stoked to have you folks join, and congratulations!
Re: App-Harness Description
We could really name it anything, I liked all the suggestions, here are more: Cordova World Cordova Dev Cordova Xing Build Cordova Harness Cordova C-Street Dev .. just to add to the confusion ~Benn On Tue, Mar 26, 2013 at 10:28 AM, Michael Brooks mich...@michaelbrooks.cawrote: haha, so Harness it is? ;) On Tue, Mar 26, 2013 at 10:17 AM, Brian LeRoux b...@brian.io wrote: cordova-kink PROS: would probably get lots of downloads in the app store CONS: would probably not get accepted into the app store On Tue, Mar 26, 2013 at 10:03 AM, Michal Mocny mmo...@chromium.org wrote: I like the kinky version. On Tue, Mar 26, 2013 at 12:52 PM, Brian LeRoux b...@brian.io wrote: Heh, DX sounds *very* Adobe. (Remember Flash MX?) Meanwhile Devtool sounds very Google. Either way I like both more than calling it a harness. ;) On Tue, Mar 26, 2013 at 9:39 AM, Andrew Grieve agri...@chromium.org wrote: Awesome! Yep - it's editable so that you can edit it :) I like Cordova DX, or maybe Cordova DevTool On Tue, Mar 26, 2013 at 12:10 PM, Michael Brooks mich...@michaelbrooks.ca wrote: Hey Andrew, This is exactly what I had planned as well. It's as if we read each other's minds. I'll go through the document a second time and add some comments. Do you mind if I edit the document? What is this thing going to be called? cordova-app-harness sounds kinky. For naming, my stance has been the Cordova App. There is no reason to make it complicated. If the app stores, users would install Cordova. If you think this is confusing users with downloading the Cordova framework (which they sort of are), then call it Cordova DX (DX is developer experience). Michael On Tue, Mar 26, 2013 at 9:06 AM, Brian LeRoux b...@brian.io wrote: Looks great Andrew. I'd add Ripple and device mirroring as part of this. (More than one device navigates in concert.) What is this thing going to be called? cordova-app-harness sounds kinky. On Mon, Mar 25, 2013 at 5:59 PM, Andrew Grieve agri...@chromium.org wrote: Hey Michael (and anyone else interested), I've written up a requirements doc for this: https://docs.google.com/document/d/14LG1IiEiQ9npc2RmPo5_UEKQTfsg-3ivJu7R2iPBmsw/edit?usp=sharing It's a bit biased towards hosting Chrome Apps, but I think the majority of the app will be generic. The chrome bits will be implemented as a combination of extra plugins that are installed in, and some UI tweaks. Would definitely love feedback to know if this describes the same type of thing you were thinking of. Shravan will likely be starting on this this week.
Re: App-Harness Description
My vote is for WebKeg On 3/26/13 11:57 AM, Benn Mapes benn.ma...@gmail.com wrote: We could really name it anything, I liked all the suggestions, here are more: Cordova World Cordova Dev Cordova Xing Build Cordova Harness Cordova C-Street Dev .. just to add to the confusion ~Benn On Tue, Mar 26, 2013 at 10:28 AM, Michael Brooks mich...@michaelbrooks.cawrote: haha, so Harness it is? ;) On Tue, Mar 26, 2013 at 10:17 AM, Brian LeRoux b...@brian.io wrote: cordova-kink PROS: would probably get lots of downloads in the app store CONS: would probably not get accepted into the app store On Tue, Mar 26, 2013 at 10:03 AM, Michal Mocny mmo...@chromium.org wrote: I like the kinky version. On Tue, Mar 26, 2013 at 12:52 PM, Brian LeRoux b...@brian.io wrote: Heh, DX sounds *very* Adobe. (Remember Flash MX?) Meanwhile Devtool sounds very Google. Either way I like both more than calling it a harness. ;) On Tue, Mar 26, 2013 at 9:39 AM, Andrew Grieve agri...@chromium.org wrote: Awesome! Yep - it's editable so that you can edit it :) I like Cordova DX, or maybe Cordova DevTool On Tue, Mar 26, 2013 at 12:10 PM, Michael Brooks mich...@michaelbrooks.ca wrote: Hey Andrew, This is exactly what I had planned as well. It's as if we read each other's minds. I'll go through the document a second time and add some comments. Do you mind if I edit the document? What is this thing going to be called? cordova-app-harness sounds kinky. For naming, my stance has been the Cordova App. There is no reason to make it complicated. If the app stores, users would install Cordova. If you think this is confusing users with downloading the Cordova framework (which they sort of are), then call it Cordova DX (DX is developer experience). Michael On Tue, Mar 26, 2013 at 9:06 AM, Brian LeRoux b...@brian.io wrote: Looks great Andrew. I'd add Ripple and device mirroring as part of this. (More than one device navigates in concert.) What is this thing going to be called? cordova-app-harness sounds kinky. On Mon, Mar 25, 2013 at 5:59 PM, Andrew Grieve agri...@chromium.org wrote: Hey Michael (and anyone else interested), I've written up a requirements doc for this: https://docs.google.com/document/d/14LG1IiEiQ9npc2RmPo5_UEKQTfsg-3ivJu7R2 iPBmsw/edit?usp=sharing It's a bit biased towards hosting Chrome Apps, but I think the majority of the app will be generic. The chrome bits will be implemented as a combination of extra plugins that are installed in, and some UI tweaks. Would definitely love feedback to know if this describes the same type of thing you were thinking of. Shravan will likely be starting on this this week.
Re: App-Harness Description
On 26/03/2013, at 16:13, Filip Maj f...@adobe.com wrote: My vote is for WebKeg THIS -- qmx
Re: App-Harness Description
omg. yes! cordova-webkeg I can see the Yohei style app icon already.. On Tue, Mar 26, 2013 at 12:14 PM, Douglas Campos q...@qmx.me wrote: On 26/03/2013, at 16:13, Filip Maj f...@adobe.com wrote: My vote is for WebKeg THIS -- qmx
Re: Welcome to our new committers!
Welcome and congrats! On 3/26/13 7:06 PM, Brian LeRoux b...@brian.io wrote: lulz On Tue, Mar 26, 2013 at 10:22 AM, Filip Maj f...@adobe.com wrote: O yeah and welcome Lorin Beer too :P On 3/26/13 10:21 AM, Lorin Beer lorin.beer@gmail.com wrote: Congratulations! On Tue, Mar 26, 2013 at 9:59 AM, Michal Mocny mmo...@chromium.org wrote: Welcome! Now get back to work :) On Tue, Mar 26, 2013 at 12:50 PM, Michael Brooks mich...@michaelbrooks.cawrote: Welcome to the team! On Tue, Mar 26, 2013 at 9:41 AM, Andrew Grieve agri...@chromium.org wrote: Yes! Awesome to have you all on the team! http://www.youtube.com/watch?v=KMU0tzLwhbE On Tue, Mar 26, 2013 at 12:31 PM, Braden Shepherdson bra...@chromium.org wrote: Congratulations! On Tue, Mar 26, 2013 at 12:27 PM, Brian LeRoux b...@brian.io wrote: \o/ On Tue, Mar 26, 2013 at 9:08 AM, Filip Maj f...@adobe.com wrote: Just wanted to send out a quick congratulatory note to the public dev list. We've voted in four new committers in the past week or two, I'm very excited about this! Don Coleman, Max Woghiren, James Jong, and Tommy Carlos-Williams: welcome, stoked to have you folks join, and congratulations!
Re: App-Harness Description
+1 for WebKeg On Tue, Mar 26, 2013 at 12:52 PM, Brian LeRoux b...@brian.io wrote: omg. yes! cordova-webkeg I can see the Yohei style app icon already.. On Tue, Mar 26, 2013 at 12:14 PM, Douglas Campos q...@qmx.me wrote: On 26/03/2013, at 16:13, Filip Maj f...@adobe.com wrote: My vote is for WebKeg THIS -- qmx
Re: Platform-level command line scripts ;)
OK, I've done some rehash of the proposal and put it up on the wiki: http://wiki.apache.org/cordova/CommandLineToolingDesign Please take a look and post back if you have questions, disagreement, want to +1 it, etc. At the top there is a generic multi-device flow that can solve a lot of the consistency issues we've seen before. Assuming this proposal is on track, there are three outstanding questions. Two for the `log` command: * Does the current iOS implementation only work for simulator, or device, or either, or neither? * Does the multi-device flow apply correctly to the log case? It seems identifying whether the user's Cordova application is running on an emulator or device target would need to be figured out. One about the build command: * What happens when a user specifies both --release and --debug, I.e. `build --release --debug`? On 3/25/13 1:54 PM, Michael Brooks mich...@michaelbrooks.ca wrote: To be absolutely clear, the above is NOT the motivation for changing this stuff around. Cordova-cli needs consistency across platforms. This is the motivation. Yep, as long as we can guarantee that each script follows a predictable input and output, I don't care how we implement it. If you guys really want a single entry-point with flags, then go nuts, but we will need to clearly define what happens when: - no flag is provided e.g. `build` - multiple flags are provided e.g. `build --release --debug` --- +1 to adding a script that validates a platform's SDK requirements. This script should not need to modify project files to assert the SDK requirements. I mention this because the current `cordova-cli` Android `check_requirements` must successfully update the Android project target before returning true. However, consider the scenario where you validate the SDK before adding the platform - in this case, the Android `check_requirements` will always fail. Michael On Mon, Mar 25, 2013 at 11:14 AM, Filip Maj f...@adobe.com wrote: Hopefully, next time we will change/update these things it will be for a real reason (such as SDK tools updates etc...) and not because we think that there might be a better implementation in C#. To be absolutely clear, the above is NOT the motivation for changing this stuff around. Cordova-cli needs consistency across platforms. This is the motivation.
Re: [cordova-cli] versioning
Noted in https://issues.apache.org/jira/browse/CB-2163 On 3/26/13 11:34 AM, Braden Shepherdson bra...@chromium.org wrote: +1 to having ~/.cordova/thing/name/version. I know we name our releases foo-version, but this is an unambiguous split on a character that isn't legal in plugin names. Braden On Tue, Mar 26, 2013 at 1:34 PM, Michael Brooks mich...@michaelbrooks.cawrote: ~/.cordova/thing/name/version I originally wrote this but expected some backlash on breaking our name-version convention. I agree, it makes the tool parsing easier. One thing, though: cordova-cli currently runs up the file tree searching for '.cordova' to identify a cordova-cli-generated project root (like git). Can we rename the cache folder to something other than .cordova? .cordovalibs or something? I think we can solve this without renaming: if .cordova path is HOME_DIR then path is not a project Thoughts? Michael On Tue, Mar 26, 2013 at 10:24 AM, Filip Maj f...@adobe.com wrote: Yep, on it, and agree. One thing, though: cordova-cli currently runs up the file tree searching for '.cordova' to identify a cordova-cli-generated project root (like git). Can we rename the cache folder to something other than .cordova? .cordovalibs or something? On 3/26/13 10:22 AM, Brian LeRoux b...@brian.io wrote: Ok. I really like Mike's proposal. Think we should do this. Its solves most of our woe. Slight caveat that I would like the cache to be in the format of: ~/.cordova/thing/name/version (To prevent weird string splitting logic/bugs emerging.) Fil: can you backlog this? I think it should come AFTER we finish fixing up plugman/jsinstall and at least one plugin xplatform done. On Mon, Mar 25, 2013 at 3:26 PM, Michael Brooks mich...@michaelbrooks.ca wrote: With respect to the lazy-loading suggestion, I know Brian has raised the offline scenario on a previous thread. At install time of the CLI (`npm install -g cordova`), we can lazy-load all platforms and sample app(s) for a given version. At install time of the CLI as a library (`npm install cordova`), we can not lazy-load the platforms. This allows other distributions (e.g. `phonegap-cli`) to not be forced to download a large number of unnecessary files. Michael On Mon, Mar 25, 2013 at 3:18 PM, Filip Maj f...@adobe.com wrote: Really like this. It a) slims down the cli tools by lazy loading the libraries as they are needed and b) solves the upgrade/downgrade story, since eventually you'll be able to simply change the version of the cordova npm dependency at a project-level. The only downside (not really) is that every generated cordova-cli project now is implicitly an npm project as it needs a package.json at the top-level. On 3/25/13 11:06 AM, Michael Brooks mich...@michaelbrooks.ca wrote: +1 to locking the CLI to a version +1 to the Grunt vision However, I'd like to propose a different approach to the CLI versioning and it can also solve the `create` command issue to help move towards a dumb global `cordova`. ## Cordova-CLI - npm version is still associated with a Cordova distribution - Cordova-CLI does not vendor the Cordova distribution - Adding a platform will lazy load the platform distribution into ~/.cordova/platform/name-version/ - We can lazy load by downloading a gzip from the Apache Git web server - Next time the platform is needed, it is copied from ~/.cordova/platform/name-version/ ## Cordova Create - Creating an app should be a lazy load of the Hello World app - Cached in ~/.cordova/app/name-version/ - We can update the Hello World app to match a standard Cordova CLI project - Now the global Cordova CLI is a dumb tool - On create: lazy loading or copying the hello world app - On project command: shelling to ./node_modules/bin/cordova command On Fri, Mar 22, 2013 at 1:08 PM, Filip Maj f...@adobe.com wrote: As Tommay pointed out, you need to create the cordova project structure in the first place with some manner of tool.. On 3/22/13 11:58 AM, tommy-carlos Williams to...@devgeeks.org wrote: I don't have much to add except that I really like this about Grunt. However, it would get interesting with Cordova since the global is what creates a project in the first place. I still think it could work and have the global only responsible for creating dirs and setting up package.json stuff etc... +1 for looking into this. On 23/03/2013, at 4:53, Brian LeRoux b...@brian.io wrote: Right now the global executable is version locked to a Cordova release. If you have a project running 2.5 you are required to have Cordova/CLI 2.5. If you need to then work in Cordova 2.4 you need to downgrade (not
Re: Platform-level command line scripts ;)
* log is only the Simulator * build release/debug -- last one clobbers? depending on how the parsing is implemented On Tue, Mar 26, 2013 at 3:56 PM, Filip Maj f...@adobe.com wrote: OK, I've done some rehash of the proposal and put it up on the wiki: http://wiki.apache.org/cordova/CommandLineToolingDesign Please take a look and post back if you have questions, disagreement, want to +1 it, etc. At the top there is a generic multi-device flow that can solve a lot of the consistency issues we've seen before. Assuming this proposal is on track, there are three outstanding questions. Two for the `log` command: * Does the current iOS implementation only work for simulator, or device, or either, or neither? * Does the multi-device flow apply correctly to the log case? It seems identifying whether the user's Cordova application is running on an emulator or device target would need to be figured out. One about the build command: * What happens when a user specifies both --release and --debug, I.e. `build --release --debug`? On 3/25/13 1:54 PM, Michael Brooks mich...@michaelbrooks.ca wrote: To be absolutely clear, the above is NOT the motivation for changing this stuff around. Cordova-cli needs consistency across platforms. This is the motivation. Yep, as long as we can guarantee that each script follows a predictable input and output, I don't care how we implement it. If you guys really want a single entry-point with flags, then go nuts, but we will need to clearly define what happens when: - no flag is provided e.g. `build` - multiple flags are provided e.g. `build --release --debug` --- +1 to adding a script that validates a platform's SDK requirements. This script should not need to modify project files to assert the SDK requirements. I mention this because the current `cordova-cli` Android `check_requirements` must successfully update the Android project target before returning true. However, consider the scenario where you validate the SDK before adding the platform - in this case, the Android `check_requirements` will always fail. Michael On Mon, Mar 25, 2013 at 11:14 AM, Filip Maj f...@adobe.com wrote: Hopefully, next time we will change/update these things it will be for a real reason (such as SDK tools updates etc...) and not because we think that there might be a better implementation in C#. To be absolutely clear, the above is NOT the motivation for changing this stuff around. Cordova-cli needs consistency across platforms. This is the motivation.
Re: Platform-level command line scripts ;)
Thanks Shaz, updated the wiki article. On 3/26/13 4:07 PM, Shazron shaz...@gmail.com wrote: * log is only the Simulator * build release/debug -- last one clobbers? depending on how the parsing is implemented On Tue, Mar 26, 2013 at 3:56 PM, Filip Maj f...@adobe.com wrote: OK, I've done some rehash of the proposal and put it up on the wiki: http://wiki.apache.org/cordova/CommandLineToolingDesign Please take a look and post back if you have questions, disagreement, want to +1 it, etc. At the top there is a generic multi-device flow that can solve a lot of the consistency issues we've seen before. Assuming this proposal is on track, there are three outstanding questions. Two for the `log` command: * Does the current iOS implementation only work for simulator, or device, or either, or neither? * Does the multi-device flow apply correctly to the log case? It seems identifying whether the user's Cordova application is running on an emulator or device target would need to be figured out. One about the build command: * What happens when a user specifies both --release and --debug, I.e. `build --release --debug`? On 3/25/13 1:54 PM, Michael Brooks mich...@michaelbrooks.ca wrote: To be absolutely clear, the above is NOT the motivation for changing this stuff around. Cordova-cli needs consistency across platforms. This is the motivation. Yep, as long as we can guarantee that each script follows a predictable input and output, I don't care how we implement it. If you guys really want a single entry-point with flags, then go nuts, but we will need to clearly define what happens when: - no flag is provided e.g. `build` - multiple flags are provided e.g. `build --release --debug` --- +1 to adding a script that validates a platform's SDK requirements. This script should not need to modify project files to assert the SDK requirements. I mention this because the current `cordova-cli` Android `check_requirements` must successfully update the Android project target before returning true. However, consider the scenario where you validate the SDK before adding the platform - in this case, the Android `check_requirements` will always fail. Michael On Mon, Mar 25, 2013 at 11:14 AM, Filip Maj f...@adobe.com wrote: Hopefully, next time we will change/update these things it will be for a real reason (such as SDK tools updates etc...) and not because we think that there might be a better implementation in C#. To be absolutely clear, the above is NOT the motivation for changing this stuff around. Cordova-cli needs consistency across platforms. This is the motivation.
Re: [cordova-cli] - config.xml handling: should that move into ./bin scripts?
I think as a first pass its ok to do things the brute force way until we find a better way. And by expensive, what are we talking about? Seconds, at most? Not a big deal IMO. Can you expand on the variables thing, Anis? On 3/26/13 11:00 AM, Anis KADRI anis.ka...@gmail.com wrote: Yeah that works but it's expensive and also would require users to re-enter some variables (in the case of C2M, facebook-connect and maps). On Tue, Mar 26, 2013 at 10:55 AM, Filip Maj f...@adobe.com wrote: What if plugman worked a little more naively: on uninstall of plugin A, it runs through all plugins and uninstalls them, then runs through and installs all plugins except for plugin A again. On 3/26/13 10:52 AM, Anis KADRI anis.ka...@gmail.com wrote: Yeah. I've talking about that specific problem with one of the PhoneGap::Build guys. It's not easy. It is also not limited to permissions but to every possible configuration entry including configuration that has runtime variables in them (package names, api keys, etc...). The easy and obvious solution would be to not delete configuration entries and leave it up the to user but it's definitely not the cleanest solution ;-) On Mon, Mar 25, 2013 at 7:17 AM, Braden Shepherdson bra...@chromium.orgwrote: Permissions require more clever handling than naive XML injection. I'll be talking about that somewhat later. Permissions on Android need de-duping, and making sure that deleting one plugin that requires permission X doesn't remove that permission if another plugin still needs it. Braden On Sun, Mar 24, 2013 at 2:57 AM, tommy-carlos Williams to...@devgeeks.orgwrote: +1 On 24/03/2013, at 16:52, Dave Johnson dave.c.john...@gmail.com wrote: it would make sense to have a separate project-level script that would (for android for example) contain stuff like setting the activity name rather than doing it all in create [1]. Ideally it would enable changing of app package/id etc in an already existing project too. [1] https://github.com/apache/cordova-android/blob/master/bin/create.js#L21 6 On Sat, Mar 23, 2013 at 7:20 PM, Filip Maj f...@adobe.com wrote: In the future when we ship without core plugins it should also, on android at least, add appropriate permissions for the various plugins. This is already handled by the plugin.xml spec, where you can attach arbitrary xml to any xml document that is platform-specific (such as android manifest).
Re: [plugman] js install
FYI, I've added a bunch of issues based on a brain dump of outstanding tasks that Braden wrote up in plugman's future branch. Tagged the issues in JIRA as future, and they are also noted at the bottom of plugman/future FUTURE.md under the TODO section. We're pretty damn close but missing tests for all the new features, but I think close to 2.6 release time this stuff should be ready.. Super exciting!! On 3/26/13 10:23 AM, Brian LeRoux b...@brian.io wrote: fuckin eh, sounds awesome---thx man On Tue, Mar 26, 2013 at 10:14 AM, Braden Shepherdson bra...@chromium.org wrote: I added the plugin-loading code there (see scripts/plugin_loader.js) but I wasn't aware that XHRs to file:// URLs always have status 0 instead of 200/404/etc. Andrew fixed that today, but we decided not to try to cherry-pick that change into 2.6.x. It's harmless for the main function of cordova-js, but it means that the future branch of the CLI tools won't work with the released 2.6. Braden On Tue, Mar 26, 2013 at 12:57 PM, Brian LeRoux b...@brian.io wrote: Braden: whats happening in cordova-js that is broken/being heavily refactored? On Tue, Mar 26, 2013 at 9:36 AM, Braden Shepherdson bra...@chromium.org wrote: You'll need the future branch of cordova-cli and plugman, and to go through a bit of a dance to get those two installed and npm linked properly. The dance is as follows: cd plugman npm install sudo npm link cd ../cordova-cli npm install sudo npm link npm link plugman Now when you run 'cordova' you get the git version, and 'plugman' likewise. You can skip everything after the first three lines if you're only using plugman and not CLI. Note that the master branch is currently broken with cordova-js 2.6.0; you'll have to use the future branch. Unfortunately that branch is under heavy development right now, but I'm trying to keep it in a working state. Braden On Tue, Mar 26, 2013 at 12:16 PM, Filip Maj f...@adobe.com wrote: Use the future branch of plugman. That's where braden is putting the symbol mapping work into. On 3/26/13 9:09 AM, Brian LeRoux b...@brian.io wrote: Steve has plugman working with devicemotion plugin. Happy days! Its time he ripped the JS out of cordova-js and put it in the plugin. But does plugman support js installation? What needs happening to make it so?
