Alright I'll add it to the
https://github.com/apache/cordova-labs/tree/plugins branch
On Thu, Sep 26, 2013 at 7:30 PM, Brian LeRoux wrote:
> +1
> On Sep 26, 2013 11:04 PM, "Michal Mocny" wrote:
>
> > You mean put it within cordova-labs/plugins? I agree it should start
> life
> > there. I don
Plugins are ready to be published. I did plugman adduser. Can't publish
plugins yet. Guessing Anis has to give me permission.
On Tue, Sep 17, 2013 at 6:10 PM, Andrew Grieve wrote:
> The ability to clone from a branch/tag already exists. It didn't for 3.0,
> but was added afterwards.
>
> I don't
On Fri, Sep 27, 2013 at 12:11 AM, Anis KADRI wrote:
> As far as IDEs, the answer is simple. You should not use IDEs and
> cordova-cli at the same time. Until IDEs are aware of cordova-cli
> there is no point in creating projects with cordova-cli because
> everything gets blown on every build. I a
+1
On Sep 26, 2013 11:04 PM, "Michal Mocny" wrote:
> You mean put it within cordova-labs/plugins? I agree it should start life
> there. I don't think plugins should live in the platform repos, even if
> they are currently platform specific.
>
>
> On Thu, Sep 26, 2013 at 4:11 PM, Andrew Grieve
You can help!
On Sep 27, 2013 2:37 AM, "Smith, Peter" wrote:
> Back when we adopted 2.9.0 we were a bit apprehensive about early
> adoption of 3.x, so were quite encouraged to read:
>
> "We understand and respect that there is a huge community of projects
> built on PhoneGap 2.0 series and we wil
We should continue to do this for defects for the time being.
On Sep 26, 2013 9:17 PM, "Joe Bowser" wrote:
> Hey
>
> What did we agree to for supporting the old 2.9.x branch? I'm just
> wondering, since we're still getting tons of bugs filed against that.
> While most of them are valid in 3.0.x,
We should be supporting 2.9 -- I'm pretty sure we've committed to at least
fixing bugs as they come up.
We never discussed whether we would *only* be fixing things that were
reported on the 2.9 branch, or whether we were going to test the issues
that were reported on 3.x and backport the fixes. I
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/14356/
---
(Updated Sept. 27, 2013, 1:16 a.m.)
Review request for cordova.
Changes
-
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/14356/
---
(Updated Sept. 27, 2013, 1:09 a.m.)
Review request for cordova.
Changes
-
Looks like I forgot to click publish on the review page. I also found a
bunch of spelling mistakes I made in my rush to create this. I just fixed
them and uploaded a new diff. The review site should be available for all
now to leave feedback.
On Thu, Sep 26, 2013 at 5:42 PM, Steven Gill wrote:
Published the branch on apache/cordova-ios/CB-4935 (see the issue for the
specific branch commit)
Decided to make the settings dynamic, although HideKeyboardFormAccessoryBar
can't be "unhidden" currently - so that setting is readonly (there's a
TODO: in there)
On Thu, Sep 26, 2013 at 4:48 PM, Sha
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/14356/
---
Review request for cordova.
Repository: cordova-site
Description
---
I t
And one more data point I think worth mentioning: I just went to the main
Cordova site, clicked the top Download button, it took me to the Download &
Archive section, and I downloaded the source.zip. I opened it up and it is just
a folder full of zip files, including the zips for each plugin.
N
Today we are doing a big plugin release in preperation for Apache Cordova
3.1.0 which is scheduled to come out next week.
The main change for this release is removing core from all of the plugin ID
fields. This was done to make installing plugins easier in 3.1.0. We are
switching over to using plu
I have no idea how this review stuff works. I will post the blog here
On Sep 26, 2013 4:59 PM, "Tim Kim" wrote:
> >
> > "You don't have access to this review request.
> > This review request is private. You must be a requested reviewer, either
> > directly or on a requested group, and have permis
Back when we adopted 2.9.0 we were a bit apprehensive about early
adoption of 3.x, so were quite encouraged to read:
"We understand and respect that there is a huge community of projects
built on PhoneGap 2.0 series and we will continue to support 2.x in a
long lived branch."
http://phonegap.com/
Re: IDEs: if it is the case that the CLI should not be used along with an IDE,
perhaps the documentation - including Getting Started Guides, etc. - ought to
be much clearer about this. Perhaps a big warning that "Xcode project files are
created by the CLI, but they should not be opened and used
>
> "You don't have access to this review request.
> This review request is private. You must be a requested reviewer, either
> directly or on a requested group, and have permission to access the
> repository in order to view this review request."
Ya, same here
On 26 September 2013 16:37, Shazro
I've added https://issues.apache.org/jira/browse/CB-4935
Scheduled this for 3.2.0 - I've already got this working in a branch on
cordova-ios actually (will publish to the branch EOD). I suppose it could
go to cordova-labs?
On Thu, Sep 26, 2013 at 1:56 PM, Michal Mocny wrote:
> You mean put it
Does everyone have access to this? I get:
"You don't have access to this review request.
This review request is private. You must be a requested reviewer, either
directly or on a requested group, and have permission to access the
repository in order to view this review request."
On Thu, Sep 26,
Can you guys review it at https://reviews.apache.org/r/14356/
I don't think post-review was working properly for me...
merged, thanks
@purplecabbage
risingj.com
On Thu, Sep 26, 2013 at 2:59 PM, Carlos Santana wrote:
> Can someone review this code?
>
> [CB-4934] plugin-splashscreen should not show by default on Windows8
> https://issues.apache.org/jira/browse/CB-4934
>
> https://github.com/apache/cordova-plugin-
@purplecabbage: I have the same workflow but I think the proposed
solution is a step in the right direction. It would allow us to easily
develop platform plugins without having to delete project/create
project/install plugin/uninstall plugin constantly. The plugin would
be packaged (plugin.xml) fro
Hey Michael,
I am not sure how that code got on master, but it shouldn't have been.
We have already taken care of this problem on the dev branch and I am in
the process of merging it today. Issue is at
https://issues.apache.org/jira/browse/CB-4889
Thanks for taking the time and sending pull requ
Can someone review this code?
[CB-4934] plugin-splashscreen should not show by default on Windows8
https://issues.apache.org/jira/browse/CB-4934
https://github.com/apache/cordova-plugin-splashscreen/pull/5
--
Carlos Santana
Michal,
Awesome. I've sent in a signed copy of the CLA.
Cheers,
Mike
On 2013-09-26 18:02, Michal Mocny wrote:
Wow, this sounds like the problem I just ran into yesterday, so thanks for
fixing it. I'm heading out for today so cannot review&pull your patches,
but to get the ball rolling for tom
Wow, this sounds like the problem I just ran into yesterday, so thanks for
fixing it. I'm heading out for today so cannot review&pull your patches,
but to get the ball rolling for tomorrow, make sure you have signed the
ICLA (http://www.apache.org/licenses/#clas) since It looks like you have
not.
You mean put it within cordova-labs/plugins? I agree it should start life
there. I don't think plugins should live in the platform repos, even if
they are currently platform specific.
On Thu, Sep 26, 2013 at 4:11 PM, Andrew Grieve wrote:
> Makes sense to me if taking it out is feasible code-w
Hi,
I opened this issue a couple of days ago:
https://issues.apache.org/jira/browse/CB-4902
The issue was the plugin identifiers were changed and the code wasn't
updated with the new identifiers. I opened two pull requests to fix the
issue but I can't figure out how to add them the to the Jira
Makes sense to me if taking it out is feasible code-wise. Would encourage
people to fork / fiddle with it themselves as well I think.
Now that we have a registry, we don't need to create new repos for them
(yay!). Maybe just put the plugins within cordova-ios/plugins?
I think we'll need to wait u
Sounds less than ideal to have to backport, given that we still support the
old workflow with 3.0.
However, I think we did discuss keeping 2.9 maintained while we iron out
3.0 issues. I think we should drop 2.9 as soon as users run out of *valid*
reasons for not upgrading to 3.0, right?
What do
Can someone review this?
https://github.com/apache/cordova-plugin-splashscreen/pull/4
https://issues.apache.org/jira/browse/CB-4929
--
Carlos Santana
I'm about to try to better clarify current behavior in the doc. I understand
when using the CLI to build, the `platforms/*/www/config.xml` files come from
passively copying the web-assets source directory. (Excpetion: Android's ends
up in `platforms/android/assets/www/config.xml`.) If you swi
Hey
What did we agree to for supporting the old 2.9.x branch? I'm just
wondering, since we're still getting tons of bugs filed against that.
While most of them are valid in 3.0.x, we probably should be
backporting to 2.9.
Have people been doing this. I've been doing this a bit, but I have
to adm
Can someone review this proposed fix for CB-4928?
https://issues.apache.org/jira/browse/CB-4928
https://github.com/apache/cordova-plugin-media/pull/3
--
Carlos Santana
On Thu, Sep 26, 2013 at 1:39 PM, Jesse wrote:
> What does a watch mean?
> - if I reboot, is it still watched?
>
No, this would start a process that lives until you CTRL+C. You could have
it run it in the background, or set it to start of startup, but that would
be using local system tools, not
Not sure how Android button labels work, but for Cordova iOS InAppBrowser I
got away with unicode arrows:
https://github.com/apache/cordova-plugin-inappbrowser/blob/b4059a2c683c486f1fb48b182ceb9a48fbc59f6e/src/ios/CDVInAppBrowser.m#L477-L485
On Tue, Sep 24, 2013 at 9:41 AM, Joe Bowser wrote:
>
On Thu, Sep 26, 2013 at 2:03 PM, Carlos Santana wrote:
> I think we can do something outside cordova in grunt using the
> grunt-contrib-watch plugin in user land.
>
Agreed. I think watch command should leverage grunt, and is just a future
value-add on top of cordova-cli base functionality. This
thank you
On Thu, Sep 26, 2013 at 2:18 PM, Jesse wrote:
> pushed!
>
> @purplecabbage
> risingj.com
>
>
> On Thu, Sep 26, 2013 at 11:07 AM, Carlos Santana >wrote:
>
> > Can someone review this proposed fix?
> >
> > https://github.com/apache/cordova-plugin-inappbrowser/pull/4
> >
> > https://iss
Thank you Lucas
On Thu, Sep 26, 2013 at 2:26 PM, Lucas Holmquist wrote:
> i have the ZTE Open, i might be able to take a look at that issue
> On Sep 25, 2013, at 9:39 AM, Carlos Santana wrote:
>
> > I worked with Jesse on Windows8 with exec.js because it was causing a
> > memory leak.
> >
> >
I would suggest perhaps a simpler approach, which doesn't add anything new
to cordova-cli/plugman:
- Each plugin ships with a "tests" js-module, and we document a convention
of where they should live, and what signature it should have (i.e.,
cordova.require('plugin.name.Tests').forEach(...) ).
-
i have the ZTE Open, i might be able to take a look at that issue
On Sep 25, 2013, at 9:39 AM, Carlos Santana wrote:
> I worked with Jesse on Windows8 with exec.js because it was causing a
> memory leak.
>
> Can someone with a firefoxos phone double check that the problem is present
> also on t
pushed!
@purplecabbage
risingj.com
On Thu, Sep 26, 2013 at 11:07 AM, Carlos Santana wrote:
> Can someone review this proposed fix?
>
> https://github.com/apache/cordova-plugin-inappbrowser/pull/4
>
> https://issues.apache.org/jira/browse/CB-4926
>
> --
> Carlos Santana
>
>
Branden
Yes I agree with you, I think we are on the same page.
Maybe I got confuse about "defaults.xml" and "A **totally different file**
with the same name is also generated by the
CLI"
my bad
On Thu, Sep 26, 2013 at 2:12 PM, Braden Shepherdson wrote:
> I don't understand at all what you're
I don't understand at all what you're suggesting. Nobody is proposing
adding any new files.
We have a bug filed to remove the unused accidental duplicates, other than
that I don't think much is going to change here. At least we'd need a
compelling reason to be moving and renaming files. In the non
Can someone review this proposed fix?
https://github.com/apache/cordova-plugin-inappbrowser/pull/4
https://issues.apache.org/jira/browse/CB-4926
--
Carlos Santana
we have one config.xml today lets keep it but lets not add a different file
with same name config.xml in a different location.
maybe I got completely lost in your explanation, sorry :-(
On Thu, Sep 26, 2013 at 2:01 PM, Braden Shepherdson wrote:
> I'm not sure which file you're suggesting that w
I think we can do something outside cordova in grunt using the
grunt-contrib-watch plugin in user land.
If after a while there is a compelling reason to add some portion or
lessons learned to cordova then it can be expose to users.
Also there is the possibility of star experimenting just for cor
I'm not sure which file you're suggesting that we rename. We have talked in
the past about moving the top-level one out of www and calling it app.xml
or similar. I don't think there are any plans to rename the
platform-specific ones.
Braden
On Thu, Sep 26, 2013 at 1:59 PM, Carlos Santana wrote:
maybe a new file cordova.xml for CLI scenario?
On Thu, Sep 26, 2013 at 1:40 PM, Braden Shepherdson wrote:
> This discussion is getting a little tangled, with CLI and not-CLI and so
> on. I'm trying to bring together the current situation:
>
> In CLI: there is a top level myproject/www/config.xml
Just one comment: if I understand this feature correctly, it watches the
top-level www folder and will copy any updated files into the platform files.
My issue with this is that I typically create the project, add the platform
(iOS in my case) and then load the Xcode project. And what is shown
This discussion is getting a little tangled, with CLI and not-CLI and so
on. I'm trying to bring together the current situation:
In CLI: there is a top level myproject/www/config.xml. This file is
*accidentally* copied into www/config.xml in each platform.
A **totally different file** with the sa
What does a watch mean?
- if I reboot, is it still watched?
I think it would be best to consider separating development from packaging
in your use-case for workflow.
If I am going to develop featureX as a plugin I would :
1. create a project for a single cordova platform, and develop the feature
On Thu Sep 26 11:32 AM, Carlos Santana wrote:
> Branden,
>"On Android, it's really easy to load XML files from res/xml/foo.xml, so
> that's
> where we put it."
>
> Easy for who?
> I think is difficult for web developer to not find it in www/config.xml and
> start
> searching for it
>
But c
I also agree to keep a single config.xml and the content as it is today
(not to have platform sections)
just document which one to edit and where is located for the two scenarios
(CLI and not-CLI)
On Thu, Sep 26, 2013 at 1:28 PM, Jonathan Bond-Caron <
jbo...@gdesolutions.com> wrote:
> On Thu S
On Thu Sep 26 10:18 AM, Braden Shepherdson wrote:
> I am strongly opposed to splitting into one file per platform. We want to
> support
> tags in config.xml, which will allow platform-specific content
> within
> the single config.xml.
>
+1, a single configuration file not in the www/ folder
It would be even nicer if any of the platforms we support had APIs to
change the 'volume' of the vibration. :(
@purplecabbage
risingj.com
On Thu, Sep 26, 2013 at 9:58 AM, Brian LeRoux wrote:
> Would be great to get our plugins aligned with the latest specs. (And now
> that we have independent
I love the idea of a watch command.
On Thu, Sep 26, 2013 at 4:48 PM, Anis KADRI wrote:
> Forgot about the existence of --link for a second. I think this is a
> good solution (not temporary). watch can be an enhancement to this
> solution. This might get people like Joe Bowser and other people w
Would be great to get our plugins aligned with the latest specs. (And now
that we have independent revisiting we can!)
On Thu, Sep 26, 2013 at 4:26 PM, Lisa Seacat DeLuca wrote:
> FYI, the w3c Device API's Working Group is discussing the idea of adding
> strength to the vibration command. more
I agree with Jesse proposal.
1. Clean up ghost copies of config.xml
2. Document a single Table in docs/config_ref_index.md.html
Two columns "CLI", "Not CLI" location of config.xml to be edit by user
--Carlos
On Thu, Sep 26, 2013 at 12:03 PM, Jesse wrote:
> Personally, when I refer to the www
I agree 100% with you Joe "enabling developers to make apps that don't suck"
And "can slow down the PluginManager and make Cordova slower"
Just saying "because is really easy" is sounded a little bit odd to be the
ONLY reason.
But a performance hit is a very good reason to not include the file at
On Thu, Sep 26, 2013 at 8:32 AM, Carlos Santana wrote:
> Branden,
>"On Android, it's really easy to load XML files from res/xml/foo.xml,
> so that's where we put it."
>
> Easy for who?
Easy for anyone who has to actually maintain this. We have to do this
on startup, and adding extra code to
Personally, when I refer to the www folder I am referring to the folder as
part of the app package at runtime, which is usually the same as the device
specific project layout.
iOS: AppRoot/www
wp7: AppRoot/www
wp8: AppRoot/www
windows8: AppRoot/www
Android: AppRoot/assets/www ?
The fact that even
On Thu, Sep 26, 2013 at 8:53 AM, Lindsey Simon wrote:
>
> When you say www are you referring to project/www or
> project/platform/android/assets/www?
>
That's the kicker, isn't it? If you're using the CLI, we're talking
project/www, but not everyone uses the CLI, or should use the CLI. I
think
On Thu, Sep 26, 2013 at 8:32 AM, Carlos Santana wrote:
> Branden,
>"On Android, it's really easy to load XML files from res/xml/foo.xml,
> so that's where we put it."
>
> Easy for who?
> I think is difficult for web developer to not find it in www/config.xml and
> start searching for it
>
> I
I too am opposed to splitting up into multiple files.
The existing config.xml should already be usable cross device without
change.
BlackBerry needs to make a small change to add it's own param.name, and
plugman needs to be aware of all the available targets and combine the
output from m
Branden,
"On Android, it's really easy to load XML files from res/xml/foo.xml,
so that's where we put it."
Easy for who?
I think is difficult for web developer to not find it in www/config.xml and
start searching for it
I don't know much about Android so maybe I'm putting my foot in my mouth
b
On Thu, Sep 26, 2013 at 11:03 AM, Joe Bowser wrote:
> On Thu, Sep 26, 2013 at 7:18 AM, Braden Shepherdson
> wrote:
> > I am strongly opposed to splitting into one file per platform. We want to
> > support tags in config.xml, which will allow platform-specific
> > content within the single confi
On Thu, Sep 26, 2013 at 7:18 AM, Braden Shepherdson wrote:
> I am strongly opposed to splitting into one file per platform. We want to
> support tags in config.xml, which will allow platform-specific
> content within the single config.xml.
Agreed. I'm not sure if Android actually supports this.
Forgot about the existence of --link for a second. I think this is a
good solution (not temporary). watch can be an enhancement to this
solution. This might get people like Joe Bowser and other people who
do native dev to give cordova-cli a try (only maybe though).
On Thu, Sep 26, 2013 at 4:25 PM,
Here's an off-the-top-of-my-head sketch of how we might do Voltron tests:
- Add a tag to plugin.xml that names each test file:
- Add a new command, cordova test (maybe prepare-test), that:
- Ignores the top-level www.
- Instead copies in a basic testing index.html similar to the
FYI, the w3c Device API's Working Group is discussing the idea of adding
strength to the vibration command. more information can be found here:
http://www.w3.org/2009/dap/track/issues/146
Does anyone here have any opinion one way or another on this change and
how it might affect our cordova v
If the proposal above is temporary, what's permanent? cordova watch? I want
to make sure we're on the same page.
Braden
On Thu, Sep 26, 2013 at 6:08 AM, Anis KADRI wrote:
> No I didn't mean implement `plugman --watch`. I don't think plugman
> needs a `watch` command.
>
> I was indeed talking a
I am strongly opposed to splitting into one file per platform. We want to
support tags in config.xml, which will allow platform-specific
content within the single config.xml.
There are good reasons why the CLI moves the config.xml on some platforms.
On Android, it's really easy to load XML files
I like the idea can we call mobilespec now cordova-voltron and be DRY and
use the tests form the plugins.
Voltron by itself creates an App that tests only core, but as you
use plugman to add plugins to voltron it has more test cases.
It would not be a bad idea to enhance plugin.xml in the future
TL;DR:
You decided it was easier to ask for forgiveness than permission ;)
On 25 Sep 2013 04:49, "Braden Shepherdson" wrote:
> I get the impression that "talking about it internally" came out wrong.
> Here's what actually happened:
>
> - I started out to fix some bugs, including killing use of s
No I didn't mean implement `plugman --watch`. I don't think plugman
needs a `watch` command.
I was indeed talking about `cordova watch` which should watch for
changes in plugins/ (and maybe in merges/ and www/ as well) and update
the platform projects (prepare?) on every change. I am happy to kno
What's the challenge of having us use the tests that come with the
individual plugins ?
On Thu, Sep 26, 2013 at 8:13 AM, David Kemp wrote:
> Currently, the automated test system that we have running (derived from
> Medic) uses only the mobilespec tests. It does not yet use tests collected
> from
Sweet! Thanks Steve! Hopefully I didn't break anything :-S
On Thu, Sep 26, 2013 at 8:24 AM, Steven Gill wrote:
> I have merged the dev branches into master on my machine and tagged all of
> the plugins. I am planning on merging this into master tomorrow if no one
> has any issues.
>
> I will also
79 matches
Mail list logo
