On 10 December 2014 at 22:20, Ally Ogilvie wrote:
>
> @Brian it's a dark road down that way..
>
> However, the guys at Ludei patched WKWebView and released "WebView+ for
> iOS" but have not released the source code :(
> https://github.com/ludei/webview-plus-ios/tree/master/ios/Release-iphoneos
>
@Brian it's a dark road down that way..
However, the guys at Ludei patched WKWebView and released "WebView+ for
iOS" but have not released the source code :(
https://github.com/ludei/webview-plus-ios/tree/master/ios/Release-iphoneos
We are playing around over here too, but have limited corp backi
Thanks all for review.
Here one more pull request to docs which could be interested - not mine
this time.
https://github.com/apache/cordova-docs/pull/212 (Instructions about signing
and releasing a phonegap android app)
Looks like we still does not have any guidance for users in that part.
201
Github user kant2002 commented on the pull request:
https://github.com/apache/cordova-docs/pull/232#issuecomment-66565109
Done.
Too many time this pull request was not merged, you even implement stuff :)
---
If your project is set up for it, you can reply to this email and have yo
Thanks,
1. Already play with marked options and don't find any way to resolve that
using that path. Now I done following:
a) Generate latest docs using Ruby & JS
b) Made changes to the original MD files, so previously generated
version with Ruby will match with generated using JS
c) Reg
Jesse: yes, that could work. By setting your polyfill to you'll be
sure it is available after pluginsready (and thus deviceready). For
plugins that use Promises during bootstrap, which is unlikely to be common,
the explicit require() on the polyfill is still an option.
Regarding your Native inj
Working fine for me as of right now.
On Wed, Dec 10, 2014 at 6:58 PM, Shazron wrote:
> I couldn't git pull.
>
> See:
> https://twitter.com/infrabot/status/542829293240217600
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cordov
so, it appears wkwebview itself is open source [1] …well outside my comfort
zone but feasible we fix these things ourselves?
[1]
https://github.com/WebKit/webkit/blob/0190dd5b8c0272beaa705dbc10863a84a3e6af5e/Source/WebKit2/UIProcess/API/Cocoa/WKWebView.h
On Wed, Dec 10, 2014 at 3:18 PM, Shazron
Github user asfgit closed the pull request at:
https://github.com/apache/cordova-android/pull/136
---
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 featur
Github user asfgit closed the pull request at:
https://github.com/apache/cordova-android/pull/137
---
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 featur
Github user asfgit closed the pull request at:
https://github.com/apache/cordova-android/pull/127
---
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 featur
Github user asfgit closed the pull request at:
https://github.com/apache/cordova-android/pull/130
---
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 featur
Github user asfgit closed the pull request at:
https://github.com/apache/cordova-android/pull/126
---
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 featur
Github user agrieve commented on the pull request:
https://github.com/apache/cordova-android/pull/127#issuecomment-66558329
Also - created a JIRA: https://issues.apache.org/jira/browse/CB-8147
---
If your project is set up for it, you can reply to this email and have your
reply appear
Github user agrieve commented on the pull request:
https://github.com/apache/cordova-android/pull/127#issuecomment-66558271
Going to close this out but will implement both of your suggestions.
---
If your project is set up for it, you can reply to this email and have your
reply appear
Github user agrieve commented on the pull request:
https://github.com/apache/cordova-android/pull/126#issuecomment-66558156
Have a read of the last line of the javadoc. The function should either
return a new object, or throw a FileNotFound exception (never returns null)
---
If your
Github user agrieve commented on the pull request:
https://github.com/apache/cordova-android/pull/128#issuecomment-66557603
Please reference CB-8146 if with your better fix :+1:
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as
Github user agrieve commented on the pull request:
https://github.com/apache/cordova-android/pull/128#issuecomment-66557534
Alright, will hold off then.
---
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 doe
we should move browserify to main and drop that insane concat code
its not heavyweight at all. it creates a hash in iife with deps mapped
in…as to why dep mgmt is better than concatenating…I don't think we need to
waste our time talking about that!
On Wed, Dec 10, 2014 at 5:00 PM, Andrew Grieve
Github user agrieve closed the pull request at:
https://github.com/apache/cordova-android/pull/132
---
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 featu
Github user odbol commented on the pull request:
https://github.com/apache/cordova-android/pull/128#issuecomment-66555987
Actually, I've since found that this is not the best solution - it
introduces another bug. Please do not merge.
I have found a better fix; I can try to pub
Github user odbol closed the pull request at:
https://github.com/apache/cordova-android/pull/128
---
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
Github user agrieve commented on the pull request:
https://github.com/apache/cordova-android/pull/128#issuecomment-66555726
Created issue for this: https://issues.apache.org/jira/browse/CB-8146.
Nice job tracking this down! I'd go even one step further to what Joe said
and cla
There's something implemented behind a --browserify flag, but not sure what
it does.
Totally in favour of having CLI / plugman concatenate plugin JS with
cordova.js, but not convinced that browserify is the right tool for this,
as it seems quite heavy-weight for just concatenating things. If someo
Pretty sure they are saving it for the "and one last thing" part of the iOS
10 release :P
On Wed, Dec 10, 2014 at 6:18 PM, Shazron wrote:
> No dice in iOS 8.2b2 that was released today:
>
> https://issues.apache.org/jira/browse/CB-7090?focusedCommentId=14241546&page=com.atlassian.jira.plugin.sys
I couldn't git pull.
See:
https://twitter.com/infrabot/status/542829293240217600
-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org
So far I have approached browser polyfils with an outside-in approach.
For example, there are issues in the C# + WP8 browser implementation of
XMLHttpRequest which prevent xhr calls to the local filesystem. This
could have been resolved by adding platform specific code to cordova-js,
but my solut
No dice in iOS 8.2b2 that was released today:
https://issues.apache.org/jira/browse/CB-7090?focusedCommentId=14241546&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14241546
On Thu, Nov 20, 2014 at 1:37 PM, Shazron wrote:
> I updated https://issues.apache.org/jira/b
We haven't worked on it, also curious. Anis, perhaps?
On Wed, Dec 10, 2014 at 4:08 PM, Brian LeRoux wrote:
> def think we should support those specs in our great and fabled api
> audit…had not considered the load order issue
>
> not insurmountable and probably should be a feature/fix for the pl
Github user agrieve closed the pull request at:
https://github.com/apache/cordova-android/pull/134
---
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 featu
Github user agrieve commented on the pull request:
https://github.com/apache/cordova-android/pull/134#issuecomment-66524675
merged.
---
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 featur
def think we should support those specs in our great and fabled api
audit…had not considered the load order issue
not insurmountable and probably should be a feature/fix for the plugin
loader load order …but also sort of scary… reminds me of script tags hell
on that note: we need to make browseri
Do we prefer to invent new cordova-specific apis, or prefer to match
standard browser apis? When there is no browser spec to match then design
comes down to aesthetics and personal preference (as you say). But often
there is an existing browser spec, and then it comes down to match or
fork. I'm
guess so yea, great first patch Martin ;)
On Wed, Dec 10, 2014 at 12:32 PM, Andrew Grieve
wrote:
> Could we just strip the license as a part of the create script?
>
> On Wed, Dec 10, 2014 at 2:30 PM, Brian LeRoux wrote:
>
> > recent discussions elsewhere indicate (to me) that while the ASL (apa
Could we just strip the license as a part of the create script?
On Wed, Dec 10, 2014 at 2:30 PM, Brian LeRoux wrote:
> recent discussions elsewhere indicate (to me) that while the ASL (apache
> software license) is compatible with other licenses but the ASF (apache
> software foundation) doesn't
Github user sandstrom commented on the pull request:
https://github.com/apache/cordova-plugins/pull/15#issuecomment-66510570
@clelland @shazron friendly ping! :smile:
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If yo
Github user sandstrom commented on the pull request:
https://github.com/apache/cordova-plugins/pull/14#issuecomment-66510313
@clelland ping!
---
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 th
recent discussions elsewhere indicate (to me) that while the ASL (apache
software license) is compatible with other licenses but the ASF (apache
software foundation) doesn't want to conflate our source with other ones
(reasonable imo)
On Wed, Dec 10, 2014 at 11:21 AM, Josh Soref wrote:
> In the
In theory, shouldn't we be able to put that file under an MIT/BSD license
to make people happier?
Getting sample content to be usable by others is a pain, and something
that is one of the last steps people work on.
I think Mozilla moved its tests to MIT to address this.
I have no idea what Apach
no mistake, but it is a requirement for us to distribute code at apache.
you are free to remove and relicense as you wish.
On Wed, Dec 10, 2014 at 9:49 AM, Martin Sidaway wrote:
> I'm a bit puzzled by the Apache license notice present in the following
> files after doing "cordova create":
>
> ww
Why does battery-status 'require' promises?
I agree that promises are here to stay, but I am unclear why it would be a
good idea to go and change/rewrite/break our apis to use them?
Most of the windows plugins use promises all over the place, the entire
async windows js api is promise based, but
I'm a bit puzzled by the Apache license notice present in the following
files after doing "cordova create":
www/index.html
www/js/index.js
www/css/index.css
The trouble is that if I begin my project by extending those files, it
seems like the Apache license covers my changes as well as the origin
GitHub user zalun opened a pull request:
https://github.com/apache/cordova-docs/pull/248
CB-8144 add systemXHR as a solution for whitelisting in FFOS
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/zalun/cordova-docs ffos_whiteli
Github user solarsaturn9 commented on the pull request:
https://github.com/apache/cordova-plugin-splashscreen/pull/14#issuecomment-66492739
Additionally, CDV_IsIPad is deprecated and produces an error when building.
Not sure how to report this seeing as how I don't know a good alterna
Github user zalun commented on the pull request:
https://github.com/apache/cordova-plugin-geolocation/pull/31#issuecomment-66492098
It would be good to have this in a separate branch. And by the way...
For some reason I can't pull master from you:
git remote add drjoj
- no technical benefit (but aesthetics, sure)
- adds weight (payload and runtime)
- might interfere with userland polly
-1
On Wed, Dec 10, 2014 at 7:48 AM, Andrew Grieve wrote:
> One specific spot in core I'd like to use it is to address this TODO in
> Android's exec bridge:
>
> https://github.
On Sun, Dec 7, 2014 at 11:53 PM, Joe Bowser wrote:
> Hey
>
> After messing with the JS for a week, I decided for now to stop work on
> MozillaView. I think I've managed to prove that the concept is at least
> possible, but I really feel that it's still too unstable to actually show
> past a demo
One specific spot in core I'd like to use it is to address this TODO in
Android's exec bridge:
https://github.com/apache/cordova-js/blob/master/src/android/exec.js#L263
The actual need is for a setImmediate polyfill, but Promise does the same
thing (with an extra object creation).
On Wed, Dec 10
So the problem appears to be just the Android Gradle plugin, which *we*
hard coded to "0.12.0+", which doesn't work with Gradle 2.x, so we can fix
that.
Looking at the Android team's docs at
http://tools.android.com/tech-docs/new-build-system/version-compatibility
(thanks for the pointer, Joe), it
On Wed Dec 10 2014 at 10:17:38 AM Andrew Grieve
wrote:
> userland means that plugins won't be able to use them unless every plugin
> also includes a copy of the polyfill within it.
>
> Looking at our core APIs, seems maybe it's just battery-status that will
> require it. Should we have battery-st
userland means that plugins won't be able to use them unless every plugin
also includes a copy of the polyfill within it.
Looking at our core APIs, seems maybe it's just battery-status that will
require it. Should we have battery-status include the polyfill within it? I
hope not. I'd hate to get t
On Tue Dec 09 2014 at 5:18:47 PM Joe Bowser wrote:
> Hey
>
> I just upgraded to Android Studio 1.0 and now none of my 4.0 builds work.
> I'm getting gradle errors everywhere, and I have no idea how to resolve
> them.
>
> I'll file an issue, but this is pretty much a blocker since nothing can
> bu
Hello,
I am using sencha with cordova to build Android and IOS app. As I
checked "Integration Tool" section, Fiksu have native SDK's for IOS and
Android SDK's. Please give input on below queries:-
1. Did Fiksu provide JavaScript SDK or web mobile SDK ?
2. Can we integrate Fiksu with sencha
GitHub user daserge opened a pull request:
https://github.com/apache/cordova-plugin-battery-status/pull/20
CB-7953 Add cordova-plugin-battery-status support for browser platform
Added browser support
Updated the docs
[JIRA item](https://issues.apache.org/jira/browse/CB-7
54 matches
Mail list logo
