date:20140714

GitHub user sgrebnov opened a pull request:

https://github.com/apache/cordova-js/pull/74

CB-6976 Add support for Windows Universal apps (Windows 8.1 and WP 8.1)

https://github.com/apache/cordova-lib/pull/39

* The following two definitions are duplicated for 'windows' platform for 
backward compatibility with current plugins which could rely on old mechanism 
based on windows8/commandProxy

"cordova/windows8/commandProxy"
"cordova/windows/commandProxy"

* windows8 folder and corresponding gruntfile setting must be removed after 
3.6.0 release

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/MSOpenTech/cordova-js 
CB-6976-win-universal-apps

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cordova-js/pull/74.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #74


commit cd084de7fdf514b554a841be83f15579363fce18
Author: sgrebnov 
Date:   2014-07-14T07:50:36Z

CB-6976 Add support for Windows Universal apps (Windows 8.1 and WP 8.1)




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: One platform development vs. Cordova CLI

My experience with Cordova (and other tools for that matter) is that it
makes no sense to change tool generated files.
If the tool is improved you do not benefit from this improvement because
your modified files will be changed by the new version.
If you change a tool generated file you are out.
When we started using Cordova me and other colleagues thought that our
project "needs" to change Cordova generated files too.
In each case this turned out to be wrong.
Most of the times writing a Cordova plugin is the solution.

The bottom line is: either use Cordova or not. (or send a pull request to
improve it)

-Axel




2014-07-13 22:18 GMT+02:00 Jan Velecký :

> Hello,
> there is serious backlog when using CLI in case one platform development.
> In
> this case is better to change platform project config.xml instead of whole
> project config.xml. Problem is what prepare should do, and what prepare
> actually do. (And prepare is also run if we do build.) At this moment,
> prepare in CLI does clean & copy...
> Also prepare does it in different way in Android, than in iOS.
> On Android, config.xml and androidmanifest.xml is probably recreated
> (destroy previous formatting, what a feature...) and then probably add
> differences, so changes and new options are preserved, however nobody wanna
> read it...
> On iOS, config.xml is completely recreated, no any option is preserved...
>
> So, there are 2 questions...
> If is Android CLI too clever to do preserve changes created by user, why it
> ruins my formatting (new lines, maybe also tabulators)?
> Why is iOS CLI such a stupid? Why it is not able to do it like Android CLI
> (at least)?

[GitHub] cordova-lib pull request: CB-7118 iOS: add target-device and Minim...

Github user sgrebnov commented on a diff in the pull request:

https://github.com/apache/cordova-lib/pull/57#discussion_r14868912
  
--- Diff: cordova-lib/src/cordova/metadata/ios_parser.js ---
@@ -217,6 +220,38 @@ module.exports.prototype = {
 self.update_overrides();
 util.deleteSvnFolders(self.www_dir());
 });
+},
+
+update_build_settings:function(config) {
+var targetDevice = 
parseTargetDevicePreference(config.getPreference('target-device', 'ios'));
+var deploymentTarget = config.getPreference('deployment-target', 
'ios');
+
+// no build settings provided, we don't need to parse and update 
.pbxproj file
+if (!targetDevice && !deploymentTarget) {
+return Q();
+}
+
+var me = this;
+var d = Q.defer();
+var proj = new xcode.project(this.pbxproj);
+proj.parse(function(err,hash) {
+if (err) {
+d.reject(new Error('An error occured during parsing of 
project.pbxproj. Start weeping. Output: ' + err));
+return;
+}
+var buildConfiguration = proj.pbxXCBuildConfigurationSection();
+if (targetDevice) {
+// TODO: replace propReplace with proj.updateBuildProperty 
after below is release
+// https://github.com/alunny/node-xcode/pull/33
--- End diff --

Updated, thx @sriranggd 


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cordova-wp8 pull request: small fix for spaces in path

2014-07-14 Thread G3z

GitHub user G3z opened a pull request:

https://github.com/apache/cordova-wp8/pull/45

small fix for spaces in path

this fixes the error about missing create.js if user has a space in his 
home folder

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/G3z/cordova-wp8 patch-1

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cordova-wp8/pull/45.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #45


commit 5b0e62f1d0182adcb82c70da78a3606f265a765e
Author: Giacomo Trezzi 
Date:   2014-07-14T10:35:58Z

small fix for spaces in path

this fixes the error about missing create.js if user has a space in his 
home folder




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cordova-app-hello-world pull request: update index.html and index....

Github user asfgit closed the pull request at:

https://github.com/apache/cordova-app-hello-world/pull/8


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cordova-app-hello-world pull request: update index.html and index....

2014-07-14 Thread JohnMcLear

Github user JohnMcLear commented on the pull request:


https://github.com/apache/cordova-app-hello-world/pull/8#issuecomment-48886202
  
Thanks guys :)


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cordova-docs pull request: Corrected the documentation for splash ...

Github user AxelNennker closed the pull request at:

https://github.com/apache/cordova-docs/pull/219


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cordova-docs pull request: Corrected the documentation for splash ...

Github user AxelNennker commented on the pull request:

https://github.com/apache/cordova-docs/pull/219#issuecomment-48887679
  
This PR changes too many files.
I will resubmit it after I have cleaned up my fork of cordova-docs.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cordova-docs pull request: CB-3571: update the docs for the splash...

GitHub user AxelNennker opened a pull request:

https://github.com/apache/cordova-docs/pull/220

CB-3571: update the docs for the splash screens

The former documentation for splash screens was for the Phonegap build 
system.
The pull request updates the documentation to describe the changes made in 
CB-3571:
https://issues.apache.org/jira/browse/CB-3571



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/AxelNennker/cordova-docs master

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cordova-docs/pull/220.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #220


commit 2e819acfdf0a9958098c35aac66d162296ccdc04
Author: ignisvulpis 
Date:   2014-07-14T11:18:44Z

CB-3571: update the docs for the splash screens




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: recent tools update, Splash screen support

I closed my former PR #219, deleted my fork of cordova-docs, reforked,
updated images.md, pushed and created another PR:
https://github.com/apache/cordova-docs/pull/220

Which now only has one changed file.

Axel



2014-07-14 1:30 GMT+02:00 Ray Camden :

> Thank you - I finally get what the change was now. ;)
>
> 
> From: Axel Nennker 
> Sent: Sunday, July 13, 2014 11:17 AM
> To: dev
> Subject: Re: recent tools update, Splash screen support
>
>
> https://github.com/AxelNennker/cordova-docs/commit/a7b2f371c3d051a5a9d4818f3f9c9cb0eb5c57be
>
> Axel
>
> Sorry about the ton of changed files. I did a "git fetch upstream" today
> and then a merge and push to my repo...
> I wish I could delete my fork and start over but github does not allow
> this...
>
>
> 2014-07-13 17:56 GMT+02:00 Ray Camden :
>
> > There are 500+ files changed with this PR - can you point to any specific
> > files that would be helpful?
> >
> > 
> > From: Axel Nennker 
> > Sent: Sunday, July 13, 2014 10:50 AM
> > To: dev
> > Subject: Re: recent tools update, Splash screen support
> >
> > A pull request is here:
> > https://github.com/apache/cordova-docs/pull/219
> >
> > -Axel
> >
> >
> > 2014-07-12 15:12 GMT+02:00 Ray Camden :
> >
> > > Just raising this again - are there docs for this?
> > >
> > > 
> > > From: Ray Camden 
> > > Sent: Friday, July 11, 2014 5:46 AM
> > > To: dev@cordova.apache.org
> > > Subject: RE: recent tools update, Splash screen support
> > >
> > > So basically the docs are *not* up to the date for any of this yet?
> > > 
> > > From: Sergey Grebnov (Akvelon) 
> > > Sent: Friday, July 11, 2014 1:15 AM
> > > To: dev@cordova.apache.org
> > > Subject: RE: recent tools update, Splash screen support
> > >
> > > I volunteer to test splash/icons support one more time and update the
> > docs
> > > where it is required.
> > >
> > > * The old documentation refers to PG Build. Cordova implementation is
> > > based on this idea, but there are some differences, for example we
> don't
> > > support gap: prefix and platform attribute, platform specific icons
> must
> > be
> > > placed inside corresponding  element
> > > * We updated icons related docs as part of Cordova icons support
> > > implementation, I will double check that it is still accurate (for
> > example
> > > I see that it mentions platform attribute which is not supported)
> > > * We should update splash screen related docs part (as per our
> > > implementation + examples)
> > > * Splash screen plugin and splash screen images support are related but
> > > different features. Core splash screen support by CLI allows replacing
> > > default template images which are showed automatically, where the
> plugin
> > > works on top of this and allows programmatically show/hide splash
> screen
> > > (pls correct me if I'm wrong).
> > >
> > >
> >
>

Mailing List Subscription

2014-07-14 Thread Rahul Pandey

Hi,

I would like to subscribe for the mailing lists.

-- 
*Rahul Pandey*
*General Manager IT*

*Application Nexus Webservices Pvt. Ltd.*
101-105, Center One,
Next to Ashoka Buildcon,
Ashoka Marg, Nasik - 422 011
Maharashtra. INDIA

Office:+91-253-2236556
Mobile: +91-9665993073
http://www.applicationnexus.com


DISCLAIMER:
---

The contents of this e-mail and any attachment(s) are confidential and
intended for the named recipient(s) only.

It shall not attach any liability on the originator or Application Nexus or
its affiliates. Any views or opinions presented in this email are solely
those of the author and may not necessarily reflect the opinions of
Application Nexus or its affiliates.

Any form of reproduction, dissemination, copying, disclosure, modification,
distribution and / or publication of this message without the prior written
consent of the author of this e-mail is strictly prohibited. If you have
received this email in error please delete it and notify the sender
immediately. Before opening any mail and attachments please check them for
viruses and defect.

---

[GitHub] cordova-plugin-inappbrowser pull request: CB- 5109 Windows 8.1 - I...

GitHub user sgrebnov opened a pull request:

https://github.com/apache/cordova-plugin-inappbrowser/pull/53

CB- 5109 Windows 8.1 - InAppBrowser.

https://issues.apache.org/jira/browse/CB-5109
Adds support of 'x-ms-webview' available in Windows 8.1 and Windows Phone 
8.1.

Based on https://github.com/Touchit/cordova-plugin-inappbrowser/tree/CB-5109
Thx Maxime LUCE @Touchit

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/sgrebnov/cordova-plugin-inappbrowser CB-5109

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cordova-plugin-inappbrowser/pull/53.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #53


commit e9b8a879311979b8211b9b4496c36d7ed3947f7b
Author: sgrebnov 
Date:   2014-07-14T13:07:30Z

CB- 5109 Windows 8.1 - InAppBrowser.

Adds support of 'x-ms-webview' available in Windows 8.1 and Windows Phone 
8.1.
Based on https://github.com/Touchit/cordova-plugin-inappbrowser/tree/CB-5109




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cordova-docs pull request: CB-3571: update the docs for the splash...

Github user sgrebnov commented on the pull request:

https://github.com/apache/cordova-docs/pull/220#issuecomment-48901707
  
Axel, could you please
1. swap Windows Phone8 and Windows8 sections so that they follow the same 
order as in Icons section, + use the same order in 'Supported platforms' (to be 
consistent)
2. Remove unnecessary ', ' (commas) from sample xml (between attributes)
3. I think we should also mention Splash Screen Plugin and put reference to 
it
https://github.com/apache/cordova-plugin-splashscreen

Otherwise LGTM, thanks Axel!


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

RE: recent tools update, Splash screen support

2014-07-14 Thread Sergey Grebnov (Akvelon)

Thx Axel. Reviewed, looks good to me. Added a few notes to github.

-Sergey
-Original Message-
From: Axel Nennker [mailto:ignisvul...@gmail.com] 
Sent: Monday, July 14, 2014 3:33 PM
To: dev
Subject: Re: recent tools update, Splash screen support

I closed my former PR #219, deleted my fork of cordova-docs, reforked, updated 
images.md, pushed and created another PR:
https://github.com/apache/cordova-docs/pull/220

Which now only has one changed file.

Axel



2014-07-14 1:30 GMT+02:00 Ray Camden :

> Thank you - I finally get what the change was now. ;)
>
> 
> From: Axel Nennker 
> Sent: Sunday, July 13, 2014 11:17 AM
> To: dev
> Subject: Re: recent tools update, Splash screen support
>
>
> https://github.com/AxelNennker/cordova-docs/commit/a7b2f371c3d051a5a9d
> 4818f3f9c9cb0eb5c57be
>
> Axel
>
> Sorry about the ton of changed files. I did a "git fetch upstream" 
> today and then a merge and push to my repo...
> I wish I could delete my fork and start over but github does not allow 
> this...
>
>
> 2014-07-13 17:56 GMT+02:00 Ray Camden :
>
> > There are 500+ files changed with this PR - can you point to any 
> > specific files that would be helpful?
> >
> > 
> > From: Axel Nennker 
> > Sent: Sunday, July 13, 2014 10:50 AM
> > To: dev
> > Subject: Re: recent tools update, Splash screen support
> >
> > A pull request is here:
> > https://github.com/apache/cordova-docs/pull/219
> >
> > -Axel
> >
> >
> > 2014-07-12 15:12 GMT+02:00 Ray Camden :
> >
> > > Just raising this again - are there docs for this?
> > >
> > > 
> > > From: Ray Camden 
> > > Sent: Friday, July 11, 2014 5:46 AM
> > > To: dev@cordova.apache.org
> > > Subject: RE: recent tools update, Splash screen support
> > >
> > > So basically the docs are *not* up to the date for any of this yet?
> > > 
> > > From: Sergey Grebnov (Akvelon) 
> > > Sent: Friday, July 11, 2014 1:15 AM
> > > To: dev@cordova.apache.org
> > > Subject: RE: recent tools update, Splash screen support
> > >
> > > I volunteer to test splash/icons support one more time and update 
> > > the
> > docs
> > > where it is required.
> > >
> > > * The old documentation refers to PG Build. Cordova implementation 
> > > is based on this idea, but there are some differences, for example 
> > > we
> don't
> > > support gap: prefix and platform attribute, platform specific 
> > > icons
> must
> > be
> > > placed inside corresponding  element
> > > * We updated icons related docs as part of Cordova icons support 
> > > implementation, I will double check that it is still accurate (for
> > example
> > > I see that it mentions platform attribute which is not supported)
> > > * We should update splash screen related docs part (as per our 
> > > implementation + examples)
> > > * Splash screen plugin and splash screen images support are 
> > > related but different features. Core splash screen support by CLI 
> > > allows replacing default template images which are showed 
> > > automatically, where the
> plugin
> > > works on top of this and allows programmatically show/hide splash
> screen
> > > (pls correct me if I'm wrong).
> > >
> > >
> >
>

RE: Add build status to github

2014-07-14 Thread Sergey Grebnov (Akvelon)

Tests on Windows:
I've compared Wercker and Appveyor and as for me it looks like Appveyor is a 
better option to proceed for Windows since
1.  Wercker's existing windows boxes doesn't support building of Windows 8.1 
and WP 8.1 apps due to absence of Windows 8.1 and WP 8.1 SDKs on the boxes.
2.  Appveyor supports above
Please note, Wercker supports custom VM boxes so potentially we can add custom 
VMs but I'm not sure it is good idea to maintain them.

Tests on OSX: 
I propose to use Travis since in comparison to Wercker it provides OSX test 
boxes with XCode installed (http://docs.travis-ci.com/user/osx-ci-environment) 
and also supports Android builds 
(http://docs.travis-ci.com/user/languages/android)

Thx!
Sergey
-Original Message-
From: Sergey Grebnov (Akvelon) 
Sent: Monday, July 7, 2014 6:00 PM
To: dev@cordova.apache.org
Subject: RE: Add build status to github

Hey Mark, it is really great to see you are working in this direction, thx! 
Here are my additional notes

I think we should have discussion in two directions here:
1. Decide what we want to run as test for each repo 2.  Particular 
service/implementation details

As for 1:
a) LIB, CLI: I propose to run unit tests via 'npm test' for cordova-lib, 
cordova-cli, cordova-plugman (btw, I don't see plugman tests so not sure we 
have them) It seems, that Mark is on the same page.

b) PLATFORMS: for the platforms I propose to start from implementing simple e2e 
test with the following steps (written in nodejs):
- install cordova-cli (apache/master?)
- create test app
- add platform
- build

* as a long term goal we may want to move this to npm tests (but include to 
special group which can be run with additional flag since I don't think we 
should run this along with general unit tests )

As for 2:
If we want unified build platform across all repos it seems that Wercker and 
Appveyor are the only good options due to windows support required. Both looks 
good to me, but I need to double check Wercker supports VS2013 (msbuild12) 
since it requires to build cordova-windows (will investigate and respond). I 
also think is that Travic-CI is the most safe option for other platforms/repos 
since they already proved to be a good solution for many open source companies. 

Thx!
Sergey
-Original Message-
From: Mark Koudritsky [mailto:kam...@google.com]
Sent: Friday, July 4, 2014 6:57 AM
To: dev@cordova.apache.org
Subject: Re: Add build status to github

Oops, sorry, didn't look at the links before sending another link to AppVeyor. 
Why not to use AppVeyor for lib and cli too? We could definitely use some 
testing on windows.

I also experimented with Wercker  which is yet another 
free CI service.
Added it to a branch in my fork of cordova-lib. You can see a badge with build 
results here in README:
https://github.com/kamrik/cordova-lib/tree/wercker

I never used Travis CI, but from description looks like Wercker is a bit more 
flexible with environment setup and they even offer a predefined environment 
for building Android apps 
 so maybe we can 
use it to run a test that goes all the way to building an apk. They say 

they support checking pull requests too.

What do you think?

That said, I'm not particularly attached to any specific CI service, any of 
them would be very helpful.

On Fri, Jun 27, 2014 at 10:40 AM, Andrew Grieve 
wrote:

> Make it happen :)
>
>
> On Fri, Jun 27, 2014 at 10:02 AM, Mark Koudritsky 
> wrote:
>
> > Would be nice to have this. Specifically Travis will only run on 
> > Linux
> (and
> > maybe OSX). Here is a random similar service I found that can also 
> > run on windows.
> > http://www.appveyor.com/
> >
>

[GitHub] cordova-js pull request: CB-6714 [webOS] Upgrade webOS for modern ...

Github user asfgit closed the pull request at:

https://github.com/apache/cordova-js/pull/68


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cordova-android pull request: Displaying error when regex does not...

Github user asfgit closed the pull request at:

https://github.com/apache/cordova-android/pull/104


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cordova-android pull request: Fix for `android` not being in PATH ...

Github user asfgit closed the pull request at:

https://github.com/apache/cordova-android/pull/103


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cordova-android pull request: Update to check for Google Glass API...

Github user asfgit closed the pull request at:

https://github.com/apache/cordova-android/pull/100


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cordova-mobile-spec pull request: CB-6928: Add 304 response test

Github user asfgit closed the pull request at:

https://github.com/apache/cordova-mobile-spec/pull/71


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: Pointing docs to edge

2014-07-14 Thread Max Woghiren

Okay, so here are the current proposals for handling Ray's issue (thanks
Ray!):

1. Update docs at commit-time and release-time.  At commit-time,
documentation changes can be marked with "coming soon", or "removed in next
release", or whatever the relevant message is.  At release-time, docs are
further updated to remove these sub-messages.

2. Use CSS to do the manual marking in proposal 1.  We could also use it to
hide certain documentation changes until release.

3. Create a docs branch for each releasable component.  Whenever a
component is released, merge that branch into master.

Does anyone feel strongly about any of these or have another suggestion?


On Fri, Jul 11, 2014 at 2:57 PM, Andrew Grieve  wrote:

> Good point Ray.
>
> Another option would be to create a branch-per-component e.g. tools,
> android, ios, etc. that changes go into, and then merge into master from
> the branch that corresponds to the release that is happening
>
>
> On Fri, Jul 11, 2014 at 2:02 PM, Michal Mocny  wrote:
>
> > Ray, but I thought we always wanted more cowbell?
> >
> > Sorry, had to.  I agree with Ray here, but I would also want to see
> latest
> > fixes to docs that apply to released version.
> >
> > Suggestion: rely on discipline to markup documentation changes which only
> > apply to development versions?
> >
> > e.g.
> >
> > 
> > Now with more ---cowbell!
> > 
> >
> > And part of release instructions is to change styling from looking
> > scary/experimental to looking ordinary?
> >
> > -Michal
> >
> >
> > On Fri, Jul 11, 2014 at 1:51 PM, Ray Camden  wrote:
> >
> > > Ok, so let me rephrase then. Imagine the next version of the CLI adds
> > > cowbell support:
> > >
> > > cordova cowbell --epic
> > >
> > > but this is NOT in the release version.
> > >
> > > If I go to docs.cordova.io, click on The Command Line Interface, will
> I
> > > see cowbell documented? If so, I think that is a mistake.
> > >
> > > 
> > > From: agri...@google.com  on behalf of Andrew
> > Grieve <
> > > agri...@chromium.org>
> > > Sent: Friday, July 11, 2014 11:39 AM
> > > To: dev
> > > Subject: Re: Pointing docs to edge
> > >
> > > Yeah, plugin docs are already gone from docs.cordova.io. This change
> is
> > > strictly for guides & platform docs. The main motivation here is that
> it
> > > doesn't make sense to have versioned docs if platform versions diverge
> > > anyways. It actually already makes little sense for the tools guides,
> > since
> > > they are released more often the platforms.
> > >
> > >
> > > On Fri, Jul 11, 2014 at 12:36 PM, Max Woghiren 
> > wrote:
> > >
> > > > My understanding is that plugin docs live in plugin repos and will be
> > > > versioned alongside the plugins themselves.  They'll be removed from
> > > > docs.cordova.io.
> > > >
> > > >
> > > > On Fri, Jul 11, 2014 at 11:49 AM, Ray Camden 
> > wrote:
> > > >
> > > > > Is edge what people use when they get the latest version of cordova
> > or
> > > a
> > > > > plugin? If not, I'd strongly argue against it.
> > > > >
> > > > > If I download the Camera plugin, I expect the default docs to match
> > > whats
> > > > > shipped in that version.
> > > > >
> > > > > 
> > > > > From: m...@google.com  on behalf of Max Woghiren
> <
> > > > > m...@chromium.org>
> > > > > Sent: Friday, July 11, 2014 10:46 AM
> > > > > To: dev
> > > > > Subject: Pointing docs to edge
> > > > >
> > > > > Just wanted to bring back this conversation—how does everyone feel
> > > about
> > > > > switching docs.cordova.io to point to edge?  There has been some
> > > > > discussion
> > > > > about cutting versioned docs after 3.5.0, and we're approaching a
> > good
> > > > time
> > > > > to do it. :)
> > > > >
> > > >
> > >
> >
>

Monthly Cordova hangouts

2014-07-14 Thread Parashuram Narasimhan (MS OPEN TECH)

Just wondering if we already had the Monthly hangouts for this month. We 
usually have it on 15th every month, right ?
Also, I remember that from the last hangout, we had trouble getting more than 
10 people into the hangout. Do we want to try alternate solutions (Webex, Lync, 
or a conference bridge) that can let more people participate?

Re: Monthly Cordova hangouts

2014-07-14 Thread David Kemp

The call is scheduled for tomorrow evening.
On 14 Jul 2014 11:44, "Parashuram Narasimhan (MS OPEN TECH)" <
panar...@microsoft.com> wrote:

> Just wondering if we already had the Monthly hangouts for this month. We
> usually have it on 15th every month, right ?
> Also, I remember that from the last hangout, we had trouble getting more
> than 10 people into the hangout. Do we want to try alternate solutions
> (Webex, Lync, or a conference bridge) that can let more people participate?
>

[GitHub] cordova-plugin-device pull request: Added Name into device propert...

2014-07-14 Thread AMAdacto

GitHub user AMAdacto opened a pull request:

https://github.com/apache/cordova-plugin-device/pull/16

Added Name into device property for iOS

Added device name property

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/AMAdacto/cordova-plugin-device patch-1

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cordova-plugin-device/pull/16.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #16


commit 55e51158f2f93421c132579ffe589b8dc0648847
Author: AMAdacto 
Date:   2014-07-14T15:53:51Z

Added Name into device property for iOS

Added device name property




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: Pointing docs to edge

2014-07-14 Thread Michal Mocny

I think we can also use a combination of these.  For small changes where it
makes sense, just push to master and be conscious of its effect on the
current tools release out in the wild.  If the change is significant and
inline documentation gets hairy, just create a branch.

A side benefit of doing more and master and getting it into the eyes of
users is earlier feedback on what's coming up.

Either way, whatever we chose, lowering process overhead is what we need
right now.  Lets just do what feels natural and leads for devs actually
focusing on docs!


On Mon, Jul 14, 2014 at 11:27 AM, Max Woghiren  wrote:

> Okay, so here are the current proposals for handling Ray's issue (thanks
> Ray!):
>
> 1. Update docs at commit-time and release-time.  At commit-time,
> documentation changes can be marked with "coming soon", or "removed in next
> release", or whatever the relevant message is.  At release-time, docs are
> further updated to remove these sub-messages.
>
> 2. Use CSS to do the manual marking in proposal 1.  We could also use it to
> hide certain documentation changes until release.
>
> 3. Create a docs branch for each releasable component.  Whenever a
> component is released, merge that branch into master.
>
> Does anyone feel strongly about any of these or have another suggestion?
>
>
> On Fri, Jul 11, 2014 at 2:57 PM, Andrew Grieve 
> wrote:
>
> > Good point Ray.
> >
> > Another option would be to create a branch-per-component e.g. tools,
> > android, ios, etc. that changes go into, and then merge into master from
> > the branch that corresponds to the release that is happening
> >
> >
> > On Fri, Jul 11, 2014 at 2:02 PM, Michal Mocny 
> wrote:
> >
> > > Ray, but I thought we always wanted more cowbell?
> > >
> > > Sorry, had to.  I agree with Ray here, but I would also want to see
> > latest
> > > fixes to docs that apply to released version.
> > >
> > > Suggestion: rely on discipline to markup documentation changes which
> only
> > > apply to development versions?
> > >
> > > e.g.
> > >
> > > 
> > > Now with more ---cowbell!
> > > 
> > >
> > > And part of release instructions is to change styling from looking
> > > scary/experimental to looking ordinary?
> > >
> > > -Michal
> > >
> > >
> > > On Fri, Jul 11, 2014 at 1:51 PM, Ray Camden 
> wrote:
> > >
> > > > Ok, so let me rephrase then. Imagine the next version of the CLI adds
> > > > cowbell support:
> > > >
> > > > cordova cowbell --epic
> > > >
> > > > but this is NOT in the release version.
> > > >
> > > > If I go to docs.cordova.io, click on The Command Line Interface,
> will
> > I
> > > > see cowbell documented? If so, I think that is a mistake.
> > > >
> > > > 
> > > > From: agri...@google.com  on behalf of Andrew
> > > Grieve <
> > > > agri...@chromium.org>
> > > > Sent: Friday, July 11, 2014 11:39 AM
> > > > To: dev
> > > > Subject: Re: Pointing docs to edge
> > > >
> > > > Yeah, plugin docs are already gone from docs.cordova.io. This change
> > is
> > > > strictly for guides & platform docs. The main motivation here is that
> > it
> > > > doesn't make sense to have versioned docs if platform versions
> diverge
> > > > anyways. It actually already makes little sense for the tools guides,
> > > since
> > > > they are released more often the platforms.
> > > >
> > > >
> > > > On Fri, Jul 11, 2014 at 12:36 PM, Max Woghiren 
> > > wrote:
> > > >
> > > > > My understanding is that plugin docs live in plugin repos and will
> be
> > > > > versioned alongside the plugins themselves.  They'll be removed
> from
> > > > > docs.cordova.io.
> > > > >
> > > > >
> > > > > On Fri, Jul 11, 2014 at 11:49 AM, Ray Camden 
> > > wrote:
> > > > >
> > > > > > Is edge what people use when they get the latest version of
> cordova
> > > or
> > > > a
> > > > > > plugin? If not, I'd strongly argue against it.
> > > > > >
> > > > > > If I download the Camera plugin, I expect the default docs to
> match
> > > > whats
> > > > > > shipped in that version.
> > > > > >
> > > > > > 
> > > > > > From: m...@google.com  on behalf of Max
> Woghiren
> > <
> > > > > > m...@chromium.org>
> > > > > > Sent: Friday, July 11, 2014 10:46 AM
> > > > > > To: dev
> > > > > > Subject: Pointing docs to edge
> > > > > >
> > > > > > Just wanted to bring back this conversation—how does everyone
> feel
> > > > about
> > > > > > switching docs.cordova.io to point to edge?  There has been some
> > > > > > discussion
> > > > > > about cutting versioned docs after 3.5.0, and we're approaching a
> > > good
> > > > > time
> > > > > > to do it. :)
> > > > > >
> > > > >
> > > >
> > >
> >
>

RE: Pointing docs to edge

2014-07-14 Thread Ray Camden

Personally I'd rather not have any "coming soon" paragraphs in the doc text. As 
a user, if I'm at the docs, I don't care what is coming next. I'm trying to 
solve a problem I have *now*, or trying to build now. Anything that is coming 
soon is a distractor.

Do I feel strongly about it? No, but I'd vote against it being in the docs at 
all. Stuff like that should definitely be communicated to users - via the 
Cordova blog perhaps - but not in the mainline docs.


From: m...@google.com  on behalf of Max Woghiren 

Sent: Monday, July 14, 2014 10:27 AM
To: dev
Subject: Re: Pointing docs to edge

Okay, so here are the current proposals for handling Ray's issue (thanks
Ray!):

1. Update docs at commit-time and release-time.  At commit-time,
documentation changes can be marked with "coming soon", or "removed in next
release", or whatever the relevant message is.  At release-time, docs are
further updated to remove these sub-messages.

2. Use CSS to do the manual marking in proposal 1.  We could also use it to

Re: Pointing docs to edge

2014-07-14 Thread Max Woghiren

I agree.  I think 3 is my preferred option; I think it lends itself best to
a sustainable and straightforward workflow.

Docs fixes relevant to the current release of the CLI and each platform can
be committed directly to master.  Unreleased changes can be committed to
the appropriate branch, and we can add the merging of the branch as a step
in the release process.


On Mon, Jul 14, 2014 at 1:06 PM, Ray Camden  wrote:

> Personally I'd rather not have any "coming soon" paragraphs in the doc
> text. As a user, if I'm at the docs, I don't care what is coming next. I'm
> trying to solve a problem I have *now*, or trying to build now. Anything
> that is coming soon is a distractor.
>
> Do I feel strongly about it? No, but I'd vote against it being in the docs
> at all. Stuff like that should definitely be communicated to users - via
> the Cordova blog perhaps - but not in the mainline docs.
>
> 
> From: m...@google.com  on behalf of Max Woghiren <
> m...@chromium.org>
> Sent: Monday, July 14, 2014 10:27 AM
> To: dev
> Subject: Re: Pointing docs to edge
>
> Okay, so here are the current proposals for handling Ray's issue (thanks
> Ray!):
>
> 1. Update docs at commit-time and release-time.  At commit-time,
> documentation changes can be marked with "coming soon", or "removed in next
> release", or whatever the relevant message is.  At release-time, docs are
> further updated to remove these sub-messages.
>
> 2. Use CSS to do the manual marking in proposal 1.  We could also use it to
>

Re: Pointing docs to edge

2014-07-14 Thread David Kemp

I would prefer to have the 'coming soon' stuff more visible.
I like the idea that when looking for how to do something, its easy to see
improvements that have already landed - and I can possibly get just by
grabbing a bleeding edge plugin/tool.



On Mon, Jul 14, 2014 at 1:25 PM, Max Woghiren  wrote:

> I agree.  I think 3 is my preferred option; I think it lends itself best to
> a sustainable and straightforward workflow.
>
> Docs fixes relevant to the current release of the CLI and each platform can
> be committed directly to master.  Unreleased changes can be committed to
> the appropriate branch, and we can add the merging of the branch as a step
> in the release process.
>
>
> On Mon, Jul 14, 2014 at 1:06 PM, Ray Camden  wrote:
>
> > Personally I'd rather not have any "coming soon" paragraphs in the doc
> > text. As a user, if I'm at the docs, I don't care what is coming next.
> I'm
> > trying to solve a problem I have *now*, or trying to build now. Anything
> > that is coming soon is a distractor.
> >
> > Do I feel strongly about it? No, but I'd vote against it being in the
> docs
> > at all. Stuff like that should definitely be communicated to users - via
> > the Cordova blog perhaps - but not in the mainline docs.
> >
> > 
> > From: m...@google.com  on behalf of Max Woghiren <
> > m...@chromium.org>
> > Sent: Monday, July 14, 2014 10:27 AM
> > To: dev
> > Subject: Re: Pointing docs to edge
> >
> > Okay, so here are the current proposals for handling Ray's issue (thanks
> > Ray!):
> >
> > 1. Update docs at commit-time and release-time.  At commit-time,
> > documentation changes can be marked with "coming soon", or "removed in
> next
> > release", or whatever the relevant message is.  At release-time, docs are
> > further updated to remove these sub-messages.
> >
> > 2. Use CSS to do the manual marking in proposal 1.  We could also use it
> to
> >
>

Re: Monthly Cordova hangouts

2014-07-14 Thread Brian LeRoux

anyone want to take a stab at an agenda? (no major blockers/issues for us
in Vancouver/SF atm)


On Mon, Jul 14, 2014 at 8:49 AM, David Kemp  wrote:

> The call is scheduled for tomorrow evening.
> On 14 Jul 2014 11:44, "Parashuram Narasimhan (MS OPEN TECH)" <
> panar...@microsoft.com> wrote:
>
> > Just wondering if we already had the Monthly hangouts for this month. We
> > usually have it on 15th every month, right ?
> > Also, I remember that from the last hangout, we had trouble getting more
> > than 10 people into the hangout. Do we want to try alternate solutions
> > (Webex, Lync, or a conference bridge) that can let more people
> participate?
> >
>

Re: Pointing docs to edge

2014-07-14 Thread Brian LeRoux

think that sort of thing belongs to a preview blog post written by the
person promising it will land not our canonical docs


On Mon, Jul 14, 2014 at 10:30 AM, David Kemp  wrote:

> I would prefer to have the 'coming soon' stuff more visible.
> I like the idea that when looking for how to do something, its easy to see
> improvements that have already landed - and I can possibly get just by
> grabbing a bleeding edge plugin/tool.
>
>
>
> On Mon, Jul 14, 2014 at 1:25 PM, Max Woghiren  wrote:
>
> > I agree.  I think 3 is my preferred option; I think it lends itself best
> to
> > a sustainable and straightforward workflow.
> >
> > Docs fixes relevant to the current release of the CLI and each platform
> can
> > be committed directly to master.  Unreleased changes can be committed to
> > the appropriate branch, and we can add the merging of the branch as a
> step
> > in the release process.
> >
> >
> > On Mon, Jul 14, 2014 at 1:06 PM, Ray Camden  wrote:
> >
> > > Personally I'd rather not have any "coming soon" paragraphs in the doc
> > > text. As a user, if I'm at the docs, I don't care what is coming next.
> > I'm
> > > trying to solve a problem I have *now*, or trying to build now.
> Anything
> > > that is coming soon is a distractor.
> > >
> > > Do I feel strongly about it? No, but I'd vote against it being in the
> > docs
> > > at all. Stuff like that should definitely be communicated to users -
> via
> > > the Cordova blog perhaps - but not in the mainline docs.
> > >
> > > 
> > > From: m...@google.com  on behalf of Max Woghiren <
> > > m...@chromium.org>
> > > Sent: Monday, July 14, 2014 10:27 AM
> > > To: dev
> > > Subject: Re: Pointing docs to edge
> > >
> > > Okay, so here are the current proposals for handling Ray's issue
> (thanks
> > > Ray!):
> > >
> > > 1. Update docs at commit-time and release-time.  At commit-time,
> > > documentation changes can be marked with "coming soon", or "removed in
> > next
> > > release", or whatever the relevant message is.  At release-time, docs
> are
> > > further updated to remove these sub-messages.
> > >
> > > 2. Use CSS to do the manual marking in proposal 1.  We could also use
> it
> > to
> > >
> >
>

RE: Monthly Cordova hangouts

2014-07-14 Thread Parashuram Narasimhan (MS OPEN TECH)

I added a couple of items for 3.6.0 release for Windows Universal apps. We also 
decided to talk about the min/max Android and iOS versions right (Joe's 
questions about this) ? 

@Lisa, would this be too early to talk about configurable folders in the CLI? 

-Original Message-
From: brian.ler...@gmail.com [mailto:brian.ler...@gmail.com] On Behalf Of Brian 
LeRoux
Sent: Monday, July 14, 2014 10:31 AM
To: dev@cordova.apache.org
Subject: Re: Monthly Cordova hangouts

anyone want to take a stab at an agenda? (no major blockers/issues for us in 
Vancouver/SF atm)

On Mon, Jul 14, 2014 at 8:49 AM, David Kemp  wrote:

> The call is scheduled for tomorrow evening.
> On 14 Jul 2014 11:44, "Parashuram Narasimhan (MS OPEN TECH)" < 
> panar...@microsoft.com> wrote:
>
> > Just wondering if we already had the Monthly hangouts for this 
> > month. We usually have it on 15th every month, right ?
> > Also, I remember that from the last hangout, we had trouble getting 
> > more than 10 people into the hangout. Do we want to try alternate 
> > solutions (Webex, Lync, or a conference bridge) that can let more 
> > people
> participate?
> >
>

Re: Should use only drawable folder for single application icon

2014-07-14 Thread Bryan Higgins

I have logged an issue related to this [1]

On 3.5.0-0.2.6, I can no longer specify a single default icon for Android.
Is this by design?

The docs imply it should be possible and it worked on 3.5.0-0.2.4

[1] https://issues.apache.org/jira/browse/CB-7132


On Sun, Jun 22, 2014 at 5:38 AM, Axel Nennker  wrote:

> Changes are here with the commit message referring to CB-2606
> https://github.com/apache/cordova-lib/pull/30
>
>
>
>
> 2014-06-21 19:51 GMT+02:00 Axel Nennker :
>
> > I am currently changing android_parser.js because of CB-3571 and moved
> the
> > icon handling code into its own method. I would implement this change and
> > mark these commits as CB-2606.
> > OK?
> >
> > Axel
> > Am 21.06.2014 17:12 schrieb "Andrew Grieve" :
> >
> > Jan, I think the rationale here is sound. Are you interested in adding
> this
> >> feature?
> >>
> >>
> >> On Sat, Jun 21, 2014 at 6:03 AM, Jan Velecký  wrote:
> >>
> >> > It is a thing of a concrete developer if he place more icons in
> >> different
> >> > dimensions or not. In iOS developing, there must be more icons, but in
> >> > Android, there can be only one icon in "drawable" folder. My
> experiences
> >> > with use of only one 128×128 px icon in Android is positive, because
> on
> >> all
> >> > testing devices icon looks great. When developer will be unhappy with
> >> > system
> >> > resized icon, he can put more icons with different resolutions.
> >> >
> >> > I'm using CLI and I'm using only one icon. And is annoying Cordova CLI
> >> > everytime copy icon also on drawable-hdpi, drawable-ldpi folders and
> on
> >> and
> >> > on instead of only into drawable folder. But You don't realize, that
> >> this
> >> > is
> >> > double bug, because this icon are in specific drawable folders, but in
> >> bad
> >> > resolution... So benefits of this are missing.
> >> >
> >> > Behaviour to be expected of (Android) CLI:
> >> >
> >> >* icon with density not specified => copy this icon into drawable
> >> folder
> >> >* icon with density specified => copy into intended drawable folder
> >> >(drawable-density)
> >> >
> >> >
> >> > Current behaviour of (Android) CLI:
> >> >
> >> >* icon with density not specified => copied this icon (and in
> >> addition
> >> >all icon in the same resolution) into all of drawable folders
> except
> >> >drawable folder...
> >> >* icon with density specified => i don't tested this behaviour, I
> >> don't
> >> >like byrocracy, so I don't use this scenario (on Android
> development
> >> >naturally), but i think this scenario is functional
> >> >
> >> >
> >> > Nice day,
> >> >
> >> > Jan Velecký.
> >> >
> >> >
> >> > "
> >> > I disagree about Android doing a good job. We just don't notice it
> >> because
> >> > we happen to have stupidly high quality template icons and we mostly
> >> test
> >> > on
> >> > hdpi and xhdpi devices. I'm sure if I ran this on an mdpi or ldpi
> >> device,
> >> > the icon would be all distorted.
> >> > "
> >> >
> >>
> >
>

Re: Monthly Cordova hangouts

2014-07-14 Thread Brian LeRoux

Joe is still PTO (and hopefully enjoying the shit out of it) so that'll
have to wait


On Mon, Jul 14, 2014 at 10:48 AM, Parashuram Narasimhan (MS OPEN TECH) <
panar...@microsoft.com> wrote:

> I added a couple of items for 3.6.0 release for Windows Universal apps. We
> also decided to talk about the min/max Android and iOS versions right
> (Joe's questions about this) ?
>
> @Lisa, would this be too early to talk about configurable folders in the
> CLI?
>
> -Original Message-
> From: brian.ler...@gmail.com [mailto:brian.ler...@gmail.com] On Behalf Of
> Brian LeRoux
> Sent: Monday, July 14, 2014 10:31 AM
> To: dev@cordova.apache.org
> Subject: Re: Monthly Cordova hangouts
>
> anyone want to take a stab at an agenda? (no major blockers/issues for us
> in Vancouver/SF atm)
>
>
> On Mon, Jul 14, 2014 at 8:49 AM, David Kemp  wrote:
>
> > The call is scheduled for tomorrow evening.
> > On 14 Jul 2014 11:44, "Parashuram Narasimhan (MS OPEN TECH)" <
> > panar...@microsoft.com> wrote:
> >
> > > Just wondering if we already had the Monthly hangouts for this
> > > month. We usually have it on 15th every month, right ?
> > > Also, I remember that from the last hangout, we had trouble getting
> > > more than 10 people into the hangout. Do we want to try alternate
> > > solutions (Webex, Lync, or a conference bridge) that can let more
> > > people
> > participate?
> > >
> >
>

Re: Mailing List Subscription

Please send an email to the appropriate mailing list subscription
address as described on our homepage:
http://cordova.apache.org/index.html#mailing-list

On Mon, Jul 14, 2014 at 3:40 AM, Rahul Pandey
 wrote:
> Hi,
>
> I would like to subscribe for the mailing lists.
>
> --
> *Rahul Pandey*
> *General Manager IT*
>
> *Application Nexus Webservices Pvt. Ltd.*
> 101-105, Center One,
> Next to Ashoka Buildcon,
> Ashoka Marg, Nasik - 422 011
> Maharashtra. INDIA
>
> Office:+91-253-2236556
> Mobile: +91-9665993073
> http://www.applicationnexus.com
>
>
> DISCLAIMER:
> ---
>
> The contents of this e-mail and any attachment(s) are confidential and
> intended for the named recipient(s) only.
>
> It shall not attach any liability on the originator or Application Nexus or
> its affiliates. Any views or opinions presented in this email are solely
> those of the author and may not necessarily reflect the opinions of
> Application Nexus or its affiliates.
>
> Any form of reproduction, dissemination, copying, disclosure, modification,
> distribution and / or publication of this message without the prior written
> consent of the author of this e-mail is strictly prohibited. If you have
> received this email in error please delete it and notify the sender
> immediately. Before opening any mail and attachments please check them for
> viruses and defect.
>
> ---

[GitHub] cordova-plugin-file pull request: CB-7093 Ported automated File te...

2014-07-14 Thread clelland

Github user clelland commented on the pull request:

https://github.com/apache/cordova-plugin-file/pull/60#issuecomment-48936357
  
Wow, thanks for taking that on; it's a lot of work!

(I had previously done most of this last year, on 
https://github.com/apache/cordova-plugin-file/tree/cdvtest, but there have 
obviously been a lot of changes to the tests since then)

Do you know what mobile-spec commit your tests are based on? (So that we 
can continue converting any new tests which land in that repository)


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: Pointing docs to edge

2014-07-14 Thread Max Woghiren

There's probably a better place for that information.  Also, in practice,
you can imagine how "coming soon" documentation could be kind of clunky,
especially in cases where it's just a behavior change ("right now, X does Y
and Z; soon it will do K as well, and M instead of Y").

I'm sure such changes could be worded more nicely, but that's maybe an
unfortunate concern to pin on someone who's making the change.  Saying
"make the documentation change in the relevant branch" instead of "find a
way to neatly explain that the change is coming soon" would probably do a
better job of encouraging documentation maintenance.


On Mon, Jul 14, 2014 at 1:30 PM, David Kemp  wrote:

> I would prefer to have the 'coming soon' stuff more visible.
> I like the idea that when looking for how to do something, its easy to see
> improvements that have already landed - and I can possibly get just by
> grabbing a bleeding edge plugin/tool.
>
>
>
> On Mon, Jul 14, 2014 at 1:25 PM, Max Woghiren  wrote:
>
> > I agree.  I think 3 is my preferred option; I think it lends itself best
> to
> > a sustainable and straightforward workflow.
> >
> > Docs fixes relevant to the current release of the CLI and each platform
> can
> > be committed directly to master.  Unreleased changes can be committed to
> > the appropriate branch, and we can add the merging of the branch as a
> step
> > in the release process.
> >
> >
> > On Mon, Jul 14, 2014 at 1:06 PM, Ray Camden  wrote:
> >
> > > Personally I'd rather not have any "coming soon" paragraphs in the doc
> > > text. As a user, if I'm at the docs, I don't care what is coming next.
> > I'm
> > > trying to solve a problem I have *now*, or trying to build now.
> Anything
> > > that is coming soon is a distractor.
> > >
> > > Do I feel strongly about it? No, but I'd vote against it being in the
> > docs
> > > at all. Stuff like that should definitely be communicated to users -
> via
> > > the Cordova blog perhaps - but not in the mainline docs.
> > >
> > > 
> > > From: m...@google.com  on behalf of Max Woghiren <
> > > m...@chromium.org>
> > > Sent: Monday, July 14, 2014 10:27 AM
> > > To: dev
> > > Subject: Re: Pointing docs to edge
> > >
> > > Okay, so here are the current proposals for handling Ray's issue
> (thanks
> > > Ray!):
> > >
> > > 1. Update docs at commit-time and release-time.  At commit-time,
> > > documentation changes can be marked with "coming soon", or "removed in
> > next
> > > release", or whatever the relevant message is.  At release-time, docs
> are
> > > further updated to remove these sub-messages.
> > >
> > > 2. Use CSS to do the manual marking in proposal 1.  We could also use
> it
> > to
> > >
> >
>

[GitHub] cordova-android pull request: Support for PluginFactory

Github user agrieve commented on the pull request:

https://github.com/apache/cordova-android/pull/97#issuecomment-48938359
  
Change needs to be rebased & I need to you confirm you've signed Apache's 
ICLA http://www.apache.org/licenses/#clas


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: Add build status to github

2014-07-14 Thread Jesse

We should just use Travis for quick sanity check tests.

re: integration testing
Getting into all the other build+test options is too close to Medic. Unless
we plan to abandon Medic, we should focus on getting Medic+BuildBot working
perfectly across all platforms, then possibly even reporting back to github
on every commit.

@purplecabbage
risingj.com


On Mon, Jul 14, 2014 at 7:16 AM, Sergey Grebnov (Akvelon) <
v-seg...@microsoft.com> wrote:

> Tests on Windows:
> I've compared Wercker and Appveyor and as for me it looks like Appveyor is
> a better option to proceed for Windows since
> 1.  Wercker's existing windows boxes doesn't support building of Windows
> 8.1 and WP 8.1 apps due to absence of Windows 8.1 and WP 8.1 SDKs on the
> boxes.
> 2.  Appveyor supports above
> Please note, Wercker supports custom VM boxes so potentially we can add
> custom VMs but I'm not sure it is good idea to maintain them.
>
> Tests on OSX:
> I propose to use Travis since in comparison to Wercker it provides OSX
> test boxes with XCode installed (
> http://docs.travis-ci.com/user/osx-ci-environment) and also supports
> Android builds (http://docs.travis-ci.com/user/languages/android)
>
> Thx!
> Sergey
> -Original Message-
> From: Sergey Grebnov (Akvelon)
> Sent: Monday, July 7, 2014 6:00 PM
> To: dev@cordova.apache.org
> Subject: RE: Add build status to github
>
> Hey Mark, it is really great to see you are working in this direction,
> thx! Here are my additional notes
>
> I think we should have discussion in two directions here:
> 1. Decide what we want to run as test for each repo 2.  Particular
> service/implementation details
>
> As for 1:
> a) LIB, CLI: I propose to run unit tests via 'npm test' for cordova-lib,
> cordova-cli, cordova-plugman (btw, I don't see plugman tests so not sure we
> have them) It seems, that Mark is on the same page.
>
> b) PLATFORMS: for the platforms I propose to start from implementing
> simple e2e test with the following steps (written in nodejs):
> - install cordova-cli (apache/master?)
> - create test app
> - add platform
> - build
>
> * as a long term goal we may want to move this to npm tests (but
> include to special group which can be run with additional flag since I
> don't think we should run this along with general unit tests )
>
> As for 2:
> If we want unified build platform across all repos it seems that Wercker
> and Appveyor are the only good options due to windows support required.
> Both looks good to me, but I need to double check Wercker supports VS2013
> (msbuild12) since it requires to build cordova-windows (will investigate
> and respond). I also think is that Travic-CI is the most safe option for
> other platforms/repos since they already proved to be a good solution for
> many open source companies.
>
> Thx!
> Sergey
> -Original Message-
> From: Mark Koudritsky [mailto:kam...@google.com]
> Sent: Friday, July 4, 2014 6:57 AM
> To: dev@cordova.apache.org
> Subject: Re: Add build status to github
>
> Oops, sorry, didn't look at the links before sending another link to
> AppVeyor. Why not to use AppVeyor for lib and cli too? We could definitely
> use some testing on windows.
>
> I also experimented with Wercker  which is yet
> another free CI service.
> Added it to a branch in my fork of cordova-lib. You can see a badge with
> build results here in README:
> https://github.com/kamrik/cordova-lib/tree/wercker
>
> I never used Travis CI, but from description looks like Wercker is a bit
> more flexible with environment setup and they even offer a predefined
> environment for building Android apps <
> http://devcenter.wercker.com/articles/languages/android.html> so maybe we
> can use it to run a test that goes all the way to building an apk. They say
> 
> they support checking pull requests too.
>
> What do you think?
>
> That said, I'm not particularly attached to any specific CI service, any
> of them would be very helpful.
>
>
> On Fri, Jun 27, 2014 at 10:40 AM, Andrew Grieve 
> wrote:
>
> > Make it happen :)
> >
> >
> > On Fri, Jun 27, 2014 at 10:02 AM, Mark Koudritsky 
> > wrote:
> >
> > > Would be nice to have this. Specifically Travis will only run on
> > > Linux
> > (and
> > > maybe OSX). Here is a random similar service I found that can also
> > > run on windows.
> > > http://www.appveyor.com/
> > >
> >
>

[GitHub] cordova-plugin-file pull request: CB-7093 Ported automated File te...

Github user asfgit closed the pull request at:

https://github.com/apache/cordova-plugin-file/pull/60


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cordova-ios pull request: Fix build warnings

Github user asfgit closed the pull request at:

https://github.com/apache/cordova-ios/pull/99


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[iOS] CDVPlugin method deprecations

https://issues.apache.org/jira/browse/CB-7000

They were documented in 2.x, but not in 3.x.
According to the deprecation policy
(http://wiki.apache.org/cordova/DeprecationPolicy), it will be
deprecated in the next release (changes are already in trunk), and
removed in 3.9.0.

If it was a publicly documented API, which it is not, it would have
been removed in 4.0 instead. Unless its a better idea to do this in
4.0?

Yup, some 3rd party plugins still use these methods.

(writing a blog post about this soon)

[GitHub] cordova-ios pull request: Fixed RegEx error when callbackId is nil

Github user agrieve commented on a diff in the pull request:

https://github.com/apache/cordova-ios/pull/97#discussion_r14897935
  
--- Diff: CordovaLib/Classes/CDVCommandDelegateImpl.m ---
@@ -107,6 +107,10 @@ - (BOOL)isValidCallbackId:(NSString *)callbackId
 return NO;
 }
 }
+//Allow nil callbackId
+if (callbackId == nil){
+  return YES;
--- End diff --

I think this should return NO. nil is not a valid callback id.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cordova-plugin-file pull request: [CB- 7057] Improve File API docu...

Github user asfgit closed the pull request at:

https://github.com/apache/cordova-plugin-file/pull/59


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cordova-plugin-file pull request: changed header

Github user agrieve commented on the pull request:

https://github.com/apache/cordova-plugin-file/pull/57#issuecomment-48948290
  
Looks like this change was made as a part of another commit. Thanks!


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: [iOS] CDVPlugin method deprecations

2014-07-14 Thread Ian Clelland

I would suggest that we have every right to drop these in 3.9.0, as you
say, but that in the interest of maintaining goodwill with the community,
this should be a 4.0 change.

If 4.0 also comes with iOS8 WKWebView support, then this has a strong
parallel with Cordova-Android 4.0.x -- the overall direction of development
for both platforms is "new WebView available, and changes may be needed to
some plugins."


On Mon, Jul 14, 2014 at 3:22 PM, Shazron  wrote:

> https://issues.apache.org/jira/browse/CB-7000
>
> They were documented in 2.x, but not in 3.x.
> According to the deprecation policy
> (http://wiki.apache.org/cordova/DeprecationPolicy), it will be
> deprecated in the next release (changes are already in trunk), and
> removed in 3.9.0.
>
> If it was a publicly documented API, which it is not, it would have
> been removed in 4.0 instead. Unless its a better idea to do this in
> 4.0?
>
> Yup, some 3rd party plugins still use these methods.
>
> (writing a blog post about this soon)
>

[GitHub] cordova-plugin-globalization pull request: CB-4602 Changed CDVGlob...

Github user asfgit closed the pull request at:

https://github.com/apache/cordova-plugin-globalization/pull/15


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cordova-android pull request: Support for PluginFactory

2014-07-14 Thread purplecabbage

Github user purplecabbage commented on the pull request:

https://github.com/apache/cordova-android/pull/97#issuecomment-48949233
  
I think this needs to be discussed more before merged, this seems to 
potentially break stuff, and the benefit has not clearly been discussed. ( or 
alternatives ) 
Essentially, Plugin creation code has been moved into it's own class ( cool 
) ... which then must be passed all over the place ... ( less cool )

I would like to hear more about the specific problem this is attempting to 
solve, and some discussion on potential other methods of solving it.

Also, the fact that IstvÃ¡n clearly states 'I'm quite a newbie programmer 
..' does not give me great confidence, although the code looks good, I fear 
architectural pitfalls.



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: Monthly Cordova hangouts

2014-07-14 Thread Joe Bowser

No, I'm actually back this week.  I'll be in Portland next week for
OSCON, so my availability will be even more sporatic than it is now.
I'll be available for the hangout tomorrow.

On Mon, Jul 14, 2014 at 10:56 AM, Brian LeRoux  wrote:
> Joe is still PTO (and hopefully enjoying the shit out of it) so that'll
> have to wait
>
>
> On Mon, Jul 14, 2014 at 10:48 AM, Parashuram Narasimhan (MS OPEN TECH) <
> panar...@microsoft.com> wrote:
>
>> I added a couple of items for 3.6.0 release for Windows Universal apps. We
>> also decided to talk about the min/max Android and iOS versions right
>> (Joe's questions about this) ?
>>
>> @Lisa, would this be too early to talk about configurable folders in the
>> CLI?
>>
>> -Original Message-
>> From: brian.ler...@gmail.com [mailto:brian.ler...@gmail.com] On Behalf Of
>> Brian LeRoux
>> Sent: Monday, July 14, 2014 10:31 AM
>> To: dev@cordova.apache.org
>> Subject: Re: Monthly Cordova hangouts
>>
>> anyone want to take a stab at an agenda? (no major blockers/issues for us
>> in Vancouver/SF atm)
>>
>>
>> On Mon, Jul 14, 2014 at 8:49 AM, David Kemp  wrote:
>>
>> > The call is scheduled for tomorrow evening.
>> > On 14 Jul 2014 11:44, "Parashuram Narasimhan (MS OPEN TECH)" <
>> > panar...@microsoft.com> wrote:
>> >
>> > > Just wondering if we already had the Monthly hangouts for this
>> > > month. We usually have it on 15th every month, right ?
>> > > Also, I remember that from the last hangout, we had trouble getting
>> > > more than 10 people into the hangout. Do we want to try alternate
>> > > solutions (Webex, Lync, or a conference bridge) that can let more
>> > > people
>> > participate?
>> > >
>> >
>>

Re: [iOS] CDVPlugin method deprecations

Makes sense - no point in landing this early anyway which will create
friction because of "rules". I'll change the removal to 4.0

On Mon, Jul 14, 2014 at 12:35 PM, Ian Clelland  wrote:
> I would suggest that we have every right to drop these in 3.9.0, as you
> say, but that in the interest of maintaining goodwill with the community,
> this should be a 4.0 change.
>
> If 4.0 also comes with iOS8 WKWebView support, then this has a strong
> parallel with Cordova-Android 4.0.x -- the overall direction of development
> for both platforms is "new WebView available, and changes may be needed to
> some plugins."
>
>
> On Mon, Jul 14, 2014 at 3:22 PM, Shazron  wrote:
>
>> https://issues.apache.org/jira/browse/CB-7000
>>
>> They were documented in 2.x, but not in 3.x.
>> According to the deprecation policy
>> (http://wiki.apache.org/cordova/DeprecationPolicy), it will be
>> deprecated in the next release (changes are already in trunk), and
>> removed in 3.9.0.
>>
>> If it was a publicly documented API, which it is not, it would have
>> been removed in 4.0 instead. Unless its a better idea to do this in
>> 4.0?
>>
>> Yup, some 3rd party plugins still use these methods.
>>
>> (writing a blog post about this soon)
>>

Re: Add build status to github

2014-07-14 Thread Mark Koudritsky

Sergey, can we set up AppVeyor to run the "npm test" of cordova-lib?
If yes, it would be an excellent option - we will have cordova-lib jasmine
tests running on windows, which otherwise happens rarely for all of us who
develop on Mac or Linux.


On Mon, Jul 14, 2014 at 2:54 PM, Jesse  wrote:

> We should just use Travis for quick sanity check tests.
>
> re: integration testing
> Getting into all the other build+test options is too close to Medic. Unless
> we plan to abandon Medic, we should focus on getting Medic+BuildBot working
> perfectly across all platforms, then possibly even reporting back to github
> on every commit.
>
> @purplecabbage
> risingj.com
>
>
> On Mon, Jul 14, 2014 at 7:16 AM, Sergey Grebnov (Akvelon) <
> v-seg...@microsoft.com> wrote:
>
> > Tests on Windows:
> > I've compared Wercker and Appveyor and as for me it looks like Appveyor
> is
> > a better option to proceed for Windows since
> > 1.  Wercker's existing windows boxes doesn't support building of Windows
> > 8.1 and WP 8.1 apps due to absence of Windows 8.1 and WP 8.1 SDKs on the
> > boxes.
> > 2.  Appveyor supports above
> > Please note, Wercker supports custom VM boxes so potentially we can add
> > custom VMs but I'm not sure it is good idea to maintain them.
> >
> > Tests on OSX:
> > I propose to use Travis since in comparison to Wercker it provides OSX
> > test boxes with XCode installed (
> > http://docs.travis-ci.com/user/osx-ci-environment) and also supports
> > Android builds (http://docs.travis-ci.com/user/languages/android)
> >
> > Thx!
> > Sergey
> > -Original Message-
> > From: Sergey Grebnov (Akvelon)
> > Sent: Monday, July 7, 2014 6:00 PM
> > To: dev@cordova.apache.org
> > Subject: RE: Add build status to github
> >
> > Hey Mark, it is really great to see you are working in this direction,
> > thx! Here are my additional notes
> >
> > I think we should have discussion in two directions here:
> > 1. Decide what we want to run as test for each repo 2.  Particular
> > service/implementation details
> >
> > As for 1:
> > a) LIB, CLI: I propose to run unit tests via 'npm test' for cordova-lib,
> > cordova-cli, cordova-plugman (btw, I don't see plugman tests so not sure
> we
> > have them) It seems, that Mark is on the same page.
> >
> > b) PLATFORMS: for the platforms I propose to start from implementing
> > simple e2e test with the following steps (written in nodejs):
> > - install cordova-cli (apache/master?)
> > - create test app
> > - add platform
> > - build
> >
> > * as a long term goal we may want to move this to npm tests (but
> > include to special group which can be run with additional flag since I
> > don't think we should run this along with general unit tests )
> >
> > As for 2:
> > If we want unified build platform across all repos it seems that Wercker
> > and Appveyor are the only good options due to windows support required.
> > Both looks good to me, but I need to double check Wercker supports VS2013
> > (msbuild12) since it requires to build cordova-windows (will investigate
> > and respond). I also think is that Travic-CI is the most safe option for
> > other platforms/repos since they already proved to be a good solution for
> > many open source companies.
> >
> > Thx!
> > Sergey
> > -Original Message-
> > From: Mark Koudritsky [mailto:kam...@google.com]
> > Sent: Friday, July 4, 2014 6:57 AM
> > To: dev@cordova.apache.org
> > Subject: Re: Add build status to github
> >
> > Oops, sorry, didn't look at the links before sending another link to
> > AppVeyor. Why not to use AppVeyor for lib and cli too? We could
> definitely
> > use some testing on windows.
> >
> > I also experimented with Wercker  which is yet
> > another free CI service.
> > Added it to a branch in my fork of cordova-lib. You can see a badge with
> > build results here in README:
> > https://github.com/kamrik/cordova-lib/tree/wercker
> >
> > I never used Travis CI, but from description looks like Wercker is a bit
> > more flexible with environment setup and they even offer a predefined
> > environment for building Android apps <
> > http://devcenter.wercker.com/articles/languages/android.html> so maybe
> we
> > can use it to run a test that goes all the way to building an apk. They
> say
> > 
> > they support checking pull requests too.
> >
> > What do you think?
> >
> > That said, I'm not particularly attached to any specific CI service, any
> > of them would be very helpful.
> >
> >
> > On Fri, Jun 27, 2014 at 10:40 AM, Andrew Grieve 
> > wrote:
> >
> > > Make it happen :)
> > >
> > >
> > > On Fri, Jun 27, 2014 at 10:02 AM, Mark Koudritsky 
> > > wrote:
> > >
> > > > Would be nice to have this. Specifically Travis will only run on
> > > > Linux
> > > (and
> > > > maybe OSX). Here is a random similar service I found that can also
> > > > run on windows.
> > > > http://www.appveyor.com/
> > > >

[GitHub] cordova-android pull request: Support for PluginFactory

2014-07-14 Thread infil00p

Github user infil00p commented on the pull request:

https://github.com/apache/cordova-android/pull/97#issuecomment-48951400
  
init() has been recently deprecated.  I'm not convinced that this is 
solving a problem that we currently have.  I'm not in favour of having 
Factories just because it's a Java pattern.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: Monthly Cordova hangouts

2014-07-14 Thread Tommy Williams

Which time slot is this one?
On 15 Jul 2014 05:49, "Joe Bowser"  wrote:

> No, I'm actually back this week.  I'll be in Portland next week for
> OSCON, so my availability will be even more sporatic than it is now.
> I'll be available for the hangout tomorrow.
>
> On Mon, Jul 14, 2014 at 10:56 AM, Brian LeRoux  wrote:
> > Joe is still PTO (and hopefully enjoying the shit out of it) so that'll
> > have to wait
> >
> >
> > On Mon, Jul 14, 2014 at 10:48 AM, Parashuram Narasimhan (MS OPEN TECH) <
> > panar...@microsoft.com> wrote:
> >
> >> I added a couple of items for 3.6.0 release for Windows Universal apps.
> We
> >> also decided to talk about the min/max Android and iOS versions right
> >> (Joe's questions about this) ?
> >>
> >> @Lisa, would this be too early to talk about configurable folders in the
> >> CLI?
> >>
> >> -Original Message-
> >> From: brian.ler...@gmail.com [mailto:brian.ler...@gmail.com] On Behalf
> Of
> >> Brian LeRoux
> >> Sent: Monday, July 14, 2014 10:31 AM
> >> To: dev@cordova.apache.org
> >> Subject: Re: Monthly Cordova hangouts
> >>
> >> anyone want to take a stab at an agenda? (no major blockers/issues for
> us
> >> in Vancouver/SF atm)
> >>
> >>
> >> On Mon, Jul 14, 2014 at 8:49 AM, David Kemp 
> wrote:
> >>
> >> > The call is scheduled for tomorrow evening.
> >> > On 14 Jul 2014 11:44, "Parashuram Narasimhan (MS OPEN TECH)" <
> >> > panar...@microsoft.com> wrote:
> >> >
> >> > > Just wondering if we already had the Monthly hangouts for this
> >> > > month. We usually have it on 15th every month, right ?
> >> > > Also, I remember that from the last hangout, we had trouble getting
> >> > > more than 10 people into the hangout. Do we want to try alternate
> >> > > solutions (Webex, Lync, or a conference bridge) that can let more
> >> > > people
> >> > participate?
> >> > >
> >> >
> >>
>

Re: Monthly Cordova hangouts

2014-07-14 Thread Jesse

http://wiki.apache.org/cordova/Google%20Hangout%20Discussion%20Notes

7PM EST

@purplecabbage
risingj.com


On Mon, Jul 14, 2014 at 1:11 PM, Tommy Williams  wrote:

> Which time slot is this one?
> On 15 Jul 2014 05:49, "Joe Bowser"  wrote:
>
> > No, I'm actually back this week.  I'll be in Portland next week for
> > OSCON, so my availability will be even more sporatic than it is now.
> > I'll be available for the hangout tomorrow.
> >
> > On Mon, Jul 14, 2014 at 10:56 AM, Brian LeRoux  wrote:
> > > Joe is still PTO (and hopefully enjoying the shit out of it) so that'll
> > > have to wait
> > >
> > >
> > > On Mon, Jul 14, 2014 at 10:48 AM, Parashuram Narasimhan (MS OPEN TECH)
> <
> > > panar...@microsoft.com> wrote:
> > >
> > >> I added a couple of items for 3.6.0 release for Windows Universal
> apps.
> > We
> > >> also decided to talk about the min/max Android and iOS versions right
> > >> (Joe's questions about this) ?
> > >>
> > >> @Lisa, would this be too early to talk about configurable folders in
> the
> > >> CLI?
> > >>
> > >> -Original Message-
> > >> From: brian.ler...@gmail.com [mailto:brian.ler...@gmail.com] On
> Behalf
> > Of
> > >> Brian LeRoux
> > >> Sent: Monday, July 14, 2014 10:31 AM
> > >> To: dev@cordova.apache.org
> > >> Subject: Re: Monthly Cordova hangouts
> > >>
> > >> anyone want to take a stab at an agenda? (no major blockers/issues for
> > us
> > >> in Vancouver/SF atm)
> > >>
> > >>
> > >> On Mon, Jul 14, 2014 at 8:49 AM, David Kemp 
> > wrote:
> > >>
> > >> > The call is scheduled for tomorrow evening.
> > >> > On 14 Jul 2014 11:44, "Parashuram Narasimhan (MS OPEN TECH)" <
> > >> > panar...@microsoft.com> wrote:
> > >> >
> > >> > > Just wondering if we already had the Monthly hangouts for this
> > >> > > month. We usually have it on 15th every month, right ?
> > >> > > Also, I remember that from the last hangout, we had trouble
> getting
> > >> > > more than 10 people into the hangout. Do we want to try alternate
> > >> > > solutions (Webex, Lync, or a conference bridge) that can let more
> > >> > > people
> > >> > participate?
> > >> > >
> > >> >
> > >>
> >
>

[GitHub] cordova-android pull request: Support for PluginFactory

2014-07-14 Thread qwe2

Github user qwe2 commented on the pull request:

https://github.com/apache/cordova-android/pull/97#issuecomment-48953658
  
The idea was that I needed a more modular way of creating plugins that I 
had more control over than just relying on Cordova to instantiate arbitrary 
classes with their default constructor. I myself don't think this is the best 
or even a good solution to the problem â if there is a problem at all â but 
this seemed to be quite an idiomatic way to go about it. I do admit though that 
I did not think much about it architecture wise.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cordova-plugin-globalization pull request: CB-7102 - Initial imple...

Github user rodms10 commented on a diff in the pull request:


https://github.com/apache/cordova-plugin-globalization/pull/17#discussion_r14900988
  
--- Diff: plugin.xml ---
@@ -70,6 +70,20 @@


 
+
+
+
+
+
+
+
+
+
--- End diff --

The `date.ini` file wasn't being loaded for me because when `l10n.js` loads 
the `application/l10n` link wasn't present in the head yet. Moving this module 
to the top here fixed it for me.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cordova-plugin-file pull request: CB-7093 Ported automated File te...

2014-07-14 Thread martincgg

Github user martincgg commented on the pull request:

https://github.com/apache/cordova-plugin-file/pull/60#issuecomment-48954105

The last commit on which is based is after this one:
https://git-wip-us.apache.org/repos/asf?p=cordova-mobile-spec.git;a=commit;h=005641907754e04895135e502ef9fcb6f24d353f

Made on 2014-06-23 by Martin Bektchiev- Fix failing battery tests. Add a
dummy battery listener
There's no file tests after that commit.
Based on some fixes that I've sent to mobile-spec.
https://github.com/apache/cordova-mobile-spec/pull/79
https://github.com/apache/cordova-mobile-spec/pull/75

By the way, your changes were good, I tried to remove most of the comments
and old content, some of them escaped from my sight, also it makes perfect
sense use URL instead of URI since is deprecated.

Ian, about the change that you made on plugin.xml, I think Andrew Grieve
point out that those changes would be made by adding some improvements to the
CLI, and avoid include tests in the release version of the plugin.
Check this comment on this PR.
https://github.com/apache/cordova-plugin-media-capture/pull/19

Thanks for taking this on, I'll be delivering the manual tests shortly.
Thanks @clelland

---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cordova-plugin-globalization pull request: CB-7102 - Initial imple...

Github user rodms10 commented on a diff in the pull request:


https://github.com/apache/cordova-plugin-globalization/pull/17#discussion_r14901564
  
--- Diff: src/firefoxos/GlobalizationProxy.js ---
@@ -0,0 +1,214 @@
+/*
+ *
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements.  See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership.  The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License.  You may obtain a copy of the License at
+ *
+ *   http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied.  See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ *
+*/
+
+var GlobalizationError = require('./GlobalizationError');
+
+
+function addLinkToLocales() {
+  // Adding globalization file to the HEAD section
+  // 
+   var link = document.createElement("link");
+   link.setAttribute("rel", "resource");
+   link.setAttribute("type", "application/l10n");
+   link.setAttribute("href", "locales/date.ini");
+
+   document.head.appendChild(link);
+}
+
+addLinkToLocales();
+
+
+function getPreferredLanguage(successCB, errorCB) {
+// WARNING: this isn't perfect - there is a difference between UI 
language
+// and preferred language, however it doesn't happen too often.
+navigator.mozL10n.ready(function() {
+  successCB({value: navigator.mozL10n.language.code});
+});
+}
+
+function getLocaleName(successCB, errorCB) {
+navigator.mozL10n.ready(function() {
+  successCB(navigator.mozL10n.language.code);
+});
+}
+
+function dateToString(successCB, errorCB, params) {
+var date = new Date(params[0].date);
+var options = params[0].options;
+
+navigator.mozL10n.ready(function() {
+  var f = new navigator.mozL10n.DateTimeFormat();
+  successCB({'value': _getStringFromDate(f, date, options)});
+});
+
+function _getStringFromDate(f, date, options) {
+var format = navigator.mozL10n.get('shortDateTimeFormat');
+if (options) {
+  if (options.selector == 'date') {
+return f.localeDateString(date);
+  }
+  if (options.selector == 'time') {
+return f.localeTimeString(date);
+  }
+  if (options.formatLength != 'short') {
+var format = navigator.mozL10n.get('dateTimeFormat');
--- End diff --

`format` is already declared up top, you can drop the `var` here.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cordova-android pull request: Support for PluginFactory

2014-07-14 Thread purplecabbage

Github user purplecabbage commented on the pull request:

https://github.com/apache/cordova-android/pull/97#issuecomment-48955669
  
Thanks IstvÃ¡n,
I think what I was missing in your pull-request and problem description, is 
how your plugin uses the factory to do something that it otherwise could not.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cordova-plugin-globalization pull request: CB-7102 - Initial imple...

Github user rodms10 commented on a diff in the pull request:


https://github.com/apache/cordova-plugin-globalization/pull/17#discussion_r14902768
  
--- Diff: src/firefoxos/GlobalizationProxy.js ---
@@ -0,0 +1,214 @@
+/*
+ *
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements.  See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership.  The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License.  You may obtain a copy of the License at
+ *
+ *   http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied.  See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ *
+*/
+
+var GlobalizationError = require('./GlobalizationError');
+
+
+function addLinkToLocales() {
+  // Adding globalization file to the HEAD section
+  // 
+   var link = document.createElement("link");
+   link.setAttribute("rel", "resource");
+   link.setAttribute("type", "application/l10n");
+   link.setAttribute("href", "locales/date.ini");
+
+   document.head.appendChild(link);
+}
+
+addLinkToLocales();
+
+
+function getPreferredLanguage(successCB, errorCB) {
+// WARNING: this isn't perfect - there is a difference between UI 
language
+// and preferred language, however it doesn't happen too often.
+navigator.mozL10n.ready(function() {
+  successCB({value: navigator.mozL10n.language.code});
+});
+}
+
+function getLocaleName(successCB, errorCB) {
+navigator.mozL10n.ready(function() {
+  successCB(navigator.mozL10n.language.code);
+});
+}
+
+function dateToString(successCB, errorCB, params) {
+var date = new Date(params[0].date);
+var options = params[0].options;
+
+navigator.mozL10n.ready(function() {
+  var f = new navigator.mozL10n.DateTimeFormat();
+  successCB({'value': _getStringFromDate(f, date, options)});
+});
+
+function _getStringFromDate(f, date, options) {
+var format = navigator.mozL10n.get('shortDateTimeFormat');
+if (options) {
+  if (options.selector == 'date') {
+return f.localeDateString(date);
+  }
+  if (options.selector == 'time') {
+return f.localeTimeString(date);
+  }
+  if (options.formatLength != 'short') {
+var format = navigator.mozL10n.get('dateTimeFormat');
+return f.localeString(date, format);
+  }
+  if (options.selector == 'time') {
+return f.localeTimeString(date, format);
+  }
+}
+var d = f.localeDateString(date);
+var t = f.localeTimeString(date);
+return d + ' ' + t;
+}
+}
+
+function stringToDate(successCB, errorCB, params) {
+var date;
+var dateString = params[0].dateString;
+var options = params[0].options;
+try {
+  date = new Date(dateString);
+} catch(e) {  
+  console.log("Cordova, stringToDate, An error occurred " + e.message);
+  return errorCB(GlobalizationError(
+GlobalizationError.PARSING_ERROR, e.message));
+} 
+if (!date || date == 'Invalid Date') {
+  console.log("Cordova, stringToDate, Invalid Date: " + dateString);
+  return errorCB(GlobalizationError(
+GlobalizationError.PARSING_ERROR, 'Invalid Date (' + 
dateString + ')'));
+}
+
+var dateObj = {
+  'year': date.getFullYear(),
+  'month': date.getMonth(),
+  'day': date.getDay() 
+};
+var timeObj = {
+  'hour': date.getHours(),
+  'minute': date.getMinutes(),
+  'second': date.getSeconds(),
+  'millisecond': date.getMilliseconds() 
+};
+if (options) {
+  if (options.selector == 'date') {
+return successCB(dateObj);
+  }
+  if (options.selector == 'time') {
+return successCB(timeObj);
+  }
+}
+for (var i in timeObj) {
+  if (timeObj.hasOwnProperty(i)) {
+dateObj[i] = timeObj[i];
+  }
+}
+successCB(dateObj);
+}
+
+function getDatePattern(successCB, failureCB, options) {
+failureCB(GlobalizationError.UNKNOWN_ERROR, 'unsupported');

[GitHub] cordova-android pull request: Support for PluginFactory

2014-07-14 Thread purplecabbage

Github user purplecabbage commented on the pull request:

https://github.com/apache/cordova-android/pull/97#issuecomment-48958012
  
I recommend you continue to use a parameter-less constructor and provide 
some other interface for setting values in another plugin.  You are destined 
for pain, when your plugin requires factoryA to create it, and runs in the same 
project as a plugin that requires factoryB create it.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cordova-plugin-globalization pull request: CB-7102 - Initial imple...

Github user rodms10 commented on a diff in the pull request:


https://github.com/apache/cordova-plugin-globalization/pull/17#discussion_r14903106
  
--- Diff: doc/index.md ---
@@ -194,6 +197,11 @@ options:
 
 - The `formatLength` option supports only `short` and `full` values.
 
+### FirefoxOS Quirks
--- End diff --

Space between Firefox and OS.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cordova-android pull request: Support for PluginFactory

2014-07-14 Thread qwe2

Github user qwe2 commented on the pull request:

https://github.com/apache/cordova-android/pull/97#issuecomment-48957070
  
The simplest example that comes to mind would be the need to be able to 
pass additional parameters to a custom set of plugins or do something with them 
at instantiation by overriding the PluginFactory's ``createPlugin`` method. 
That's something I could not solve in a sensible way in Cordova.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cordova-plugin-globalization pull request: CB-7102 - Initial imple...

Github user rodms10 commented on a diff in the pull request:


https://github.com/apache/cordova-plugin-globalization/pull/17#discussion_r14903135
  
--- Diff: doc/index.md ---
@@ -194,6 +197,11 @@ options:
 
 - The `formatLength` option supports only `short` and `full` values.
 
+### FirefoxOS Quirks
+
+- `formatLength` is not sitinguishing `long` and `full` 
--- End diff --

Typo sitinguishing -> distinguishing.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cordova-plugin-globalization pull request: CB-7102 - Initial imple...

Github user rodms10 commented on a diff in the pull request:


https://github.com/apache/cordova-plugin-globalization/pull/17#discussion_r14903604
  
--- Diff: src/firefoxos/GlobalizationProxy.js ---
@@ -0,0 +1,214 @@
+/*
+ *
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements.  See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership.  The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License.  You may obtain a copy of the License at
+ *
+ *   http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied.  See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ *
+*/
+
+var GlobalizationError = require('./GlobalizationError');
+
+
+function addLinkToLocales() {
+  // Adding globalization file to the HEAD section
+  // 
+   var link = document.createElement("link");
+   link.setAttribute("rel", "resource");
+   link.setAttribute("type", "application/l10n");
+   link.setAttribute("href", "locales/date.ini");
+
+   document.head.appendChild(link);
+}
+
+addLinkToLocales();
+
+
+function getPreferredLanguage(successCB, errorCB) {
+// WARNING: this isn't perfect - there is a difference between UI 
language
+// and preferred language, however it doesn't happen too often.
+navigator.mozL10n.ready(function() {
+  successCB({value: navigator.mozL10n.language.code});
+});
+}
+
+function getLocaleName(successCB, errorCB) {
+navigator.mozL10n.ready(function() {
+  successCB(navigator.mozL10n.language.code);
+});
+}
+
+function dateToString(successCB, errorCB, params) {
--- End diff --

I think we can support more formats assuming what is [defined 
here](http://pubs.opengroup.org/onlinepubs/007908799/xsh/strftime.html) is 
supported. Got the link from [a comment in l10n_date.js 
file](https://github.com/zalun/cordova-plugin-globalization/blob/ffos-initial/src/firefoxos/l10n_date.js#L34).

Long time and date is looking good, I'm getting: `Wed Oct 29 2014 5:00:00 
PM`. Long time and short date are fine too. But long date gives me a short date 
and short time gives me long time.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: Monthly Cordova hangouts

2014-07-14 Thread Mike Billau

I added something about a default secure configuration: no whitelist, no
permissions, etc., that hopefully plays into the whitelist-as-a-plugin
topic that I don't think was ever resolved. Maybe this can be a more
general discussion about security but probably not.


On Mon, Jul 14, 2014 at 4:16 PM, Jesse  wrote:

> http://wiki.apache.org/cordova/Google%20Hangout%20Discussion%20Notes
>
> 7PM EST
>
> @purplecabbage
> risingj.com
>
>
> On Mon, Jul 14, 2014 at 1:11 PM, Tommy Williams 
> wrote:
>
> > Which time slot is this one?
> > On 15 Jul 2014 05:49, "Joe Bowser"  wrote:
> >
> > > No, I'm actually back this week.  I'll be in Portland next week for
> > > OSCON, so my availability will be even more sporatic than it is now.
> > > I'll be available for the hangout tomorrow.
> > >
> > > On Mon, Jul 14, 2014 at 10:56 AM, Brian LeRoux  wrote:
> > > > Joe is still PTO (and hopefully enjoying the shit out of it) so
> that'll
> > > > have to wait
> > > >
> > > >
> > > > On Mon, Jul 14, 2014 at 10:48 AM, Parashuram Narasimhan (MS OPEN
> TECH)
> > <
> > > > panar...@microsoft.com> wrote:
> > > >
> > > >> I added a couple of items for 3.6.0 release for Windows Universal
> > apps.
> > > We
> > > >> also decided to talk about the min/max Android and iOS versions
> right
> > > >> (Joe's questions about this) ?
> > > >>
> > > >> @Lisa, would this be too early to talk about configurable folders in
> > the
> > > >> CLI?
> > > >>
> > > >> -Original Message-
> > > >> From: brian.ler...@gmail.com [mailto:brian.ler...@gmail.com] On
> > Behalf
> > > Of
> > > >> Brian LeRoux
> > > >> Sent: Monday, July 14, 2014 10:31 AM
> > > >> To: dev@cordova.apache.org
> > > >> Subject: Re: Monthly Cordova hangouts
> > > >>
> > > >> anyone want to take a stab at an agenda? (no major blockers/issues
> for
> > > us
> > > >> in Vancouver/SF atm)
> > > >>
> > > >>
> > > >> On Mon, Jul 14, 2014 at 8:49 AM, David Kemp 
> > > wrote:
> > > >>
> > > >> > The call is scheduled for tomorrow evening.
> > > >> > On 14 Jul 2014 11:44, "Parashuram Narasimhan (MS OPEN TECH)" <
> > > >> > panar...@microsoft.com> wrote:
> > > >> >
> > > >> > > Just wondering if we already had the Monthly hangouts for this
> > > >> > > month. We usually have it on 15th every month, right ?
> > > >> > > Also, I remember that from the last hangout, we had trouble
> > getting
> > > >> > > more than 10 people into the hangout. Do we want to try
> alternate
> > > >> > > solutions (Webex, Lync, or a conference bridge) that can let
> more
> > > >> > > people
> > > >> > participate?
> > > >> > >
> > > >> >
> > > >>
> > >
> >
>

[GitHub] cordova-lib pull request: CB-3571: support for element in...

2014-07-14 Thread perilousleigh

Github user perilousleigh commented on the pull request:

https://github.com/apache/cordova-lib/pull/30#issuecomment-48961753
  
After checking the code it doesn't look like it's expecting the "land" or 
"port" prefixes in the density attribute.  So removing the orientation prefix 
and just using the density values ("hdpi", "ldpi", "mdpi", "xhdpi") worked for 
me.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cordova-lib pull request: CB-7132: fix regression regarding defaul...

GitHub user AxelNennker opened a pull request:

https://github.com/apache/cordova-lib/pull/58

CB-7132: fix regression regarding default resources



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/AxelNennker/cordova-lib master

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cordova-lib/pull/58.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #58


commit 09b16db9df8083c0955680004cb89db23af1459e
Author: ignisvulpis 
Date:   2014-07-14T21:38:18Z

CB-7132: fix regression regarding default resources




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cordova-lib pull request: CB-3571: support for element in...

Github user AxelNennker commented on the pull request:

https://github.com/apache/cordova-lib/pull/30#issuecomment-48963855
  
@perilousleigh 
On Android the default splash screen are in the land/port directories. 
The example above uses the same directories.
Please add output from "cordova platform add android -d"  to describe what 
is not working for you.

There is a new issue that "default" resources do not work in 3.5.0-0.2.6.
https://issues.apache.org/jira/browse/CB-7132
Maybe that is causing problems for you too?
https://github.com/apache/cordova-lib/pull/58

I am always using the full monty; that is: specify icons and splashes for 
all densities for the best look


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: One platform development vs. Cordova CLI

2014-07-14 Thread Frederico Galvão

I agree with the core message from Axel, but I'd refrase that last line as:

"The bottom line is: either use Cordova CLI or not".

Cordova can still be used without the CLI portion just as well, which
should suffice Jan for his needs.

However, I'll add that you can still use Cordova with the CLI (and thus
following the directory structure and rules the CLI gives you) and still be
efficient even if it's only one target platform.
What made you think that it is "better to change platform project
config.xml instead of whole project config.xml" should be clarified better
if you can, so that the Cordova team can improve the tool.


2014-07-14 5:35 GMT-03:00 Axel Nennker :

> My experience with Cordova (and other tools for that matter) is that it
> makes no sense to change tool generated files.
> If the tool is improved you do not benefit from this improvement because
> your modified files will be changed by the new version.
> If you change a tool generated file you are out.
> When we started using Cordova me and other colleagues thought that our
> project "needs" to change Cordova generated files too.
> In each case this turned out to be wrong.
> Most of the times writing a Cordova plugin is the solution.
>
> The bottom line is: either use Cordova or not. (or send a pull request to
> improve it)
>
> -Axel
>
>
>
>
> 2014-07-13 22:18 GMT+02:00 Jan Velecký :
>
> > Hello,
> > there is serious backlog when using CLI in case one platform development.
> > In
> > this case is better to change platform project config.xml instead of
> whole
> > project config.xml. Problem is what prepare should do, and what prepare
> > actually do. (And prepare is also run if we do build.) At this moment,
> > prepare in CLI does clean & copy...
> > Also prepare does it in different way in Android, than in iOS.
> > On Android, config.xml and androidmanifest.xml is probably recreated
> > (destroy previous formatting, what a feature...) and then probably add
> > differences, so changes and new options are preserved, however nobody
> wanna
> > read it...
> > On iOS, config.xml is completely recreated, no any option is preserved...
> >
> > So, there are 2 questions...
> > If is Android CLI too clever to do preserve changes created by user, why
> it
> > ruins my formatting (new lines, maybe also tabulators)?
> > Why is iOS CLI such a stupid? Why it is not able to do it like Android
> CLI
> > (at least)?
>



-- 

*Frederico Galvão*

Diretor de Tecnologia

PontoGet Inovação Web


( +55(62) 8131-5720

* www.pontoget.com.br

[GitHub] cordova-cli pull request: adding .gush.yml for contribuing

2014-07-14 Thread cordoval

GitHub user cordoval opened a pull request:

https://github.com/apache/cordova-cli/pull/184

adding .gush.yml for contribuing

   
|Q|A  |
|---  |---|
|Bug Fix? |no |
|New Feature? |no |
|BC Breaks?   |no |
|Deprecations?|no |
|Tests Pass?  |no |
|Fixed Tickets|   |
|License  |MIT|
   


 Sent using [Gush](https://github.com/gushphp/gush)

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/cordoval/cordova-cli add-gush

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cordova-cli/pull/184.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #184


commit e3f4974e4fb678082fd58866cb583dd09b196c98
Author: Luis Cordova 
Date:   2014-07-14T20:55:58Z

plug gush




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: Mailing List Subscription

2014-07-14 Thread Jan Velecký

@Shazron: Is there any option to subscribe cordova mailing list, but with 
receiving only e-mails from threads which I sent message into?

Re: Mailing List Subscription

It uses ezmlm, so unless there is a way through it, probably not.

On Mon, Jul 14, 2014 at 3:46 PM, Jan Velecký  wrote:
> @Shazron: Is there any option to subscribe cordova mailing list, but with
> receiving only e-mails from threads which I sent message into?

Re: One platform development vs. Cordova CLI

2014-07-14 Thread Anis KADRI

If you're touching any non-www project files (that is *.xml, *.plist, *.m,
*.java etc...) or are using an IDE you should not be using cordova-cli and
switch to single platform development. Browse the documentation and there
is always the equivalent platform command available to you. Example:
cordova build becomes ./cordova/build etc...You can then modify all your
files at will but will loose the benefit of a shared www/ across platforms.


On Mon, Jul 14, 2014 at 5:49 PM, Frederico Galvão <
frederico.gal...@pontoget.com.br> wrote:

> I agree with the core message from Axel, but I'd refrase that last line as:
>
> "The bottom line is: either use Cordova CLI or not".
>
> Cordova can still be used without the CLI portion just as well, which
> should suffice Jan for his needs.
>
> However, I'll add that you can still use Cordova with the CLI (and thus
> following the directory structure and rules the CLI gives you) and still be
> efficient even if it's only one target platform.
> What made you think that it is "better to change platform project
> config.xml instead of whole project config.xml" should be clarified better
> if you can, so that the Cordova team can improve the tool.
>
>
> 2014-07-14 5:35 GMT-03:00 Axel Nennker :
>
> > My experience with Cordova (and other tools for that matter) is that it
> > makes no sense to change tool generated files.
> > If the tool is improved you do not benefit from this improvement because
> > your modified files will be changed by the new version.
> > If you change a tool generated file you are out.
> > When we started using Cordova me and other colleagues thought that our
> > project "needs" to change Cordova generated files too.
> > In each case this turned out to be wrong.
> > Most of the times writing a Cordova plugin is the solution.
> >
> > The bottom line is: either use Cordova or not. (or send a pull request to
> > improve it)
> >
> > -Axel
> >
> >
> >
> >
> > 2014-07-13 22:18 GMT+02:00 Jan Velecký :
> >
> > > Hello,
> > > there is serious backlog when using CLI in case one platform
> development.
> > > In
> > > this case is better to change platform project config.xml instead of
> > whole
> > > project config.xml. Problem is what prepare should do, and what prepare
> > > actually do. (And prepare is also run if we do build.) At this moment,
> > > prepare in CLI does clean & copy...
> > > Also prepare does it in different way in Android, than in iOS.
> > > On Android, config.xml and androidmanifest.xml is probably recreated
> > > (destroy previous formatting, what a feature...) and then probably add
> > > differences, so changes and new options are preserved, however nobody
> > wanna
> > > read it...
> > > On iOS, config.xml is completely recreated, no any option is
> preserved...
> > >
> > > So, there are 2 questions...
> > > If is Android CLI too clever to do preserve changes created by user,
> why
> > it
> > > ruins my formatting (new lines, maybe also tabulators)?
> > > Why is iOS CLI such a stupid? Why it is not able to do it like Android
> > CLI
> > > (at least)?
> >
>
>
>
> --
>
> *Frederico Galvão*
>
> Diretor de Tecnologia
>
> PontoGet Inovação Web
>
>
> ( +55(62) 8131-5720
>
> * www.pontoget.com.br 
>

Re: One platform development vs. Cordova CLI

2014-07-14 Thread tommy-carlos williams

Sooo.. translation:

“If you aren’t just making a test / example app…”

??

Unless a lot has changed that I don’t know about, it is still impossible to 
make an app all the way to market without modifying those non-www files using 
the CLI.

There are fantastic workarounds available (mostly hooks, etc) for the CLI until 
we get it to the point where the platforms/* and plugins/* folders are build 
artefacts.

- tommy

On 15 July 2014 at 9:14:12, Anis KADRI (anis.ka...@gmail.com) wrote:

If you're touching any non-www project files (that is *.xml, *.plist, *.m,  
*.java etc...) or are using an IDE you should not be using cordova-cli and  
switch to single platform development. Browse the documentation and there  
is always the equivalent platform command available to you. Example:  
cordova build becomes ./cordova/build etc...You can then modify all your  
files at will but will loose the benefit of a shared www/ across platforms.  


On Mon, Jul 14, 2014 at 5:49 PM, Frederico Galvão <  
frederico.gal...@pontoget.com.br> wrote:  

> I agree with the core message from Axel, but I'd refrase that last line as:  
>  
> "The bottom line is: either use Cordova CLI or not".  
>  
> Cordova can still be used without the CLI portion just as well, which  
> should suffice Jan for his needs.  
>  
> However, I'll add that you can still use Cordova with the CLI (and thus  
> following the directory structure and rules the CLI gives you) and still be  
> efficient even if it's only one target platform.  
> What made you think that it is "better to change platform project  
> config.xml instead of whole project config.xml" should be clarified better  
> if you can, so that the Cordova team can improve the tool.  
>  
>  
> 2014-07-14 5:35 GMT-03:00 Axel Nennker :  
>  
> > My experience with Cordova (and other tools for that matter) is that it  
> > makes no sense to change tool generated files.  
> > If the tool is improved you do not benefit from this improvement because  
> > your modified files will be changed by the new version.  
> > If you change a tool generated file you are out.  
> > When we started using Cordova me and other colleagues thought that our  
> > project "needs" to change Cordova generated files too.  
> > In each case this turned out to be wrong.  
> > Most of the times writing a Cordova plugin is the solution.  
> >  
> > The bottom line is: either use Cordova or not. (or send a pull request to  
> > improve it)  
> >  
> > -Axel  
> >  
> >  
> >  
> >  
> > 2014-07-13 22:18 GMT+02:00 Jan Velecký :  
> >  
> > > Hello,  
> > > there is serious backlog when using CLI in case one platform  
> development.  
> > > In  
> > > this case is better to change platform project config.xml instead of  
> > whole  
> > > project config.xml. Problem is what prepare should do, and what prepare  
> > > actually do. (And prepare is also run if we do build.) At this moment,  
> > > prepare in CLI does clean & copy...  
> > > Also prepare does it in different way in Android, than in iOS.  
> > > On Android, config.xml and androidmanifest.xml is probably recreated  
> > > (destroy previous formatting, what a feature...) and then probably add  
> > > differences, so changes and new options are preserved, however nobody  
> > wanna  
> > > read it...  
> > > On iOS, config.xml is completely recreated, no any option is  
> preserved...  
> > >  
> > > So, there are 2 questions...  
> > > If is Android CLI too clever to do preserve changes created by user,  
> why  
> > it  
> > > ruins my formatting (new lines, maybe also tabulators)?  
> > > Why is iOS CLI such a stupid? Why it is not able to do it like Android  
> > CLI  
> > > (at least)?  
> >  
>  
>  
>  
> --  
>  
> *Frederico Galvão*  
>  
> Diretor de Tecnologia  
>  
> PontoGet Inovação Web  
>  
>  
> ( +55(62) 8131-5720  
>  
> * www.pontoget.com.br   
>

[GitHub] cordova-lib pull request: CB-7132: fix regression regarding defaul...

2014-07-14 Thread kamrik

Github user kamrik commented on a diff in the pull request:

https://github.com/apache/cordova-lib/pull/58#discussion_r14914123
  
--- Diff: cordova-lib/src/cordova/metadata/android_parser.js ---
@@ -42,6 +42,12 @@ module.exports = function android_parser(project) {
 this.android_config = path.join(this.path, 'res', 'xml', 'config.xml');
 };
 
+// Returns a promise.
+module.exports.check_requirements = function(project_root) {
+// Rely on platform's bin/create script to check requirements.
+return Q(true);
+};
+
--- End diff --

Is this intentional or a merge artifact?
The check_reqs functions were all removed as part of CB-7091
commits:

https://github.com/apache/cordova-lib/commit/ab49973560ccb7a1ea37d9f5db4e497ef0ce92d1

https://github.com/apache/cordova-lib/commit/153092f2c235185c7f141979a550779800954a92


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cordova-plugin-statusbar pull request: Added javascript event on s...

Github user asfgit closed the pull request at:

https://github.com/apache/cordova-plugin-statusbar/pull/4


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cordova-js pull request: Fixed jshint whitespace issues

Github user asfgit closed the pull request at:

https://github.com/apache/cordova-js/pull/73


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cordova-plugin-file pull request: changed header

Github user asfgit closed the pull request at:

https://github.com/apache/cordova-plugin-file/pull/57


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cordova-android pull request: [CB-7104] Fix for the missing plugin...

Github user asfgit closed the pull request at:

https://github.com/apache/cordova-android/pull/105


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cordova-plugin-file pull request: CB-4917 Clean up streams

Github user asfgit closed the pull request at:

https://github.com/apache/cordova-plugin-file/pull/24


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cordova-android pull request: [CB-5258] use exit library

Github user asfgit closed the pull request at:

https://github.com/apache/cordova-android/pull/82


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cordova-android pull request: Spelling

Github user asfgit closed the pull request at:

https://github.com/apache/cordova-android/pull/81


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cordova-plugin-inappbrowser pull request: Only Navigate after th...

Github user asfgit closed the pull request at:

https://github.com/apache/cordova-plugin-inappbrowser/pull/42


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cordova-android pull request: Support for PluginFactory

Github user agrieve commented on the pull request:

https://github.com/apache/cordova-android/pull/97#issuecomment-48985460
  
Sounds like maybe we abandon this PR.
Plugins have an initialize() method that you can override to do extra 
constructor-time logic.
I've tweaked the API of PluginManager on master to have it take in a list 
of PluginEntry objects. You can use this to give it a pre-instantiated 
CordovaPlugin object.

Hopefully one of these two options addresses your usecase?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cordova-plugin-file pull request: CB-7093 Ported automated File te...

2014-07-14 Thread clelland

Github user clelland commented on the pull request:

https://github.com/apache/cordova-plugin-file/pull/60#issuecomment-48985942
  
Yeah, the URL/URI messages have been there a long time; I just figured I'd 
take the opportunity to clean them up now, especially as the console log is 
much more in-your-face with the new test runner.

I didn't see the earlier discussion re: plugin.xml on the other PR; I'll 
try to get that sorted out before the next plugin release, though. Thanks.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: [GitHub] cordova-lib pull request: CB-7132: fix regression regarding defaul...

Merge artefact.
Am 15.07.2014 03:46 schrieb "kamrik" :

> Github user kamrik commented on a diff in the pull request:
>
> https://github.com/apache/cordova-lib/pull/58#discussion_r14914123
>
> --- Diff: cordova-lib/src/cordova/metadata/android_parser.js ---
> @@ -42,6 +42,12 @@ module.exports = function android_parser(project) {
>  this.android_config = path.join(this.path, 'res', 'xml',
> 'config.xml');
>  };
>
> +// Returns a promise.
> +module.exports.check_requirements = function(project_root) {
> +// Rely on platform's bin/create script to check requirements.
> +return Q(true);
> +};
> +
> --- End diff --
>
> Is this intentional or a merge artifact?
> The check_reqs functions were all removed as part of CB-7091
> commits:
>
> https://github.com/apache/cordova-lib/commit/ab49973560ccb7a1ea37d9f5db4e497ef0ce92d1
>
> https://github.com/apache/cordova-lib/commit/153092f2c235185c7f141979a550779800954a92
>
>
> ---
> If your project is set up for it, you can reply to this email and have your
> reply appear on GitHub as well. If your project does not have this feature
> enabled and wishes so, or if the feature is enabled but not working, please
> contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
> with INFRA.
> ---
>

Re: One platform development vs. Cordova CLI

Could you please give an example which files you need to change and why?
(Preferably Android)

Thanks
Axel
Am 15.07.2014 02:23 schrieb "tommy-carlos williams" :

> Sooo.. translation:
>
> “If you aren’t just making a test / example app…”
>
> ??
>
> Unless a lot has changed that I don’t know about, it is still impossible
> to make an app all the way to market without modifying those non-www files
> using the CLI.
>
> There are fantastic workarounds available (mostly hooks, etc) for the CLI
> until we get it to the point where the platforms/* and plugins/* folders
> are build artefacts.
>
> - tommy
>
> On 15 July 2014 at 9:14:12, Anis KADRI (anis.ka...@gmail.com) wrote:
>
> If you're touching any non-www project files (that is *.xml, *.plist, *.m,
> *.java etc...) or are using an IDE you should not be using cordova-cli and
> switch to single platform development. Browse the documentation and there
> is always the equivalent platform command available to you. Example:
> cordova build becomes ./cordova/build etc...You can then modify all your
> files at will but will loose the benefit of a shared www/ across platforms.
>
>
> On Mon, Jul 14, 2014 at 5:49 PM, Frederico Galvão <
> frederico.gal...@pontoget.com.br> wrote:
>
> > I agree with the core message from Axel, but I'd refrase that last line
> as:
> >
> > "The bottom line is: either use Cordova CLI or not".
> >
> > Cordova can still be used without the CLI portion just as well, which
> > should suffice Jan for his needs.
> >
> > However, I'll add that you can still use Cordova with the CLI (and thus
> > following the directory structure and rules the CLI gives you) and still
> be
> > efficient even if it's only one target platform.
> > What made you think that it is "better to change platform project
> > config.xml instead of whole project config.xml" should be clarified
> better
> > if you can, so that the Cordova team can improve the tool.
> >
> >
> > 2014-07-14 5:35 GMT-03:00 Axel Nennker :
> >
> > > My experience with Cordova (and other tools for that matter) is that it
> > > makes no sense to change tool generated files.
> > > If the tool is improved you do not benefit from this improvement
> because
> > > your modified files will be changed by the new version.
> > > If you change a tool generated file you are out.
> > > When we started using Cordova me and other colleagues thought that our
> > > project "needs" to change Cordova generated files too.
> > > In each case this turned out to be wrong.
> > > Most of the times writing a Cordova plugin is the solution.
> > >
> > > The bottom line is: either use Cordova or not. (or send a pull request
> to
> > > improve it)
> > >
> > > -Axel
> > >
> > >
> > >
> > >
> > > 2014-07-13 22:18 GMT+02:00 Jan Velecký :
> > >
> > > > Hello,
> > > > there is serious backlog when using CLI in case one platform
> > development.
> > > > In
> > > > this case is better to change platform project config.xml instead of
> > > whole
> > > > project config.xml. Problem is what prepare should do, and what
> prepare
> > > > actually do. (And prepare is also run if we do build.) At this
> moment,
> > > > prepare in CLI does clean & copy...
> > > > Also prepare does it in different way in Android, than in iOS.
> > > > On Android, config.xml and androidmanifest.xml is probably recreated
> > > > (destroy previous formatting, what a feature...) and then probably
> add
> > > > differences, so changes and new options are preserved, however nobody
> > > wanna
> > > > read it...
> > > > On iOS, config.xml is completely recreated, no any option is
> > preserved...
> > > >
> > > > So, there are 2 questions...
> > > > If is Android CLI too clever to do preserve changes created by user,
> > why
> > > it
> > > > ruins my formatting (new lines, maybe also tabulators)?
> > > > Why is iOS CLI such a stupid? Why it is not able to do it like
> Android
> > > CLI
> > > > (at least)?
> > >
> >
> >
> >
> > --
> >
> > *Frederico Galvão*
> >
> > Diretor de Tecnologia
> >
> > PontoGet Inovação Web
> >
> >
> > ( +55(62) 8131-5720
> >
> > * www.pontoget.com.br 
> >
>
>

[GitHub] cordova-docs pull request: CB-3571: update the docs for the splash...

Github user sgrebnov commented on a diff in the pull request:

https://github.com/apache/cordova-docs/pull/220#discussion_r14918639
  
--- Diff: docs/en/edge/config_ref/images.md ---
@@ -135,118 +135,60 @@ Windows8
 
 ## Configuring Splash Screens in the CLI
 
-Use the Splashscreen API to enable display of an app's introductory
-splash screen on many platforms.  When working in the CLI, splash
-screen source files are located within the project's `www/res/screens`
-subdirectory.
-
-Android specifies both portrait- and landscape-oriented splash screen
-images for low, medium, high, and extra-high resolutions:
-
-android/screen-hdpi-landscape.png
-android/screen-hdpi-portrait.png
-android/screen-ldpi-landscape.png
-android/screen-ldpi-portrait.png
-android/screen-mdpi-landscape.png
-android/screen-mdpi-portrait.png
-android/screen-xhdpi-landscape.png
-android/screen-xhdpi-portrait.png
-
-The iOS platform specifies variants for iPhone/iPod and iPad, with
-variants for retina displays and different orientations. The _568h_
-file applies to the iPhone 5's taller screen:
-
-ios/screen-ipad-landscape-2x.png
-ios/screen-ipad-landscape.png
-ios/screen-ipad-portrait-2x.png
-ios/screen-ipad-portrait.png
-ios/screen-iphone-landscape-2x.png
-ios/screen-iphone-landscape.png
-ios/screen-iphone-portrait-2x.png
-ios/screen-iphone-portrait.png
-ios/screen-iphone-portrait-568h-2x.png
-
-Windows Phone specifies a single splash screen image:
-
-windows-phone/screen-portrait.jpg
-
-The following sections detail how to set up splash screens when
-working with SDKs and related command-line tools described in Platform
-Guides.
-
-Don't forget to install the SplashScreen plugin before trying to use the
-`navigator.splashscreen.hide()` or `navigator.splashscreen.show()` methods.
-
-## Splash Screens for the Android Platform
-
-Place [9-patch 
image](https://developer.android.com/tools/help/draw9patch.html)
-files in the Android project's `platforms/android/res/drawable*` 
directories.
-
-The size for each should be:
-
-- xlarge (xhdpi): at least 960 × 720
-- large (hdpi): at least 640 × 480
-- medium (mdpi): at least 470 × 320
-- small (ldpi): at least 426 × 320
-
-When creating a new Android project, the default splash screen images
-provided in the Cordova sample app should already be present in the
-`platforms/android/res/drawable*` directories. Feel free to replace these
-with your own images.
-When providing your own splash screen images, you do not need to 
-provide the same permutation of 8 as the Cordova default ones
-here.  More or less optimization can be used. 
-The `drawable` directory names must follow the Android conventions for
-supporting
-[screen 
sizes](http://developer.android.com/guide/practices/screens_support.html) and
-[alternate 
resources](http://developer.android.com/guide/topics/resources/providing-resources.html#AlternativeResources).
-
-In the top-level `config.xml` file (not the one in `platforms`), add the
-following preferences:
-
-
+In the top-level `config.xml` file (not the one in `platforms`), add 
configuration elements like those specified here.
+
+# Example configuration 
+
+Please notice that the value of the "src" attribute is relative to the 
project directory and not to the www directory.
+You can name the source image whatever you like. The internal name in the 
app are determined by Cordova.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
 
 
-The first line sets the image to display as the splash screen. This is the
-file name of the png in the `drawable*` directories, minus the `.png`
-extension. The default value for SplashScreen is `screen` (for the file
-`platforms/android/res/drawable*/screen.png`), so if you
-name the image anything other than `screen.png` in the `drawable*` 
directories,
-you need to add/modify this line.
-
-The second line sets the default delay of how long the splashscreen 
appears in
-milliseconds. This should be the worst-case expected start time.
-The default value for SplashScreenDelay is 3000 ms.
-
-Finally, as a best practice, the splash screen should be present only as 
long

[GitHub] cordova-docs pull request: CB-3571: update the docs for the splash...

Github user sgrebnov commented on the pull request:

https://github.com/apache/cordova-docs/pull/220#issuecomment-48994108
  
@AxelNennker, thx for the update! LGTM now


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: One platform development vs. Cordova CLI

2014-07-14 Thread Jan Velecký



Well, when I need something test quickly or check something with trial and 
error procedure, I don't like to use cordova run.

On Android, in most cases I need modificate androidmanifest.xml, rarely 
config.xml. Modifications of androidmanifest are, how I told, preserved, 
only formatting (and maybe only new lines) is destroyed. I do not change 
andoridmanifest through cross-platform config.xml, because this method is 
too complicated, to do it this way more changes in androidmanifest, so maybe
it is reason for that is changes in andoridmanifest preserved.

Well, I don't like to use cordova run for a reason. Cordova run/build 
compile perhaps every file everytime, so testing with this way is more 
likely waiting to build success, while Eclipse only compile changed files. 
For that reason I develop most time in Eclipse IDE. This is case for non-
assetss files.


When changing assets files (www), I must changed root www files, then run 
cordova run.




So I cannot switch to completely one platform development (which is 
preferred by me in this case), because refreshing project in Eclipse don't 
refresh assets, and then I must do long clean... I didn't try cordova 
executable inside android project, I'll try it.

But there is another one reason – plugins. In cordova executables in project
there are no parallel of cordova plugins add/remove, which there maybe 
should be too, so I need jump back to CLI. Yeah, I know about plugman, but 
it is so terrible to use it to add or remove plugins, I would rather do it 
manually, than with plugman.




I hope I explain it good.





Nice day,

Jan Velecký.





--


Sooo.. translation: 

“If you aren’t just making a test / example app…” 

?? 

Unless a lot has changed that I don’t know about, it is still impossible to 
make an app all the way to market without modifying those non-www files 
using the CLI. 

There are fantastic workarounds available (mostly hooks, etc) for the CLI 
until we get it to the point where the platforms/* and plugins/* folders are
build artefacts. 

- tommy 

On 15 July 2014 at 9:14:12, Anis KADRI (anis...@gmail.com) wrote: 

If you're touching any non-www project files (that is *.xml, *.plist, *.m, *
.java etc...) or are using an IDE you should not be using cordova-cli and 
switch to single platform development. Browse the documentation and there is
always the equivalent platform command available to you. Example: cordova 
build becomes ./cordova/build etc...You can then modify all your files at 
will but will loose the benefit of a shared www/ across platforms. 

On Mon, Jul 14, 2014 at 5:49 PM, Frederico Galvão < fred...@pontoget.com.br>
wrote: 


I agree with the core message from Axel, but I'd refrase that last line as: 


"The bottom line is: either use Cordova CLI or not". 

Cordova can still be used without the CLI portion just as well, which should
suffice Jan for his needs. 

However, I'll add that you can still use Cordova with the CLI (and thus 
following the directory structure and rules the CLI gives you) and still be 
efficient even if it's only one target platform. What made you think that it
is "better to change platform project config.xml instead of whole project 
config.xml" should be clarified better if you can, so that the Cordova team 
can improve the tool. 

2014-07-14 5:35 GMT-03:00 Axel Nennker : 


My experience with Cordova (and other tools for that matter) is that it 
makes no sense to change tool generated files. If the tool is improved you 
do not benefit from this improvement because your modified files will be 
changed by the new version. If you change a tool generated file you are out.
When we started using Cordova me and other colleagues thought that our 
project "needs" to change Cordova generated files too. In each case this 
turned out to be wrong. Most of the times writing a Cordova plugin is the 
solution. 

The bottom line is: either use Cordova or not. (or send a pull request to 
improve it) 

-Axel 

2014-07-13 22:18 GMT+02:00 Jan Velecký : 


Hello, there is serious backlog when using CLI in case one platform 
development. In this case is better to change platform project config.xml 
instead of whole project config.xml. Problem is what prepare should do, and 
what prepare actually do. (And prepare is also run if we do build.) At this 
moment, prepare in CLI does clean & copy... Also prepare does it in 
different way in Android, than in iOS. On Android, config.xml and 
androidmanifest.xml is probably recreated (destroy previous formatting, what
a feature...) and then probably add differences, so changes and new options 
are preserved, however nobody wanna read it... On iOS, config.xml is 
completely recreated, no any option is preserved... 

So, there are 2 questions... If is Android CLI too clever to do preserve 
changes created by user, 



why 


it 


ruins my formatting (new lines, maybe also tabulators)? Why is iOS CLI such 
a stupid? Why i

[GitHub] cordova-docs pull request: CB-3571: update the docs for the splash...

2014-07-14 Thread jsoref

Github user jsoref commented on the pull request:

https://github.com/apache/cordova-docs/pull/220#issuecomment-48994596
  
Why is the BlackBerry 10 content being removed? 


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cordova-wp8 pull request: small fix for spaces in path

Github user sgrebnov commented on the pull request:

https://github.com/apache/cordova-wp8/pull/45#issuecomment-48994839
  
Hey @G3z, thx for the fix. Do you have iCLA signed?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: [GitHub] cordova-docs pull request: CB-3571: update the docs for the splash...

Because that content referred to Phonegap Build not Cordova.
Am 15.07.2014 08:19 schrieb "jsoref" :

> Github user jsoref commented on the pull request:
>
> https://github.com/apache/cordova-docs/pull/220#issuecomment-48994596
>
> Why is the BlackBerry 10 content being removed?
>
>
> ---
> If your project is set up for it, you can reply to this email and have your
> reply appear on GitHub as well. If your project does not have this feature
> enabled and wishes so, or if the feature is enabled but not working, please
> contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
> with INFRA.
> ---
>

[GitHub] cordova-docs pull request: CB-3571: update the docs for the splash...

2014-07-14 Thread jsoref

Github user jsoref commented on the pull request:

https://github.com/apache/cordova-docs/pull/220#issuecomment-48995182
  
-1 don't commit this. 


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: [GitHub] cordova-docs pull request: CB-3571: update the docs for the splash...

Could you please give a reason for your -1?
Am 15.07.2014 08:30 schrieb "jsoref" :

> Github user jsoref commented on the pull request:
>
> https://github.com/apache/cordova-docs/pull/220#issuecomment-48995182
>
> -1 don't commit this.
>
>
> ---
> If your project is set up for it, you can reply to this email and have your
> reply appear on GitHub as well. If your project does not have this feature
> enabled and wishes so, or if the feature is enabled but not working, please
> contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
> with INFRA.
> ---
>

[GitHub] cordova-docs pull request: CB-3571: update the docs for the splash...

Github user sgrebnov commented on the pull request:

https://github.com/apache/cordova-docs/pull/220#issuecomment-48995659
  
Have not seen BlackBerry10 content is removed; agree, it must be put back.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: [GitHub] cordova-docs pull request: CB-3571: update the docs for the splash...