Re: JAVA_HOME
I blame Maven. Maven requires JAVA_HOME. (Yes, I had maven installed. I'm not proud of that.) On Dec 5, 2013 9:36 PM, "Steven Gill" wrote: > It is a bug with Cordova android. We could have tried to do a 3.2.1 for > android but instead are focusing on getting 3.3.0 out next week. > > On Thursday, December 5, 2013, Don Coleman wrote: > > > I was hoping this fix was going to make 3.2.0-0.4.0 but it looks like > it's > > marked as 3.3 in JIRA. Would it be difficult to get this fix > > into 3.2.0-0.5.0? > > > > https://issues.apache.org/jira/browse/CB-5422 > > > > > > On Tue, Dec 3, 2013 at 12:08 PM, Marcel Kinard > > > wrote: > > > > > Yeah. It's really cool what works in Cordova, but it's also embarrasing > > > what gets broken. Running real end-to-end (in the generic sense) tests > > like > > > a real consumer in a real app-dev workflow should help us catch the bad > > > parts. I don't think we are exercising end-to-end without automated CI. > > > > > > On Dec 3, 2013, at 1:36 AM, Brian LeRoux > > > wrote: > > > > > > > This is really a symptom of how badly we need to get CI running > again. > > > The > > > > hello world workflow being broken is completely unacceptable. > > > > > >
Re: JAVA_HOME
It is a bug with Cordova android. We could have tried to do a 3.2.1 for android but instead are focusing on getting 3.3.0 out next week. On Thursday, December 5, 2013, Don Coleman wrote: > I was hoping this fix was going to make 3.2.0-0.4.0 but it looks like it's > marked as 3.3 in JIRA. Would it be difficult to get this fix > into 3.2.0-0.5.0? > > https://issues.apache.org/jira/browse/CB-5422 > > > On Tue, Dec 3, 2013 at 12:08 PM, Marcel Kinard > > > wrote: > > > Yeah. It's really cool what works in Cordova, but it's also embarrasing > > what gets broken. Running real end-to-end (in the generic sense) tests > like > > a real consumer in a real app-dev workflow should help us catch the bad > > parts. I don't think we are exercising end-to-end without automated CI. > > > > On Dec 3, 2013, at 1:36 AM, Brian LeRoux > > wrote: > > > > > This is really a symptom of how badly we need to get CI running again. > > The > > > hello world workflow being broken is completely unacceptable. > > >
Re: JAVA_HOME
I was hoping this fix was going to make 3.2.0-0.4.0 but it looks like it's marked as 3.3 in JIRA. Would it be difficult to get this fix into 3.2.0-0.5.0? https://issues.apache.org/jira/browse/CB-5422 On Tue, Dec 3, 2013 at 12:08 PM, Marcel Kinard wrote: > Yeah. It's really cool what works in Cordova, but it's also embarrasing > what gets broken. Running real end-to-end (in the generic sense) tests like > a real consumer in a real app-dev workflow should help us catch the bad > parts. I don't think we are exercising end-to-end without automated CI. > > On Dec 3, 2013, at 1:36 AM, Brian LeRoux wrote: > > > This is really a symptom of how badly we need to get CI running again. > The > > hello world workflow being broken is completely unacceptable. >
Re: Adding a "plugman create" command
Looks good On Fri, Dec 6, 2013 at 5:33 AM, Andrew Grieve wrote: > Going though pull requests and came upon Lucas' pull request for this. > > Seems okay to me, anyone have comments about it? > > https://github.com/apache/cordova-plugman/pull/25 > > https://issues.apache.org/jira/browse/CB-4886 >
Re: Ubuntu and FireOS update
On Thu, Dec 5, 2013 at 8:53 PM, Steven Gill wrote: > Just wanted to give a update > > Support for both of these now exists in plugman + CLI on master. It seems > to be working well enough. > > Docs: This is a pretty important piece. Once we release 3.3.0, our users > are going to want to know what plugins are supported, what the getting > started requirements are, etc. I know FireOS has already sent some doc > updates. I would suggest installing all of the plugins you support and run > mobile-spec. Once you have confirmed a plugin has full support, add your > platform to the supported platform list. > > Docs can be found at https://github.com/apache/cordova-docs/ > > *FireOS* > Plugman Tests: I commented out the tests because they need work. They rely > to heavily on a copy paste job of the android tests. I had to update the > plugin.xml files for the three plugins in the tests to add support for > amazon-fireos just to get the tests to run. > > Check-reqs: right now the requirements are being checked in the cli. We > will want to change this to use the platform level chec_reqs script > instead. Android made this change recently. Hopefully someone can point you > to the specific commits that made the change. This is suffering from the > same problem Android just had, in that it is setting the base api level at > 17. We should update that number for now and after 3.3.0 work on converting > this. > To add to this - I made a check afterwards to just make CLI's check_requirements return true immediately. It makes more sense to have the bin/create script run check_reqs itself. The original reason for having check_requirements in CLI was to be able to check requirements before running lazy_load, but that never came to fruition (and is a pretty minor optimization anyways). > > *Ubuntu* > Tests! We need them! :) > Need to make clear that ubuntu option isn't available on Mac or Windows. > The error messages aren't clear here. Documentation around this would go a > long way! > > > I will continue to give suggestions as I play around more with both of > these platforms. Please file issues for any of the work you do and use > those in the commit messages. > > The 3.3.0-rc.1 will be tagged & released tomorrow. I will tag both of these > platforms leading up to the release. I'm aiming to release 3.3.0 next Wed > or Thursday. So we will still have some time to improve the experience for > users who will be trying out these platforms for the first time. >
Re: Pull request for adding ubuntu to plugman
Sounds good! On Thu, Dec 5, 2013 at 3:44 PM, Steven Gill wrote: > Yup. I was planning on asking after I merge them into master today. For > plugman and cli. > > On Thursday, December 5, 2013, Andrew Grieve wrote: > > > Cool. > > > > Should you ask for the PRs to be closed? The other (fireos) is: > > https://github.com/apache/cordova-plugman/pull/35/files > > > > > > > > > > On Thu, Dec 5, 2013 at 1:54 PM, Steven Gill > > > wrote: > > > > > It has been merged into the ubuntu branch of plugman. I am going to > spend > > > most of the day testing ubuntu + fireOS today before tagging the RCs > for > > > them > > > > > > > > > > > > > > > On Thu, Dec 5, 2013 at 10:22 AM, Andrew Grieve > > > wrote: > > > > > > > Wanted to check the status of this pull request: > > > > > > > > https://github.com/apache/cordova-plugman/pull/24 > > > > > > > > > >
Ubuntu and FireOS update
Just wanted to give a update Support for both of these now exists in plugman + CLI on master. It seems to be working well enough. Docs: This is a pretty important piece. Once we release 3.3.0, our users are going to want to know what plugins are supported, what the getting started requirements are, etc. I know FireOS has already sent some doc updates. I would suggest installing all of the plugins you support and run mobile-spec. Once you have confirmed a plugin has full support, add your platform to the supported platform list. Docs can be found at https://github.com/apache/cordova-docs/ *FireOS* Plugman Tests: I commented out the tests because they need work. They rely to heavily on a copy paste job of the android tests. I had to update the plugin.xml files for the three plugins in the tests to add support for amazon-fireos just to get the tests to run. Check-reqs: right now the requirements are being checked in the cli. We will want to change this to use the platform level chec_reqs script instead. Android made this change recently. Hopefully someone can point you to the specific commits that made the change. This is suffering from the same problem Android just had, in that it is setting the base api level at 17. We should update that number for now and after 3.3.0 work on converting this. *Ubuntu* Tests! We need them! :) Need to make clear that ubuntu option isn't available on Mac or Windows. The error messages aren't clear here. Documentation around this would go a long way! I will continue to give suggestions as I play around more with both of these platforms. Please file issues for any of the work you do and use those in the commit messages. The 3.3.0-rc.1 will be tagged & released tomorrow. I will tag both of these platforms leading up to the release. I'm aiming to release 3.3.0 next Wed or Thursday. So we will still have some time to improve the experience for users who will be trying out these platforms for the first time.
iOS webview size
Hi everyone, It appears that on iOS, webview is restricted to a 320x240 canvas. Is it possible to automatically set canvas size using device screen's one ? Why is it not the default scenario ? Cordialement. --- Maxime LUCE - Somatic maxime.l...@somatic.fr 06 28 60 72 34
Re: ios7 overlapping status bar
Yes! On Dec 5, 2013 11:14 PM, "Christian Grobmeier" wrote: > Ok got it running. Thanks for the pointers. > > I would love to see this in the docs. Any interest in a patch? > > On 4 Dec 2013, at 22:04, Shazron wrote: > > Yeah there have been blog posts about it. Also see: >> >> 1. https://gist.github.com/shazron/6602131 >> 2. >> http://shazronatadobe.wordpress.com/2013/10/15/ >> cordova-ios-and-ios-7-support/ >> 3. >> https://issues.apache.org/jira/browse/CB-4918?focusedCommentId=13782197&; >> page=com.atlassian.jira.plugin.system.issuetabpanels: >> comment-tabpanel#comment-13782197 >> >> >> On Wed, Dec 4, 2013 at 12:28 PM, Steven Gill >> wrote: >> >> Hey Christian, >>> >>> I think Icenium did a good summary on their blog. >>> >>> http://www.icenium.com/blog/icenium-team-blog/2013/11/07/ >>> everything-hybrid-web-apps-need-to-know-about-the-status-bar-in-ios7 >>> >>> It points to some of the work shaz has done around the iOS status bar >>> problem. >>> >>> >>> On Wed, Dec 4, 2013 at 12:21 PM, Christian Grobmeier < >>> grobme...@gmail.com >>> wrote: >>> >>> hi folks, i am facing the problem that ios7 overlaps my cordova app. I already googled and found some people are hacking things in obj-c: http://stackoverflow.com/questions/18886195/ios-7- status-bar-overlapping-ui I would prefer not to hack in obj-c. First, lack of skills, second I >>> don't >>> want to commit the xcode project to scm but let cordova generate it. Is this issue known or are there even any recommendations how to address it without hacking Cordova? Thanks! Christian --- http://www.grobmeier.de @grobmeier GPG: 0xA5CC90DB >>> > > --- > http://www.grobmeier.de > @grobmeier > GPG: 0xA5CC90DB >
Re: [android] How to remove the automatic default of
Nice! I will check it out later today. On Thursday, December 5, 2013, Michal Mocny wrote: > Alright, I've landed a defaults.xml for ios and android and closed the long > standing bugs for this. > > Aside from removing the tag, I also removed the settings which are > overwritten by the app-level config anyway, such as app name, description, > tag, etc. Please take a look if you have any concerns. I did > leave the default platform preferences/features in there, because those can > be overridden in the app config and many really are platform specific. > > Tested using both the CLI and bin/create workflows to make sure both still > work and do what we intent. > > Now, when a CLI user makes changes to the app config to remove or > tags, the final platform config actually reflects those changes. > Win. > > -Michal > > > On Wed, Dec 4, 2013 at 2:31 PM, Tommy-Carlos Williams > > >wrote: > > > +1 > > > > This is all sounding great and no matter how much I love the CLI, > > supporting both workflows is important. > > > > > > > > > > On 5 Dec 2013, at 6:13 am, Michal Mocny wrote: > > > > > Yes, there is no need to change the tools, which is why I like this > > > approach. I forgot to mention that part :P > > > > > > I did not think we previously discussed supplying both config files > with > > > different default settings. I had previously imagined we would ship > > > platforms with only one defaults file (defaults.xml/config.xml > whichever > > > name) that was consumed by both flows. The function of a defaults.xml > > was > > > as an implementation detail of CLI to help us treat config.xml as a > build > > > artifact. Now I am proposing using it as a first class config file > that > > > gets maintained along with config.xml in platform releases. > > > > > > -Michal > > > > > > > > > On Wed, Dec 4, 2013 at 1:43 PM, Braden Shepherdson > >wrote: > > > > > >> It's possible I'm misunderstanding something here, but the flow you > > >> described here is exactly the one we intended when designing how > > >> details.xml was going to work. Platforms ship both files, cli uses > > >> defaults.xml where available, and config.xml where not. Platform > scripts > > >> use config.xml always. > > >> > > >> I don't think any (many?) Changes to the tools will be necessary to > > support > > >> this. > > >> > > >> Braden > > >> On Dec 4, 2013 8:25 AM, "Michal Mocny" wrote: > > >> > > >>> Alright, Andrew and I discussed this and think we have a resolution > > that > > >>> works with all the use cases (yay for options). > > >>> > > >>> TLDR; I think we already (accidentally?) support using a different > > >> default > > >>> platform config file for each of our two workflows. This means we > can > > >> have > > >>> the tag live inside the platform config for > > >>> platform-centric workflow, and inside the app config for app-centric > > >>> workflow. This means users less surprise for end users, and > downstream > > >>> distributions can more sensibly override these types of defaults > should > > >>> they chose to. > > >>> > > >>> > > >>> > > >>> Most platforms don't ship with a defaults.xml file yet (except for > BB; > > >>> because Jeff did this work, he followed through for that platform). > > >> There > > >>> are open bugs to add these (ie, CB-5047). > > >>> > > >>> Jeff also added a nice fallback to the CLI: if there does not exist a > > >>> defaults.xml when running "prepare", backup the initial config.xml > to a > > >>> defaults.xml file before we go messing everything up with plugin / > app > > >>> settings. Effectively the config.xml that ships with platforms is > the > > >>> defaults.xml for platforms that don't have one explicitly added. > This > > >> is a > > >>> great default. > > >>> > > >>> However, if there actually were a defaults.xml, the CLI would consume > > >> that > > >>> for its initial input in the prepare process, and completely ignore > the > > >>> platform config.xml. The bin/create script would completely ignore > the > > >>> defaults.xml file and use only the config.xml file. > > >>> > > >>> So, if we shipped both a config.xml *and* defaults.xml, we could > choose > > >>> which settings to set for each workflow. I don't actually think the > > >>> settings should generally differ, and its mildly annoying that we > would > > >>> have mostly duplicated files, but it means we can move such > "optional" > > >>> settings as or etc out of the platform config, > > and > > >>> into the default app config which lives in cordova-cli, since that is
Re: Pull request for adding ubuntu to plugman
Yup. I was planning on asking after I merge them into master today. For plugman and cli. On Thursday, December 5, 2013, Andrew Grieve wrote: > Cool. > > Should you ask for the PRs to be closed? The other (fireos) is: > https://github.com/apache/cordova-plugman/pull/35/files > > > > > On Thu, Dec 5, 2013 at 1:54 PM, Steven Gill > > > wrote: > > > It has been merged into the ubuntu branch of plugman. I am going to spend > > most of the day testing ubuntu + fireOS today before tagging the RCs for > > them > > > > > > > > > > On Thu, Dec 5, 2013 at 10:22 AM, Andrew Grieve > > > > wrote: > > > > > Wanted to check the status of this pull request: > > > > > > https://github.com/apache/cordova-plugman/pull/24 > > > > > >
Re: FileTransfer download null-target
If I understand this correctly, then I am very much +1. There is currently a layer of callback hell and a painful procedure just to download a file you won't care about 10 minutes later, heh. On 06/12/2013 2:44 am, "Ian Clelland" wrote: > On Thu, Dec 5, 2013 at 9:56 AM, Axel Nennker > wrote: > > > Exposing a mkstemp like function would be another issue. > > Where would you put it? The W3C File API does not have this. > > http://www.w3.org/TR/FileAPI/ > > > I just mean that it has similar semantics to mkstemp -- without the > template, I suppose: you are guaranteed to get back a file in a temporary > location, with a name that doesn't collide with any other files that happen > to be there. (Hopefully, with no race conditions, in the event that you > have two outstanding requests at the same time). Not that we literally > implement File.mkstemp(). > > Ian > > > > > > > > I think that implementing "target==null" for FileTransfer.download on > > Android is super simple. > > I guess that it is simple an other platforms too. > > > > I started this for Android > > > > > https://github.com/AxelNennker/cordova-plugin-file-transfer/blob/master/src/android/FileTransfer.java > > (not tested yet. Will do that later) > > > > -Axel > > > > > > > > 2013/12/5 Ian Clelland > > > > > This could be really useful -- like a mkstemp() function -- to avoid > any > > > possibility of name collision, and save the user from the hassle of > > > managing names that they don't really care about anyway. > > > > > > I wonder how many developers have had to independently implement some > > kind > > > of "generate random filename; check for existing file; repeat if true" > > > procedure just to cache files. > > > > > > > > > > > > > > > On Thu, Dec 5, 2013 at 4:57 AM, wrote: > > > > > > > Hi, > > > > > > > > I think a developer who uses FileTransfer's download does not always > > care > > > > to which file the remote content is downloaded to. > > > > > > > > I suggest to allow a target parameter of "null" to denote some > > temporary > > > > file. > > > > > > > > > > > > > > https://github.com/apache/cordova-plugin-file-transfer/blob/master/src/android/FileTransfer.java#L180 > > > > > > > > In the success callback the developer gets a FileEntry and can do > with > > it > > > > whatever is needed e.g. delete it after use. > > > > > > > > Do you think this is usefull for cordova user? > > > > > > > > - Axel > > > > > > > > > > > > > > > > > > https://cordova.apache.org/docs/en/2.5.0/cordova_file_file.md.html#FileTransfer_download > > > > > > > > > >
Re: Pull request for adding ubuntu to plugman
Cool. Should you ask for the PRs to be closed? The other (fireos) is: https://github.com/apache/cordova-plugman/pull/35/files On Thu, Dec 5, 2013 at 1:54 PM, Steven Gill wrote: > It has been merged into the ubuntu branch of plugman. I am going to spend > most of the day testing ubuntu + fireOS today before tagging the RCs for > them > > > > > On Thu, Dec 5, 2013 at 10:22 AM, Andrew Grieve wrote: > > > Wanted to check the status of this pull request: > > > > https://github.com/apache/cordova-plugman/pull/24 > > >
Re: Camera API: correctOrientation
Here's the test app: https://github.com/johnwargo/camera_correctOrientation I ran some tests on Android and orientation is 1 (instead of 0 on iOS) I put some screen shots in the repository to show what I'm seeing. On 12/5/2013 2:16 PM, purplecabbage wrote: Looking at the code for ios, correctOrientation doesn't modify exif, it rotates image bits. Can you share your test app John? Sent from my iPhone On Dec 5, 2013, at 7:42 AM, "John M. Wargo" wrote: That makes sense. As I only have this iOS 7 device, can someone do a quick test on an older version of the OS? On 12/5/2013 9:51 AM, Andrew Grieve wrote: One explanation is that the iOS camera now always rotates the image for you? On Thu, Dec 5, 2013 at 9:11 AM, John M. Wargo wrote: Jesse, I've been thinking about what you said and I'm not getting it. I created an app that has three buttons, one takes a picture without correctOrientation even defined, another sets correctOrientation to true while the last one sets correctOrientation to false. When I look at the photos on my Mac or in Windows Explorer, all three photos have the same orientation. When I look at the EXIF properties in an EXIF editor, all three photos have orientation set the same value. The editor says its 0, but the field seems to be a two byte value which contains 00 01. Since I'm comparing three photos at the same time, one of them should be turned on its side (the one where correctOrientation is true) while the other two are displayed in portrait orientation. That's expected behavior based on what you say below, but that's not what's happening for me. I'm still leaning toward this particular option being broken. On 12/4/2013 9:04 PM, Jesse wrote: It definitely does something, you just may not notice it. If you try to display an image you took in your app on iOS in any image viewer that does not correctly interpret exif, then the picture will still display correctly. If you remove the code, it will not. @purplecabbage risingj.com On Wed, Dec 4, 2013 at 5:59 PM, John M. Wargo wrote: I can't get it to do anything on iOS, so I think it's broken. Any chance someone can do a quick test to confirm my suspicion? Probably need to remove it from the docs if it doesn't do anything. On 12/4/2013 8:41 PM, Jesse wrote: It appears to do nothing, except on iOS. It is listed as supported on iOS and Android, and back in 1.7, it was iOS only, Android does this: this.correctOrientation = args.getBoolean(8); iOS uses it after the image is captured, and calls imageCorrectedForCaptureOrientation [1] which rotates it according to the orientation of the camera when the picture was taken. [1] https://github.com/apache/cordova-plugin-camera/blob/ master/src/ios/CDVCamera.m#L455 @purplecabbage risingj.com On Wed, Dec 4, 2013 at 5:25 PM, Josh Soref wrote: John wrote: Can someone explain to me what correctOrientation is supposed to do? http://docs.phonegap.com/en/1.7.0/cordova_camera_camera.md.html Lists a bunch of platforms that don't implement it. My guess is that some older platforms wouldn't automatically switch between portrait and landscape orientations for photos. - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
RE: Plugins Release today
Thank you, Steve! It is definitely a good reserve way to proceed, but I think we should target to single post and no changes after so I'm discussing options with my colleagues to see if there is an easy way to achieve this. As for the current release let's keep it as is in this situation. Thank you! -Sergey -Original Message- From: Steven Gill [mailto:stevengil...@gmail.com] Sent: Thursday, December 5, 2013 10:52 PM To: dev@cordova.apache.org Subject: Re: Plugins Release today Hey Sergey, We can still add the lines. The File plugin didn't get released with this release. Feel free to share the line you want added about contacts with me and I can add it to the blog post. You are always welcomed to go edit the blog post by pulling down the site if you want to go that route instead. -Steve On Thu, Dec 5, 2013 at 12:38 AM, Sergey Grebnov (Akvelon) < v-seg...@microsoft.com> wrote: > Congrats and thx! > > I have the only following concern - since release info review process > goes very fast (during my night) I can't participate in it :) For > example for > WP8 I would love to add one line note about important fixes in > Contacts api and File api. I'll figure out how we can improve this > with Jesse and my US team. > > Thx! > Sergey > -Original Message- > From: Carlos Santana [mailto:csantan...@gmail.com] > Sent: Thursday, December 5, 2013 8:44 AM > To: dev@cordova.apache.org > Subject: Re: Plugins Release today > > Thanks Steve! > > > On Wed, Dec 4, 2013 at 11:07 PM, Andrew Grieve > wrote: > > > Great job! Thanks indeed! > > > > > > On Wed, Dec 4, 2013 at 11:01 PM, Brian LeRoux wrote: > > > > > thx Steve! > > > > > > > > > On Thu, Dec 5, 2013 at 2:47 PM, Steven Gill > > > > > > wrote: > > > > > > > Plugins have been released! > > > > > > > > http://cordova.apache.org/news/2013/12/04/plugins-release.html > > > > https://twitter.com/apachecordova/status/408441655222476800 > > > > > > > > device-motion and battery-status haven't been published yet due > > > > to a > > > error > > > > I ran into with plugman publish. I have pinged Anis to take a look. > > They > > > > will be up asap. > > > > > > > > File also didn't get released today. It will hopefully be ready > > > > to get released next week before 3.3.0 final! > > > > > > > > Cheers, > > > > -Steve > > > > > > > > > > > > On Wed, Dec 4, 2013 at 12:55 PM, Josh Soref > > > > > > > wrote: > > > > > > > > > > I suspect we almost always want to test new feature against > > > tip-of-tree > > > > > > (I guess thats master). > > > > > > > > > > For what I believe are hysterical reasons, I think it's > > > > > sometimes > > > called > > > > > "dev". > > > > > > > > > > > So being able to run that but replace some of the > > > > > repos with a different branch would be awesome. > > > > > > > > > > > What if we used the convention of naming feature branches in > > > > > > all > > the > > > > > applicable repos the same thing, > > > > > > that way we can poke CI with a single name and it would > > > > > > check out > > > that > > > > > branch on all the repos if it existed? > > > > > -- > > > > > -- > > > > > - This transmission (including any attachments) may > > > > > contain > > confidential > > > > > information, privileged material (including material protected > > > > > by the solicitor-client or other applicable privileges), or > > > > > constitute > > > > non-public > > > > > information. Any use of this information by anyone other than > > > > > the > > > > intended > > > > > recipient is prohibited. If you have received this > > > > > transmission in > > > error, > > > > > please immediately reply to the sender and delete this > > > > > information > > from > > > > > your system. Use, dissemination, distribution, or reproduction > > > > > of > > this > > > > > transmission by unintended recipients is not authorized and > > > > > may be > > > > unlawful. > > > > > > > > > > > > > > > > > > -- > Carlos Santana > >
Re: [android] How to remove the automatic default of
Alright, I've landed a defaults.xml for ios and android and closed the long standing bugs for this. Aside from removing the tag, I also removed the settings which are overwritten by the app-level config anyway, such as app name, description, tag, etc. Please take a look if you have any concerns. I did leave the default platform preferences/features in there, because those can be overridden in the app config and many really are platform specific. Tested using both the CLI and bin/create workflows to make sure both still work and do what we intent. Now, when a CLI user makes changes to the app config to remove or tags, the final platform config actually reflects those changes. Win. -Michal On Wed, Dec 4, 2013 at 2:31 PM, Tommy-Carlos Williams wrote: > +1 > > This is all sounding great and no matter how much I love the CLI, > supporting both workflows is important. > > > > > On 5 Dec 2013, at 6:13 am, Michal Mocny wrote: > > > Yes, there is no need to change the tools, which is why I like this > > approach. I forgot to mention that part :P > > > > I did not think we previously discussed supplying both config files with > > different default settings. I had previously imagined we would ship > > platforms with only one defaults file (defaults.xml/config.xml whichever > > name) that was consumed by both flows. The function of a defaults.xml > was > > as an implementation detail of CLI to help us treat config.xml as a build > > artifact. Now I am proposing using it as a first class config file that > > gets maintained along with config.xml in platform releases. > > > > -Michal > > > > > > On Wed, Dec 4, 2013 at 1:43 PM, Braden Shepherdson >wrote: > > > >> It's possible I'm misunderstanding something here, but the flow you > >> described here is exactly the one we intended when designing how > >> details.xml was going to work. Platforms ship both files, cli uses > >> defaults.xml where available, and config.xml where not. Platform scripts > >> use config.xml always. > >> > >> I don't think any (many?) Changes to the tools will be necessary to > support > >> this. > >> > >> Braden > >> On Dec 4, 2013 8:25 AM, "Michal Mocny" wrote: > >> > >>> Alright, Andrew and I discussed this and think we have a resolution > that > >>> works with all the use cases (yay for options). > >>> > >>> TLDR; I think we already (accidentally?) support using a different > >> default > >>> platform config file for each of our two workflows. This means we can > >> have > >>> the tag live inside the platform config for > >>> platform-centric workflow, and inside the app config for app-centric > >>> workflow. This means users less surprise for end users, and downstream > >>> distributions can more sensibly override these types of defaults should > >>> they chose to. > >>> > >>> > >>> > >>> Most platforms don't ship with a defaults.xml file yet (except for BB; > >>> because Jeff did this work, he followed through for that platform). > >> There > >>> are open bugs to add these (ie, CB-5047). > >>> > >>> Jeff also added a nice fallback to the CLI: if there does not exist a > >>> defaults.xml when running "prepare", backup the initial config.xml to a > >>> defaults.xml file before we go messing everything up with plugin / app > >>> settings. Effectively the config.xml that ships with platforms is the > >>> defaults.xml for platforms that don't have one explicitly added. This > >> is a > >>> great default. > >>> > >>> However, if there actually were a defaults.xml, the CLI would consume > >> that > >>> for its initial input in the prepare process, and completely ignore the > >>> platform config.xml. The bin/create script would completely ignore the > >>> defaults.xml file and use only the config.xml file. > >>> > >>> So, if we shipped both a config.xml *and* defaults.xml, we could choose > >>> which settings to set for each workflow. I don't actually think the > >>> settings should generally differ, and its mildly annoying that we would > >>> have mostly duplicated files, but it means we can move such "optional" > >>> settings as or etc out of the platform config, > and > >>> into the default app config which lives in cordova-cli, since that is > >> where > >>> users of the CLI expect them to be. > >>> > >>> Note that I think this is important & good because for users of the > >>> platform workflow, they expect to make changes directly to platform > >>> config.xml, but for users of the CLI, we keep harping at them to never > >> edit > >>> those files, yet thats the only way at the moment to remove these > >> optional > >>> defaults we inject for them. > >>> > >>> WDYT? I'm working on a prototype and will report back if the theory > >> works > >>> in practice. > >>> > >>> -Michal > >>> > >>> > >>> > >>> On Tue, Dec 3, 2013 at 9:15 PM, Andrew Grieve > >>> wrote: > >>> > Michal - I'm not s > > > On Tue, Dec 3, 2013 at 3:13 PM, Tommy-Carlos Williams < > >>> to...@devgeeks.org > > wrote: > >>
Re: Camera API: correctOrientation
Looking at the code for ios, correctOrientation doesn't modify exif, it rotates image bits. Can you share your test app John? Sent from my iPhone > On Dec 5, 2013, at 7:42 AM, "John M. Wargo" wrote: > > That makes sense. As I only have this iOS 7 device, can someone do a quick > test on an older version of the OS? > >> On 12/5/2013 9:51 AM, Andrew Grieve wrote: >> One explanation is that the iOS camera now always rotates the image for you? >> >> >>> On Thu, Dec 5, 2013 at 9:11 AM, John M. Wargo wrote: >>> >>> Jesse, >>> >>> I've been thinking about what you said and I'm not getting it. I created >>> an app that has three buttons, one takes a picture without >>> correctOrientation even defined, another sets correctOrientation to true >>> while the last one sets correctOrientation to false. >>> >>> When I look at the photos on my Mac or in Windows Explorer, all three >>> photos have the same orientation. >>> >>> When I look at the EXIF properties in an EXIF editor, all three photos >>> have orientation set the same value. The editor says its 0, but the field >>> seems to be a two byte value which contains 00 01. >>> >>> Since I'm comparing three photos at the same time, one of them should be >>> turned on its side (the one where correctOrientation is true) while the >>> other two are displayed in portrait orientation. That's expected behavior >>> based on what you say below, but that's not what's happening for me. >>> >>> I'm still leaning toward this particular option being broken. >>> >>> On 12/4/2013 9:04 PM, Jesse wrote: It definitely does something, you just may not notice it. If you try to display an image you took in your app on iOS in any image viewer that does not correctly interpret exif, then the picture will still display correctly. If you remove the code, it will not. @purplecabbage risingj.com On Wed, Dec 4, 2013 at 5:59 PM, John M. Wargo wrote: I can't get it to do anything on iOS, so I think it's broken. > Any chance someone can do a quick test to confirm my suspicion? Probably > need to remove it from the docs if it doesn't do anything. > > > On 12/4/2013 8:41 PM, Jesse wrote: > > It appears to do nothing, except on iOS. >> It is listed as supported on iOS and Android, and back in 1.7, it was >> iOS >> only, >> >> Android does this: >> this.correctOrientation = args.getBoolean(8); >> >> iOS uses it after the image is captured, and calls >> imageCorrectedForCaptureOrientation >> [1] which rotates it according to the orientation of the camera when the >> picture was taken. >> >> >> [1] >> https://github.com/apache/cordova-plugin-camera/blob/ >> master/src/ios/CDVCamera.m#L455 >> >> >> @purplecabbage >> risingj.com >> >> >> On Wed, Dec 4, 2013 at 5:25 PM, Josh Soref >> wrote: >> >> John wrote: >> >>> Can someone explain to me what correctOrientation is supposed to do? http://docs.phonegap.com/en/1.7.0/cordova_camera_camera.md.html >>> Lists a bunch of platforms that don't implement it. >>> >>> My guess is that some older platforms wouldn't automatically switch >>> between portrait and landscape orientations for photos. >>> - >>> This transmission (including any attachments) may contain confidential >>> information, privileged material (including material protected by the >>> solicitor-client or other applicable privileges), or constitute >>> non-public >>> information. Any use of this information by anyone other than the >>> intended >>> recipient is prohibited. If you have received this transmission in >>> error, >>> please immediately reply to the sender and delete this information from >>> your system. Use, dissemination, distribution, or reproduction of this >>> transmission by unintended recipients is not authorized and may be >>> unlawful. >
Re: Pull request for adding ubuntu to plugman
It has been merged into the ubuntu branch of plugman. I am going to spend most of the day testing ubuntu + fireOS today before tagging the RCs for them On Thu, Dec 5, 2013 at 10:22 AM, Andrew Grieve wrote: > Wanted to check the status of this pull request: > > https://github.com/apache/cordova-plugman/pull/24 >
Re: amazon-fireos : Added missing section in platform guides
Thanks! I will pull it in On Thu, Dec 5, 2013 at 9:10 AM, Naik, Archana wrote: > Hello, Guys > > I realized a missing section in platform guides for amazon fire os > platform in platform guides. I added it. Here is the pull request: > https://github.com/apache/cordova-docs/pull/161 > > Please merge before we tag 3.3.0 release. Otherwise, Fire OS related > guides won't show up in platform guides. :( > > http://cordova.apache.org/docs/en/edge/guide_platforms_index.md.html#Platform%20Guides > > Thanks > Archana >
Re: Plugins Release today
Hey Sergey, We can still add the lines. The File plugin didn't get released with this release. Feel free to share the line you want added about contacts with me and I can add it to the blog post. You are always welcomed to go edit the blog post by pulling down the site if you want to go that route instead. -Steve On Thu, Dec 5, 2013 at 12:38 AM, Sergey Grebnov (Akvelon) < v-seg...@microsoft.com> wrote: > Congrats and thx! > > I have the only following concern - since release info review process goes > very fast (during my night) I can't participate in it :) For example for > WP8 I would love to add one line note about important fixes in Contacts api > and File api. I'll figure out how we can improve this with Jesse and my US > team. > > Thx! > Sergey > -Original Message- > From: Carlos Santana [mailto:csantan...@gmail.com] > Sent: Thursday, December 5, 2013 8:44 AM > To: dev@cordova.apache.org > Subject: Re: Plugins Release today > > Thanks Steve! > > > On Wed, Dec 4, 2013 at 11:07 PM, Andrew Grieve > wrote: > > > Great job! Thanks indeed! > > > > > > On Wed, Dec 4, 2013 at 11:01 PM, Brian LeRoux wrote: > > > > > thx Steve! > > > > > > > > > On Thu, Dec 5, 2013 at 2:47 PM, Steven Gill > > > wrote: > > > > > > > Plugins have been released! > > > > > > > > http://cordova.apache.org/news/2013/12/04/plugins-release.html > > > > https://twitter.com/apachecordova/status/408441655222476800 > > > > > > > > device-motion and battery-status haven't been published yet due to > > > > a > > > error > > > > I ran into with plugman publish. I have pinged Anis to take a look. > > They > > > > will be up asap. > > > > > > > > File also didn't get released today. It will hopefully be ready to > > > > get released next week before 3.3.0 final! > > > > > > > > Cheers, > > > > -Steve > > > > > > > > > > > > On Wed, Dec 4, 2013 at 12:55 PM, Josh Soref > > > > > > > wrote: > > > > > > > > > > I suspect we almost always want to test new feature against > > > tip-of-tree > > > > > > (I guess thats master). > > > > > > > > > > For what I believe are hysterical reasons, I think it's > > > > > sometimes > > > called > > > > > "dev". > > > > > > > > > > > So being able to run that but replace some of the > > > > > repos with a different branch would be awesome. > > > > > > > > > > > What if we used the convention of naming feature branches in > > > > > > all > > the > > > > > applicable repos the same thing, > > > > > > that way we can poke CI with a single name and it would check > > > > > > out > > > that > > > > > branch on all the repos if it existed? > > > > > > > > > > - This transmission (including any attachments) may contain > > confidential > > > > > information, privileged material (including material protected > > > > > by the solicitor-client or other applicable privileges), or > > > > > constitute > > > > non-public > > > > > information. Any use of this information by anyone other than > > > > > the > > > > intended > > > > > recipient is prohibited. If you have received this transmission > > > > > in > > > error, > > > > > please immediately reply to the sender and delete this > > > > > information > > from > > > > > your system. Use, dissemination, distribution, or reproduction > > > > > of > > this > > > > > transmission by unintended recipients is not authorized and may > > > > > be > > > > unlawful. > > > > > > > > > > > > > > > > > > -- > Carlos Santana > >
Adding a "plugman create" command
Going though pull requests and came upon Lucas' pull request for this. Seems okay to me, anyone have comments about it? https://github.com/apache/cordova-plugman/pull/25 https://issues.apache.org/jira/browse/CB-4886
Pull request for adding ubuntu to plugman
Wanted to check the status of this pull request: https://github.com/apache/cordova-plugman/pull/24
amazon-fireos : Added missing section in platform guides
Hello, Guys I realized a missing section in platform guides for amazon fire os platform in platform guides. I added it. Here is the pull request: https://github.com/apache/cordova-docs/pull/161 Please merge before we tag 3.3.0 release. Otherwise, Fire OS related guides won't show up in platform guides. :( http://cordova.apache.org/docs/en/edge/guide_platforms_index.md.html#Platform%20Guides Thanks Archana
Re: splashscreen docs
Awesome! Hopefully that will ease the pain for other devs. On Thu, Dec 5, 2013 at 10:01 AM, Christian Grobmeier wrote: > Thanks Andrew. > > I have added a comment how I worked around this. Maybe it helps! > > > > On 5 Dec 2013, at 15:46, Andrew Grieve wrote: > > Hmm, I think that documentation page is just flat out wrong. I've filed >> this as: >> >> https://issues.apache.org/jira/browse/CB-5582 >> >> The cordova command line tools unfortunately don't have support for splash >> screens and icons. These are tracked as CB-2606 and CB-3571 respectively. >> >> Thanks for pointing this out! It's certainly an overdue feature so >> hopefully we can address it soon. >> >> >> >> On Thu, Dec 5, 2013 at 7:02 AM, Christian Grobmeier > >wrote: >> >> Hi folks, >>> >>> I am much confused by these docs: >>> >>> http://cordova.apache.org/docs/en/3.2.0/config_ref_ >>> images.md.html#Icons%20and%20Splash%20Screens >>> >>> They say I have to push my splashscreens in $project/www/res/screens/ios. >>> But "cordova build ios" doesn't update the splash screens in >>> $project/platforms/ios/$myproject/Resources/splash. >>> >>> Now later I read I have to copy the files: >>> >>> ios/screen-iphone-landscape-2x.png >>> ios/screen-iphone-landscape.png >>> ios/screen-iphone-portrait-2x.png >>> ios/screen-iphone-portrait.png >>> ios/screen-iphone-portrait-568h-2x.png >>> >>> to my iOS project's Resources/splash with different names. >>> >>> Why should I keep them in my dev folder then? I would have expected >>> Cordova deals for me with that. >>> >>> Thanks >>> Christian >>> >>> >>> --- >>> http://www.grobmeier.de >>> @grobmeier >>> GPG: 0xA5CC90DB >>> >>> > > --- > http://www.grobmeier.de > @grobmeier > GPG: 0xA5CC90DB >
Re: FileTransfer download null-target
On Thu, Dec 5, 2013 at 9:56 AM, Axel Nennker wrote: > Exposing a mkstemp like function would be another issue. > Where would you put it? The W3C File API does not have this. > http://www.w3.org/TR/FileAPI/ I just mean that it has similar semantics to mkstemp -- without the template, I suppose: you are guaranteed to get back a file in a temporary location, with a name that doesn't collide with any other files that happen to be there. (Hopefully, with no race conditions, in the event that you have two outstanding requests at the same time). Not that we literally implement File.mkstemp(). Ian > > > I think that implementing "target==null" for FileTransfer.download on > Android is super simple. > I guess that it is simple an other platforms too. > > I started this for Android > > https://github.com/AxelNennker/cordova-plugin-file-transfer/blob/master/src/android/FileTransfer.java > (not tested yet. Will do that later) > > -Axel > > > > 2013/12/5 Ian Clelland > > > This could be really useful -- like a mkstemp() function -- to avoid any > > possibility of name collision, and save the user from the hassle of > > managing names that they don't really care about anyway. > > > > I wonder how many developers have had to independently implement some > kind > > of "generate random filename; check for existing file; repeat if true" > > procedure just to cache files. > > > > > > > > > > On Thu, Dec 5, 2013 at 4:57 AM, wrote: > > > > > Hi, > > > > > > I think a developer who uses FileTransfer's download does not always > care > > > to which file the remote content is downloaded to. > > > > > > I suggest to allow a target parameter of "null" to denote some > temporary > > > file. > > > > > > > > > https://github.com/apache/cordova-plugin-file-transfer/blob/master/src/android/FileTransfer.java#L180 > > > > > > In the success callback the developer gets a FileEntry and can do with > it > > > whatever is needed e.g. delete it after use. > > > > > > Do you think this is usefull for cordova user? > > > > > > - Axel > > > > > > > > > > > > https://cordova.apache.org/docs/en/2.5.0/cordova_file_file.md.html#FileTransfer_download > > > > > >
Re: Camera API: correctOrientation
That makes sense. As I only have this iOS 7 device, can someone do a quick test on an older version of the OS? On 12/5/2013 9:51 AM, Andrew Grieve wrote: One explanation is that the iOS camera now always rotates the image for you? On Thu, Dec 5, 2013 at 9:11 AM, John M. Wargo wrote: Jesse, I've been thinking about what you said and I'm not getting it. I created an app that has three buttons, one takes a picture without correctOrientation even defined, another sets correctOrientation to true while the last one sets correctOrientation to false. When I look at the photos on my Mac or in Windows Explorer, all three photos have the same orientation. When I look at the EXIF properties in an EXIF editor, all three photos have orientation set the same value. The editor says its 0, but the field seems to be a two byte value which contains 00 01. Since I'm comparing three photos at the same time, one of them should be turned on its side (the one where correctOrientation is true) while the other two are displayed in portrait orientation. That's expected behavior based on what you say below, but that's not what's happening for me. I'm still leaning toward this particular option being broken. On 12/4/2013 9:04 PM, Jesse wrote: It definitely does something, you just may not notice it. If you try to display an image you took in your app on iOS in any image viewer that does not correctly interpret exif, then the picture will still display correctly. If you remove the code, it will not. @purplecabbage risingj.com On Wed, Dec 4, 2013 at 5:59 PM, John M. Wargo wrote: I can't get it to do anything on iOS, so I think it's broken. Any chance someone can do a quick test to confirm my suspicion? Probably need to remove it from the docs if it doesn't do anything. On 12/4/2013 8:41 PM, Jesse wrote: It appears to do nothing, except on iOS. It is listed as supported on iOS and Android, and back in 1.7, it was iOS only, Android does this: this.correctOrientation = args.getBoolean(8); iOS uses it after the image is captured, and calls imageCorrectedForCaptureOrientation [1] which rotates it according to the orientation of the camera when the picture was taken. [1] https://github.com/apache/cordova-plugin-camera/blob/ master/src/ios/CDVCamera.m#L455 @purplecabbage risingj.com On Wed, Dec 4, 2013 at 5:25 PM, Josh Soref wrote: John wrote: Can someone explain to me what correctOrientation is supposed to do? http://docs.phonegap.com/en/1.7.0/cordova_camera_camera.md.html Lists a bunch of platforms that don't implement it. My guess is that some older platforms wouldn't automatically switch between portrait and landscape orientations for photos. - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
Re: splashscreen docs
Thanks Andrew. I have added a comment how I worked around this. Maybe it helps! On 5 Dec 2013, at 15:46, Andrew Grieve wrote: Hmm, I think that documentation page is just flat out wrong. I've filed this as: https://issues.apache.org/jira/browse/CB-5582 The cordova command line tools unfortunately don't have support for splash screens and icons. These are tracked as CB-2606 and CB-3571 respectively. Thanks for pointing this out! It's certainly an overdue feature so hopefully we can address it soon. On Thu, Dec 5, 2013 at 7:02 AM, Christian Grobmeier wrote: Hi folks, I am much confused by these docs: http://cordova.apache.org/docs/en/3.2.0/config_ref_ images.md.html#Icons%20and%20Splash%20Screens They say I have to push my splashscreens in $project/www/res/screens/ios. But "cordova build ios" doesn't update the splash screens in $project/platforms/ios/$myproject/Resources/splash. Now later I read I have to copy the files: ios/screen-iphone-landscape-2x.png ios/screen-iphone-landscape.png ios/screen-iphone-portrait-2x.png ios/screen-iphone-portrait.png ios/screen-iphone-portrait-568h-2x.png to my iOS project's Resources/splash with different names. Why should I keep them in my dev folder then? I would have expected Cordova deals for me with that. Thanks Christian --- http://www.grobmeier.de @grobmeier GPG: 0xA5CC90DB --- http://www.grobmeier.de @grobmeier GPG: 0xA5CC90DB
Re: FileTransfer download null-target
Exposing a mkstemp like function would be another issue. Where would you put it? The W3C File API does not have this. http://www.w3.org/TR/FileAPI/ I think that implementing "target==null" for FileTransfer.download on Android is super simple. I guess that it is simple an other platforms too. I started this for Android https://github.com/AxelNennker/cordova-plugin-file-transfer/blob/master/src/android/FileTransfer.java (not tested yet. Will do that later) -Axel 2013/12/5 Ian Clelland > This could be really useful -- like a mkstemp() function -- to avoid any > possibility of name collision, and save the user from the hassle of > managing names that they don't really care about anyway. > > I wonder how many developers have had to independently implement some kind > of "generate random filename; check for existing file; repeat if true" > procedure just to cache files. > > > > > On Thu, Dec 5, 2013 at 4:57 AM, wrote: > > > Hi, > > > > I think a developer who uses FileTransfer's download does not always care > > to which file the remote content is downloaded to. > > > > I suggest to allow a target parameter of "null" to denote some temporary > > file. > > > > > https://github.com/apache/cordova-plugin-file-transfer/blob/master/src/android/FileTransfer.java#L180 > > > > In the success callback the developer gets a FileEntry and can do with it > > whatever is needed e.g. delete it after use. > > > > Do you think this is usefull for cordova user? > > > > - Axel > > > > > > > https://cordova.apache.org/docs/en/2.5.0/cordova_file_file.md.html#FileTransfer_download > > >
Re: Camera API: correctOrientation
One explanation is that the iOS camera now always rotates the image for you? On Thu, Dec 5, 2013 at 9:11 AM, John M. Wargo wrote: > Jesse, > > I've been thinking about what you said and I'm not getting it. I created > an app that has three buttons, one takes a picture without > correctOrientation even defined, another sets correctOrientation to true > while the last one sets correctOrientation to false. > > When I look at the photos on my Mac or in Windows Explorer, all three > photos have the same orientation. > > When I look at the EXIF properties in an EXIF editor, all three photos > have orientation set the same value. The editor says its 0, but the field > seems to be a two byte value which contains 00 01. > > Since I'm comparing three photos at the same time, one of them should be > turned on its side (the one where correctOrientation is true) while the > other two are displayed in portrait orientation. That's expected behavior > based on what you say below, but that's not what's happening for me. > > I'm still leaning toward this particular option being broken. > > > On 12/4/2013 9:04 PM, Jesse wrote: > >> It definitely does something, you just may not notice it. >> If you try to display an image you took in your app on iOS in any image >> viewer that does not correctly interpret exif, then the picture will still >> display correctly. >> If you remove the code, it will not. >> >> @purplecabbage >> risingj.com >> >> >> On Wed, Dec 4, 2013 at 5:59 PM, John M. Wargo wrote: >> >> I can't get it to do anything on iOS, so I think it's broken. >>> >>> Any chance someone can do a quick test to confirm my suspicion? Probably >>> need to remove it from the docs if it doesn't do anything. >>> >>> >>> On 12/4/2013 8:41 PM, Jesse wrote: >>> >>> It appears to do nothing, except on iOS. It is listed as supported on iOS and Android, and back in 1.7, it was iOS only, Android does this: this.correctOrientation = args.getBoolean(8); iOS uses it after the image is captured, and calls imageCorrectedForCaptureOrientation [1] which rotates it according to the orientation of the camera when the picture was taken. [1] https://github.com/apache/cordova-plugin-camera/blob/ master/src/ios/CDVCamera.m#L455 @purplecabbage risingj.com On Wed, Dec 4, 2013 at 5:25 PM, Josh Soref wrote: John wrote: > Can someone explain to me what correctOrientation is supposed to do? >> >> http://docs.phonegap.com/en/1.7.0/cordova_camera_camera.md.html > > Lists a bunch of platforms that don't implement it. > > My guess is that some older platforms wouldn't automatically switch > between portrait and landscape orientations for photos. > - > This transmission (including any attachments) may contain confidential > information, privileged material (including material protected by the > solicitor-client or other applicable privileges), or constitute > non-public > information. Any use of this information by anyone other than the > intended > recipient is prohibited. If you have received this transmission in > error, > please immediately reply to the sender and delete this information from > your system. Use, dissemination, distribution, or reproduction of this > transmission by unintended recipients is not authorized and may be > unlawful. > > > > >
Re: splashscreen docs
Hmm, I think that documentation page is just flat out wrong. I've filed this as: https://issues.apache.org/jira/browse/CB-5582 The cordova command line tools unfortunately don't have support for splash screens and icons. These are tracked as CB-2606 and CB-3571 respectively. Thanks for pointing this out! It's certainly an overdue feature so hopefully we can address it soon. On Thu, Dec 5, 2013 at 7:02 AM, Christian Grobmeier wrote: > Hi folks, > > I am much confused by these docs: > > http://cordova.apache.org/docs/en/3.2.0/config_ref_ > images.md.html#Icons%20and%20Splash%20Screens > > They say I have to push my splashscreens in $project/www/res/screens/ios. > But "cordova build ios" doesn't update the splash screens in > $project/platforms/ios/$myproject/Resources/splash. > > Now later I read I have to copy the files: > > ios/screen-iphone-landscape-2x.png > ios/screen-iphone-landscape.png > ios/screen-iphone-portrait-2x.png > ios/screen-iphone-portrait.png > ios/screen-iphone-portrait-568h-2x.png > > to my iOS project's Resources/splash with different names. > > Why should I keep them in my dev folder then? I would have expected > Cordova deals for me with that. > > Thanks > Christian > > > --- > http://www.grobmeier.de > @grobmeier > GPG: 0xA5CC90DB >
Re: Whitelist.java config.xml access missing scheme
On Thu, Dec 5, 2013 at 6:07 AM, wrote: > Hi, > > I think that this code is wrong: > > https://github.com/apache/cordova-android/blob/master/framework/src/org/apache/cordova/Whitelist.java#L133 > > If the scheme is null then the scheme of the UrlPattern should be null. > The UrlPattern class is coded to handle scheme==null as allow access. > > I think that a missing scheme should be handled as "*://host/path" NOT as " > http://host/path || https://host/path";. > FWIW, I agree that it's inconsistent with the way that the wildcards are implemented. That logic was present in cordova-android long before I got around to rewriting the whitelist earlier this year. I left it in so as not to change the behaviour for existing apps that just have "example.com" in their whitelist. > > In reality this does not make much difference though... > > -Axel > > Another thing: The definition of the W3C Widget element's access > definition is that if port is missing the default port of the scheme must > be used. > I think that the UrlPattern matcher should know about default ports for > well known schemes... > http://developer.chrome.com/apps/match_patterns.html is what the current whitelist is modeled on (with a couple of exceptions for backwards compatibility). There's nothing specific in that page about ports, though. I think you may be right -- if the user whitelists "http://example.com/*";, he probably isn't intending http://example.com:25/ to be accessible, but http://example.com:80/ should be. In that case, "*://example.com/*" should match all ports, unless restricted like "*://example.com:123/*" Ian
RE: Cordova and Crosswalk
> -Original Message- > From: brian.ler...@gmail.com [mailto:brian.ler...@gmail.com] On Behalf Of > Brian LeRoux > Sent: Thursday, December 05, 2013 6:45 AM > To: dev@cordova.apache.org > Subject: Re: Cordova and Crosswalk > > We've been discussing allowing alternate rendering engines in Android for some > time. FireOS is basically this. GeckoView is around the corner from Mozilla. > It is a > likely future. > I think the alternate rendering engine idea is great. So there will be an rendering engine adaption layer in Cordova Android with several concrete implementations (rendering engine plugin?), say WebView, Crosswalk and GeckoView etc., for users to choose at build time (via cli). Is my understanding correct? > I'm still curious if Crosswalk wants to donate to Apache? > Crosswalk Cordova Android (https://github.com/crosswalk-project/crosswalk-cordova-android) is forked from Crodova Android. It is to showcase the possibility and values that running Cordova on Crosswalk. If the value are acknowledged by upstream Cordova, it is straight forward to merge it back in an appropriate way, say alternate rendering engine design. Does it align with what you mean by 'donation'? Thanks, -ningxin > > On Thu, Dec 5, 2013 at 2:46 AM, Jonathan Bond-Caron > > wrote: > > > On Tue Dec 3 08:40 AM, Hu, Ningxin wrote: > > > Your thoughts about the integration? > > > Is it possible to support Crosswalk runtime as a platform in Cordova > > > upstream? > > > > > > [2]: https://github.com/crosswalk-project/crosswalk-cordova-android > > > > It looks really awesome, can't wait to try it out. > > > > I have some concerns about more platforms and the terminology. > > Android should be considered as the platform, maybe Cordova needs a > > new flag, -engine? > > > > e.g. cli perspective > > > cordova prepare android > > #uses WebView of OS > > > cordova prepare android -engine crosswalk #uses Crosswalk > > > cordova prepare android -engine ChromeView #uses ChromeView > bundled > > jar > > > > That could solve some issues with windows 8: > > e.g. > > > cordova prepare windows8 > > > cordova prepare windows8 -engine v8.1 #uses/injects 8.1 > > code > > > cordova prepare windows8 -engine crosswalk#uses Crosswalk? > > > > Putting this idea out there, might make the maintenance easier. > > Problem for me is terminology of crosswalk as a platform, it's more > > like an engine that sits on top of the OS. > > > >
Re: Cordova and Crosswalk
I think so. One way I can see this going is to create a Java Interface for the webview and associated classes that Cordova uses, and add to that interface every method that Cordova uses. Then, have implementations of those interfaces by each engine. On Wed, Dec 4, 2013 at 11:55 PM, Hu, Ningxin wrote: > > -Original Message- > > From: Jonathan Bond-Caron [mailto:jbo...@gdesolutions.com] > > Sent: Wednesday, December 04, 2013 11:47 PM > > To: dev@cordova.apache.org > > Subject: RE: Cordova and Crosswalk > > > > On Tue Dec 3 08:40 AM, Hu, Ningxin wrote: > > > Your thoughts about the integration? > > > Is it possible to support Crosswalk runtime as a platform in Cordova > > > upstream? > > > > > > [2]: https://github.com/crosswalk-project/crosswalk-cordova-android > > > > It looks really awesome, can't wait to try it out. > > > > I have some concerns about more platforms and the terminology. > > Sorry for the confusion due to the terminology. > > > Android should be considered as the platform, maybe Cordova needs a new > > flag, -engine? > > > > I agree with your idea. Treating Crosswalk on android as an engine option > for android platform makes sense to me. > > > e.g. cli perspective > > > cordova prepare android > > #uses WebView of OS > > > cordova prepare android -engine crosswalk #uses Crosswalk > > > cordova prepare android -engine ChromeView #uses ChromeView > > bundled jar > > > > That could solve some issues with windows 8: > > e.g. > > > cordova prepare windows8 > > > cordova prepare windows8 -engine v8.1 #uses/injects 8.1 > > code > > > cordova prepare windows8 -engine crosswalk#uses Crosswalk? > > > > Putting this idea out there, might make the maintenance easier. > > Problem for me is terminology of crosswalk as a platform, it's more like > an engine > > that sits on top of the OS. > > So do you agree that the first step is to make Cordova Android engine > exchangeable? > > Thanks, > -ningxin >
Re: Camera API: correctOrientation
Jesse, I've been thinking about what you said and I'm not getting it. I created an app that has three buttons, one takes a picture without correctOrientation even defined, another sets correctOrientation to true while the last one sets correctOrientation to false. When I look at the photos on my Mac or in Windows Explorer, all three photos have the same orientation. When I look at the EXIF properties in an EXIF editor, all three photos have orientation set the same value. The editor says its 0, but the field seems to be a two byte value which contains 00 01. Since I'm comparing three photos at the same time, one of them should be turned on its side (the one where correctOrientation is true) while the other two are displayed in portrait orientation. That's expected behavior based on what you say below, but that's not what's happening for me. I'm still leaning toward this particular option being broken. On 12/4/2013 9:04 PM, Jesse wrote: It definitely does something, you just may not notice it. If you try to display an image you took in your app on iOS in any image viewer that does not correctly interpret exif, then the picture will still display correctly. If you remove the code, it will not. @purplecabbage risingj.com On Wed, Dec 4, 2013 at 5:59 PM, John M. Wargo wrote: I can't get it to do anything on iOS, so I think it's broken. Any chance someone can do a quick test to confirm my suspicion? Probably need to remove it from the docs if it doesn't do anything. On 12/4/2013 8:41 PM, Jesse wrote: It appears to do nothing, except on iOS. It is listed as supported on iOS and Android, and back in 1.7, it was iOS only, Android does this: this.correctOrientation = args.getBoolean(8); iOS uses it after the image is captured, and calls imageCorrectedForCaptureOrientation [1] which rotates it according to the orientation of the camera when the picture was taken. [1] https://github.com/apache/cordova-plugin-camera/blob/ master/src/ios/CDVCamera.m#L455 @purplecabbage risingj.com On Wed, Dec 4, 2013 at 5:25 PM, Josh Soref wrote: John wrote: Can someone explain to me what correctOrientation is supposed to do? http://docs.phonegap.com/en/1.7.0/cordova_camera_camera.md.html Lists a bunch of platforms that don't implement it. My guess is that some older platforms wouldn't automatically switch between portrait and landscape orientations for photos. - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
Re: FileTransfer download null-target
This could be really useful -- like a mkstemp() function -- to avoid any possibility of name collision, and save the user from the hassle of managing names that they don't really care about anyway. I wonder how many developers have had to independently implement some kind of "generate random filename; check for existing file; repeat if true" procedure just to cache files. On Thu, Dec 5, 2013 at 4:57 AM, wrote: > Hi, > > I think a developer who uses FileTransfer's download does not always care > to which file the remote content is downloaded to. > > I suggest to allow a target parameter of "null" to denote some temporary > file. > > https://github.com/apache/cordova-plugin-file-transfer/blob/master/src/android/FileTransfer.java#L180 > > In the success callback the developer gets a FileEntry and can do with it > whatever is needed e.g. delete it after use. > > Do you think this is usefull for cordova user? > > - Axel > > > https://cordova.apache.org/docs/en/2.5.0/cordova_file_file.md.html#FileTransfer_download >
Re: Camera API: correctOrientation
Jesse, Thanks for providing that information. I downloaded an EXIF property viewer and notice that with correctOrientation missing or set to false, there are 18 EXIF properties in the file. When I enable correctOrientation, another 30 EXIF properties are added to the file (for a total of 48). Do you know what part of this actually affects orientation? There's an orientation EXIF property, but it's set to 0 for all three of my test files. Enabling this option adds GPS information to image files on iOS as well. I wonder if this particular option is not named correctly. Should it be called something like enableEXIF with the documentation explaining what features it adds to a file. On 12/4/2013 9:04 PM, Jesse wrote: It definitely does something, you just may not notice it. If you try to display an image you took in your app on iOS in any image viewer that does not correctly interpret exif, then the picture will still display correctly. If you remove the code, it will not. @purplecabbage risingj.com On Wed, Dec 4, 2013 at 5:59 PM, John M. Wargo wrote: I can't get it to do anything on iOS, so I think it's broken. Any chance someone can do a quick test to confirm my suspicion? Probably need to remove it from the docs if it doesn't do anything. On 12/4/2013 8:41 PM, Jesse wrote: It appears to do nothing, except on iOS. It is listed as supported on iOS and Android, and back in 1.7, it was iOS only, Android does this: this.correctOrientation = args.getBoolean(8); iOS uses it after the image is captured, and calls imageCorrectedForCaptureOrientation [1] which rotates it according to the orientation of the camera when the picture was taken. [1] https://github.com/apache/cordova-plugin-camera/blob/ master/src/ios/CDVCamera.m#L455 @purplecabbage risingj.com On Wed, Dec 4, 2013 at 5:25 PM, Josh Soref wrote: John wrote: Can someone explain to me what correctOrientation is supposed to do? http://docs.phonegap.com/en/1.7.0/cordova_camera_camera.md.html Lists a bunch of platforms that don't implement it. My guess is that some older platforms wouldn't automatically switch between portrait and landscape orientations for photos. - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
Re: ios7 overlapping status bar
Ok got it running. Thanks for the pointers. I would love to see this in the docs. Any interest in a patch? On 4 Dec 2013, at 22:04, Shazron wrote: Yeah there have been blog posts about it. Also see: 1. https://gist.github.com/shazron/6602131 2. http://shazronatadobe.wordpress.com/2013/10/15/cordova-ios-and-ios-7-support/ 3. https://issues.apache.org/jira/browse/CB-4918?focusedCommentId=13782197&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13782197 On Wed, Dec 4, 2013 at 12:28 PM, Steven Gill wrote: Hey Christian, I think Icenium did a good summary on their blog. http://www.icenium.com/blog/icenium-team-blog/2013/11/07/everything-hybrid-web-apps-need-to-know-about-the-status-bar-in-ios7 It points to some of the work shaz has done around the iOS status bar problem. On Wed, Dec 4, 2013 at 12:21 PM, Christian Grobmeier wrote: hi folks, i am facing the problem that ios7 overlaps my cordova app. I already googled and found some people are hacking things in obj-c: http://stackoverflow.com/questions/18886195/ios-7- status-bar-overlapping-ui I would prefer not to hack in obj-c. First, lack of skills, second I don't want to commit the xcode project to scm but let cordova generate it. Is this issue known or are there even any recommendations how to address it without hacking Cordova? Thanks! Christian --- http://www.grobmeier.de @grobmeier GPG: 0xA5CC90DB --- http://www.grobmeier.de @grobmeier GPG: 0xA5CC90DB
splashscreen docs
Hi folks, I am much confused by these docs: http://cordova.apache.org/docs/en/3.2.0/config_ref_images.md.html#Icons%20and%20Splash%20Screens They say I have to push my splashscreens in $project/www/res/screens/ios. But "cordova build ios" doesn't update the splash screens in $project/platforms/ios/$myproject/Resources/splash. Now later I read I have to copy the files: ios/screen-iphone-landscape-2x.png ios/screen-iphone-landscape.png ios/screen-iphone-portrait-2x.png ios/screen-iphone-portrait.png ios/screen-iphone-portrait-568h-2x.png to my iOS project's Resources/splash with different names. Why should I keep them in my dev folder then? I would have expected Cordova deals for me with that. Thanks Christian --- http://www.grobmeier.de @grobmeier GPG: 0xA5CC90DB
Whitelist.java config.xml access missing scheme
Hi, I think that this code is wrong: https://github.com/apache/cordova-android/blob/master/framework/src/org/apache/cordova/Whitelist.java#L133 If the scheme is null then the scheme of the UrlPattern should be null. The UrlPattern class is coded to handle scheme==null as allow access. I think that a missing scheme should be handled as "*://host/path" NOT as "http://host/path || https://host/path";. In reality this does not make much difference though... -Axel Another thing: The definition of the W3C Widget element's access definition is that if port is missing the default port of the scheme must be used. I think that the UrlPattern matcher should know about default ports for well known schemes...
FileTransfer download null-target
Hi, I think a developer who uses FileTransfer's download does not always care to which file the remote content is downloaded to. I suggest to allow a target parameter of "null" to denote some temporary file. https://github.com/apache/cordova-plugin-file-transfer/blob/master/src/android/FileTransfer.java#L180 In the success callback the developer gets a FileEntry and can do with it whatever is needed e.g. delete it after use. Do you think this is usefull for cordova user? - Axel https://cordova.apache.org/docs/en/2.5.0/cordova_file_file.md.html#FileTransfer_download
RE: Plugins Release today
Congrats and thx! I have the only following concern - since release info review process goes very fast (during my night) I can't participate in it :) For example for WP8 I would love to add one line note about important fixes in Contacts api and File api. I'll figure out how we can improve this with Jesse and my US team. Thx! Sergey -Original Message- From: Carlos Santana [mailto:csantan...@gmail.com] Sent: Thursday, December 5, 2013 8:44 AM To: dev@cordova.apache.org Subject: Re: Plugins Release today Thanks Steve! On Wed, Dec 4, 2013 at 11:07 PM, Andrew Grieve wrote: > Great job! Thanks indeed! > > > On Wed, Dec 4, 2013 at 11:01 PM, Brian LeRoux wrote: > > > thx Steve! > > > > > > On Thu, Dec 5, 2013 at 2:47 PM, Steven Gill > > wrote: > > > > > Plugins have been released! > > > > > > http://cordova.apache.org/news/2013/12/04/plugins-release.html > > > https://twitter.com/apachecordova/status/408441655222476800 > > > > > > device-motion and battery-status haven't been published yet due to > > > a > > error > > > I ran into with plugman publish. I have pinged Anis to take a look. > They > > > will be up asap. > > > > > > File also didn't get released today. It will hopefully be ready to > > > get released next week before 3.3.0 final! > > > > > > Cheers, > > > -Steve > > > > > > > > > On Wed, Dec 4, 2013 at 12:55 PM, Josh Soref > > > > > wrote: > > > > > > > > I suspect we almost always want to test new feature against > > tip-of-tree > > > > > (I guess thats master). > > > > > > > > For what I believe are hysterical reasons, I think it's > > > > sometimes > > called > > > > "dev". > > > > > > > > > So being able to run that but replace some of the > > > > repos with a different branch would be awesome. > > > > > > > > > What if we used the convention of naming feature branches in > > > > > all > the > > > > applicable repos the same thing, > > > > > that way we can poke CI with a single name and it would check > > > > > out > > that > > > > branch on all the repos if it existed? > > > > > > > > - This transmission (including any attachments) may contain > confidential > > > > information, privileged material (including material protected > > > > by the solicitor-client or other applicable privileges), or > > > > constitute > > > non-public > > > > information. Any use of this information by anyone other than > > > > the > > > intended > > > > recipient is prohibited. If you have received this transmission > > > > in > > error, > > > > please immediately reply to the sender and delete this > > > > information > from > > > > your system. Use, dissemination, distribution, or reproduction > > > > of > this > > > > transmission by unintended recipients is not authorized and may > > > > be > > > unlawful. > > > > > > > > > > -- Carlos Santana
