date:20131204

One of the suggestions in the past that I liked was to add console as a
 to the default app template, so (at least for the cli) it gets
automatically installed but can be manually removed.

Whatever we do, I would not like to see it added directly to the platform,
as that would make it hard to remove.

On Wed, Dec 4, 2013 at 4:27 AM, Dick Van den Brink <
d_vandenbr...@outlook.com> wrote:

> I'm not really sure.
> On Android console.logs are visible in logcat without the logger plugin.
> iOS has remote debugging where the console.log are also visible in console.
>
> It might be nice for Windows Phone though
>
>
> > Date: Wed, 4 Dec 2013 19:21:03 +1100
> > Subject: logger / console.log redux
> > From: b...@brian.io
> > To: dev@cordova.apache.org
> >
> > We talked a while back about this. I'm wondering if ppl feel its
> important
> > to having logging capability as a default installed thing. Also, we
> > probably would want this available to the CLI workflow somehow.
> >
> > I know I find logging helpful for development!
> >
> > Thoughts?
>

RE: Cordova and Crosswalk

2013-12-04 Thread Hu, Ningxin

> -Original Message-
> From: Ally Ogilvie [mailto:aogil...@wizcorp.jp]
> Sent: Wednesday, December 04, 2013 4:35 PM
> To: dev@cordova.apache.org
> Subject: Re: Cordova and Crosswalk
> 
> Ningxin,
> 
> Fantastic work! Couple of quick questions;
> 
> - Crosswalk has support for some Cordova plugins, is that the same for ANY
> plugman & Cordova 3.0 compatible plugin?

The major difference is Crosswalk doesn't provide all APIs that WebView has. It 
just provides the essential ones (as we understand, we may add new if they are 
essential). So if the plugin calls some APIs Crosswalk doesn't have, it may 
fail. However, AFAIK, most plugins doesn't need to call WebView APIs.

A good example is Cordova contacts API @ 3.0.0. Contacts API refers to WebView 
although it doesn't use it. We worked with Crodova developers to fix that, see 
details at: https://github.com/apache/cordova-plugin-contacts/pull/8 

As current crosswalk-cordova-android is based 3.0.0, some new versions of 
plugin requires higher version. So we maintain a list of Cordova core plugins @ 
3.0.0 verified with Crosswalk at: 
https://crosswalk-project.org/#wiki/Plugins-List-@-3.0.0-Supported-by-Crosswalk-Cordova-Android
 for your reference.

At meanwhile, we are working to rebase to latest Cordova Android, we believe we 
will get better plugins support.

> - I see Canvas 2D context is supported, how about canvas.getContext("webgl")
> || canvas.getContext("experimental-webgl")
> ? :p

WebGL is supported by default. And Canvas 2D is hardware accelerated.

Thanks,
-ningxin

> Or perhaps, that is a limitation of Blink?
> 
> Exciting stuff!
> Thanks,
> Ally.
> 
> 
> On Wed, Dec 4, 2013 at 3:17 PM, Hu, Ningxin  wrote:
> 
> > > -Original Message-
> > > From: agri...@google.com [mailto:agri...@google.com] On Behalf Of
> > > Andrew Grieve
> > > Sent: Wednesday, December 04, 2013 10:39 AM
> > > To: Andrew Grieve
> > > Cc: dev
> > > Subject: Re: Cordova and Crosswalk
> > >
> > > On Tue, Dec 3, 2013 at 9:08 PM, Andrew Grieve 
> > wrote:
> > >
> > > > Wow, super impressive stuff!
> > > >
> > > > A couple things that weren't clear to me from your website:
> > > > - Is the idea that users will need to install XWalkRuntimeLib.apk
> > > > in addition to their app's .apk?
> > > > - Is it x86-only at the moment?
> > > >
> > > Also - What version of Android is required to use it? 4.0?
> >
> > Android 4.0+.
> >
> > Thanks,
> > -ningxin
> >
> > >
> > >
> > > >
> > > > It seems as though Xwalk is made to match the Android Webview API
> > > > quite closely. I'm hesitant to make a separate repo for
> > > > cordova-crosswalk for this reason. I think we'd benefit a lot more
> > > > by having a single code base that could work with either webview. E.g.
> > > > add a level of abstraction so that cordova-android and Android
> > > > plugins
> > could
> > > use either webview impl.
> > > >
> > > > Does that make sense? WDYT?
> > > >
> > > > Andrew
> > > >
> > > >
> > > >
> > > > On Tue, Dec 3, 2013 at 5:02 PM, Brian LeRoux  wrote:
> > > >
> > > >> Crosswalk is cool. Very aligned with the Cordova approach and our
> > > >> desktop (and even mobile runtime) story right now is somewhat
> > > >> scattered. A unified cross platform approach would be a welcome
> > > >> option for our community to be sure.
> > > >>
> > > >> So, are you guys saying you guys want to donate the source to
> > > >> Apache as a subproject of Cordova (Eg. as cordova-crosswalk)?
> > > >>
> > > >>
> > > >> On Wed, Dec 4, 2013 at 12:40 AM, Hu, Ningxin
> > > >> 
> > > >> wrote:
> > > >>
> > > >> > Hi Cordova Developers,
> > > >> >
> > > >> > Crosswalk [1] is a web application runtime based on Blink and
> > Chromium.
> > > >> It
> > > >> > supports Android 4.0+. By integrating Cordova with Crosswalk,
> > > >> > it brings remote debugging capability, better HTML5 support and
> > > >> > higher
> > > >> performance to
> > > >> > Cordova apps.
> > > >> >
> > > >> > In Crosswalk projects, there is a crosswalk-cordova-android
> > > >> > project [2]
> > > >> to
> > > >> > prove the idea. It is derived from Cordova Android [3] and
> > > >> > embeds
> > > >> Crosswalk
> > > >> > as the HTML5 runtime instead of WebView. Currently It is based
> > > >> > on
> > > >> Cordova
> > > >> > 3.0.0 and supports 16 Cordova APIs. Please check the wiki [4]
> > > >> > for more details.
> > > >> >
> > > >> > Your thoughts about the integration?
> > > >> > Is it possible to support Crosswalk runtime as a platform in
> > > >> > Cordova upstream?
> > > >> >
> > > >> > Thanks,
> > > >> > -ningxin
> > > >> >
> > > >> > [1]: https://crosswalk-project.org/
> > > >> > [2]:
> > > >> > https://github.com/crosswalk-project/crosswalk-cordova-android
> > > >> > [3]: https://github.com/apache/cordova-android
> > > >> > [4]:
> > > >> > https://crosswalk-project.org/#wiki/crosswalk-cordova-android
> > > >> >
> > > >>
> > > >
> > > >
> >
> 
> 
> 
> --
> Ally Ogilvie
> Lead Developer - MobDev. | Wizcorp Inc.

RE: Cordova and Crosswalk

2013-12-04 Thread Jonathan Bond-Caron

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: Camera targetWidth & targetHeight

2013-12-04 Thread Wargo, John

Apparently, when aspect ratio isn't maintained, it grabs one of the properties 
and applies it and drops the other. 

That seems odd to me too. It should fail (and call the error callback).

For me it's weird as well that on iOS in portrait, it's applying the metric to 
the wrong axis.


-Original Message-
From: James Jong [mailto:wjamesj...@gmail.com] 
Sent: Tuesday, December 03, 2013 11:35 AM
To: dev@cordova.apache.org
Subject: Re: Camera targetWidth & targetHeight

For targetWidth = 2048 , targetHeight=768, does it make sense to have the 
result picture with width=768,height=1024?  That seems odd to me.

-James Jong

On Dec 3, 2013, at 7:34 AM, John M. Wargo  wrote:

> It occurred to me this morning that I didn't test a scenario where an 
> application deliberately didn't maintain an appropriate aspect ratio with 
> targetWidth & targetHeight.
> 
> I added a button to my app that set targetWidth to 2048 and targetHeight to 
> 768.
> 
> On Android I got the following:
> 
> Portrait: 768x1024
> Landscape: 1024x768
> 
> On iOS I got the following:
> 
> Portrait: 576x768
> Landscape: 1024x768
> 
> Not what I expected. So apparently the API grabs the smaller property and 
> applies a set aspect ratio to the resulting photo rather than try to do 
> something weird. Notice again that on iOS the API applies the restriction 
> weirdly in portrait.
> 
> On 12/2/2013 10:18 PM, Simon MacDonald wrote:
>> IIRC on Android if you only specify the width or height it will determine
>> what the other value should be by using the same aspect ration as the
>> original image.
>> 
>> 
>> Simon Mac Donald
>> http://hi.im/simonmacdonald
>> 
>> 
>> On Mon, Dec 2, 2013 at 10:15 PM, John M. Wargo  wrote:
>> 
>>> A while back I posted a question regarding Camera targetWidth &
>>> targetHeight properties and how they worked. After some discussion, the
>>> conclusion I reached was that the documentation couldn't be correct about
>>> how it worked since there was no way to determine the camera's resolution
>>> with the current API but the docs said I had to provide both parameters.  I
>>> said I'd do some testing and I have finally gotten around to completing it.
>>> Here's what I discovered:
>>> 
>>> I created an application that allowed me to pass in different values for
>>> targetWidth & targetHeight when taking a picture. I tested at the following
>>> image sizes: 640x480, 800x600, 1024x768 as well as setting only the
>>> targetWidth to 1024 or only the targetHeight to 768.
>>> 
>>> Here's the results:
>>> 
>>> Android
>>> PortraitLandscape
>>> 480x640 640x480
>>> 600x800 800x600
>>> 768x10241024x768
>>> 768x10241024x768
>>> 768x10241024x768
>>> 
>>> 
>>> 
>>> iOS
>>> PortraitLandscape
>>> 360x480 640x480
>>> 450x600 800x600
>>> 576x768 1024x768
>>> 2448x3264   3264x2448
>>> 2448x3264   3264x2448
>>> 
>>> 
>>> 
>>> Windows Phone 8
>>> PortraitLandscape
>>> 1836x3264   3264x1836
>>> 1836x3264   3264x1836
>>> 1836x3264   3264x1836
>>> 1836x3264   3264x1836
>>> 1836x3264   3264x1836
>>> 
>>> 
>>> As you can see, Android properly implements the targetWidth & targetHeight
>>> properties. On iOS, it supports setting both properties, but not instances
>>> where only one is specified. Windows Phone 8 ignores the parameters
>>> completely.  On iOS, when you turn the device on its side, the Camera API
>>> applies the target width or height to the wrong axis (Android does this
>>> well however).
>>> 
>>> I'm trying to test this on a BlackBerry device, but my development
>>> environment is giving me fits right now. I'll work on it in the morning and
>>> publish my results when I get them.
>>> 
>>> I would suggest that the android implementation is as expected and that
>>> the other platforms need their implementations of targetWidth &
>>> targetHeight adjusted so it works correctly. The documentation should be
>>> updated as well as it's incorrect today specifying that both properties
>>> must be provided.
>>> 
>>> If the group doesn't want to support only providing one of the properties,
>>> then I would expect that the onError callback is called when only one is
>>> provided rather than simply ignoring them as is the case with iOS and
>>> Windows Phone.
>>> 
>>> I posted my sample application and a spreadsheet with my results to
>>> https://github.com/johnwargo/camera_res_test
>>> 
>>> --
>>> John M. Wargo
>>> @johnwargo 
>>> www.johnwargo.com 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> -

Re: Windows8 and Contacts Api

2013-12-04 Thread purplecabbage

It is NOT supported on win8 because there is no central contact store. [1] is 
an error. 
On windows8 any app can be a contact provider by extending and registering the 
interface, but the API does not provide create functionality. 

http://msdn.microsoft.com/en-US/library/windows/apps/windows.applicationmodel.contacts.provider

Sent from my iPhone

> On Dec 4, 2013, at 5:37 AM, "Sergey Grebnov (Akvelon)" 
>  wrote:
> 
> Hi,
> Contacts Api is marked as supported on Windows8 as per Platform support 
> overview page [1] but there is no windows8 related code[2] and windows8 is 
> not marked as supported on plugin info page[3].
> Could someone confirm that it is not supported on windows8 (can someone 
> update the page[1] in this case) or point me to the related source code?
> 
> [1] 
> http://docs.phonegap.com/en/3.2.0/guide_overview_index.md.html#Overview_platform_support
> [2] https://github.com/apache/cordova-plugin-contacts
> [3] http://docs.phonegap.com/en/3.2.0/cordova_contacts_contacts.md.html
> 
> Thx!
> Sergey

RE: Camera targetWidth & targetHeight

2013-12-04 Thread Wargo, John

Actually, I like being able to only apply one property. That is a useful use 
case for me. We know the camera is going to maintain an aspect ratio when it 
resizes the image, right? All that matters then is one dimension; aspect ratio 
takes care of the other one.  I would expect it to be implemented better 
though; iOS is applying it to the wrong axis when in portrait mode for example. 

John M. Wargo

-Original Message-
From: Shazron [mailto:shaz...@gmail.com] 
Sent: Tuesday, December 03, 2013 4:24 PM
To: dev@cordova.apache.org
Subject: Re: Camera targetWidth & targetHeight

Thanks for doing this John.

I think the immediate win is to do this:
"If the group doesn't want to support only providing one of the properties,
then I would expect that the onError callback is called when only one is
provided rather than simply ignoring them as is the case with iOS and
Windows Phone."

... since this should be done anyway regardless of what is decided.


On Tue, Dec 3, 2013 at 8:34 AM, James Jong  wrote:

> For targetWidth = 2048 , targetHeight=768, does it make sense to have the
> result picture with width=768,height=1024?  That seems odd to me.
>
> -James Jong
>
> On Dec 3, 2013, at 7:34 AM, John M. Wargo  wrote:
>
> > It occurred to me this morning that I didn't test a scenario where an
> application deliberately didn't maintain an appropriate aspect ratio with
> targetWidth & targetHeight.
> >
> > I added a button to my app that set targetWidth to 2048 and targetHeight
> to 768.
> >
> > On Android I got the following:
> >
> > Portrait: 768x1024
> > Landscape: 1024x768
> >
> > On iOS I got the following:
> >
> > Portrait: 576x768
> > Landscape: 1024x768
> >
> > Not what I expected. So apparently the API grabs the smaller property
> and applies a set aspect ratio to the resulting photo rather than try to do
> something weird. Notice again that on iOS the API applies the restriction
> weirdly in portrait.
> >
> > On 12/2/2013 10:18 PM, Simon MacDonald wrote:
> >> IIRC on Android if you only specify the width or height it will
> determine
> >> what the other value should be by using the same aspect ration as the
> >> original image.
> >>
> >>
> >> Simon Mac Donald
> >> http://hi.im/simonmacdonald
> >>
> >>
> >> On Mon, Dec 2, 2013 at 10:15 PM, John M. Wargo 
> wrote:
> >>
> >>> A while back I posted a question regarding Camera targetWidth &
> >>> targetHeight properties and how they worked. After some discussion, the
> >>> conclusion I reached was that the documentation couldn't be correct
> about
> >>> how it worked since there was no way to determine the camera's
> resolution
> >>> with the current API but the docs said I had to provide both
> parameters.  I
> >>> said I'd do some testing and I have finally gotten around to
> completing it.
> >>> Here's what I discovered:
> >>>
> >>> I created an application that allowed me to pass in different values
> for
> >>> targetWidth & targetHeight when taking a picture. I tested at the
> following
> >>> image sizes: 640x480, 800x600, 1024x768 as well as setting only the
> >>> targetWidth to 1024 or only the targetHeight to 768.
> >>>
> >>> Here's the results:
> >>>
> >>> Android
> >>> PortraitLandscape
> >>> 480x640 640x480
> >>> 600x800 800x600
> >>> 768x10241024x768
> >>> 768x10241024x768
> >>> 768x10241024x768
> >>>
> >>>
> >>>
> >>> iOS
> >>> PortraitLandscape
> >>> 360x480 640x480
> >>> 450x600 800x600
> >>> 576x768 1024x768
> >>> 2448x3264   3264x2448
> >>> 2448x3264   3264x2448
> >>>
> >>>
> >>>
> >>> Windows Phone 8
> >>> PortraitLandscape
> >>> 1836x3264   3264x1836
> >>> 1836x3264   3264x1836
> >>> 1836x3264   3264x1836
> >>> 1836x3264   3264x1836
> >>> 1836x3264   3264x1836
> >>>
> >>>
> >>> As you can see, Android properly implements the targetWidth &
> targetHeight
> >>> properties. On iOS, it supports setting both properties, but not
> instances
> >>> where only one is specified. Windows Phone 8 ignores the parameters
> >>> completely.  On iOS, when you turn the device on its side, the Camera
> API
> >>> applies the target width or height to the wrong axis (Android does this
> >>> well however).
> >>>
> >>> I'm trying to test this on a BlackBerry device, but my development
> >>> environment is giving me fits right now. I'll work on it in the
> morning and
> >>> publish my results when I get them.
> >>>
> >>> I would suggest that the android implementation is as expected and that
> >>> the other platforms need their implementations of targetWidth &
> >>> targetHeight adjusted so it works correctly. The documentation should
> be
> >>> updated as well as it's incorrect today specifying that both properties
> >>> must be provided.
> >>>
> >>> If the group doesn't want to support only providing one of the
> properties,
> >>> then I would expect that the onError callback is called when only one
> is
> >>> provided rather than simply ignoring

RE: logger / console.log redux

2013-12-04 Thread Wargo, John

I was surprised to see it pulled out into a plugin and I constantly forget to 
add it when I'm testing applications. +1 to it being default in the container. 
It's default in browser after all.

John M. Wargo


-Original Message-
From: brian.ler...@gmail.com [mailto:brian.ler...@gmail.com] On Behalf Of Brian 
LeRoux
Sent: Wednesday, December 04, 2013 3:21 AM
To: dev@cordova.apache.org
Subject: logger / console.log redux

We talked a while back about this. I'm wondering if ppl feel its important
to having logging capability as a default installed thing. Also, we
probably would want this available to the CLI workflow somehow.

I know I find logging helpful for development!

Thoughts?

Re: [android] How to remove the automatic default of

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  >wrote:
>
> > Absolutely agree.
> >
> > +1 for * as default, but just as importantly, +1 for never having to hax
> > inside ./platforms/**/* for this stuff.
> >
> > We are already forced to use hooks to enforce ./platforms as a build
> > artefact. Any progress towards the great goal of being able to safely
> > .gitignore the platforms make me feel warm and fuzzy. ;)
> >
> >
> >
> > On 4 Dec 2013, at 7:09 am, Michal Mocny  wrote:
> >
> > > Tommy, absolutely the default should remain *, as I said.
> > >
> > > But I hope we can agree that it should also be possible to override the
> > > default without requiring hacks.  iOS already supports this, so its a
> > > matter of feature parity.
> > >
> > > -Michal
> > >
> > >
> > > On Tue, Dec 3, 2013 at 2:57 PM, Tommy Williams 
> > wrote:
> > >
> > >> Please don't go back to when every new dev had to struggle with the
> > Google
> > >> group or irc to find out why their ajax requests didn't work.
> > >>
> > >> There was a hge discussion at the time that we chose to default
> to *
> > >> On 04/12/2013 6:03 am, "Michal Mocny"  wrote:
> > >>
> > >>> On Tue, Dec 3, 2013 at 1:30 PM, Braden Shepherdson <
> > bra...@chromium.org
> >  wrote:
> > >>>
> >  There are two different files here: one is defaults.xml, which the
> CLI
> >  takes as the basis for its platform config.xml. The other is the
> > >>> config.xml
> >  that you get after running bin/create. In the CLI world, that second
> > >> file
> >  is immediately overwritten by one created from defaults.xml, the
> > >>> top-level
> >  app config.xml, etc.
> > 
> > >>>
> > >>> Okay, thats what I thought we were doing, but I cannot find where/how
> > the
> > >>> defaults.xml is created in the first place.  I see now that it does
> > exist
> > >>> in my CLI projects, but seems not to exist inside our platforms nor
> > CLI,
> > >>> nor can I find the code that generates it.
> > >>>
> > >>>
> > 
> >  I support the second point of removing the 
> from
> > >> the
> >  CLI's hello world template app; it should be turned into a comment.
> > 
> > >>>
> > >>> Seems this is redundant anyway given that the platforms provide this
> > as a
> > >>> default.  Regarding leaving it in as a comment: should we embed the
> > full
> > >>> spec as a comment?  If not, I would just leave a general description
> > and
> > >>> link to the spec docs online.
> > >>>
> > >>>
> >  I don't think we should be including  by
> default
> >  anywhere, unless we really do want to disable the whitelist on that
> >  platform. And if we do want to disabl

Re: logger / console.log redux

Just to be clear: there are costs involved with using the console plugin.
 Aside from performance, which is likely negligible, it misreports line
numbers since the call to the actual native console.log comes from within
the plugin's wrapper.  If you are using safari remote inspector to debug
anyway, where the console plugin doesn't buy you anything, this is just a
terrible price to pay.

If the vast majority of ios developers are doing dev for ios 5 or debugging
exclusively using console.log and never need remote inspector, then maybe I
would see the importance of this here.

Perhaps if the plugin was re-written to not clobber by default, or detect
when inspector is attached somehow and disable itself automatically, I
would be more impressed with seeing this added by default always.  As it
stands, please don't do this in a way that isn't trivial to disable.

-Michal

On Wed, Dec 4, 2013 at 11:21 AM, Wargo, John  wrote:

> I was surprised to see it pulled out into a plugin and I constantly forget
> to add it when I'm testing applications. +1 to it being default in the
> container. It's default in browser after all.
>
> John M. Wargo
>
>
> -Original Message-
> From: brian.ler...@gmail.com [mailto:brian.ler...@gmail.com] On Behalf Of
> Brian LeRoux
> Sent: Wednesday, December 04, 2013 3:21 AM
> To: dev@cordova.apache.org
> Subject: logger / console.log redux
>
> We talked a while back about this. I'm wondering if ppl feel its important
> to having logging capability as a default installed thing. Also, we
> probably would want this available to the CLI workflow somehow.
>
> I know I find logging helpful for development!
>
> Thoughts?
>

Re: country differences in device OS usage

2013-12-04 Thread Marcel Kinard

India:

30% Series 40
27% Android
15% Samsung
11% Symbian
7% unknown
4% Linux
1% Windows Phone
1% iOS

Go to http://gs.statcounter.com and select:
- Stat = Mobile OS
- Region = Asia
- Period = Last 3 months
- Map

On Dec 3, 2013, at 2:45 PM, Steven Gill  wrote:

> Thanks for sharing. What are people in india using?

Re: [android] How to remove the automatic default of

2013-12-04 Thread Braden Shepherdson

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:
> >
> > > Absolutely agree.
> > >
> > > +1 for * as default, but just as importantly, +1 for never having to
> hax
> > > inside ./platforms/**/* for this stuff.
> > >
> > > We are already forced to use hooks to enforce ./platforms as a build
> > > artefact. Any progress towards the great goal of being able to safely
> > > .gitignore the platforms make me feel warm and fuzzy. ;)
> > >
> > >
> > >
> > > On 4 Dec 2013, at 7:09 am, Michal Mocny  wrote:
> > >
> > > > Tommy, absolutely the default should remain *, as I said.
> > > >
> > > > But I hope we can agree that it should also be possible to override
> the
> > > > default without requiring hacks.  iOS already supports this, so its a
> > > > matter of feature parity.
> > > >
> > > > -Michal
> > > >
> > > >
> > > > On Tue, Dec 3, 2013 at 2:57 PM, Tommy Williams 
> > > wrote:
> > > >
> > > >> Please don't go back to when every new dev had to struggle with the
> > > Google
> > > >> group or irc to find out why their ajax requests didn't work.
> > > >>
> > > >> There was a hge discussion at the time that we chose to default
> > to *
> > > >> On 04/12/2013 6:03 am, "Michal Mocny"  wrote:
> > > >>
> > > >>> On Tue, Dec 3, 2013 at 1:30 PM, Braden Shepherdson <
> > > bra...@chromium.org
> > >  wrote:
> > > >>>
> > >  There are two different files here: one is defaults.xml, which the
> > CLI
> > >  takes as the basis for its platform config.xml. The other is the
> > > >>> config.xml
> > >  that you get after running bin/create. In the CLI world, that
> second
> > > >> file
> > >  is immediately overwritten by one created from defaults.xml, the
> > > >>> top-level
> > >  app config.xml, etc.
> > > 
> > > >>>
> > > >>> Okay, thats what I thought we were doing, but I cannot find
> where/how
> > > the
> > > >>> defaults.xml is created in the first place.  I see now that it does
> > > exist
> > > >>> in my CLI projects, but seems not to exist inside our platforms nor
> > > CLI,
> > > >>> nor can I find the code that generates it.
>

Re: [android] How to remove the automatic default of

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:
> > >
> > > > Absolutely agree.
> > > >
> > > > +1 for * as default, but just as importantly, +1 for never having to
> > hax
> > > > inside ./platforms/**/* for this stuff.
> > > >
> > > > We are already forced to use hooks to enforce ./platforms as a build
> > > > artefact. Any progress towards the great goal of being able to safely
> > > > .gitignore the platforms make me feel warm and fuzzy. ;)
> > > >
> > > >
> > > >
> > > > On 4 Dec 2013, at 7:09 am, Michal Mocny  wrote:
> > > >
> > > > > Tommy, absolutely the default should remain *, as I said.
> > > > >
> > > > > But I hope we can agree that it should also be possible to override
> > the
> > > > > default without requiring hacks.  iOS already supports this, so
> its a
> > > > > matter of feature parity.
> > > > >
> > > > > -Michal
> > > > >
> > > > >
> > > > > On Tue, Dec 3, 2013 at 2:57 PM, Tommy Williams  >
> > > > wrote:
> > > > >
> > > > >> Please don't go back to when every new dev had to struggle with
> the
> > > > Google
> > > > >> group or irc to find out why their ajax requests didn't work.
> > > > >>
> > > > >> There was a hge discussion at the time that we chose to
> default
> > > to *
> > > > >> On 04/12/2

Re: [android] How to remove the automatic default of

2013-12-04 Thread Braden Shepherdson

If I remember correctly, that isn't a change for the policy - it's just
that most platforms don't have a defaults.xml yet.

My intention with the defaults.xml change has always been that we ship both
files, and maintain both files, since they're consumed by the different
workflows in different ways.

That could probably have been better-communicated, and we should have
pushed more firmly for getting defaults.xml files added to all platforms.

Braden


On Wed, Dec 4, 2013 at 11: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:
> > > >
> > > > > Absolutely agree.
> > > > >
> > > > > +1 for * as default, but just as importantly, +1 for never having
> to
> > > hax
> > > > > inside ./platforms/**/* for this stuff.
> > > > >
> > > > > We are already forced to use hooks to enforce ./platforms as a
> build
> > > > > artefact. Any progress towards the great goal of being able to
> safely
> > > > > .gitignore the platforms make me feel warm and fuzzy. ;)
> > > > >
> > > > >
> > > > >
> > > > > On 4 Dec 2013, at 7:09 a

Re: [android] How to remove the automatic default of

2013-12-04 Thread Tommy-Carlos Williams

+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:
 
> Absolutely agree.
> 
> +1 for * as default, but just as importantly, +1 for never having to
>>> hax
> inside ./platforms/**/* for this stuff.
> 
> We are already forced to use hooks to enforce ./platforms as a build
> artefact. Any progress towards the great goal of being able to safely
> .gitignore the platforms make me feel warm and fuzzy. ;)
> 
> 
> 
> On 4 Dec 2013, at 7:09 am, Michal Mocny  wrote:
> 
>> Tommy, absolutely the default should remain *, as I said.
>> 
>> But I hope we can agree that it should also be possible to override
>>> the
>> default without requiring hacks.  iOS already supports this, so
>> its a
>> matter of feature parity.
>> 
>> -Michal
>> 
>> 
>> On Tue, Dec 3, 2013 at 2:57 PM, Tommy Williams >> 
> wrote:
>> 
>>> Please don't go back to when every new dev had to struggle with
>> the
> Google
>>> group or ir

Re: proposal to simplify hello world

2013-12-04 Thread Tommy-Carlos Williams

I have been thinking about this, and happy to start a new thread if needed, but 
is there a valid reason to have DisallowOverscroll default to false?

I think we can all agree on getting rid of the nonexistent ‘webviewbounce’ that 
is misleadingly in the default config.xml now… but what about what the default 
should be on the real preference? Is there actually a use case for apps looking 
more like web pages and less like apps? I admit to being fairly 
platform-ignorant outside of the “big two”, so it might be that one of the 
other platforms needs this (though, I hope not, as that would raise a whole 
other issue around different platforms needing different values for a given 
preference since iOS nearly always needs this turned on).

- tommy



On 30 Nov 2013, at 3:33 am, Andrew Grieve  wrote:

> (plus webviewbounce doesn't exist)

Re: Plugins Release today

2013-12-04 Thread Ian Clelland

On Tue, Dec 3, 2013 at 3:29 PM, Steven Gill  wrote:

> On Tue, Dec 3, 2013 at 12:14 PM, Ian Clelland 
> wrote:> Dev becomes a staging branch, essentially; and all actual dev work
> happens
>  > on branches. That sounds like a more sane way to do it. The only reason
> I
> > had it on dev in the first place was to be able to test with buildbot --
> > I'd love to have a way to run those branches through the CI server before
> > merging them into dev/staging/master.
>
>
> Good point. Maybe we standardize a third branch (ducks for cover) that the
> CI server also tests and can be used for breaking dev work. This way dev is
> used for staging and only has code that can be released. I'm afraid that
> this just adds more complexity to plugins though and I am not a fan of
> adding more complexity.
>

I was thinking that it would be cool to be able to force a buildbot build
of a specific branch (though maybe a set of branches would be required) --
it wouldn't have to happen with every commit, but you could say "I'm ready
to merge my feature into dev, let's get buildbot to run all of the tests on
that branch first, to see if the merge will break anything".

That would avoid the need for a third special branch, but would let anybody
with access to buildbot (which we hope is everybody, soon) the ability to
test a branch before merging.

I don't know if it's possible to get buildbot to do that or not; I'll defer
to David on that subject :)

Ian


>
> >
>  Ian
> >
> >
> >
> > > Still confusing at times. It will be
> > > nice once we can get away from this dev-master setup we have. I'm sure
> > many
> > > of us have pushed code to dev that isn't in a sate to be released.
> Maybe
> > > this point/process should get added to our wiki? Not sure where the
> best
> > > place for it would be.
> > >
> > >
> > >
> > >
> > > On Tue, Dec 3, 2013 at 11:34 AM, Ian Clelland 
> > > wrote:
> > >
> > > > Hey Steven,
> > > >
> > > > File is close to being ready, but I haven't merged in my Android code
> > > yet,
> > > > and I want to add some more tests, given how critical the plugin is.
> > I'm
> > > > not comfortable with it going to master yet. If you want, I can pull
> it
> > > out
> > > > of dev and put it on another branch. (There have been some other
> > commits,
> > > > so we could also create a new branch without those commits, and merge
> > > > *that* into master instead)
> > > >
> > > > Let me know how you want to handle it, I'll help out any way I can.
> > > >
> > > > Ian
> > > >
> > > >
> > > > On Tue, Dec 3, 2013 at 2:20 PM, Steven Gill 
> > > > wrote:
> > > >
> > > > > Any plugin issues I should know about before releasing today?
> > > > >
> > > > > Last I heard file and file-transfer dev branches aren't ready to be
> > > > merged
> > > > > into master. Has this changed? Ian?
> > > > >
> > > > > Plugin issues that are still being reviewed/worked on:
> > > > > https://issues.apache.org/jira/browse/CB-5525
> > > > > https://issues.apache.org/jira/browse/CB-5531
> > > > > https://issues.apache.org/jira/browse/CB-5532
> > > > > https://issues.apache.org/jira/browse/CB-5430
> > > > > https://issues.apache.org/jira/browse/CB-5504
> > > > > https://issues.apache.org/jira/browse/CB-5505
> > > > >
> > > > > I can wait until later in the day to release if some of these are
> > > getting
> > > > > resolve today. I know Jesse is looking at the windows ones.
> > > > >
> > > > > We can also just do another plugin release next week (or post
> > holidays)
> > > > > once some of these land.
> > > > >
> > > >
> > >
> >
>

Re: Plugins Release today

2013-12-04 Thread David Kemp

You can definitely do an automated build on demand, but the interesting
part is specifying exactly what to build.
Currently a build is made up of a bunch of repos at one tag, and some other
repos at another tag.
We would need to have a well defined way to specify which tag for each repo.

example:
I want to build cordova-android from the 'fancy-pants' branch, because I am
ready to push it to master

I presumably need:
  cordova-android - fancy-pants branch
  cli,plugman,coho,mobilespec, js from master branch
  all plugins from master branch

If we can ALWAYS say that a demand build is the same as a master build, but
with one repo at a different branch that might be pretty easy...




On Wed, Dec 4, 2013 at 2:44 PM, Ian Clelland  wrote:

> On Tue, Dec 3, 2013 at 3:29 PM, Steven Gill 
> wrote:
>
> > On Tue, Dec 3, 2013 at 12:14 PM, Ian Clelland 
> > wrote:> Dev becomes a staging branch, essentially; and all actual dev
> work
> > happens
> >  > on branches. That sounds like a more sane way to do it. The only
> reason
> > I
> > > had it on dev in the first place was to be able to test with buildbot
> --
> > > I'd love to have a way to run those branches through the CI server
> before
> > > merging them into dev/staging/master.
> >
> >
> > Good point. Maybe we standardize a third branch (ducks for cover) that
> the
> > CI server also tests and can be used for breaking dev work. This way dev
> is
> > used for staging and only has code that can be released. I'm afraid that
> > this just adds more complexity to plugins though and I am not a fan of
> > adding more complexity.
> >
>
> I was thinking that it would be cool to be able to force a buildbot build
> of a specific branch (though maybe a set of branches would be required) --
> it wouldn't have to happen with every commit, but you could say "I'm ready
> to merge my feature into dev, let's get buildbot to run all of the tests on
> that branch first, to see if the merge will break anything".
>
> That would avoid the need for a third special branch, but would let anybody
> with access to buildbot (which we hope is everybody, soon) the ability to
> test a branch before merging.
>
> I don't know if it's possible to get buildbot to do that or not; I'll defer
> to David on that subject :)
>
> Ian
>
>
> >
> > >
> >  Ian
> > >
> > >
> > >
> > > > Still confusing at times. It will be
> > > > nice once we can get away from this dev-master setup we have. I'm
> sure
> > > many
> > > > of us have pushed code to dev that isn't in a sate to be released.
> > Maybe
> > > > this point/process should get added to our wiki? Not sure where the
> > best
> > > > place for it would be.
> > > >
> > > >
> > > >
> > > >
> > > > On Tue, Dec 3, 2013 at 11:34 AM, Ian Clelland 
> > > > wrote:
> > > >
> > > > > Hey Steven,
> > > > >
> > > > > File is close to being ready, but I haven't merged in my Android
> code
> > > > yet,
> > > > > and I want to add some more tests, given how critical the plugin
> is.
> > > I'm
> > > > > not comfortable with it going to master yet. If you want, I can
> pull
> > it
> > > > out
> > > > > of dev and put it on another branch. (There have been some other
> > > commits,
> > > > > so we could also create a new branch without those commits, and
> merge
> > > > > *that* into master instead)
> > > > >
> > > > > Let me know how you want to handle it, I'll help out any way I can.
> > > > >
> > > > > Ian
> > > > >
> > > > >
> > > > > On Tue, Dec 3, 2013 at 2:20 PM, Steven Gill <
> stevengil...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Any plugin issues I should know about before releasing today?
> > > > > >
> > > > > > Last I heard file and file-transfer dev branches aren't ready to
> be
> > > > > merged
> > > > > > into master. Has this changed? Ian?
> > > > > >
> > > > > > Plugin issues that are still being reviewed/worked on:
> > > > > > https://issues.apache.org/jira/browse/CB-5525
> > > > > > https://issues.apache.org/jira/browse/CB-5531
> > > > > > https://issues.apache.org/jira/browse/CB-5532
> > > > > > https://issues.apache.org/jira/browse/CB-5430
> > > > > > https://issues.apache.org/jira/browse/CB-5504
> > > > > > https://issues.apache.org/jira/browse/CB-5505
> > > > > >
> > > > > > I can wait until later in the day to release if some of these are
> > > > getting
> > > > > > resolve today. I know Jesse is looking at the windows ones.
> > > > > >
> > > > > > We can also just do another plugin release next week (or post
> > > holidays)
> > > > > > once some of these land.
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: proposal to simplify hello world

2013-12-04 Thread Josh Soref

> I have been thinking about this, 
> is there a valid reason to have DisallowOverscroll default to false?

> I think we can all agree on getting rid of the nonexistent ‘webviewbounce’ 
> that is misleadingly in the default config.xml now…
> but what about what the default should be on the real preference?
> Is there actually a use case for apps looking more like web pages and less 
> like apps?
> I admit to being fairly platform-ignorant outside of the “big two”,

As far as I understand, BlackBerry 10 content areas bounce. That doesn't 
include the toolbar below the content area. 

I'm not sure what this preference does or how. 
-
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.

ios7 overlapping status bar

2013-12-04 Thread Christian Grobmeier


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

Re: ios7 overlapping status bar

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
>

Re: Plugins Release today

On Wed, Dec 4, 2013 at 2:54 PM, David Kemp  wrote:

> You can definitely do an automated build on demand, but the interesting
> part is specifying exactly what to build.
> Currently a build is made up of a bunch of repos at one tag, and some other
> repos at another tag.
> We would need to have a well defined way to specify which tag for each
> repo.
>
> example:
> I want to build cordova-android from the 'fancy-pants' branch, because I am
> ready to push it to master
>
> I presumably need:
>   cordova-android - fancy-pants branch
>   cli,plugman,coho,mobilespec, js from master branch
>   all plugins from master branch
>
> If we can ALWAYS say that a demand build is the same as a master build, but
> with one repo at a different branch that might be pretty easy...
>
+1 to this.

I suspect we almost always want to test new feature against tip-of-tree (I
guess thats master).  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?


>
>
>
>
> On Wed, Dec 4, 2013 at 2:44 PM, Ian Clelland  wrote:
>
> > On Tue, Dec 3, 2013 at 3:29 PM, Steven Gill 
> > wrote:
> >
> > > On Tue, Dec 3, 2013 at 12:14 PM, Ian Clelland 
> > > wrote:> Dev becomes a staging branch, essentially; and all actual dev
> > work
> > > happens
> > >  > on branches. That sounds like a more sane way to do it. The only
> > reason
> > > I
> > > > had it on dev in the first place was to be able to test with buildbot
> > --
> > > > I'd love to have a way to run those branches through the CI server
> > before
> > > > merging them into dev/staging/master.
> > >
> > >
> > > Good point. Maybe we standardize a third branch (ducks for cover) that
> > the
> > > CI server also tests and can be used for breaking dev work. This way
> dev
> > is
> > > used for staging and only has code that can be released. I'm afraid
> that
> > > this just adds more complexity to plugins though and I am not a fan of
> > > adding more complexity.
> > >
> >
> > I was thinking that it would be cool to be able to force a buildbot build
> > of a specific branch (though maybe a set of branches would be required)
> --
> > it wouldn't have to happen with every commit, but you could say "I'm
> ready
> > to merge my feature into dev, let's get buildbot to run all of the tests
> on
> > that branch first, to see if the merge will break anything".
> >
> > That would avoid the need for a third special branch, but would let
> anybody
> > with access to buildbot (which we hope is everybody, soon) the ability to
> > test a branch before merging.
> >
> > I don't know if it's possible to get buildbot to do that or not; I'll
> defer
> > to David on that subject :)
> >
> > Ian
> >
> >
> > >
> > > >
> > >  Ian
> > > >
> > > >
> > > >
> > > > > Still confusing at times. It will be
> > > > > nice once we can get away from this dev-master setup we have. I'm
> > sure
> > > > many
> > > > > of us have pushed code to dev that isn't in a sate to be released.
> > > Maybe
> > > > > this point/process should get added to our wiki? Not sure where the
> > > best
> > > > > place for it would be.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On Tue, Dec 3, 2013 at 11:34 AM, Ian Clelland <
> iclell...@google.com>
> > > > > wrote:
> > > > >
> > > > > > Hey Steven,
> > > > > >
> > > > > > File is close to being ready, but I haven't merged in my Android
> > code
> > > > > yet,
> > > > > > and I want to add some more tests, given how critical the plugin
> > is.
> > > > I'm
> > > > > > not comfortable with it going to master yet. If you want, I can
> > pull
> > > it
> > > > > out
> > > > > > of dev and put it on another branch. (There have been some other
> > > > commits,
> > > > > > so we could also create a new branch without those commits, and
> > merge
> > > > > > *that* into master instead)
> > > > > >
> > > > > > Let me know how you want to handle it, I'll help out any way I
> can.
> > > > > >
> > > > > > Ian
> > > > > >
> > > > > >
> > > > > > On Tue, Dec 3, 2013 at 2:20 PM, Steven Gill <
> > stevengil...@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > Any plugin issues I should know about before releasing today?
> > > > > > >
> > > > > > > Last I heard file and file-transfer dev branches aren't ready
> to
> > be
> > > > > > merged
> > > > > > > into master. Has this changed? Ian?
> > > > > > >
> > > > > > > Plugin issues that are still being reviewed/worked on:
> > > > > > > https://issues.apache.org/jira/browse/CB-5525
> > > > > > > https://issues.apache.org/jira/browse/CB-5531
> > > > > > > https://issues.apache.org/jira/browse/CB-5532
> > > > > > > https://issues.apache.org/jira/browse/CB-5430
> > > > > > > https://issues.apache.org/jira/browse/CB-5504
> > > > > > > https://issues.apache.org/jira/browse/CB-5505
> > > > > > >
> > > > > > > I can

Re: Plugins Release today

2013-12-04 Thread Josh Soref

> 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.

Re: ios7 overlapping status bar

2013-12-04 Thread Shazron

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
> >
>

Re: cordova-labs plugins branch to be deleted

2013-12-04 Thread Shazron

Deleted.


On Mon, Nov 11, 2013 at 4:21 PM, Shazron  wrote:

> FYI
> Since the code has been migrated to cordova-plugins a week or so ago, this
> branch can be deleted.
>

CLI release today - 3.2.0-0.4.0

Going to do a small cli release shortly. Win8 builds are failing due to a
issue with version matching. See [1] for fix

[1]
https://git-wip-us.apache.org/repos/asf?p=cordova-cli.git;a=blobdiff;f=src/metadata/windows8_parser.js;h=e85b86ff6c01e2dcdab8f5aed62799d62c7f8f5a;hp=f8e077648db3034700b9fd69ab931f7524806e45;hb=e325e5dd63a31c30cd0b493e6b56b0816f341094;hpb=3a53c222c78585e323e153427f06be5d4aed0464

Re: Cordova and Crosswalk

2013-12-04 Thread Brian LeRoux

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'm still curious if Crosswalk wants to donate to Apache?


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.
>
>

Camera API: correctOrientation

2013-12-04 Thread John M. Wargo


Can someone explain to me what correctOrientation is supposed to do?

I just spent the last hour or so trying everything I can think of to make this 
thing do its voodo on Android and iOS and I can't tell the difference between 
photos taken with correctOrientation : true and
correctOrientation : false. either I don't know what I'm looking for, I can't 
code or this option simply does nothing. :-)

--
John M. Wargo
@johnwargo 
www.johnwargo.com 
--

Re: Camera API: correctOrientation

2013-12-04 Thread Josh Soref

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: Camera API: correctOrientation

2013-12-04 Thread Jesse

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: Camera API: correctOrientation

2013-12-04 Thread John M. Wargo

Josh,

That's the PhoneGap 1.7 docs you linked - when you look at the Cordova 3.2 docs
(http://docs.phonegap.com/en/3.2.0/cordova_camera_camera.md.html#cameraOptions),
it does not list _any_ issues with correctOrientation on Android or iOS. I
expect it not to work on Windows Phone because it's listed in the docs as being
a limitation, but not on Android or iOS.

I'm not a newb; I'm not asking because I'm too stupid to look in the documentation first.
I've written a book on PhoneGap as well as a book on Cordova 3.0, so I know how most of
this works and to look at the docs first. I'm hoping that I don't have to begin any
question with "I've already looked in the docs, but..."

I started with the documentation and all it says is:

"Rotate the image to correct for the orientation of the device during capture"

Not a very clear description of what actually happens. You're right though, I'm not really asking
what it's supopsed to do, but instead "does it work?" and if so, "Any idea why it
isn't working for me?"

I've written an application that takes a picture without the option defined and
with the option set to true as well as false and on Android or iOS devices; I
can't see any difference in the photos for all three options.

So, am I missing something and this just not supposed to work? Or is something
else biting me in the butt here?

On 12/4/2013 8: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: Camera API: correctOrientation

I believe it was meant to be used with WebViews that don't render jpegs
according to the orientation in their EXIF data.

Quite possible that it solves a problem that no longer exists. If so, it
would be great to get rid of it.


On Wed, Dec 4, 2013 at 8:47 PM, John M. Wargo  wrote:

> Josh,
>
> That's the PhoneGap 1.7 docs you linked - when you look at the Cordova 3.2
> docs (http://docs.phonegap.com/en/3.2.0/cordova_camera_camera.
> md.html#cameraOptions), it does not list _any_ issues with
> correctOrientation on Android or iOS. I expect it not to work on Windows
> Phone because it's listed in the docs as being a limitation, but not on
> Android or iOS.
>
> I'm not a newb; I'm not asking because I'm too stupid to look in the
> documentation first. I've written a book on PhoneGap as well as a book on
> Cordova 3.0, so I know how most of this works and to look at the docs
> first. I'm hoping that I don't have to begin any question with "I've
> already looked in the docs, but..."
>
> I started with the documentation and all it says is:
>
> "Rotate the image to correct for the orientation of the device during
> capture"
>
> Not a very clear description of what actually happens. You're right
> though, I'm not really asking what it's supopsed to do, but instead "does
> it work?" and if so, "Any idea why it isn't working for me?"
>
> I've written an application that takes a picture without the option
> defined and with the option set to true as well as false and on Android or
> iOS devices; I can't see any difference in the photos for all three options.
>
> So, am I missing something and this just not supposed to work? Or is
> something else biting me in the butt here?
>
>
> On 12/4/2013 8: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: Camera API: correctOrientation

2013-12-04 Thread John M. Wargo


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: Camera API: correctOrientation

2013-12-04 Thread Jesse

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.
>>>
>>>
>>>
>

Review Request 16032: Cordova Plugins release Dec 4, 2013


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/16032/
---

Review request for cordova.


Repository: cordova-site


Description
---

Blog post for the plugins release. Plugins have already been pushed and 
published. 


Diffs
-

  /cordova/site/www/_posts/2013-12-04-plugins-release.md PRE-CREATION 

Diff: https://reviews.apache.org/r/16032/diff/


Testing
---


Thanks,

Steven Gill

Re: Review Request 16032: Cordova Plugins release Dec 4, 2013


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/16032/#review29792
---

Ship it!


All my comments are nitpicks. Fix them and LGTM!

- Andrew Grieve


On Dec. 5, 2013, 2:41 a.m., Steven Gill wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/16032/
> ---
> 
> (Updated Dec. 5, 2013, 2:41 a.m.)
> 
> 
> Review request for cordova.
> 
> 
> Repository: cordova-site
> 
> 
> Description
> ---
> 
> Blog post for the plugins release. Plugins have already been pushed and 
> published. 
> 
> 
> Diffs
> -
> 
>   /cordova/site/www/_posts/2013-12-04-plugins-release.md PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/16032/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Steven Gill
> 
>

Re: Review Request 16032: Cordova Plugins release Dec 4, 2013


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/16032/#review29791
---



/cordova/site/www/_posts/2013-12-04-plugins-release.md


I don't know what this means. Delete or translate into something more clear



/cordova/site/www/_posts/2013-12-04-plugins-release.md


fixed -> Fixed. Should specify platform as well.



/cordova/site/www/_posts/2013-12-04-plugins-release.md


ios -> iOS. Don't start with a "-", no other bullet is like this.



/cordova/site/www/_posts/2013-12-04-plugins-release.md


remove : after issue. Also - reword to english:

CB-5275 Fixed media-capture's ability to select images & videos on Android



/cordova/site/www/_posts/2013-12-04-plugins-release.md


Not sure we need to include this in plugins release post.



/cordova/site/www/_posts/2013-12-04-plugins-release.md


Not sure we need to include this in a plugins release post.


- Andrew Grieve


On Dec. 5, 2013, 2:41 a.m., Steven Gill wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/16032/
> ---
> 
> (Updated Dec. 5, 2013, 2:41 a.m.)
> 
> 
> Review request for cordova.
> 
> 
> Repository: cordova-site
> 
> 
> Description
> ---
> 
> Blog post for the plugins release. Plugins have already been pushed and 
> published. 
> 
> 
> Diffs
> -
> 
>   /cordova/site/www/_posts/2013-12-04-plugins-release.md PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/16032/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Steven Gill
> 
>

Re: Plugins Release today

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.
>

Re: Plugins Release today

2013-12-04 Thread Brian LeRoux

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.
> >
>

Re: Plugins Release today