Re: Camera API
I went back and looked at the manuscript for PhoneGap Essentials and back then (a year and a half ago) I had tested this and wrote the following: "The targetHeight & targetWidth parameters are supposed to control the height and width of the image obtained using getPicture. In my testing though, the parameters did not affect the resulting picture. The documentation says as well that the parameters must be used in conjunction with each other and that aspect ratio is maintained. This further reinforces that these options cannot work as documented (which my testing has proven) since it doesn't make sense that you have to set both height and width while at the same time maintaining an aspect ratio for the picture. If it truly was maintaining aspect ratio, then I'd expect that only one of the values would be able to be set. To truly maintain aspect ratio, you'd only be able to set either targetHeight or targetWidth, not both." Anyway, I'll do some testing again and post the results. On 8/28/2013 12:15 PM, Shazron wrote: IMO first step would be that we find out what the existing implementations actually do, and doc them do our standard deprecation dance and implement the new shiny and correct functionality On Thu, Aug 29, 2013 at 12:04 AM, James Jong wrote: Several ways we could go here. One is to improve the documentation. iOS chooses the larger image size. I'm not sure if all the platforms do it the same way. I'd be happy to update the doc if it's all the same. Second is to modify the implementation to only require either W or H. Note that we would break backwards compatibility there. -James Jong On Aug 28, 2013, at 10:16 AM, Ray Camden wrote: As a user though, that doesn't necessarily make sense. You are saying, "You must give me a H and W, but I'm going to maintain the aspect ratio no matter what." Given that, which side is "corrected" if I pass a H and W that do not maintain the aspect ratio? Do we document it? I've worked on another platform that provides a way to pass a H and W that act as a bounding box, so if I use 150x150, my final result will be no bigger than 150x150, but possibly smaller in order to maintain aspect ratio. If that is what PG is doing, then the docs should clearly spell that out. Maybe it is assumed by "Aspect ratio remains constant", but I think it could be clearer. On 8/28/13 9:04 AM, "James Jong" wrote: You're right that it could be calculated based on one or the other. The code expects both today. I think the point is to be clear that the aspect ratio is maintained, so that the user does not expect to be able to arbitrarily set both. -James Jong On Aug 28, 2013, at 7:15 AM, John Wargo wrote: I've got another silly question. In looking at the Camera API, I see the following: targetWidth: Width in pixels to scale image. Must be used with targetHeight. Aspect ratio remains constant. (Number) targetHeight: Height in pixels to scale image. Must be used with targetWidth. Aspect ratio remains constant. (Number) I'm not getting why targetWidth MUST be used with targetHeight (and visa versa) when aspect ratio remains constant. If aspect ratio remains constant, then setting one automatically forces the other - that's the whole point of maintaining aspect ratio, right? If the API is maintaining aspect ratio while sizing the image, then forcing the developer to specify both parameters is simply wasted work. What am I missing here?
Re: Camera API
I could spend some time working through the permutations on a few platforms (Android, BB 10, iOS and Windows Phone), but will be a while before I can get to it - I've got a day job and I'm trying to finish writing a book with three chapters to go and a deadline approaching. If nobody else can get to it before then, then I'll make that my first doc contribution. On 8/28/2013 12:15 PM, Shazron wrote: IMO first step would be that we find out what the existing implementations actually do, and doc them do our standard deprecation dance and implement the new shiny and correct functionality On Thu, Aug 29, 2013 at 12:04 AM, James Jong wrote: Several ways we could go here. One is to improve the documentation. iOS chooses the larger image size. I'm not sure if all the platforms do it the same way. I'd be happy to update the doc if it's all the same. Second is to modify the implementation to only require either W or H. Note that we would break backwards compatibility there. -James Jong On Aug 28, 2013, at 10:16 AM, Ray Camden wrote: As a user though, that doesn't necessarily make sense. You are saying, "You must give me a H and W, but I'm going to maintain the aspect ratio no matter what." Given that, which side is "corrected" if I pass a H and W that do not maintain the aspect ratio? Do we document it? I've worked on another platform that provides a way to pass a H and W that act as a bounding box, so if I use 150x150, my final result will be no bigger than 150x150, but possibly smaller in order to maintain aspect ratio. If that is what PG is doing, then the docs should clearly spell that out. Maybe it is assumed by "Aspect ratio remains constant", but I think it could be clearer. On 8/28/13 9:04 AM, "James Jong" wrote: You're right that it could be calculated based on one or the other. The code expects both today. I think the point is to be clear that the aspect ratio is maintained, so that the user does not expect to be able to arbitrarily set both. -James Jong On Aug 28, 2013, at 7:15 AM, John Wargo wrote: I've got another silly question. In looking at the Camera API, I see the following: targetWidth: Width in pixels to scale image. Must be used with targetHeight. Aspect ratio remains constant. (Number) targetHeight: Height in pixels to scale image. Must be used with targetWidth. Aspect ratio remains constant. (Number) I'm not getting why targetWidth MUST be used with targetHeight (and visa versa) when aspect ratio remains constant. If aspect ratio remains constant, then setting one automatically forces the other - that's the whole point of maintaining aspect ratio, right? If the API is maintaining aspect ratio while sizing the image, then forcing the developer to specify both parameters is simply wasted work. What am I missing here?
Re: Published CLI 3.07 may have Windows line endings, and is generally broken.
Yah, there should be something to catch this cause I could see it happening again down the road. I just republished on an mac and it seems to work fine now. ~Benn On Wed, Aug 28, 2013 at 9:55 AM, Carlos Santana wrote: > What about a git hook (server or client)? > > example of pre-commit hook: > https://gist.github.com/johnjohndoe/4024222 > > reference: > http://git-scm.com/book/en/Customizing-Git-Git-Hooks > > --Carlos > > > > On Wed, Aug 28, 2013 at 11:47 AM, Ian Clelland > wrote: > > > Yes, by 4684, I mean 4686 :) > > > > Thanks > > > > > > > > On Wed, Aug 28, 2013 at 11:44 AM, Shazron wrote: > > > > > CB-4686 actually > > > https://issues.apache.org/jira/browse/CB-4686 > > > > > > > > > On Wed, Aug 28, 2013 at 10:19 PM, Ian Clelland > > >wrote: > > > > > > > From the discussion on CB-4684, it looks like the latest CLI (3.0.7) > is > > > > broken on non-windows environments. > > > > > > > > The line endings have changed from \n to \r\n, and Bash is confused. > > > > > > > > The quick fix seems to be to republish from Unix, and declare "Don't > > > > publish from a Windows machine". > > > > > > > > I feel like there should be a better solution, as this must come up > all > > > the > > > > time in other projects, but this bug is two years old and still open: > > > > https://github.com/isaacs/npm/issues/2097 > > > > > > > > Ian > > > > > > > > > > > > > -- > Carlos Santana > >
Re: config.xml refactoring
James, I think that sounds like what we've been thinking -- but, why do you expect to need to copy something when doing an upgrade? Is it because you think upgrade means re-creating a new workspace (which is kinda true right now)? We are hoping to support in-place upgrades, with no copies needed. -Michal On Wed, Aug 28, 2013 at 4:34 PM, James Jong wrote: > I think you have covered the common workflows. Some developers will have > their own workflow but it should resemble the bin script method in the end. > > What I'd like to see is the ability to have my app's user config.xml (1 > per platform would be fine) and have defaults for what is not specified > there. The user specified config.xml takes precedence. So when I upgrade, > I just need to copy over the config.xml. > > -James Jong > > On Aug 28, 2013, at 2:56 PM, Michal Mocny wrote: > > > supporting platforms/ as generated content (aka "build artifact") is > > certainly an ultimate goal, but only for the CLI workflow, and even then > we > > would love to suport fallback to sane actions when users don't see it > that > > way and do modify platforms/. > > > > Second, a single config.xml shared for all platforms, modified directly > by > > the user maybe might be possible (may involve tags or just > > whitelisted tag per platform), but I'm not sure thats really what we > want: > > * Plugins modify it anyway, so its not really the final version > > * When we upgrade platforms we may want to add/remove/change default > > values, so its better to separate platform defaults from user explicit > > choices > > > > -Michal > > > > On Wed, Aug 28, 2013 at 2:30 PM, Gorkem Ercan >wrote: > > > >> We (JBoss Tools) have been playing with ideas on how to work with > >> config.xml. One thing we do right now is to have only one config.xml > file, > >> we try to treat config.xml as a universal way of defining cordova > >> applications. We do not have platform versions of config,xml (l think > cli > >> massages them per platform right now) but rather copy the config.xml to > >> platform directory (I guess on CLI this would be at the prepare stage) > . I > >> think what the developer works with and what gets deployed in the > >> application should be same. It prevents any surprises to developer when > >> he/she is trying to debug a problem. I guess use case/requirement here > is > >> not to have config.xml differences between platforms. > >> > >> As a note we treat platforms/... directory as generated content (and > >> regenerate them when needed). > >> -- > >> Gorkem > >> > >> > >> On Wed, Aug 28, 2013 at 1:49 PM, Braden Shepherdson < > bra...@chromium.org > >>> wrote: > >> > >>> So we have several bugs[1][2][3] about fixing the handling of > config.xml > >>> and of upgrading CLI projects. Upgrading platforms is hard because the > >> user > >>> might have been modifying files in the platforms/foo directory, and we > >>> don't want to go overwriting them. Most of the time the file that's > been > >>> changed is the platform's config.xml. > >>> > >>> So we (the Google team) are working on a proposal for rearranging how > we > >>> handle config.xml files in order to make upgrades easier, and solving > >> some > >>> of these other problems (splash screens) easier. Also to make the CLI > >>> tooling simpler, because currently the platform config.xml file is both > >> the > >>> input and output of several processes (mainly adding and removing > >> plugins, > >>> as well as cordova prepare). > >>> > >>> What we want to know, in writing this proposal is: what use-cases for > the > >>> config.xml files are there? There seem to be two: > >>> 1. Not using CLI, just bin/create and maybe Plugman. > >>> 2. Using CLI, and needing to upgrade smoothly from the 3.0 world to 3.1 > >>> with these changes to the files. > >>> > >>> Is there anything else we should be thinking about? If not, we'll have > >> the > >>> proposal sent around tomorrow. > >>> > >>> > >>> Braden > >>> > >>> [1] https://issues.apache.org/jira/browse/CB-4624 > >>> [2] https://issues.apache.org/jira/browse/CB-3216 > >>> [3] https://issues.apache.org/jira/browse/CB-3571 > >>> > >> > >
Re: AIDE Phonegap - develop cordova apps on android
Yeah, an external keyboard would be needed to make it efficient for me. -James Jong On Aug 28, 2013, at 3:04 PM, Joe Bowser wrote: > I'd use this if i had one of those ASUS Transformer devices. Those > things are awesome! > > On Wed, Aug 28, 2013 at 12:01 PM, Anis KADRI wrote: >> It looks pretty cool. However, not sure if I would use something like >> this as I am completely hopeless when it comes to typing on >> touchscreen devices. It might be good for quick testing/edits. >> >> On Wed, Aug 28, 2013 at 10:33 AM, David Kemp wrote: >>> I have never looked, but it's my understanding that building and running >>> code on an iOS device is not really supported. >>> The part that makes this tool interesting is the edit - compile - run >>> cycle right on the device. >>> On Aug 28, 2013 1:01 PM, "Carlos Santana" wrote: >>> wow this is mind blowing. Do you know if something similar for iOS? --Carlos On Wed, Aug 28, 2013 at 11:55 AM, David Kemp wrote: > I have used AIDE previously and found it quite fast and handy. > > This Phonegap version was released Aug 14th. I bought it on the weekend to > see how it stacked up against the previous AIDE offering. Pretty slick > actually. > > https://play.google.com/store/apps/details?id=com.aide.phonegap > -- Carlos Santana
Re: config.xml refactoring
I think you have covered the common workflows. Some developers will have their own workflow but it should resemble the bin script method in the end. What I'd like to see is the ability to have my app's user config.xml (1 per platform would be fine) and have defaults for what is not specified there. The user specified config.xml takes precedence. So when I upgrade, I just need to copy over the config.xml. -James Jong On Aug 28, 2013, at 2:56 PM, Michal Mocny wrote: > supporting platforms/ as generated content (aka "build artifact") is > certainly an ultimate goal, but only for the CLI workflow, and even then we > would love to suport fallback to sane actions when users don't see it that > way and do modify platforms/. > > Second, a single config.xml shared for all platforms, modified directly by > the user maybe might be possible (may involve tags or just > whitelisted tag per platform), but I'm not sure thats really what we want: > * Plugins modify it anyway, so its not really the final version > * When we upgrade platforms we may want to add/remove/change default > values, so its better to separate platform defaults from user explicit > choices > > -Michal > > On Wed, Aug 28, 2013 at 2:30 PM, Gorkem Ercan wrote: > >> We (JBoss Tools) have been playing with ideas on how to work with >> config.xml. One thing we do right now is to have only one config.xml file, >> we try to treat config.xml as a universal way of defining cordova >> applications. We do not have platform versions of config,xml (l think cli >> massages them per platform right now) but rather copy the config.xml to >> platform directory (I guess on CLI this would be at the prepare stage) . I >> think what the developer works with and what gets deployed in the >> application should be same. It prevents any surprises to developer when >> he/she is trying to debug a problem. I guess use case/requirement here is >> not to have config.xml differences between platforms. >> >> As a note we treat platforms/... directory as generated content (and >> regenerate them when needed). >> -- >> Gorkem >> >> >> On Wed, Aug 28, 2013 at 1:49 PM, Braden Shepherdson >> wrote: >> >>> So we have several bugs[1][2][3] about fixing the handling of config.xml >>> and of upgrading CLI projects. Upgrading platforms is hard because the >> user >>> might have been modifying files in the platforms/foo directory, and we >>> don't want to go overwriting them. Most of the time the file that's been >>> changed is the platform's config.xml. >>> >>> So we (the Google team) are working on a proposal for rearranging how we >>> handle config.xml files in order to make upgrades easier, and solving >> some >>> of these other problems (splash screens) easier. Also to make the CLI >>> tooling simpler, because currently the platform config.xml file is both >> the >>> input and output of several processes (mainly adding and removing >> plugins, >>> as well as cordova prepare). >>> >>> What we want to know, in writing this proposal is: what use-cases for the >>> config.xml files are there? There seem to be two: >>> 1. Not using CLI, just bin/create and maybe Plugman. >>> 2. Using CLI, and needing to upgrade smoothly from the 3.0 world to 3.1 >>> with these changes to the files. >>> >>> Is there anything else we should be thinking about? If not, we'll have >> the >>> proposal sent around tomorrow. >>> >>> >>> Braden >>> >>> [1] https://issues.apache.org/jira/browse/CB-4624 >>> [2] https://issues.apache.org/jira/browse/CB-3216 >>> [3] https://issues.apache.org/jira/browse/CB-3571 >>> >>
Re: AIDE Phonegap - develop cordova apps on android
I'd use this if i had one of those ASUS Transformer devices. Those things are awesome! On Wed, Aug 28, 2013 at 12:01 PM, Anis KADRI wrote: > It looks pretty cool. However, not sure if I would use something like > this as I am completely hopeless when it comes to typing on > touchscreen devices. It might be good for quick testing/edits. > > On Wed, Aug 28, 2013 at 10:33 AM, David Kemp wrote: >> I have never looked, but it's my understanding that building and running >> code on an iOS device is not really supported. >> The part that makes this tool interesting is the edit - compile - run >> cycle right on the device. >> On Aug 28, 2013 1:01 PM, "Carlos Santana" wrote: >> >>> wow this is mind blowing. >>> >>> Do you know if something similar for iOS? >>> >>> --Carlos >>> >>> >>> On Wed, Aug 28, 2013 at 11:55 AM, David Kemp wrote: >>> >>> > I have used AIDE previously and found it quite fast and handy. >>> > >>> > This Phonegap version was released Aug 14th. I bought it on the weekend >>> to >>> > see how it stacked up against the previous AIDE offering. Pretty slick >>> > actually. >>> > >>> > https://play.google.com/store/apps/details?id=com.aide.phonegap >>> > >>> >>> >>> >>> -- >>> Carlos Santana >>> >>>
Re: AIDE Phonegap - develop cordova apps on android
It looks pretty cool. However, not sure if I would use something like this as I am completely hopeless when it comes to typing on touchscreen devices. It might be good for quick testing/edits. On Wed, Aug 28, 2013 at 10:33 AM, David Kemp wrote: > I have never looked, but it's my understanding that building and running > code on an iOS device is not really supported. > The part that makes this tool interesting is the edit - compile - run > cycle right on the device. > On Aug 28, 2013 1:01 PM, "Carlos Santana" wrote: > >> wow this is mind blowing. >> >> Do you know if something similar for iOS? >> >> --Carlos >> >> >> On Wed, Aug 28, 2013 at 11:55 AM, David Kemp wrote: >> >> > I have used AIDE previously and found it quite fast and handy. >> > >> > This Phonegap version was released Aug 14th. I bought it on the weekend >> to >> > see how it stacked up against the previous AIDE offering. Pretty slick >> > actually. >> > >> > https://play.google.com/store/apps/details?id=com.aide.phonegap >> > >> >> >> >> -- >> Carlos Santana >> >>
Re: config.xml refactoring
supporting platforms/ as generated content (aka "build artifact") is certainly an ultimate goal, but only for the CLI workflow, and even then we would love to suport fallback to sane actions when users don't see it that way and do modify platforms/. Second, a single config.xml shared for all platforms, modified directly by the user maybe might be possible (may involve tags or just whitelisted tag per platform), but I'm not sure thats really what we want: * Plugins modify it anyway, so its not really the final version * When we upgrade platforms we may want to add/remove/change default values, so its better to separate platform defaults from user explicit choices -Michal On Wed, Aug 28, 2013 at 2:30 PM, Gorkem Ercan wrote: > We (JBoss Tools) have been playing with ideas on how to work with > config.xml. One thing we do right now is to have only one config.xml file, > we try to treat config.xml as a universal way of defining cordova > applications. We do not have platform versions of config,xml (l think cli > massages them per platform right now) but rather copy the config.xml to > platform directory (I guess on CLI this would be at the prepare stage) . I > think what the developer works with and what gets deployed in the > application should be same. It prevents any surprises to developer when > he/she is trying to debug a problem. I guess use case/requirement here is > not to have config.xml differences between platforms. > > As a note we treat platforms/... directory as generated content (and > regenerate them when needed). > -- > Gorkem > > > On Wed, Aug 28, 2013 at 1:49 PM, Braden Shepherdson >wrote: > > > So we have several bugs[1][2][3] about fixing the handling of config.xml > > and of upgrading CLI projects. Upgrading platforms is hard because the > user > > might have been modifying files in the platforms/foo directory, and we > > don't want to go overwriting them. Most of the time the file that's been > > changed is the platform's config.xml. > > > > So we (the Google team) are working on a proposal for rearranging how we > > handle config.xml files in order to make upgrades easier, and solving > some > > of these other problems (splash screens) easier. Also to make the CLI > > tooling simpler, because currently the platform config.xml file is both > the > > input and output of several processes (mainly adding and removing > plugins, > > as well as cordova prepare). > > > > What we want to know, in writing this proposal is: what use-cases for the > > config.xml files are there? There seem to be two: > > 1. Not using CLI, just bin/create and maybe Plugman. > > 2. Using CLI, and needing to upgrade smoothly from the 3.0 world to 3.1 > > with these changes to the files. > > > > Is there anything else we should be thinking about? If not, we'll have > the > > proposal sent around tomorrow. > > > > > > Braden > > > > [1] https://issues.apache.org/jira/browse/CB-4624 > > [2] https://issues.apache.org/jira/browse/CB-3216 > > [3] https://issues.apache.org/jira/browse/CB-3571 > > >
Re: config.xml refactoring
We (JBoss Tools) have been playing with ideas on how to work with config.xml. One thing we do right now is to have only one config.xml file, we try to treat config.xml as a universal way of defining cordova applications. We do not have platform versions of config,xml (l think cli massages them per platform right now) but rather copy the config.xml to platform directory (I guess on CLI this would be at the prepare stage) . I think what the developer works with and what gets deployed in the application should be same. It prevents any surprises to developer when he/she is trying to debug a problem. I guess use case/requirement here is not to have config.xml differences between platforms. As a note we treat platforms/... directory as generated content (and regenerate them when needed). -- Gorkem On Wed, Aug 28, 2013 at 1:49 PM, Braden Shepherdson wrote: > So we have several bugs[1][2][3] about fixing the handling of config.xml > and of upgrading CLI projects. Upgrading platforms is hard because the user > might have been modifying files in the platforms/foo directory, and we > don't want to go overwriting them. Most of the time the file that's been > changed is the platform's config.xml. > > So we (the Google team) are working on a proposal for rearranging how we > handle config.xml files in order to make upgrades easier, and solving some > of these other problems (splash screens) easier. Also to make the CLI > tooling simpler, because currently the platform config.xml file is both the > input and output of several processes (mainly adding and removing plugins, > as well as cordova prepare). > > What we want to know, in writing this proposal is: what use-cases for the > config.xml files are there? There seem to be two: > 1. Not using CLI, just bin/create and maybe Plugman. > 2. Using CLI, and needing to upgrade smoothly from the 3.0 world to 3.1 > with these changes to the files. > > Is there anything else we should be thinking about? If not, we'll have the > proposal sent around tomorrow. > > > Braden > > [1] https://issues.apache.org/jira/browse/CB-4624 > [2] https://issues.apache.org/jira/browse/CB-3216 > [3] https://issues.apache.org/jira/browse/CB-3571 >
RE: Android & iOS Bridge Improvements (more)
On Wed Aug 7 04:23 PM, Andrew Grieve wrote: > Wrote up some ideas for removing jank from the bridges. > > https://docs.google.com/document/d/1b2igeRoGXpdr_B89W7n2CaiXTspXq9tnr > K5ocsyhNNM/edit# > > Includes content from CB-3900, which I'd previously brought up on the ML. > Also relates to CB-3359 for one of the ideas. > > Feel free to give it a read, add comments & share thoughts of what other > improvements we could make. > For Android, any thoughts on a 'npapi' plugin for the webview like what google gears used to do: http://gears.googlecode.com/svn/trunk/gears/base/npapi/module_android.cc It's locked down but maybe Adobe could 'sign' it and it would be BC compatible with older Android versions? https://groups.google.com/forum/#!topic/android-platform/FGvrCwTC16I It doesn't look like npapi has a bright future though.
Re: config.xml refactoring
FYI: This was a quick whiteboard discussion this morning that started with "why do I need to modify the platform config just to update my application's name", and sorta spiraled into an interesting idea to potentially solve this problem once and for all. Trying to make sure we haven't missed anything before putting the effort into formulating it into an email. On Wed, Aug 28, 2013 at 1:49 PM, Braden Shepherdson wrote: > So we have several bugs[1][2][3] about fixing the handling of config.xml > and of upgrading CLI projects. Upgrading platforms is hard because the user > might have been modifying files in the platforms/foo directory, and we > don't want to go overwriting them. Most of the time the file that's been > changed is the platform's config.xml. > > So we (the Google team) are working on a proposal for rearranging how we > handle config.xml files in order to make upgrades easier, and solving some > of these other problems (splash screens) easier. Also to make the CLI > tooling simpler, because currently the platform config.xml file is both the > input and output of several processes (mainly adding and removing plugins, > as well as cordova prepare). > > What we want to know, in writing this proposal is: what use-cases for the > config.xml files are there? There seem to be two: > 1. Not using CLI, just bin/create and maybe Plugman. > 2. Using CLI, and needing to upgrade smoothly from the 3.0 world to 3.1 > with these changes to the files. > > Is there anything else we should be thinking about? If not, we'll have the > proposal sent around tomorrow. > > > Braden > > [1] https://issues.apache.org/jira/browse/CB-4624 > [2] https://issues.apache.org/jira/browse/CB-3216 > [3] https://issues.apache.org/jira/browse/CB-3571 >
RE: Camera API
The way I handle this server-side is using strings: [100x100] - means a "bounding box", resize so that width & height <= 100 100x[100] - means a fixed 100 width, height varies according to aspect ratio [100]x100 - means a fixed 100 height, width varies according to aspect ratio There's cases where those 3 are useful, would be nice if it could be done client side consistently. -Original Message- From: James Jong [mailto:wjamesj...@gmail.com] Sent: Wednesday, August 28, 2013 12:05 PM To: dev@cordova.apache.org Subject: Re: Camera API Several ways we could go here. One is to improve the documentation. iOS chooses the larger image size. I'm not sure if all the platforms do it the same way. I'd be happy to update the doc if it's all the same. Second is to modify the implementation to only require either W or H. Note that we would break backwards compatibility there. -James Jong On Aug 28, 2013, at 10:16 AM, Ray Camden wrote: > As a user though, that doesn't necessarily make sense. You are saying, > "You must give me a H and W, but I'm going to maintain the aspect > ratio no matter what." Given that, which side is "corrected" if I pass > a H and W that do not maintain the aspect ratio? Do we document it? > I've worked on another platform that provides a way to pass a H and W > that act as a bounding box, so if I use 150x150, my final result will > be no bigger than 150x150, but possibly smaller in order to maintain > aspect ratio. If that is what PG is doing, then the docs should > clearly spell that out. Maybe it is assumed by "Aspect ratio remains > constant", but I think it could be clearer. > > On 8/28/13 9:04 AM, "James Jong" wrote: > >> You're right that it could be calculated based on one or the other. >> The code expects both today. I think the point is to be clear that >> the aspect ratio is maintained, so that the user does not expect to >> be able to arbitrarily set both. >> >> -James Jong >> >> On Aug 28, 2013, at 7:15 AM, John Wargo wrote: >> >>> I've got another silly question. In looking at the Camera API, I see >>> the following: >>> >>> targetWidth: Width in pixels to scale image. Must be used with >>> targetHeight. Aspect ratio remains constant. (Number) >>> >>> targetHeight: Height in pixels to scale image. Must be used with >>> targetWidth. Aspect ratio remains constant. (Number) >>> >>> I'm not getting why targetWidth MUST be used with targetHeight (and >>> visa versa) when aspect ratio remains constant. If aspect ratio >>> remains constant, then setting one automatically forces the other - >>> that's the whole point of maintaining aspect ratio, right? If the >>> API is maintaining aspect ratio while sizing the image, then forcing >>> the developer to specify both parameters is simply wasted work. >>> >>> What am I missing here? >> >
config.xml refactoring
So we have several bugs[1][2][3] about fixing the handling of config.xml and of upgrading CLI projects. Upgrading platforms is hard because the user might have been modifying files in the platforms/foo directory, and we don't want to go overwriting them. Most of the time the file that's been changed is the platform's config.xml. So we (the Google team) are working on a proposal for rearranging how we handle config.xml files in order to make upgrades easier, and solving some of these other problems (splash screens) easier. Also to make the CLI tooling simpler, because currently the platform config.xml file is both the input and output of several processes (mainly adding and removing plugins, as well as cordova prepare). What we want to know, in writing this proposal is: what use-cases for the config.xml files are there? There seem to be two: 1. Not using CLI, just bin/create and maybe Plugman. 2. Using CLI, and needing to upgrade smoothly from the 3.0 world to 3.1 with these changes to the files. Is there anything else we should be thinking about? If not, we'll have the proposal sent around tomorrow. Braden [1] https://issues.apache.org/jira/browse/CB-4624 [2] https://issues.apache.org/jira/browse/CB-3216 [3] https://issues.apache.org/jira/browse/CB-3571
Re: AIDE Phonegap - develop cordova apps on android
I have never looked, but it's my understanding that building and running code on an iOS device is not really supported. The part that makes this tool interesting is the edit - compile - run cycle right on the device. On Aug 28, 2013 1:01 PM, "Carlos Santana" wrote: > wow this is mind blowing. > > Do you know if something similar for iOS? > > --Carlos > > > On Wed, Aug 28, 2013 at 11:55 AM, David Kemp wrote: > > > I have used AIDE previously and found it quite fast and handy. > > > > This Phonegap version was released Aug 14th. I bought it on the weekend > to > > see how it stacked up against the previous AIDE offering. Pretty slick > > actually. > > > > https://play.google.com/store/apps/details?id=com.aide.phonegap > > > > > > -- > Carlos Santana > >
Re: Camera API
+1 on documenting existing implementation first On Wed, Aug 28, 2013 at 12:15 PM, Shazron wrote: > IMO first step would be that we find out what the existing implementations > actually do, and doc them > do our standard deprecation dance and implement the new shiny and correct > functionality > > > On Thu, Aug 29, 2013 at 12:04 AM, James Jong wrote: > > > Several ways we could go here. One is to improve the documentation. iOS > > chooses the larger image size. I'm not sure if all the platforms do it > the > > same way. I'd be happy to update the doc if it's all the same. Second > is > > to modify the implementation to only require either W or H. Note that we > > would break backwards compatibility there. > > > > -James Jong > > > > On Aug 28, 2013, at 10:16 AM, Ray Camden wrote: > > > > > As a user though, that doesn't necessarily make sense. You are saying, > > > "You must give me a H and W, but I'm going to maintain the aspect ratio > > no > > > matter what." Given that, which side is "corrected" if I pass a H and W > > > that do not maintain the aspect ratio? Do we document it? I've worked > on > > > another platform that provides a way to pass a H and W that act as a > > > bounding box, so if I use 150x150, my final result will be no bigger > than > > > 150x150, but possibly smaller in order to maintain aspect ratio. If > that > > > is what PG is doing, then the docs should clearly spell that out. Maybe > > it > > > is assumed by "Aspect ratio remains constant", but I think it could be > > > clearer. > > > > > > On 8/28/13 9:04 AM, "James Jong" wrote: > > > > > >> You're right that it could be calculated based on one or the other. > The > > >> code expects both today. I think the point is to be clear that the > > >> aspect ratio is maintained, so that the user does not expect to be > able > > >> to arbitrarily set both. > > >> > > >> -James Jong > > >> > > >> On Aug 28, 2013, at 7:15 AM, John Wargo wrote: > > >> > > >>> I've got another silly question. In looking at the Camera API, I see > > >>> the following: > > >>> > > >>> targetWidth: Width in pixels to scale image. Must be used with > > >>> targetHeight. Aspect ratio remains constant. (Number) > > >>> > > >>> targetHeight: Height in pixels to scale image. Must be used with > > >>> targetWidth. Aspect ratio remains constant. (Number) > > >>> > > >>> I'm not getting why targetWidth MUST be used with targetHeight (and > > >>> visa versa) when aspect ratio remains constant. If aspect ratio > remains > > >>> constant, then setting one automatically forces the other - that's > the > > >>> whole point of maintaining aspect ratio, right? If the API is > > >>> maintaining aspect ratio while sizing the image, then forcing the > > >>> developer to specify both parameters is simply wasted work. > > >>> > > >>> What am I missing here? > > >> > > > > > > > > -- Carlos Santana
Re: AIDE Phonegap - develop cordova apps on android
wow this is mind blowing. Do you know if something similar for iOS? --Carlos On Wed, Aug 28, 2013 at 11:55 AM, David Kemp wrote: > I have used AIDE previously and found it quite fast and handy. > > This Phonegap version was released Aug 14th. I bought it on the weekend to > see how it stacked up against the previous AIDE offering. Pretty slick > actually. > > https://play.google.com/store/apps/details?id=com.aide.phonegap > -- Carlos Santana
Re: Published CLI 3.07 may have Windows line endings, and is generally broken.
What about a git hook (server or client)? example of pre-commit hook: https://gist.github.com/johnjohndoe/4024222 reference: http://git-scm.com/book/en/Customizing-Git-Git-Hooks --Carlos On Wed, Aug 28, 2013 at 11:47 AM, Ian Clelland wrote: > Yes, by 4684, I mean 4686 :) > > Thanks > > > > On Wed, Aug 28, 2013 at 11:44 AM, Shazron wrote: > > > CB-4686 actually > > https://issues.apache.org/jira/browse/CB-4686 > > > > > > On Wed, Aug 28, 2013 at 10:19 PM, Ian Clelland > >wrote: > > > > > From the discussion on CB-4684, it looks like the latest CLI (3.0.7) is > > > broken on non-windows environments. > > > > > > The line endings have changed from \n to \r\n, and Bash is confused. > > > > > > The quick fix seems to be to republish from Unix, and declare "Don't > > > publish from a Windows machine". > > > > > > I feel like there should be a better solution, as this must come up all > > the > > > time in other projects, but this bug is two years old and still open: > > > https://github.com/isaacs/npm/issues/2097 > > > > > > Ian > > > > > > -- Carlos Santana
Re: Android InAppBrowser with local file blocks XHR on Android 4.1
Fair enough. How about adding the following option on Android?
allowuniversalaccessfromfile - set to 'yes' to allow JavaScript running in
the context of a file scheme to be allowed to access content from any
origin.
Eg.
window.open('iab.html', '_blank',
'location=no,toolbar=no,allowuniversalaccessfromfile =yes');
On 8/27/13 10:57 AM, "Ian Clelland" wrote:
>This looks like a direct port of cordova-android commit #07439ff9 to
>InAppBrowser.
>
>The actual setting controls whether file:///* urls are allowed to execute
>JavaScript from any context; it is usually false for browsers (at least
>Chrome) for security reasons. We turn it on for the main Cordova WebView,
>since (presumably) the developer has full control over what URLs can be
>loaded into that space. InAppBrowser is meant to be more like a regular
>browser view, (i.e. no Cordova APIs), so we haven't chosen to open that
>up.
>
>There is probably a good case to be made for allowing this -- certainly
>not
>as the default setting, but as an option that the app can set in specific
>cases when it knows that the IAB is only going to be used for local
>content, and won't be executing arbitrary scripts.
>
>Ian
>
>
>On Mon, Aug 26, 2013 at 10:56 PM, Shazron wrote:
>
>> I'll let the Android devs comment on this more - seems like an easy
>>patch
>> but the question is more of a policy thing, whether we want it in there
>>at
>> all. If anything, it would be an InAppBrowser option.
>>
>>
>> On Tue, Aug 27, 2013 at 7:02 AM, Sethi, Raman wrote:
>>
>> > Hi All,
>> >
>> > We ran into this issue with the InAppBrowser with local URLs, happens
>>on
>> > JellyBean only.
>> >
>> >
>> > https://issues.apache.org/jira/browse/CB-4083
>> >
>> >
>> > The fix is suggested in the comments if @Shazron or others can take a
>> > look.
>> >
>> >
>> > So far we have been patching it on our side and would like customers
>>to
>> > use the default Cordova plugin.
>> >
>> > Thanks
>> >
>> > Raman
>> >
>> >
>>
Re: Camera API
IMO first step would be that we find out what the existing implementations actually do, and doc them do our standard deprecation dance and implement the new shiny and correct functionality On Thu, Aug 29, 2013 at 12:04 AM, James Jong wrote: > Several ways we could go here. One is to improve the documentation. iOS > chooses the larger image size. I'm not sure if all the platforms do it the > same way. I'd be happy to update the doc if it's all the same. Second is > to modify the implementation to only require either W or H. Note that we > would break backwards compatibility there. > > -James Jong > > On Aug 28, 2013, at 10:16 AM, Ray Camden wrote: > > > As a user though, that doesn't necessarily make sense. You are saying, > > "You must give me a H and W, but I'm going to maintain the aspect ratio > no > > matter what." Given that, which side is "corrected" if I pass a H and W > > that do not maintain the aspect ratio? Do we document it? I've worked on > > another platform that provides a way to pass a H and W that act as a > > bounding box, so if I use 150x150, my final result will be no bigger than > > 150x150, but possibly smaller in order to maintain aspect ratio. If that > > is what PG is doing, then the docs should clearly spell that out. Maybe > it > > is assumed by "Aspect ratio remains constant", but I think it could be > > clearer. > > > > On 8/28/13 9:04 AM, "James Jong" wrote: > > > >> You're right that it could be calculated based on one or the other. The > >> code expects both today. I think the point is to be clear that the > >> aspect ratio is maintained, so that the user does not expect to be able > >> to arbitrarily set both. > >> > >> -James Jong > >> > >> On Aug 28, 2013, at 7:15 AM, John Wargo wrote: > >> > >>> I've got another silly question. In looking at the Camera API, I see > >>> the following: > >>> > >>> targetWidth: Width in pixels to scale image. Must be used with > >>> targetHeight. Aspect ratio remains constant. (Number) > >>> > >>> targetHeight: Height in pixels to scale image. Must be used with > >>> targetWidth. Aspect ratio remains constant. (Number) > >>> > >>> I'm not getting why targetWidth MUST be used with targetHeight (and > >>> visa versa) when aspect ratio remains constant. If aspect ratio remains > >>> constant, then setting one automatically forces the other - that's the > >>> whole point of maintaining aspect ratio, right? If the API is > >>> maintaining aspect ratio while sizing the image, then forcing the > >>> developer to specify both parameters is simply wasted work. > >>> > >>> What am I missing here? > >> > > > >
Re: Camera API
Several ways we could go here. One is to improve the documentation. iOS chooses the larger image size. I'm not sure if all the platforms do it the same way. I'd be happy to update the doc if it's all the same. Second is to modify the implementation to only require either W or H. Note that we would break backwards compatibility there. -James Jong On Aug 28, 2013, at 10:16 AM, Ray Camden wrote: > As a user though, that doesn't necessarily make sense. You are saying, > "You must give me a H and W, but I'm going to maintain the aspect ratio no > matter what." Given that, which side is "corrected" if I pass a H and W > that do not maintain the aspect ratio? Do we document it? I've worked on > another platform that provides a way to pass a H and W that act as a > bounding box, so if I use 150x150, my final result will be no bigger than > 150x150, but possibly smaller in order to maintain aspect ratio. If that > is what PG is doing, then the docs should clearly spell that out. Maybe it > is assumed by "Aspect ratio remains constant", but I think it could be > clearer. > > On 8/28/13 9:04 AM, "James Jong" wrote: > >> You're right that it could be calculated based on one or the other. The >> code expects both today. I think the point is to be clear that the >> aspect ratio is maintained, so that the user does not expect to be able >> to arbitrarily set both. >> >> -James Jong >> >> On Aug 28, 2013, at 7:15 AM, John Wargo wrote: >> >>> I've got another silly question. In looking at the Camera API, I see >>> the following: >>> >>> targetWidth: Width in pixels to scale image. Must be used with >>> targetHeight. Aspect ratio remains constant. (Number) >>> >>> targetHeight: Height in pixels to scale image. Must be used with >>> targetWidth. Aspect ratio remains constant. (Number) >>> >>> I'm not getting why targetWidth MUST be used with targetHeight (and >>> visa versa) when aspect ratio remains constant. If aspect ratio remains >>> constant, then setting one automatically forces the other - that's the >>> whole point of maintaining aspect ratio, right? If the API is >>> maintaining aspect ratio while sizing the image, then forcing the >>> developer to specify both parameters is simply wasted work. >>> >>> What am I missing here? >> >
AIDE Phonegap - develop cordova apps on android
I have used AIDE previously and found it quite fast and handy. This Phonegap version was released Aug 14th. I bought it on the weekend to see how it stacked up against the previous AIDE offering. Pretty slick actually. https://play.google.com/store/apps/details?id=com.aide.phonegap
Re: Cordova-cli not mirroring on github?
Created INFRA-6700 for it. On Wed, Aug 28, 2013 at 11:44 AM, Shazron wrote: > Definitely - at least that's what I've done when this sort of thing > happened before > > > On Wed, Aug 28, 2013 at 9:04 PM, Ian Clelland >wrote: > > > It looks like https://github.com/apache/cordova-cli is not properly > > following the apache repo -- the last commit on github is three weeks > old, > > and there has certainly been some development on CLI since then. > > > > Is this something to open an INFRA ticket for? > > > > Ian > > >
Re: Published CLI 3.07 may have Windows line endings, and is generally broken.
Yes, by 4684, I mean 4686 :) Thanks On Wed, Aug 28, 2013 at 11:44 AM, Shazron wrote: > CB-4686 actually > https://issues.apache.org/jira/browse/CB-4686 > > > On Wed, Aug 28, 2013 at 10:19 PM, Ian Clelland >wrote: > > > From the discussion on CB-4684, it looks like the latest CLI (3.0.7) is > > broken on non-windows environments. > > > > The line endings have changed from \n to \r\n, and Bash is confused. > > > > The quick fix seems to be to republish from Unix, and declare "Don't > > publish from a Windows machine". > > > > I feel like there should be a better solution, as this must come up all > the > > time in other projects, but this bug is two years old and still open: > > https://github.com/isaacs/npm/issues/2097 > > > > Ian > > >
Re: Cordova-cli not mirroring on github?
Definitely - at least that's what I've done when this sort of thing happened before On Wed, Aug 28, 2013 at 9:04 PM, Ian Clelland wrote: > It looks like https://github.com/apache/cordova-cli is not properly > following the apache repo -- the last commit on github is three weeks old, > and there has certainly been some development on CLI since then. > > Is this something to open an INFRA ticket for? > > Ian >
Re: Published CLI 3.07 may have Windows line endings, and is generally broken.
CB-4686 actually https://issues.apache.org/jira/browse/CB-4686 On Wed, Aug 28, 2013 at 10:19 PM, Ian Clelland wrote: > From the discussion on CB-4684, it looks like the latest CLI (3.0.7) is > broken on non-windows environments. > > The line endings have changed from \n to \r\n, and Bash is confused. > > The quick fix seems to be to republish from Unix, and declare "Don't > publish from a Windows machine". > > I feel like there should be a better solution, as this must come up all the > time in other projects, but this bug is two years old and still open: > https://github.com/isaacs/npm/issues/2097 > > Ian >
Published CLI 3.07 may have Windows line endings, and is generally broken.
>From the discussion on CB-4684, it looks like the latest CLI (3.0.7) is broken on non-windows environments. The line endings have changed from \n to \r\n, and Bash is confused. The quick fix seems to be to republish from Unix, and declare "Don't publish from a Windows machine". I feel like there should be a better solution, as this must come up all the time in other projects, but this bug is two years old and still open: https://github.com/isaacs/npm/issues/2097 Ian
Re: Camera API
As a user though, that doesn't necessarily make sense. You are saying, "You must give me a H and W, but I'm going to maintain the aspect ratio no matter what." Given that, which side is "corrected" if I pass a H and W that do not maintain the aspect ratio? Do we document it? I've worked on another platform that provides a way to pass a H and W that act as a bounding box, so if I use 150x150, my final result will be no bigger than 150x150, but possibly smaller in order to maintain aspect ratio. If that is what PG is doing, then the docs should clearly spell that out. Maybe it is assumed by "Aspect ratio remains constant", but I think it could be clearer. On 8/28/13 9:04 AM, "James Jong" wrote: >You're right that it could be calculated based on one or the other. The >code expects both today. I think the point is to be clear that the >aspect ratio is maintained, so that the user does not expect to be able >to arbitrarily set both. > >-James Jong > >On Aug 28, 2013, at 7:15 AM, John Wargo wrote: > >> I've got another silly question. In looking at the Camera API, I see >>the following: >> >> targetWidth: Width in pixels to scale image. Must be used with >>targetHeight. Aspect ratio remains constant. (Number) >> >> targetHeight: Height in pixels to scale image. Must be used with >>targetWidth. Aspect ratio remains constant. (Number) >> >> I'm not getting why targetWidth MUST be used with targetHeight (and >>visa versa) when aspect ratio remains constant. If aspect ratio remains >>constant, then setting one automatically forces the other - that's the >>whole point of maintaining aspect ratio, right? If the API is >>maintaining aspect ratio while sizing the image, then forcing the >>developer to specify both parameters is simply wasted work. >> >> What am I missing here? >
Re: Camera API
I would expect, if anything, that specifying only one of the two dimensions would be desired. I'm guessing one overrides the other if both are specified but don't conform to the aspect ratio; that should probably be in the docs. On Wed, Aug 28, 2013 at 10:04 AM, James Jong wrote: > You're right that it could be calculated based on one or the other. The > code expects both today. I think the point is to be clear that the aspect > ratio is maintained, so that the user does not expect to be able to > arbitrarily set both. > > -James Jong > > On Aug 28, 2013, at 7:15 AM, John Wargo wrote: > > > I've got another silly question. In looking at the Camera API, I see the > following: > > > > targetWidth: Width in pixels to scale image. Must be used with > targetHeight. Aspect ratio remains constant. (Number) > > > > targetHeight: Height in pixels to scale image. Must be used with > targetWidth. Aspect ratio remains constant. (Number) > > > > I'm not getting why targetWidth MUST be used with targetHeight (and visa > versa) when aspect ratio remains constant. If aspect ratio remains > constant, then setting one automatically forces the other - that's the > whole point of maintaining aspect ratio, right? If the API is maintaining > aspect ratio while sizing the image, then forcing the developer to specify > both parameters is simply wasted work. > > > > What am I missing here? > >
Re: Camera API
You're right that it could be calculated based on one or the other. The code expects both today. I think the point is to be clear that the aspect ratio is maintained, so that the user does not expect to be able to arbitrarily set both. -James Jong On Aug 28, 2013, at 7:15 AM, John Wargo wrote: > I've got another silly question. In looking at the Camera API, I see the > following: > > targetWidth: Width in pixels to scale image. Must be used with targetHeight. > Aspect ratio remains constant. (Number) > > targetHeight: Height in pixels to scale image. Must be used with targetWidth. > Aspect ratio remains constant. (Number) > > I'm not getting why targetWidth MUST be used with targetHeight (and visa > versa) when aspect ratio remains constant. If aspect ratio remains constant, > then setting one automatically forces the other - that's the whole point of > maintaining aspect ratio, right? If the API is maintaining aspect ratio while > sizing the image, then forcing the developer to specify both parameters is > simply wasted work. > > What am I missing here?
Cordova-cli not mirroring on github?
It looks like https://github.com/apache/cordova-cli is not properly following the apache repo -- the last commit on github is three weeks old, and there has certainly been some development on CLI since then. Is this something to open an INFRA ticket for? Ian
Camera API
I've got another silly question. In looking at the Camera API, I see the following: targetWidth: Width in pixels to scale image. Must be used with targetHeight. Aspect ratio remains constant. (Number) targetHeight: Height in pixels to scale image. Must be used with targetWidth. Aspect ratio remains constant. (Number) I'm not getting why targetWidth MUST be used with targetHeight (and visa versa) when aspect ratio remains constant. If aspect ratio remains constant, then setting one automatically forces the other - that's the whole point of maintaining aspect ratio, right? If the API is maintaining aspect ratio while sizing the image, then forcing the developer to specify both parameters is simply wasted work. What am I missing here?
Re: Serve vs. opening an HTML file in the browser
On 8/27/13 11:41 PM, "Gord Tanner" wrote: > >I think with some tweaks we could have ripple working on all platform >cordova.js files again. I am going to need to version out a new platform >for cordova to handle the updated hacks and overrides to boot each >platform >cleanly but doesn't seem like an impossible task. If you need someone to help test, just let me know. -rc
