[GitHub] cordova-osx pull request: CB-6567 Adding the OSX platform also cop...
GitHub user tripodsan opened a pull request: https://github.com/apache/cordova-osx/pull/10 CB-6567 Adding the OSX platform also copies over the CordovaLibTests fixed * moved CordovaLibTests to project root * fixed schemes * fixed bug in create script You can merge this pull request into a Git repository by running: $ git pull https://github.com/tripodsan/cordova-osx CB-6567 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cordova-osx/pull/10.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 #10 commit 80029013ba873078f91fbe4ab7c5171aea769a95 Author: Tobias Bocanegra Date: 2014-04-30T07:27:46Z CB-6567 Adding the OSX platform also copies over the CordovaLibTests fixed * moved CordovaLibTests to project root * fixed schemes * fixed bug in create script --- 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-firefoxos pull request: CB-5816 FirefoxOS - add build scri...
Github user Steckelfisch commented on a diff in the pull request:
https://github.com/apache/cordova-firefoxos/pull/7#discussion_r12133238
--- Diff: bin/templates/project/cordova/clean ---
@@ -0,0 +1,38 @@
+#!/usr/bin/env node
+
+/*
+ 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 path = require('path'),
+clean = require('./lib/clean'),
+reqs = require('./lib/check_reqs'),
+args = process.argv;
+
+// Support basic help commands
+if(args.length > 2
+ || args[2] == '--help' || args[2] == '/?' || args[2] == '-h' ||
--- End diff --
stole it from android
---
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: [Android] Refactoring for different engines
Brian, Joe and Ian, Thanks for your detailed explanations. It makes lots of senses. Let's make it happen. Thanks, -ningxin > -Original Message- > From: brian.ler...@gmail.com [mailto:brian.ler...@gmail.com] On Behalf Of > Brian LeRoux > Sent: Wednesday, April 30, 2014 4:47 AM > To: dev@cordova.apache.org > Subject: Re: [Android] Refactoring for different engines > > Think those builds should be hosted by those downstreams anyhow. Cordova is > sort of the low level, on the metal, default webview and building these > things is > a very deliberate choice by the end developer using the platform. > Moz should host Gecko builds. Chromium should host custom ChromeViews > (someday, I dream) and, Crosswalk should host their thing. Etc. Maybe someday > we can get an IE binary from Microsoft. Dare to dream. > > > On Tue, Apr 29, 2014 at 11:22 AM, Ian Clelland wrote: > > > On Tue, Apr 29, 2014 at 10:55 AM, Joe Bowser wrote: > > > > > So, when Apache publishes something, it has fill the following criteria: > > > > > > - All source code must have their licence headers intact > > > - All third-party source code must be mentioned in the NOTICE file > > > - No Binary Blobs - No compiled libraries, which include JARs and > > > shared object files (including the pak). > > > > > > Now, with Crosswalk, there's obviously the Chromium Library that we > > > need, so we need a way to get that into the generated project somehow. > > > The easiest way is with plugman, but the issue is that Apache can't > > > legally pass around binary blobs when it does an official release of > > > anything. Intel, OTOH, isn't restricted by cumbersome open source > > > foundation rules, and can do so. > > > > > > > Intel has their own rules to follow, certainly, but we're presuming > > here that Intel has already worked out the legal requirements to > > distribute Crosswalk in the first place, so the idea of Intel also > > distributing the "official" Crosswalk Cordova Engine plugin just seems > > to make a lot of sense. > > > > Apache distributes Cordova-Android, which defines the integration API, > > and includes the default AndroidWebView classes, and other parties > > should be free to distribute their own engine plugins, implementing > > that API. That distribution can then be in any form that makes sense > > (and complies with the licenses of the various components) > > > > Joe's right that it would be awkward, if not impossible, for Apache to > > distribute the Crosswalk core library. We'd have to include the 15GB > > of source as well, at the very least, and that doesn't sound like fun at > > all. > > It *is* all open-source, but there are a lot of different licenses in > > there, and we'd need some lawyerly help to make sure that the ASF > > could release software that included it all. > > > > Ian > > > > > > > On Tue, Apr 29, 2014 at 7:43 AM, Hu, Ningxin > > wrote: > > > >> - who publishes the plugins, intel or cordova? > > > > > > > > For this open, could someone elaborate it a little bit more? What > > > > does > > > it mean? I remembered someone mentioned the license is open in the > > > hangouts, any details? > > > > > > > > Thanks, > > > > -ningxin > > > > > > > >> -Original Message- > > > >> From: mmo...@google.com [mailto:mmo...@google.com] On Behalf Of > > Michal > > > >> Mocny > > > >> Sent: Saturday, April 26, 2014 12:53 AM > > > >> To: dev > > > >> Subject: Re: [Android] Refactoring for different engines > > > >> > > > >> Notes: > > > >> > > > >> - native junit tests needs fixing (due to deprication) > > > >> > > > >> - common script for creating walk mobilespec > > > >> > > > >> - fix failing mobile spec tests (file-transfer?, media?) > > > >> > > > >> - who publishes the plugins, intel or cordova? > > > >> > > > >> - static vs dynamic xwalk lib > > > >> > > > >> - (option) one plugin, use hooks to download static library > > > >> > > > >> - (option) one plugin, just bundle static lib > > > >> > > > >> - (option) one plugin, download static lib on app run > > > >> > > > >> - (option) two plugins, xwalk lib bundled in a separate plugin, > > > >> and > > > can be added > > > >> as a ? > > > >> > > > >> - intel vs arm binary apk targets for CLI. Two android > > > >> platforms, or > > > just two build > > > >> targets? > > > >> > > > >> - How long to get GeckoView: Joe not sure. days to weeks :( > > > >> > > > >> - Not blocking, though > > > >> > > > >> - plugman works to install but CLI does not, lets figure that out > > > >> > > > >> - Other platforms: Windows Phone support!? BB10?! > > > >> > > > >> - Can we share code between xwalk WebViewClient and gecko view > > > >> WebViewClient etc? > > > >> > > > >> > > > >> On Fri, Apr 25, 2014 at 12:09 PM, Josh Soref > > > >> > > > wrote: > > > >> > > > >> > Ian Clelland wrote: > > > >> > > > > >> > > > > > >> > > > > https://staging.talkgadget.google.com/hangouts/_/7ecpi3uaclcuedn7imn > > > 6b > > > >> > 9jdq > > > >> > >c > > > >> > > > > >> >
[GitHub] cordova-plugin-file pull request: updated support for the OS X pla...
GitHub user onflapp opened a pull request: https://github.com/apache/cordova-plugin-file/pull/42 updated support for the OS X platform - copying all the files to osx - making sure it works with the latest osx platform You can merge this pull request into a Git repository by running: $ git pull https://github.com/onflapp/cordova-plugin-file master Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cordova-plugin-file/pull/42.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 #42 commit ed8df565fb1f74f8cda347424c6de95f3f89870f Author: Ondrej Florian Date: 2014-04-27T12:18:04Z initial support for the OS X platform commit eba83426d8af139f46797c94f07cc9d69335ea94 Author: Ondrej Florian Date: 2014-04-28T16:14:01Z fix callbackid being released and set default root for the OS X to be / commit e3e6677dc18b49fa5db25afdc1a879ac98c4adfc Author: Ondrej Florian Date: 2014-04-30T10:03:57Z copy all implementation files into the osx directory --- 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: Some pain points from our users :'(
I've had some recent discussions on this myself - and it came up at the open PhoneGap/Cordova session I hosted online a few days back. I'd love to take a stab at this. Where would be a good place for to post a draft that folks could edit and the Cordova team could just take it over when happy? From: Joe Bowser Sent: Tuesday, April 29, 2014 3:12 PM To: dev Subject: Re: Some pain points from our users :'( +1 to this post, who wants to take this on? On Tue, Apr 29, 2014 at 12:22 PM, Joerg Holz wrote: > I’m developing B2B-Apps (iOS and Android), using cordova. > > First of all, thank you for your great job. From release to release things > are going easier and tidier. > > It is relatively easy for a beginner to start with cordova, but in a bigger > project there are a lot of small jobs and decisions, which have to be made: > The developer has to write clean html, js and css. Has to take care of: > structure of the project, strategy to fall back and restart the project, > testing, ui and ux, perhaps knowledge about a js-framework, sqlite, the > plugin-things, … > > It needs a lot of time to get into all this stuff, learning the tricks and > finding a good way for developing. >
Docs for plugins
I just noticed that the links for plugins from docs.cordova.io go to a new page (http://plugins.cordova.io/#/package/org.apache.cordova.file as an example). The docs for this one in particular seem wrong. I recently did a small mod to add the error codes to the docs, and I'm not seeing it here. Mistake? Do I need to make a new PR on the repo? Related - why is the link to the github version gone?
Re: Docs for plugins
I believe the plugin docs reflect what was bundled with the latest plugin release -- perhaps your recent changes were not released yet? Or has something gotten lost in the recent shuffle with dev/master branches? Its true, though, that for core plugins our registry links to the official apache repos and not the github mirrors, and the official repo links do not have a pretty renderers for markdown docs. Not sure what we want to do here. On Wed, Apr 30, 2014 at 9:14 AM, Ray Camden wrote: > I just noticed that the links for plugins from docs.cordova.io go to a > new page (http://plugins.cordova.io/#/package/org.apache.cordova.file as > an example). The docs for this one in particular seem wrong. I recently did > a small mod to add the error codes to the docs, and I'm not seeing it here. > Mistake? Do I need to make a new PR on the repo? > > Related - why is the link to the github version gone?
Re: Docs for plugins
Ray, Yeah seems file plugin @c1a1052 was tagged for 1.1.0 release 13 days ago, you patched docs after that tag @abcaf70 12 days ago, and plugin was actually released with @e9efe65 7 days ago. You just missed the window narrowly! -Michal On Wed, Apr 30, 2014 at 9:45 AM, Michal Mocny wrote: > I believe the plugin docs reflect what was bundled with the latest plugin > release -- perhaps your recent changes were not released yet? Or has > something gotten lost in the recent shuffle with dev/master branches? > > Its true, though, that for core plugins our registry links to the official > apache repos and not the github mirrors, and the official repo links do not > have a pretty renderers for markdown docs. Not sure what we want to do > here. > > > On Wed, Apr 30, 2014 at 9:14 AM, Ray Camden wrote: > >> I just noticed that the links for plugins from docs.cordova.io go to a >> new page (http://plugins.cordova.io/#/package/org.apache.cordova.file as >> an example). The docs for this one in particular seem wrong. I recently did >> a small mod to add the error codes to the docs, and I'm not seeing it here. >> Mistake? Do I need to make a new PR on the repo? >> >> Related - why is the link to the github version gone? > > >
Re: Docs for plugins
.. which I guess raises the question, how can we make docs fixes without formal releases? Do we want that, or should we just make formal releases easier and more frequent until the problem goes away? On Wed, Apr 30, 2014 at 9:50 AM, Michal Mocny wrote: > Ray, Yeah seems file plugin @c1a1052 was tagged for 1.1.0 release 13 days > ago, you patched docs after that tag @abcaf70 12 days ago, and plugin was > actually released with @e9efe65 7 days ago. You just missed the window > narrowly! > > -Michal > > > On Wed, Apr 30, 2014 at 9:45 AM, Michal Mocny wrote: > >> I believe the plugin docs reflect what was bundled with the latest plugin >> release -- perhaps your recent changes were not released yet? Or has >> something gotten lost in the recent shuffle with dev/master branches? >> >> Its true, though, that for core plugins our registry links to the >> official apache repos and not the github mirrors, and the official repo >> links do not have a pretty renderers for markdown docs. Not sure what we >> want to do here. >> >> >> On Wed, Apr 30, 2014 at 9:14 AM, Ray Camden wrote: >> >>> I just noticed that the links for plugins from docs.cordova.io go to a >>> new page (http://plugins.cordova.io/#/package/org.apache.cordova.fileas an >>> example). The docs for this one in particular seem wrong. I recently >>> did a small mod to add the error codes to the docs, and I'm not seeing it >>> here. Mistake? Do I need to make a new PR on the repo? >>> >>> Related - why is the link to the github version gone? >> >> >> >
RE: Docs for plugins
So... pretend I'm dumb here. Do I need to do anything? Will it just be updated in the next plugin release? From: mmo...@google.com on behalf of Michal Mocny Sent: Wednesday, April 30, 2014 8:50 AM To: Michal Mocny Cc: dev Subject: Re: Docs for plugins Ray, Yeah seems file plugin @c1a1052 was tagged for 1.1.0 release 13 days ago, you patched docs after that tag @abcaf70 12 days ago, and plugin was actually released with @e9efe65 7 days ago. You just missed the window narrowly! -Michal On Wed, Apr 30, 2014 at 9:45 AM, Michal Mocny wrote: > I believe the plugin docs reflect what was bundled with the latest plugin > release -- perhaps your recent changes were not released yet? Or has > something gotten lost in the recent shuffle with dev/master branches? > > Its true, though, that for core plugins our registry links to the official > apache repos and not the github mirrors, and the official repo links do not > have a pretty renderers for markdown docs. Not sure what we want to do > here. > > > On Wed, Apr 30, 2014 at 9:14 AM, Ray Camden wrote: > >> I just noticed that the links for plugins from docs.cordova.io go to a >> new page (http://plugins.cordova.io/#/package/org.apache.cordova.file as >> an example). The docs for this one in particular seem wrong. I recently did >> a small mod to add the error codes to the docs, and I'm not seeing it here. >> Mistake? Do I need to make a new PR on the repo? >> >> Related - why is the link to the github version gone? > > >
Re: Docs for plugins
Thats will be easy to pretend (just kidding! ;). Yes, the plugin registry shows the docs as they exist at the time of the plugin release, so next release the docs will be up to date. The primary benefit here is that the plugin registry has a version switcher on the side, and you'll get to see the docs as they existed for that version. (for the future, we could consider adding "edge" versions for core plugins on plugin registry. Not for installs, but just to list the latest docs) On Wed, Apr 30, 2014 at 9:54 AM, Ray Camden wrote: > So... pretend I'm dumb here. Do I need to do anything? Will it just be > updated in the next plugin release? > > > From: mmo...@google.com on behalf of Michal Mocny < > mmo...@chromium.org> > Sent: Wednesday, April 30, 2014 8:50 AM > To: Michal Mocny > Cc: dev > Subject: Re: Docs for plugins > > Ray, Yeah seems file plugin @c1a1052 was tagged for 1.1.0 release 13 days > ago, you patched docs after that tag @abcaf70 12 days ago, and plugin was > actually released with @e9efe65 7 days ago. You just missed the window > narrowly! > > -Michal > > > On Wed, Apr 30, 2014 at 9:45 AM, Michal Mocny wrote: > > > I believe the plugin docs reflect what was bundled with the latest plugin > > release -- perhaps your recent changes were not released yet? Or has > > something gotten lost in the recent shuffle with dev/master branches? > > > > Its true, though, that for core plugins our registry links to the > official > > apache repos and not the github mirrors, and the official repo links do > not > > have a pretty renderers for markdown docs. Not sure what we want to do > > here. > > > > > > On Wed, Apr 30, 2014 at 9:14 AM, Ray Camden wrote: > > > >> I just noticed that the links for plugins from docs.cordova.io go to a > >> new page (http://plugins.cordova.io/#/package/org.apache.cordova.fileas > >> an example). The docs for this one in particular seem wrong. I recently > did > >> a small mod to add the error codes to the docs, and I'm not seeing it > here. > >> Mistake? Do I need to make a new PR on the repo? > >> > >> Related - why is the link to the github version gone? > > > > > > >
Re: 3.5.0rc1
On Apr 29, 2014, at 11:14 PM, Andrew Grieve wrote: >> I say we aim to make 3.5.0 our last cadence release. I'm hoping to switch >> to independent platform releases. >> >> As for docs, I don't think everyone is convinced yet that loosing the >> version numbers is the way to go. I say we add version 3.5.0 to docs and >> then make the switch to edge for the next cli release. That way it fits >> well with this being our last cadence release. >> > Haven't seen any opposition to this on the list or in your doc. Might as > well go to edge now, no? I like Steve's idea to make the switch to edge at the first post-cadence release. For losing the version numbers in the docs, I can see how something like a "@since" tag could help, but that is really just for new APIs. If there is a behavioral change or return value change, how does that get documented? Are we talking something like: globalization.getLocale() returns: symbolic name, i.e. "English" (before r1.0.0) BCP-147 identifier, ie "En_US" (since r1.0.0) For this reason, I'm not yet sold on the non-creation of versions in the docs. Thinking out loud: For plugins, the docs are now in each plugin repo. We could continue to create versions there, or link to github with a tag/branch name to render as HTML. I think the latter would be sufficient and easy. But to do this right, the same thing ought to happen with platforms and tools. Then it becomes consistent across all our repos, and the same approach can be used for versioning the docs. The only thing in cordova-docs would be overviews. Is this idea loathed? On a slightly different topic: So what identifier are we using to specify a point in the timeline of all these independent releases (platforms, plugins, tools)? The goal is to have a recreatable state of Cordova. Is it the CLI version because that gets bumped for every component release?
[GitHub] cordova-plugin-dialogs pull request: Fix Beep exception on Android
GitHub user shortstuffsushi opened a pull request: https://github.com/apache/cordova-plugin-dialogs/pull/20 Fix Beep exception on Android In iOS, if you call the beep function and don't provide a count, it plays a single beep. On Android, however, it always attempts to load the fix object in the array, which is null if no count is provided, causes an exception to be thrown, and no beep to occur. The simplest fix for this is to simply pass `1` if no count is provide from the web. You can merge this pull request into a Git repository by running: $ git pull https://github.com/shortstuffsushi/cordova-plugin-dialogs patch-1 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cordova-plugin-dialogs/pull/20.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 #20 commit a1713d035a7f0456869585d0fb62f38ef590b08b Author: Graham Mueller Date: 2014-04-30T15:10:59Z Fix Beep exception on Android In iOS, if you call the beep function and don't provide a count, it plays a single beep. On Android, however, it always attempts to load the fix object in the array, which is null if no count is provided, causes an exception to be thrown, and no beep to occur. The simplest fix for this is to simply pass `1` if no count is provide from the web. --- 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: Docs for plugins
I'd suggest the latter. On Apr 30, 2014, at 9:52 AM, Michal Mocny wrote: > .. which I guess raises the question, how can we make docs fixes without > formal releases? Do we want that, or should we just make formal releases > easier and more frequent until the problem goes away?
Re: Some pain points from our users :'(
How about using a short-term wiki page to create/grow the draft? Then it could migrate into cordova-docs.git. Getting to the end of the Cordova docs with a working helloWorld, and then having signposts for the next places to go would be a significant gain in the perceived usability of Cordova. Ray, thank you! On Apr 30, 2014, at 9:11 AM, Ray Camden wrote: > I'd love to take a stab at this. Where would be a good place for to post a > draft that folks could edit and the Cordova team could just take it over when > happy?
RE: Some pain points from our users :'(
Any particular place? Sorry if obvious - but it would need to be a github repo multiple folks can edit. (Seems like that would be quicker than PRs imo.) From: Marcel Kinard Sent: Wednesday, April 30, 2014 10:22 AM To: dev@cordova.apache.org Subject: Re: Some pain points from our users :'( How about using a short-term wiki page to create/grow the draft? Then it could migrate into cordova-docs.git. Getting to the end of the Cordova docs with a working helloWorld, and then having signposts for the next places to go would be a significant gain in the perceived usability of Cordova. Ray, thank you! On Apr 30, 2014, at 9:11 AM, Ray Camden wrote: > I'd love to take a stab at this. Where would be a good place for to post a > draft that folks could edit and the Cordova team could just take it over when > happy?
Re: 3.5.0rc1
On Wed, Apr 30, 2014 at 11:08 AM, Marcel Kinard wrote: > > On Apr 29, 2014, at 11:14 PM, Andrew Grieve wrote: > > >> I say we aim to make 3.5.0 our last cadence release. I'm hoping to > switch > >> to independent platform releases. > >> > >> As for docs, I don't think everyone is convinced yet that loosing the > >> version numbers is the way to go. I say we add version 3.5.0 to docs and > >> then make the switch to edge for the next cli release. That way it fits > >> well with this being our last cadence release. > >> > > Haven't seen any opposition to this on the list or in your doc. Might as > > well go to edge now, no? > > I like Steve's idea to make the switch to edge at the first post-cadence > release. > > For losing the version numbers in the docs, I can see how something like a > "@since" tag could help, but that is really just for new APIs. If there is > a behavioral change or return value change, how does that get documented? > Are we talking something like: > > globalization.getLocale() returns: > symbolic name, i.e. "English" (before r1.0.0) > BCP-147 identifier, ie "En_US" (since r1.0.0) > > For this reason, I'm not yet sold on the non-creation of versions in the > docs. > > Thinking out loud: For plugins, the docs are now in each plugin repo. We > could continue to create versions there, or link to github with a > tag/branch name to render as HTML. I think the latter would be sufficient > and easy. But to do this right, the same thing ought to happen with > platforms and tools. Then it becomes consistent across all our repos, and > the same approach can be used for versioning the docs. The only thing in > cordova-docs would be overviews. Is this idea loathed? > Having plugin docs versioned with the plugin is definitely the idea. Only guides & specs will remain in docs.cordova.io. For changes in CLI / guides, then we should call out when features were added right inline in the docs. For the events APIs, I think the button events should be moved into a plugin. That would leave only deviceready, pause, resume. > > On a slightly different topic: So what identifier are we using to specify > a point in the timeline of all these independent releases (platforms, > plugins, tools)? The goal is to have a recreatable state of Cordova. Is it > the CLI version because that gets bumped for every component release? We don't actually have this right now since plugins are uncoupled. If you wanted right now to take the release version of everything and tag it, I think you'd be fine to just use a timestamp as the label.
Re: Some pain points from our users :'(
How about here? https://wiki.apache.org/cordova/signposts-draft . I'd hope this works, as long as the contributions are considered "trivial" by Apache standards. Otherwise pull requests to cordova-doc.git would be the [slower and more proper] way to go. On Apr 30, 2014, at 11:29 AM, Ray Camden wrote: > Any particular place? Sorry if obvious - but it would need to be a github > repo multiple folks can edit. (Seems like that would be quicker than PRs imo.)
RE: Some pain points from our users :'(
It took some time to actually register, but I'll give it a shot. Traveling today but will try to get a basic outline up there asap. (And anyone else listening - don't wait for me - attack the doc if you can. :) From: Marcel Kinard Sent: Wednesday, April 30, 2014 10:41 AM To: dev@cordova.apache.org Subject: Re: Some pain points from our users :'( How about here? https://wiki.apache.org/cordova/signposts-draft . I'd hope this works, as long as the contributions are considered "trivial" by Apache standards. Otherwise pull requests to cordova-doc.git would be the [slower and more proper] way to go. On Apr 30, 2014, at 11:29 AM, Ray Camden wrote: > Any particular place? Sorry if obvious - but it would need to be a github > repo multiple folks can edit. (Seems like that would be quicker than PRs imo.)
RE: Some pain points from our users :'(
Crap, I spoke too soon. it is a "Immutable Page" and I can't edit it. From: Marcel Kinard Sent: Wednesday, April 30, 2014 10:41 AM To: dev@cordova.apache.org Subject: Re: Some pain points from our users :'( How about here? https://wiki.apache.org/cordova/signposts-draft . I'd hope this works, as long as the contributions are considered "trivial" by Apache standards. Otherwise pull requests to cordova-doc.git would be the [slower and more proper] way to go. On Apr 30, 2014, at 11:29 AM, Ray Camden wrote: > Any particular place? Sorry if obvious - but it would need to be a github > repo multiple folks can edit. (Seems like that would be quicker than PRs imo.)
Re: [DISCUSS] Automate signed icla to git commits
Jesse wrote: > again: I would rather leave the definition of 'trivial' to the reviewer >of > the pull request. > > An update to docs of 100 lines can be trivial ... Josh renaming 'cordova' > to 'Cordova' across 3 repos, and 15 files, could be considered trivial >... > 4 lines of critical code could be non-trivial. > > Note, I am not calling out Josh, I am just making a more specific >example, > valuable and trivial are different things. Nothing wrong with using me as an example of such things. I tend to cover most interesting edge cases, so it's a good idea to check to see if any of my actions are relevant edges that should be addressed.
RE: Some pain points from our users :'(
I would suggest creating a Google doc and sharing it here. On Apr 30, 2014 8:59 AM, "Ray Camden" wrote: > Crap, I spoke too soon. it is a "Immutable Page" and I can't edit it. > > > From: Marcel Kinard > Sent: Wednesday, April 30, 2014 10:41 AM > To: dev@cordova.apache.org > Subject: Re: Some pain points from our users :'( > > How about here? https://wiki.apache.org/cordova/signposts-draft . I'd > hope this works, as long as the contributions are considered "trivial" by > Apache standards. Otherwise pull requests to cordova-doc.git would be the > [slower and more proper] way to go. > > On Apr 30, 2014, at 11:29 AM, Ray Camden wrote: > > > Any particular place? Sorry if obvious - but it would need to be a > github repo multiple folks can edit. (Seems like that would be quicker than > PRs imo.) >
[Android] Not so fast....API changes in Cordova-Android for Pluggable WebView
Hey So, once again, we're dealing with some major API changes once we introduce pluggable webview. The first change that was done for sanity was finally deprecating setProperty. This was slated to be removed by 3.5 or in six months from the deprecation date, but we kept it in too long. While I would like to assume that everyone has moved over to setting their preferences in config.xml, which is the much more sane way of doing things, we can't do that. We need to publicize this in some blog posts, as well as in our documentation somehow. There will obviously be some pissed off users, as we've seen in past posts, but I think having the ability to use a WebView other than Chrome 30 is worth these changes. The other change, which says more about our design is adding a getter method for pluginManager. We need to access the pluginManager to get plugins, and it's expected that everyone who implements a CordovaWebView will have this method produce a pluginManager. In the past, it was just publicly exposed, which was not the greatest idea and was kinda sloppy. So, how do people want to handle these changes? We constantly get shit for changing our API when we do development, but I do think these improvements are extremely important, especially given how much flak we get for relying on Android's WebView. Thoughts? Joe
RE: Some pain points from our users :'(
On it. From: Steven Gill Sent: Wednesday, April 30, 2014 11:12 AM To: dev@cordova.apache.org Subject: RE: Some pain points from our users :'( I would suggest creating a Google doc and sharing it here. On Apr 30, 2014 8:59 AM, "Ray Camden" wrote: > Crap, I spoke too soon. it is a "Immutable Page" and I can't edit it. > > > From: Marcel Kinard > Sent: Wednesday, April 30, 2014 10:41 AM > To: dev@cordova.apache.org > Subject: Re: Some pain points from our users :'( > > How about here? https://wiki.apache.org/cordova/signposts-draft . I'd > hope this works, as long as the contributions are considered "trivial" by > Apache standards. Otherwise pull requests to cordova-doc.git would be the > [slower and more proper] way to go. > > On Apr 30, 2014, at 11:29 AM, Ray Camden wrote: > > > Any particular place? Sorry if obvious - but it would need to be a > github repo multiple folks can edit. (Seems like that would be quicker than > PRs imo.) >
RE: Some pain points from our users :'(
Ok folks, here is the document. I even took a quick stab at an outline. I've set this as Anyone Can Edit, but if that causes problems I'll set it back to invited folks only. https://docs.google.com/document/d/1uJ5qXqQxK2oh1eZPgMdYuhK2rQTB7QMHXUHbkcomWgk/edit?usp=sharing From: Ray Camden Sent: Wednesday, April 30, 2014 11:28 AM To: dev@cordova.apache.org Subject: RE: Some pain points from our users :'( On it. From: Steven Gill Sent: Wednesday, April 30, 2014 11:12 AM To: dev@cordova.apache.org Subject: RE: Some pain points from our users :'( I would suggest creating a Google doc and sharing it here. On Apr 30, 2014 8:59 AM, "Ray Camden" wrote: > Crap, I spoke too soon. it is a "Immutable Page" and I can't edit it. > > > From: Marcel Kinard > Sent: Wednesday, April 30, 2014 10:41 AM > To: dev@cordova.apache.org > Subject: Re: Some pain points from our users :'( > > How about here? https://wiki.apache.org/cordova/signposts-draft . I'd > hope this works, as long as the contributions are considered "trivial" by > Apache standards. Otherwise pull requests to cordova-doc.git would be the > [slower and more proper] way to go. > > On Apr 30, 2014, at 11:29 AM, Ray Camden wrote: > > > Any particular place? Sorry if obvious - but it would need to be a > github repo multiple folks can edit. (Seems like that would be quicker than > PRs imo.) >
Re: [Android] Not so fast....API changes in Cordova-Android for Pluggable WebView
On Wed, Apr 30, 2014 at 12:23 PM, Joe Bowser wrote: > Hey > > So, once again, we're dealing with some major API changes once we > introduce pluggable webview. The first change that was done for > sanity was finally deprecating setProperty. This was slated to be > removed by 3.5 or in six months from the deprecation date, but we kept > it in too long. While I would like to assume that everyone has moved > over to setting their preferences in config.xml, which is the much > more sane way of doing things, we can't do that. We need to publicize > this in some blog posts, as well as in our documentation somehow. > There will obviously be some pissed off users, as we've seen in past > posts, but I think having the ability to use a WebView other than > Chrome 30 is worth these changes. > Is it feasible to leave setProperty working only for default WebView? This would mean that custom webviews won't work with older plugins, but I think thats fine. > > The other change, which says more about our design is adding a getter > method for pluginManager. We need to access the pluginManager to get > plugins, and it's expected that everyone who implements a > CordovaWebView will have this method produce a pluginManager. In the > past, it was just publicly exposed, which was not the greatest idea > and was kinda sloppy. > Similar to above question, could we leave it (deprecated) as an exposed property only on the default webview? And only support the new getter for new webviews (xwalk, gecko)? Again, only updated plugins would work with custom webview, but I think thats fine. > > So, how do people want to handle these changes? We constantly get > shit for changing our API when we do development, but I do think these > improvements are extremely important, especially given how much flak > we get for relying on Android's WebView. > > Thoughts? > > Joe >
Re: Some pain points from our users :'(
Thanks for choosing a saner option than the wiki ;) On Wed, Apr 30, 2014 at 12:34 PM, Ray Camden wrote: > Ok folks, here is the document. I even took a quick stab at an outline. > I've set this as Anyone Can Edit, but if that causes problems I'll set it > back to invited folks only. > > > https://docs.google.com/document/d/1uJ5qXqQxK2oh1eZPgMdYuhK2rQTB7QMHXUHbkcomWgk/edit?usp=sharing > > > > From: Ray Camden > Sent: Wednesday, April 30, 2014 11:28 AM > To: dev@cordova.apache.org > Subject: RE: Some pain points from our users :'( > > On it. > > From: Steven Gill > Sent: Wednesday, April 30, 2014 11:12 AM > To: dev@cordova.apache.org > Subject: RE: Some pain points from our users :'( > > I would suggest creating a Google doc and sharing it here. > On Apr 30, 2014 8:59 AM, "Ray Camden" wrote: > > > Crap, I spoke too soon. it is a "Immutable Page" and I can't edit it. > > > > > > From: Marcel Kinard > > Sent: Wednesday, April 30, 2014 10:41 AM > > To: dev@cordova.apache.org > > Subject: Re: Some pain points from our users :'( > > > > How about here? https://wiki.apache.org/cordova/signposts-draft . I'd > > hope this works, as long as the contributions are considered "trivial" by > > Apache standards. Otherwise pull requests to cordova-doc.git would be the > > [slower and more proper] way to go. > > > > On Apr 30, 2014, at 11:29 AM, Ray Camden wrote: > > > > > Any particular place? Sorry if obvious - but it would need to be a > > github repo multiple folks can edit. (Seems like that would be quicker > than > > PRs imo.) > > >
Re: [DISCUSS] Automate signed icla to git commits
Agreed that it is working as intended. It’s also good to know that although Cordova’s been requiring CLA’s for it’s contributions, it isn’t a hard Apache requirement. For some contributions I’ve wanted to pull in, the CLA has been the holdup. Thanks for the clarification. -James Jong On Apr 28, 2014, at 10:40 PM, Andrew Grieve wrote: > I'm pretty confident it's working as intended for now. > > > On Mon, Apr 28, 2014 at 3:05 PM, Marvin Humphrey > wrote: > >> On Mon, Apr 28, 2014 at 9:20 AM, Andrew Grieve >> wrote: >>> Interesting! Going by this description, it sounds like we wound't need >>> ICLAs for the majority of pull requests since pull requests details get >>> forwarded to the mailing-list. >> >> Legally, the party making the pull request implicitly asserts that they >> have >> the right to contribute the commits under the ALv2 section 5. >> >> However, if a release with infringing material escapes out into the wild, >> having somebody to blame will be cold comfort. Should the original >> copyright >> owner request that we cease distributing the offending release, Cordova's >> users are going to be in a bad situation regardless. >> >>> New proposal: don't worry about CLAs at release time. >> >> The key here is that the Cordova PMC needs to be vigilant with every pull >> request from somebody who has not signed a CLA or is otherwise well-known >> to >> be submitting clean IP. The Cordova committer who accepts the pull request >> and pushes to the ASF repo is the first line of defense. However, the >> rest of >> the PMC is also collectively responsible for reviewing all commits. >> >> So the question is, how confident are you in the existing review process? >> If >> it's working as intended, then there's indeed no need to perform an >> additional >> audit at release time. On the other hand if it's porous, then building in >> more checks might be wise. >> >> Marvin Humphrey >>
Re: [Android] Not so fast....API changes in Cordova-Android for Pluggable WebView
On Wed, Apr 30, 2014 at 9:35 AM, Michal Mocny wrote: > On Wed, Apr 30, 2014 at 12:23 PM, Joe Bowser wrote: > >> Hey >> >> So, once again, we're dealing with some major API changes once we >> introduce pluggable webview. The first change that was done for >> sanity was finally deprecating setProperty. This was slated to be >> removed by 3.5 or in six months from the deprecation date, but we kept >> it in too long. While I would like to assume that everyone has moved >> over to setting their preferences in config.xml, which is the much >> more sane way of doing things, we can't do that. We need to publicize >> this in some blog posts, as well as in our documentation somehow. >> There will obviously be some pissed off users, as we've seen in past >> posts, but I think having the ability to use a WebView other than >> Chrome 30 is worth these changes. >> > > Is it feasible to leave setProperty working only for default WebView? This > would mean that custom webviews won't work with older plugins, but I think > thats fine. > The setProperty methods are actually in Cordova-Activity, and we could re-add those. The thing is that these aren't actually used by plugins, and instead are legacy methods that only our unit tests use. I'll put them back in. > >> >> The other change, which says more about our design is adding a getter >> method for pluginManager. We need to access the pluginManager to get >> plugins, and it's expected that everyone who implements a >> CordovaWebView will have this method produce a pluginManager. In the >> past, it was just publicly exposed, which was not the greatest idea >> and was kinda sloppy. >> > > Similar to above question, could we leave it (deprecated) as an exposed > property only on the default webview? And only support the new getter for > new webviews (xwalk, gecko)? Again, only updated plugins would work with > custom webview, but I think thats fine. > No, I don't think so. It's probably better to make a clean break and have all the WebViews expected to function the same than to have some plugins simply fail with certain webviews. Plugins breaking across all the WebViews will force people to fix them, while things breaking with only Crosswalk will put crosswalk at an unfair disadvantage.
Re: [Android] Not so fast....API changes in Cordova-Android for Pluggable WebView
On Wed, Apr 30, 2014 at 1:30 PM, Joe Bowser wrote: > On Wed, Apr 30, 2014 at 9:35 AM, Michal Mocny wrote: > > On Wed, Apr 30, 2014 at 12:23 PM, Joe Bowser wrote: > > > >> Hey > >> > >> So, once again, we're dealing with some major API changes once we > >> introduce pluggable webview. The first change that was done for > >> sanity was finally deprecating setProperty. This was slated to be > >> removed by 3.5 or in six months from the deprecation date, but we kept > >> it in too long. While I would like to assume that everyone has moved > >> over to setting their preferences in config.xml, which is the much > >> more sane way of doing things, we can't do that. We need to publicize > >> this in some blog posts, as well as in our documentation somehow. > >> There will obviously be some pissed off users, as we've seen in past > >> posts, but I think having the ability to use a WebView other than > >> Chrome 30 is worth these changes. > >> > > > > Is it feasible to leave setProperty working only for default WebView? > This > > would mean that custom webviews won't work with older plugins, but I > think > > thats fine. > > > > The setProperty methods are actually in Cordova-Activity, and we could > re-add those. The thing is that these aren't actually used by > plugins, and instead are legacy methods that only our unit tests use. > I'll put them back in. > > > > >> > >> The other change, which says more about our design is adding a getter > >> method for pluginManager. We need to access the pluginManager to get > >> plugins, and it's expected that everyone who implements a > >> CordovaWebView will have this method produce a pluginManager. In the > >> past, it was just publicly exposed, which was not the greatest idea > >> and was kinda sloppy. > >> > > > > Similar to above question, could we leave it (deprecated) as an exposed > > property only on the default webview? And only support the new getter > for > > new webviews (xwalk, gecko)? Again, only updated plugins would work with > > custom webview, but I think thats fine. > > > > No, I don't think so. It's probably better to make a clean break and > have all the WebViews expected to function the same than to have some > plugins simply fail with certain webviews. Plugins breaking across > all the WebViews will force people to fix them, while things breaking > with only Crosswalk will put crosswalk at an unfair disadvantage. > Trust me, Crosswalk is going to have an unfair *advantage* regardless of plugin support ;)
[GitHub] cordova-plugin-file pull request: updated support for the OS X pla...
Github user jsoref commented on a diff in the pull request: https://github.com/apache/cordova-plugin-file/pull/42#discussion_r12157876 --- Diff: plugin.xml --- @@ -203,6 +203,27 @@ xmlns:android="http://schemas.android.com/apk/res/android"; + + + + + + + + + --- End diff -- Why is this indented? --- 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: updated support for the OS X pla...
Github user jsoref commented on a diff in the pull request: https://github.com/apache/cordova-plugin-file/pull/42#discussion_r12157924 --- Diff: doc/index.md --- @@ -69,6 +70,10 @@ Android also supports a special filesystem named "documents", which represents a By default, the library and documents directories can be synced to iCloud. You can also request two additional filesystems, "library-nosync" and "documents-nosync", which represent a special non-synced directory within the Library or Documents filesystem. +### OS X + +The implementation is the same as the one for the iOS, except the asset library support. --- End diff -- What does "except the asset library support" mean? is it there? is it not there? --- 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-camera pull request: [iOS] Returns a specific error...
GitHub user m-revetria opened a pull request: https://github.com/apache/cordova-plugin-camera/pull/24 [iOS] Returns a specific error message when app has no access to Photos If user cancel the UIImagePickerController and the app has no authorization to access to the Photos, an error with the message "has no access to assets" is returned as the plugin result. You can merge this pull request into a Git repository by running: $ git pull https://github.com/m-revetria/cordova-plugin-camera master Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cordova-plugin-camera/pull/24.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 #24 commit 5d79b38beec61ebe2d97af5e3187fd4f5027ac13 Author: RemeR Date: 2014-04-29T15:30:50Z [iOS] Returns a specific error message when app has no access to library. --- 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: [Android] Not so fast....API changes in Cordova-Android for Pluggable WebView
Config.xml is not a very sane way to do things for the embedded webview case. E.g. you may want two webviews with different configs. Config.java is a singleton right now, and I think it would be much nicer as a parameter you could give to the WebView upon initialization & plugins should say: this.getConfig().getPreference() rather than using it as a singleton. So... If we could leave setPreference() in for now, I think we should. When we remove it, we should provide a nice API for the embedding case (e.g. a Config without the need to hit the filesystem). pluginManager being public is unfortunate. That said, other than getPlugin(), I don't see any methods in it that plugins should need. If we're to remove the property, I don't think we should expose PluginManager to plugins, but rather try and keep that an internal detail. On Wed, Apr 30, 2014 at 1:58 PM, Michal Mocny wrote: > On Wed, Apr 30, 2014 at 1:30 PM, Joe Bowser wrote: > > > On Wed, Apr 30, 2014 at 9:35 AM, Michal Mocny > wrote: > > > On Wed, Apr 30, 2014 at 12:23 PM, Joe Bowser > wrote: > > > > > >> Hey > > >> > > >> So, once again, we're dealing with some major API changes once we > > >> introduce pluggable webview. The first change that was done for > > >> sanity was finally deprecating setProperty. This was slated to be > > >> removed by 3.5 or in six months from the deprecation date, but we kept > > >> it in too long. While I would like to assume that everyone has moved > > >> over to setting their preferences in config.xml, which is the much > > >> more sane way of doing things, we can't do that. We need to publicize > > >> this in some blog posts, as well as in our documentation somehow. > > >> There will obviously be some pissed off users, as we've seen in past > > >> posts, but I think having the ability to use a WebView other than > > >> Chrome 30 is worth these changes. > > >> > > > > > > Is it feasible to leave setProperty working only for default WebView? > > This > > > would mean that custom webviews won't work with older plugins, but I > > think > > > thats fine. > > > > > > > The setProperty methods are actually in Cordova-Activity, and we could > > re-add those. The thing is that these aren't actually used by > > plugins, and instead are legacy methods that only our unit tests use. > > I'll put them back in. > > > > > > > >> > > >> The other change, which says more about our design is adding a getter > > >> method for pluginManager. We need to access the pluginManager to get > > >> plugins, and it's expected that everyone who implements a > > >> CordovaWebView will have this method produce a pluginManager. In the > > >> past, it was just publicly exposed, which was not the greatest idea > > >> and was kinda sloppy. > > >> > > > > > > Similar to above question, could we leave it (deprecated) as an exposed > > > property only on the default webview? And only support the new getter > > for > > > new webviews (xwalk, gecko)? Again, only updated plugins would work > with > > > custom webview, but I think thats fine. > > > > > > > No, I don't think so. It's probably better to make a clean break and > > have all the WebViews expected to function the same than to have some > > plugins simply fail with certain webviews. Plugins breaking across > > all the WebViews will force people to fix them, while things breaking > > with only Crosswalk will put crosswalk at an unfair disadvantage. > > > > Trust me, Crosswalk is going to have an unfair *advantage* regardless of > plugin support ;) >
[ios] plugin os version support
With 3.4.0, the default template only supports iOS 6.0 and up. I know that plugins can specify iOS support (apple-ios key in engines tag) but we haven't done it yet. I'm not even sure if the cli plugin installer checks for this yet. Should we start using this in core plugins? A specific case is this PR: https://github.com/apache/cordova-plugin-camera/pull/24 It is using [ALAssetsLibrary authorizationStatus] and that API only occurs in iOS 6.0 and up. Wrapping this in a runtime os version check is not hard, however (IsAtLeastVersion macro).
[GitHub] cordova-plugin-file pull request: updated support for the OS X pla...
Github user tripodsan commented on a diff in the pull request: https://github.com/apache/cordova-plugin-file/pull/42#discussion_r12163518 --- Diff: src/ios/CDVFile.m --- @@ -313,11 +313,9 @@ - (void)pluginInitialize --- End diff -- why is this changed? I thought you copied all the files from ios to osx? --- 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: updated support for the OS X pla...
Github user tripodsan commented on a diff in the pull request:
https://github.com/apache/cordova-plugin-file/pull/42#discussion_r12163564
--- Diff: src/osx/CDVLocalFilesystem.m ---
@@ -0,0 +1,719 @@
+/*
+ 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.
+ */
+
+#import "CDVFile.h"
+#import "CDVLocalFilesystem.h"
+#import
+#import
+
+@implementation CDVLocalFilesystem
+@synthesize name=_name, fsRoot=_fsRoot;
+
+- (id) initWithName:(NSString *)name root:(NSString *)fsRoot
+{
+if (self) {
+_name = name;
+_fsRoot = fsRoot;
+}
+return self;
+}
+
+/*
+ * IN
+ * NSString localURI
+ * OUT
+ * CDVPluginResult result containing a file or directoryEntry for the
localURI, or an error if the
+ * URI represents a non-existent path, or is unrecognized or otherwise
malformed.
+ */
+- (CDVPluginResult *)entryForLocalURI:(CDVFilesystemURL *)url
+{
+CDVPluginResult* result = nil;
+NSDictionary* entry = [self makeEntryForLocalURL:url];
+if (entry) {
+result = [CDVPluginResult resultWithStatus:CDVCommandStatus_OK
messageAsDictionary:entry];
+} else {
+// return NOT_FOUND_ERR
+result = [CDVPluginResult
resultWithStatus:CDVCommandStatus_IO_EXCEPTION messageAsInt:NOT_FOUND_ERR];
+}
+return result;
+}
+- (NSDictionary *)makeEntryForLocalURL:(CDVFilesystemURL *)url {
+NSString *path = [self filesystemPathForURL:url];
+NSFileManager* fileMgr = [[NSFileManager alloc] init];
+BOOL isDir = NO;
+// see if exists and is file or dir
+BOOL bExists = [fileMgr fileExistsAtPath:path isDirectory:&isDir];
+if (bExists) {
+return [self makeEntryForPath:url.fullPath
fileSystemName:url.fileSystemName isDirectory:isDir];
+} else {
+return nil;
+}
+}
+- (NSDictionary*)makeEntryForPath:(NSString*)fullPath
fileSystemName:(NSString *)fsName isDirectory:(BOOL)isDir
+{
+NSMutableDictionary* dirEntry = [NSMutableDictionary
dictionaryWithCapacity:5];
+NSString* lastPart = [[self stripQueryParametersFromPath:fullPath]
lastPathComponent];
+if (isDir && ![fullPath hasSuffix:@"/"]) {
+fullPath = [fullPath stringByAppendingString:@"/"];
+}
+[dirEntry setObject:[NSNumber numberWithBool:!isDir]
forKey:@"isFile"];
+[dirEntry setObject:[NSNumber numberWithBool:isDir]
forKey:@"isDirectory"];
+[dirEntry setObject:fullPath forKey:@"fullPath"];
+[dirEntry setObject:lastPart forKey:@"name"];
+[dirEntry setObject: [NSNumber numberWithInt:([fsName
isEqualToString:@"temporary"] ? 0 : 1)] forKey: @"filesystem"];
+[dirEntry setObject:fsName forKey: @"filesystemName"];
+dirEntry[@"nativeURL"] = [[NSURL fileURLWithPath:[self
filesystemPathForFullPath:fullPath]] absoluteString];
+
+
+return dirEntry;
+}
+
+- (NSString *)stripQueryParametersFromPath:(NSString *)fullPath
+{
+NSRange questionMark = [fullPath rangeOfString:@"?"];
+if (questionMark.location != NSNotFound) {
+return [fullPath
substringWithRange:NSMakeRange(0,questionMark.location)];
+}
+return fullPath;
+}
+
+- (NSString *)filesystemPathForFullPath:(NSString *)fullPath
+{
+NSString *path = nil;
+NSString *strippedFullPath = [self
stripQueryParametersFromPath:fullPath];
+path = [NSString stringWithFormat:@"%@%@", self.fsRoot,
strippedFullPath];
+if ([path length] > 1 && [path hasSuffix:@"/"]) {
+ path = [path substringToIndex:([path length]-1)];
+}
+return path;
+}
+/*
+ * IN
+ * NSString localURI
+ * OUT
+ * NSString full local filesystem path for the represented file or
directory, or nil if no such path is possible
+ * The file or directory does not necessarily have to exist. nil is
returned if the filesystem type is not recognized,
+ * or if the URL is malformed.
+ * The incoming U
[GitHub] cordova-plugin-file pull request: updated support for the OS X pla...
Github user tripodsan commented on a diff in the pull request:
https://github.com/apache/cordova-plugin-file/pull/42#discussion_r12163593
--- Diff: src/osx/CDVFile.m ---
@@ -0,0 +1,1024 @@
+/*
+ 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.
+ */
+
+#import
+#import "CDVFile.h"
+#import "CDVLocalFilesystem.h"
+
+CDVFile *filePlugin = nil;
+
+extern NSString * const NSURLIsExcludedFromBackupKey
__attribute__((weak_import));
+
+NSString* const NSURLIsExcludedFromBackupKey =
@"NSURLIsExcludedFromBackupKey";
+
+NSString* const kCDVFilesystemURLPrefix = @"cdvfile";
+
+@implementation CDVFilesystemURL
+@synthesize url=_url;
+@synthesize fileSystemName=_fileSystemName;
+@synthesize fullPath=_fullPath;
+
+- (id) initWithString:(NSString *)strURL
+{
+if ( self = [super init] ) {
+NSURL *decodedURL = [NSURL URLWithString:strURL];
+return [self initWithURL:decodedURL];
+}
+return nil;
+}
+
+-(id) initWithURL:(NSURL *)URL
+{
+if ( self = [super init] ) {
+_url = URL;
+_fileSystemName = [self filesystemNameForLocalURI:URL];
+_fullPath = [self fullPathForLocalURI:URL];
+}
+return self;
+}
+
+/*
+ * IN
+ * NSString localURI
+ * OUT
+ * NSString FileSystem Name for this URI, or nil if it is not recognized.
+ */
+- (NSString *)filesystemNameForLocalURI:(NSURL *)uri
+{
+if ([[uri scheme] isEqualToString:kCDVFilesystemURLPrefix] && [[uri
host] isEqualToString:@"localhost"]) {
+NSArray *pathComponents = [uri pathComponents];
+if (pathComponents != nil && pathComponents.count > 1) {
+return [pathComponents objectAtIndex:1];
+}
+}
+return nil;
+}
+
+/*
+ * IN
+ * NSString localURI
+ * OUT
+ * NSString fullPath component suitable for an Entry object.
+ * The incoming URI should be properly escaped. The returned fullPath is
unescaped.
+ */
+- (NSString *)fullPathForLocalURI:(NSURL *)uri
+{
+if ([[uri scheme] isEqualToString:kCDVFilesystemURLPrefix] && [[uri
host] isEqualToString:@"localhost"]) {
+NSString *path = [uri path];
+if ([uri query]) {
+path = [NSString stringWithFormat:@"%@?%@", path, [uri query]];
+}
+NSRange slashRange = [path rangeOfString:@"/" options:0
range:NSMakeRange(1, path.length-1)];
+if (slashRange.location == NSNotFound) {
+return @"";
+}
+return [path substringFromIndex:slashRange.location];
+}
+return nil;
+}
+
++ (CDVFilesystemURL *)fileSystemURLWithString:(NSString *)strURL
+{
+return [[CDVFilesystemURL alloc] initWithString:strURL];
+}
+
++ (CDVFilesystemURL *)fileSystemURLWithURL:(NSURL *)URL
+{
+return [[CDVFilesystemURL alloc] initWithURL:URL];
+}
+
+- (NSString *)absoluteURL
+{
+return [NSString stringWithFormat:@"cdvfile://localhost/%@%@",
self.fileSystemName, self.fullPath];
+}
+
+@end
+
+@implementation CDVFilesystemURLProtocol
+
++ (BOOL)canInitWithRequest:(NSURLRequest*)request
+{
+NSURL* url = [request URL];
+return [[url scheme] isEqualToString:kCDVFilesystemURLPrefix];
+}
+
++ (NSURLRequest*)canonicalRequestForRequest:(NSURLRequest*)request
+{
+return request;
+}
+
++ (BOOL)requestIsCacheEquivalent:(NSURLRequest*)requestA
toRequest:(NSURLRequest*)requestB
+{
+return [[[requestA URL] resourceSpecifier] isEqualToString:[[requestB
URL] resourceSpecifier]];
+}
+
+- (void)startLoading
+{
+CDVFilesystemURL* url = [CDVFilesystemURL fileSystemURLWithURL:[[self
request] URL]];
+NSObject *fs = [filePlugin filesystemForURL:url];
+[fs readFileAtURL:url start:0 end:-1 callback:^void(NSData *data,
NSString *mimetype, CDVFileError error) {
+NSMutableDictionary* responseHead
[GitHub] cordova-plugin-file pull request: updated support for the OS X pla...
Github user tripodsan commented on the pull request: https://github.com/apache/cordova-plugin-file/pull/42#issuecomment-41845829 I think you should check our editor settings. it looks like the lines you changed have the wrong indentation. make sure you have "replace tabs with spaces" enabled, or at least smart-tabs.. --- 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] plugin os version support
https://developer.apple.com/support/appstore/ iOS <6 = 2%. That meets the criteria we've used in the past.. On Wed, Apr 30, 2014 at 4:13 PM, Shazron wrote: > With 3.4.0, the default template only supports iOS 6.0 and up. I know that > plugins can specify iOS support (apple-ios key in engines tag) but we > haven't done it yet. I'm not even sure if the cli plugin installer checks > for this yet. > > Should we start using this in core plugins? > > A specific case is this PR: > https://github.com/apache/cordova-plugin-camera/pull/24 > It is using [ALAssetsLibrary authorizationStatus] and that API only occurs > in iOS 6.0 and up. > > Wrapping this in a runtime os version check is not hard, however > (IsAtLeastVersion macro). >
First stab at Next Steps article
I had 3 hours here at the airport so I took at stab at writing content for the Next Steps document. You can find (and edit) the document here: https://docs.google.com/document/d/1uJ5qXqQxK2oh1eZPgMdYuhK2rQTB7QMHXUHbkcomWgk/edit# The main thing missing now (imo) is the Upgrade section. I think with that added - this is in a good place (at least initially). Thoughts, opinions, etc? Any volunteers ready to write out the upgrade section?
Re: [ios] plugin os version support
I agree of course, now comes the part where we add the "apple-ios" key into the engines tag for all plugins. We can add 6.0 for everything or actually test whether it actually needs 6.0 (more work, requires testing with an older Cordova version, and Xcode version that has the iOS 5 SDK) On Wed, Apr 30, 2014 at 1:47 PM, Michal Mocny wrote: > https://developer.apple.com/support/appstore/ > > iOS <6 = 2%. That meets the criteria we've used in the past.. > > > On Wed, Apr 30, 2014 at 4:13 PM, Shazron wrote: > > > With 3.4.0, the default template only supports iOS 6.0 and up. I know > that > > plugins can specify iOS support (apple-ios key in engines tag) but we > > haven't done it yet. I'm not even sure if the cli plugin installer checks > > for this yet. > > > > Should we start using this in core plugins? > > > > A specific case is this PR: > > https://github.com/apache/cordova-plugin-camera/pull/24 > > It is using [ALAssetsLibrary authorizationStatus] and that API only > occurs > > in iOS 6.0 and up. > > > > Wrapping this in a runtime os version check is not hard, however > > (IsAtLeastVersion macro). > > >
[GitHub] cordova-plugman pull request: CB-6481 adds plugin level hooks supp...
Github user sgrebnov commented on the pull request: https://github.com/apache/cordova-plugman/pull/74#issuecomment-41850345 Switched to single parameter called context --- 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: Proposal: hooks support for plugins
Updated code as per latest notes. Do we ready to merge this?
https://github.com/apache/cordova-plugman/pull/74
Thx!
Sergey
-Original Message-
From: mmo...@google.com [mailto:mmo...@google.com] On Behalf Of Michal Mocny
Sent: Tuesday, April 22, 2014 10:39 AM
To: dev
Subject: Re: Proposal: hooks support for plugins
Passing in a reference is not a bad idea, though that implies that there is a
single top-level `cordova` object to reference. Not sure if thats the plan so
far.. though it could be.
Probably easier to just support require() of cordova bits, but I'm not sure how
to get that to work.
On Tue, Apr 22, 2014 at 1:32 PM, Brian LeRoux wrote:
> shhh
>
>
> On Tue, Apr 22, 2014 at 10:18 AM, purplecabbage
> >wrote:
>
> > If you need a shell script, that can be easily hidden behind the
> > node module.
> >
> > Sent from my iPhone
> >
> > > On Apr 22, 2014, at 9:34 AM, Brian LeRoux wrote:
> > >
> > > Maybe harsh but I'm in favor of abandoning shell scripts
> > > altogether and forcing modules as the way for hooks. Cross platform yada
> > > yada.
> > >
> > >
> > >> On Tue, Apr 22, 2014 at 9:23 AM, Andrew Grieve
> > >>
> > wrote:
> > >>
> > >> Very good point. Seen at least one other bug report that
> > >> struggled
> with
> > >> this use-case.
> > >>
> > >> I *think* hooks-as-a-module makes it easier.
> > >>
> > >> Just to be clear - I am also in favour of allowing hooks to be
> > >> npm
> > modules.
> > >> Possible there's use in continuing to support bash scripts as
> > >> hooks,
> but
> > >> there are definitely advantages to allowing modules.
> > >>
> > >>
> > >> On Tue, Apr 22, 2014 at 12:15 PM, Michal Mocny
> > >>
> > >> wrote:
> > >>
> > >>> I was recently trying to solve a problem with hooks: how do I
> require()
> > >>> cordova itself? (I was trying to call "cordova plugin ls" and
> > >>> ended
> up
> > >>> just writing my own crude inline implementation instead). If
> > >>> the
> hooks
> > >>> themselves are being require()-ed, does it simplify that problem?
> > >>>
> > >>> -Michal
> > >>>
> > >>>
> > >>> On Tue, Apr 22, 2014 at 12:04 PM, Andrew Grieve <
> agri...@chromium.org
> > wrote:
> > >>>
> > There are some *disadvantages* to not sub-shelling out for hooks:
> > - Harder to capture their stdio (certainly do-able though by
> swapping
> > >> out
> > system.std* for the duration of the hook)
> > - Harder to handle script failures (e.g. if they throw an
> > uncaught exception, we would like to be able to say "This hook script
> > failed:
> > foo.js")
> > - Maybe this is doable, by storing a global
> > exception-was-thrown callback?
> > - Gives hooks the ability to mess up cordova's environment
> > (although
> > >>> maybe
> > the vm thing addresses this?)
> >
> > Would like to see tests for these things added before we launch
> > this feature.
> >
> >
> >
> > On Tue, Apr 22, 2014 at 10:40 AM, Sergey Grebnov (Akvelon) <
> > v-seg...@microsoft.com> wrote:
> >
> > > +1, I will name it as 'context'
> > >
> > > Thx!
> > > Sergey
> > > -Original Message-
> > > From: Jonathan Bond-Caron [mailto:jbo...@gdesolutions.com]
> > > Sent: Tuesday, April 22, 2014 7:34 AM
> > > To: dev@cordova.apache.org
> > > Subject: RE: Proposal: hooks support for plugins
> > >
> > >> On Mon Apr 21 03:39 PM, Sergey Grebnov (Akvelon) wrote:
> > >> module.exports = function(platform, projectDir, pluginDir,
> > >> cmdLine) {
> > >>console.log('hook.js: ' + platform);
> > >>console.log('hook.js: ' + projectDir);
> > >>console.log('hook.js: ' + pluginDir);
> > >>console.log('hook.js: ' + cmdLine);
> > >
> > > Personnaly prefer:
> > >
> > >> module.exports = function(hookApi) {
> > >>console.log('hook.js: ' + hookApi.platform);
> > >>console.log('hook.js: ' + hookApi.projectDir);
> > >>console.log('hook.js: ' + hookApi.pluginDir);
> > >>console.log('hook.js: ' + hookApi.cmdLine);}
> > >
> > > Make it easier to pass other stuff in the future & using a
> > > sandoxed hookApi object.
> > >>
> >
>
Re: First stab at Next Steps article
Ray, This looks great. Interesting choice to both link Brock’s “you half-assed it” article *and* list jQM first in the list of UI libs... :) On 1 May 2014 at 6:50:53 am, Ray Camden (rayca...@adobe.com) wrote: I had 3 hours here at the airport so I took at stab at writing content for the Next Steps document. You can find (and edit) the document here: https://docs.google.com/document/d/1uJ5qXqQxK2oh1eZPgMdYuhK2rQTB7QMHXUHbkcomWgk/edit# The main thing missing now (imo) is the Upgrade section. I think with that added - this is in a good place (at least initially). Thoughts, opinions, etc? Any volunteers ready to write out the upgrade section?
Re: [Android] Not so fast....API changes in Cordova-Android for Pluggable WebView
On Wed, Apr 30, 2014 at 3:58 PM, Andrew Grieve wrote:
> Config.xml is not a very sane way to do things for the embedded webview
> case. E.g. you may want two webviews with different configs. Config.java is
> a singleton right now, and I think it would be much nicer as a parameter
> you could give to the WebView upon initialization & plugins should say:
> this.getConfig().getPreference() rather than using it as a singleton. So...
> If we could leave setPreference() in for now, I think we should. When we
> remove it, we should provide a nice API for the embedding case (e.g. a
> Config without the need to hit the filesystem).
>
>
> pluginManager being public is unfortunate. That said, other than
> getPlugin(), I don't see any methods in it that plugins should need. If
> we're to remove the property, I don't think we should expose PluginManager
> to plugins, but rather try and keep that an internal detail.
>
This is actually what I was working on last night -- the problem is that
plugins *do* use that field right now. File, File-Transfer, and Media
Capture all use it to get access to other plugins to use their APIs.
(through this.webView.pluginManager.getPlugin("somePlugin") )
It does make sense for plugins to have native APIs as well as JavaScript
APIs, and the only way to expose that right now is through the plugin
manager.
Unfortunately, it's been a public field on the plugin's webView object, and
there's no easy way to transition that to a setter. At least, not in a way
that ensures that both existing and new plugins can work with pre- and
post-3.5.0 Cordova.
>
>
>
>
>
>
>
> On Wed, Apr 30, 2014 at 1:58 PM, Michal Mocny wrote:
>
> > On Wed, Apr 30, 2014 at 1:30 PM, Joe Bowser wrote:
> >
> > > On Wed, Apr 30, 2014 at 9:35 AM, Michal Mocny
> > wrote:
> > > > On Wed, Apr 30, 2014 at 12:23 PM, Joe Bowser
> > wrote:
> > > >
> > > >> Hey
> > > >>
> > > >> So, once again, we're dealing with some major API changes once we
> > > >> introduce pluggable webview. The first change that was done for
> > > >> sanity was finally deprecating setProperty. This was slated to be
> > > >> removed by 3.5 or in six months from the deprecation date, but we
> kept
> > > >> it in too long. While I would like to assume that everyone has
> moved
> > > >> over to setting their preferences in config.xml, which is the much
> > > >> more sane way of doing things, we can't do that. We need to
> publicize
> > > >> this in some blog posts, as well as in our documentation somehow.
> > > >> There will obviously be some pissed off users, as we've seen in past
> > > >> posts, but I think having the ability to use a WebView other than
> > > >> Chrome 30 is worth these changes.
> > > >>
> > > >
> > > > Is it feasible to leave setProperty working only for default WebView?
> > > This
> > > > would mean that custom webviews won't work with older plugins, but I
> > > think
> > > > thats fine.
> > > >
> > >
> > > The setProperty methods are actually in Cordova-Activity, and we could
> > > re-add those. The thing is that these aren't actually used by
> > > plugins, and instead are legacy methods that only our unit tests use.
> > > I'll put them back in.
> > >
> > > >
> > > >>
> > > >> The other change, which says more about our design is adding a
> getter
> > > >> method for pluginManager. We need to access the pluginManager to
> get
> > > >> plugins, and it's expected that everyone who implements a
> > > >> CordovaWebView will have this method produce a pluginManager. In
> the
> > > >> past, it was just publicly exposed, which was not the greatest idea
> > > >> and was kinda sloppy.
> > > >>
> > > >
> > > > Similar to above question, could we leave it (deprecated) as an
> exposed
> > > > property only on the default webview? And only support the new
> getter
> > > for
> > > > new webviews (xwalk, gecko)? Again, only updated plugins would work
> > with
> > > > custom webview, but I think thats fine.
> > > >
> > >
> > > No, I don't think so. It's probably better to make a clean break and
> > > have all the WebViews expected to function the same than to have some
> > > plugins simply fail with certain webviews. Plugins breaking across
> > > all the WebViews will force people to fix them, while things breaking
> > > with only Crosswalk will put crosswalk at an unfair disadvantage.
> > >
> >
> > Trust me, Crosswalk is going to have an unfair *advantage* regardless of
> > plugin support ;)
> >
>
Re: First stab at Next Steps article
Ray Camden wrote: > I had 3 hours here at the airport so I took at stab at writing content > for the Next Steps document. You can find (and edit) the document here: > >https://docs.google.com/document/d/1uJ5qXqQxK2oh1eZPgMdYuhK2rQTB7QMHXUHbkc >omWgk/edit# Personally, I favor ether pads / pirate pads. > The main thing missing now (imo) is the Upgrade section. > I think with that added - this is in a good place (at least initially). > > Thoughts, opinions, etc? I like it. > Any volunteers ready to write out the upgrade section? I don't want to set up a Google account at work, but 1. Please don't mention WebSQL. 2. The offline/online event is not a great indicator, it's a hint, but it can be misleading. People need to try a connection (XHR) to their destination, if it works, great, if it doesn't that's it. If I'm in a captive portal, or if I'm in an office, I can easily not have access to your backend, even though I do have some form of "network access". 3. For Debugging, on BlackBerry 10, you get web inspector out of the box. https://developer.blackberry.com/html5/documentation/v2_0/enabling_web_insp ector.html https://developer.blackberry.com/html5/documentation/v2_0/debugging_using_w eb_inspector.html 4. I think we decided to favor stack overflow over google groups 5. s/you simulator the accelerometer to test shake events/you simulate the accelerometer to test shake events/ — this last one means you should introduce the document to WinWord and ask it for an opinion :).
Re: [Android] Not so fast....API changes in Cordova-Android for Pluggable WebView
This is a perfect example of this XKCD: https://xkcd.com/1172/
On Wed, Apr 30, 2014 at 2:25 PM, Ian Clelland wrote:
> On Wed, Apr 30, 2014 at 3:58 PM, Andrew Grieve wrote:
>
>> Config.xml is not a very sane way to do things for the embedded webview
>> case. E.g. you may want two webviews with different configs. Config.java is
>> a singleton right now, and I think it would be much nicer as a parameter
>> you could give to the WebView upon initialization & plugins should say:
>> this.getConfig().getPreference() rather than using it as a singleton. So...
>> If we could leave setPreference() in for now, I think we should. When we
>> remove it, we should provide a nice API for the embedding case (e.g. a
>> Config without the need to hit the filesystem).
>>
>>
>> pluginManager being public is unfortunate. That said, other than
>> getPlugin(), I don't see any methods in it that plugins should need. If
>> we're to remove the property, I don't think we should expose PluginManager
>> to plugins, but rather try and keep that an internal detail.
>>
>
> This is actually what I was working on last night -- the problem is that
> plugins *do* use that field right now. File, File-Transfer, and Media
> Capture all use it to get access to other plugins to use their APIs.
> (through this.webView.pluginManager.getPlugin("somePlugin") )
>
> It does make sense for plugins to have native APIs as well as JavaScript
> APIs, and the only way to expose that right now is through the plugin
> manager.
>
> Unfortunately, it's been a public field on the plugin's webView object, and
> there's no easy way to transition that to a setter. At least, not in a way
> that ensures that both existing and new plugins can work with pre- and
> post-3.5.0 Cordova.
>
>
>>
>>
>>
>>
>>
>>
>>
>> On Wed, Apr 30, 2014 at 1:58 PM, Michal Mocny wrote:
>>
>> > On Wed, Apr 30, 2014 at 1:30 PM, Joe Bowser wrote:
>> >
>> > > On Wed, Apr 30, 2014 at 9:35 AM, Michal Mocny
>> > wrote:
>> > > > On Wed, Apr 30, 2014 at 12:23 PM, Joe Bowser
>> > wrote:
>> > > >
>> > > >> Hey
>> > > >>
>> > > >> So, once again, we're dealing with some major API changes once we
>> > > >> introduce pluggable webview. The first change that was done for
>> > > >> sanity was finally deprecating setProperty. This was slated to be
>> > > >> removed by 3.5 or in six months from the deprecation date, but we
>> kept
>> > > >> it in too long. While I would like to assume that everyone has
>> moved
>> > > >> over to setting their preferences in config.xml, which is the much
>> > > >> more sane way of doing things, we can't do that. We need to
>> publicize
>> > > >> this in some blog posts, as well as in our documentation somehow.
>> > > >> There will obviously be some pissed off users, as we've seen in past
>> > > >> posts, but I think having the ability to use a WebView other than
>> > > >> Chrome 30 is worth these changes.
>> > > >>
>> > > >
>> > > > Is it feasible to leave setProperty working only for default WebView?
>> > > This
>> > > > would mean that custom webviews won't work with older plugins, but I
>> > > think
>> > > > thats fine.
>> > > >
>> > >
>> > > The setProperty methods are actually in Cordova-Activity, and we could
>> > > re-add those. The thing is that these aren't actually used by
>> > > plugins, and instead are legacy methods that only our unit tests use.
>> > > I'll put them back in.
>> > >
>> > > >
>> > > >>
>> > > >> The other change, which says more about our design is adding a
>> getter
>> > > >> method for pluginManager. We need to access the pluginManager to
>> get
>> > > >> plugins, and it's expected that everyone who implements a
>> > > >> CordovaWebView will have this method produce a pluginManager. In
>> the
>> > > >> past, it was just publicly exposed, which was not the greatest idea
>> > > >> and was kinda sloppy.
>> > > >>
>> > > >
>> > > > Similar to above question, could we leave it (deprecated) as an
>> exposed
>> > > > property only on the default webview? And only support the new
>> getter
>> > > for
>> > > > new webviews (xwalk, gecko)? Again, only updated plugins would work
>> > with
>> > > > custom webview, but I think thats fine.
>> > > >
>> > >
>> > > No, I don't think so. It's probably better to make a clean break and
>> > > have all the WebViews expected to function the same than to have some
>> > > plugins simply fail with certain webviews. Plugins breaking across
>> > > all the WebViews will force people to fix them, while things breaking
>> > > with only Crosswalk will put crosswalk at an unfair disadvantage.
>> > >
>> >
>> > Trust me, Crosswalk is going to have an unfair *advantage* regardless of
>> > plugin support ;)
>> >
>>
Re: First stab at Next Steps article
On Wed, Apr 30, 2014 at 5:28 PM, Josh Soref wrote: > Ray Camden wrote: > > I had 3 hours here at the airport so I took at stab at writing content > > for the Next Steps document. You can find (and edit) the document here: > > > > > https://docs.google.com/document/d/1uJ5qXqQxK2oh1eZPgMdYuhK2rQTB7QMHXUHbkc > >omWgk/edit# > > Personally, I favor ether pads / pirate pads. > > > The main thing missing now (imo) is the Upgrade section. > > I think with that added - this is in a good place (at least initially). > > > > Thoughts, opinions, etc? > > I like it. > > > Any volunteers ready to write out the upgrade section? > > I don't want to set up a Google account at work, but > FYI - you don't need an account to edit a doc that's made "editable via those with the link" (as this one is). > 1. Please don't mention WebSQL. > 2. The offline/online event is not a great indicator, it's a hint, but it > can be misleading. People need to try a connection (XHR) to their > destination, if it works, great, if it doesn't that's it. If I'm in a > captive portal, or if I'm in an office, I can easily not have access to > your backend, even though I do have some form of "network access". > 3. For Debugging, on BlackBerry 10, you get web inspector out of the box. > https://developer.blackberry.com/html5/documentation/v2_0/enabling_web_insp > ector.html > https://developer.blackberry.com/html5/documentation/v2_0/debugging_using_w > eb_inspector.html > > 4. I think we decided to favor stack overflow over google groups > 5. s/you simulator the accelerometer to test shake events/you simulate the > accelerometer to test shake events/ > — this last one means you should introduce the document to WinWord and ask > it for an opinion :). > >
Re: [Android] Not so fast....API changes in Cordova-Android for Pluggable WebView
On Wed, Apr 30, 2014 at 5:35 PM, Joe Bowser wrote:
> This is a perfect example of this XKCD: https://xkcd.com/1172/
>
> On Wed, Apr 30, 2014 at 2:25 PM, Ian Clelland
> wrote:
> > On Wed, Apr 30, 2014 at 3:58 PM, Andrew Grieve
> wrote:
> >
> >> Config.xml is not a very sane way to do things for the embedded webview
> >> case. E.g. you may want two webviews with different configs.
> Config.java is
> >> a singleton right now, and I think it would be much nicer as a parameter
> >> you could give to the WebView upon initialization & plugins should say:
> >> this.getConfig().getPreference() rather than using it as a singleton.
> So...
> >> If we could leave setPreference() in for now, I think we should. When we
> >> remove it, we should provide a nice API for the embedding case (e.g. a
> >> Config without the need to hit the filesystem).
>
Although I still think it shouldn't be a singleton, I've realized that
plugins require it reading from config.xml, so an all-in-memory config
doesn't make sense (would break plugins). Maybe for prefs it still would...
not sure. Just thinking out loud on this one. Don't have a proposal.
> >>
> >>
> >> pluginManager being public is unfortunate. That said, other than
> >> getPlugin(), I don't see any methods in it that plugins should need. If
> >> we're to remove the property, I don't think we should expose
> PluginManager
> >> to plugins, but rather try and keep that an internal detail.
> >>
> >
> > This is actually what I was working on last night -- the problem is that
> > plugins *do* use that field right now. File, File-Transfer, and Media
> > Capture all use it to get access to other plugins to use their APIs.
> > (through this.webView.pluginManager.getPlugin("somePlugin") )
> >
> > It does make sense for plugins to have native APIs as well as JavaScript
> > APIs, and the only way to expose that right now is through the plugin
> > manager.
> >
> > Unfortunately, it's been a public field on the plugin's webView object,
> and
> > there's no easy way to transition that to a setter. At least, not in a
> way
> > that ensures that both existing and new plugins can work with pre- and
> > post-3.5.0 Cordova.
>
I think we're saying the same thing. I called out getPlugin() as the one
plugins would actually need. It's things like init() shouldn't be touched
by plugins.
I don't see a clean way to not break this. I doubt it's used much by
non-core plugins, so I think it's worth changing & doing a major semver
bump for Android.
> >
> >
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> On Wed, Apr 30, 2014 at 1:58 PM, Michal Mocny
> wrote:
> >>
> >> > On Wed, Apr 30, 2014 at 1:30 PM, Joe Bowser
> wrote:
> >> >
> >> > > On Wed, Apr 30, 2014 at 9:35 AM, Michal Mocny
> >> > wrote:
> >> > > > On Wed, Apr 30, 2014 at 12:23 PM, Joe Bowser
> >> > wrote:
> >> > > >
> >> > > >> Hey
> >> > > >>
> >> > > >> So, once again, we're dealing with some major API changes once we
> >> > > >> introduce pluggable webview. The first change that was done for
> >> > > >> sanity was finally deprecating setProperty. This was slated to
> be
> >> > > >> removed by 3.5 or in six months from the deprecation date, but we
> >> kept
> >> > > >> it in too long. While I would like to assume that everyone has
> >> moved
> >> > > >> over to setting their preferences in config.xml, which is the
> much
> >> > > >> more sane way of doing things, we can't do that. We need to
> >> publicize
> >> > > >> this in some blog posts, as well as in our documentation somehow.
> >> > > >> There will obviously be some pissed off users, as we've seen in
> past
> >> > > >> posts, but I think having the ability to use a WebView other than
> >> > > >> Chrome 30 is worth these changes.
> >> > > >>
> >> > > >
> >> > > > Is it feasible to leave setProperty working only for default
> WebView?
> >> > > This
> >> > > > would mean that custom webviews won't work with older plugins,
> but I
> >> > > think
> >> > > > thats fine.
> >> > > >
> >> > >
> >> > > The setProperty methods are actually in Cordova-Activity, and we
> could
> >> > > re-add those. The thing is that these aren't actually used by
> >> > > plugins, and instead are legacy methods that only our unit tests
> use.
> >> > > I'll put them back in.
> >> > >
> >> > > >
> >> > > >>
> >> > > >> The other change, which says more about our design is adding a
> >> getter
> >> > > >> method for pluginManager. We need to access the pluginManager to
> >> get
> >> > > >> plugins, and it's expected that everyone who implements a
> >> > > >> CordovaWebView will have this method produce a pluginManager. In
> >> the
> >> > > >> past, it was just publicly exposed, which was not the greatest
> idea
> >> > > >> and was kinda sloppy.
> >> > > >>
> >> > > >
> >> > > > Similar to above question, could we leave it (deprecated) as an
> >> exposed
> >> > > > property only on the default webview? And only support the new
> >> getter
> >> > > for
> >> > > > new webviews (xwalk, gecko)? Again, only u
[GitHub] cordova-plugin-camera pull request: [iOS] Returns a specific error...
Github user shazron commented on the pull request: https://github.com/apache/cordova-plugin-camera/pull/24#issuecomment-41855580 https://issues.apache.org/jira/browse/CB-6576 --- 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-splashscreen pull request: CB-6483 Use splash scree...
Github user purplecabbage commented on the pull request: https://github.com/apache/cordova-plugin-splashscreen/pull/18#issuecomment-41862976 Merged, this should auto-close soon --- 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-splashscreen pull request: CB-6483 Use splash scree...
Github user asfgit closed the pull request at: https://github.com/apache/cordova-plugin-splashscreen/pull/18 --- 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] plugin os version support
Why do we need to do that? If the cordova-ios template support iOS 6+, don't we only need to update the cordova engine requirements? If you are using an older cordova-ios platform (that still supported iOS5), then would you be using a CLI that understood apple-ios engine tag? -Michal On Wed, Apr 30, 2014 at 4:54 PM, Shazron wrote: > I agree of course, now comes the part where we add the "apple-ios" key into > the engines tag for all plugins. We can add 6.0 for everything or actually > test whether it actually needs 6.0 (more work, requires testing with an > older Cordova version, and Xcode version that has the iOS 5 SDK) > > > On Wed, Apr 30, 2014 at 1:47 PM, Michal Mocny wrote: > > > https://developer.apple.com/support/appstore/ > > > > iOS <6 = 2%. That meets the criteria we've used in the past.. > > > > > > On Wed, Apr 30, 2014 at 4:13 PM, Shazron wrote: > > > > > With 3.4.0, the default template only supports iOS 6.0 and up. I know > > that > > > plugins can specify iOS support (apple-ios key in engines tag) but we > > > haven't done it yet. I'm not even sure if the cli plugin installer > checks > > > for this yet. > > > > > > Should we start using this in core plugins? > > > > > > A specific case is this PR: > > > https://github.com/apache/cordova-plugin-camera/pull/24 > > > It is using [ALAssetsLibrary authorizationStatus] and that API only > > occurs > > > in iOS 6.0 and up. > > > > > > Wrapping this in a runtime os version check is not hard, however > > > (IsAtLeastVersion macro). > > > > > >
[GitHub] cordova-plugin-device pull request: Use Windows system calls to ge...
GitHub user EionRobb opened a pull request: https://github.com/apache/cordova-plugin-device/pull/14 Use Windows system calls to get better info Use the hardware GUID as a basis for the device uuid (to persist between reinstalls) Look at the HAL device driver version to work out what version of Windows we're actually running on (because running a Win8 app on Win8.1 will report as if it's still running on Win8) You can merge this pull request into a Git repository by running: $ git pull https://github.com/EionRobb/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/14.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 #14 commit 878a314a84a7280e5c155bbebea13dd97f47e514 Author: Eion Robb Date: 2014-05-01T00:22:01Z Use Windows system calls to get better info Use the hardware GUID as a basis for the device uuid (to persist between reinstalls) Look at the HAL device driver version to work out what version of Windows we're actually running on (because running a Win8 app on Win8.1 will report as if it's still running on Win8) --- 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] plugin os version support
It's also informational - so it has some value for plain human eyes (browsing the registry for example) vs automatons On Wednesday, April 30, 2014, Michal Mocny wrote: > Why do we need to do that? > > If the cordova-ios template support iOS 6+, don't we only need to update > the cordova engine requirements? If you are using an older cordova-ios > platform (that still supported iOS5), then would you be using a CLI that > understood apple-ios engine tag? > > -Michal > > > On Wed, Apr 30, 2014 at 4:54 PM, Shazron > > wrote: > > > I agree of course, now comes the part where we add the "apple-ios" key > into > > the engines tag for all plugins. We can add 6.0 for everything or > actually > > test whether it actually needs 6.0 (more work, requires testing with an > > older Cordova version, and Xcode version that has the iOS 5 SDK) > > > > > > On Wed, Apr 30, 2014 at 1:47 PM, Michal Mocny > > > > wrote: > > > > > https://developer.apple.com/support/appstore/ > > > > > > iOS <6 = 2%. That meets the criteria we've used in the past.. > > > > > > > > > On Wed, Apr 30, 2014 at 4:13 PM, Shazron > > wrote: > > > > > > > With 3.4.0, the default template only supports iOS 6.0 and up. I know > > > that > > > > plugins can specify iOS support (apple-ios key in engines tag) but we > > > > haven't done it yet. I'm not even sure if the cli plugin installer > > checks > > > > for this yet. > > > > > > > > Should we start using this in core plugins? > > > > > > > > A specific case is this PR: > > > > https://github.com/apache/cordova-plugin-camera/pull/24 > > > > It is using [ALAssetsLibrary authorizationStatus] and that API only > > > occurs > > > > in iOS 6.0 and up. > > > > > > > > Wrapping this in a runtime os version check is not hard, however > > > > (IsAtLeastVersion macro). > > > > > > > > > >
Re: [DISCUSS] Release 3.5.0
Hello everyone! Shall we move forward with 3.5.0 release? Please list any issues that exist & reasons to postpone. I know both windows platforms and amazon fireos both really want this release to get out asap. Proposed timeline: - RC this Friday/next Monday (no vote required, cli published under rc tag) - Final tag & vote either May 8 or May 12 (lets not release on friday). I volunteer to be release master for this release. On Fri, Apr 4, 2014 at 12:09 PM, Josh Soref wrote: > purplecabbage wrote: > > > I would like to see 3.5.0 ready to vote on late next week. > > I won¹t be around then (Passover). > > > Bryan + I will try to ensure that 3.5 works nicely w/ BlackBerry 10 early > next week (this week is overŠ). > > Hopefully someone can review the announce bits. > > My general requests: > 1. Please spell brands correctly (Tizen, FirefoxOS, BlackBerry, iOS, Š) > 2. Please `` commands, arguments, filenames, and file types > >
Re: [ios] plugin os version support
Another motivation is to actually use it ourselves and bring light to this feature which is underused. Inevitably there will be iOS 7 only plugins. Eventually we will support only iOS 7 and 8 only, etc On Wednesday, April 30, 2014, Shazron wrote: > It's also informational - so it has some value for plain human eyes > (browsing the registry for example) vs automatons > > On Wednesday, April 30, 2014, Michal Mocny > > > wrote: > >> Why do we need to do that? >> >> If the cordova-ios template support iOS 6+, don't we only need to update >> the cordova engine requirements? If you are using an older cordova-ios >> platform (that still supported iOS5), then would you be using a CLI that >> understood apple-ios engine tag? >> >> -Michal >> >> >> On Wed, Apr 30, 2014 at 4:54 PM, Shazron wrote: >> >> > I agree of course, now comes the part where we add the "apple-ios" key >> into >> > the engines tag for all plugins. We can add 6.0 for everything or >> actually >> > test whether it actually needs 6.0 (more work, requires testing with an >> > older Cordova version, and Xcode version that has the iOS 5 SDK) >> > >> > >> > On Wed, Apr 30, 2014 at 1:47 PM, Michal Mocny >> wrote: >> > >> > > https://developer.apple.com/support/appstore/ >> > > >> > > iOS <6 = 2%. That meets the criteria we've used in the past.. >> > > >> > > >> > > On Wed, Apr 30, 2014 at 4:13 PM, Shazron wrote: >> > > >> > > > With 3.4.0, the default template only supports iOS 6.0 and up. I >> know >> > > that >> > > > plugins can specify iOS support (apple-ios key in engines tag) but >> we >> > > > haven't done it yet. I'm not even sure if the cli plugin installer >> > checks >> > > > for this yet. >> > > > >> > > > Should we start using this in core plugins? >> > > > >> > > > A specific case is this PR: >> > > > https://github.com/apache/cordova-plugin-camera/pull/24 >> > > > It is using [ALAssetsLibrary authorizationStatus] and that API only >> > > occurs >> > > > in iOS 6.0 and up. >> > > > >> > > > Wrapping this in a runtime os version check is not hard, however >> > > > (IsAtLeastVersion macro). >> > > > >> > > >> > >> >
