Re: [iOS] Keyboard Preferences - move to a plugin for 3.2.0

[Shazron]

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'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-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 until after 3.1 to rip it out.
> > >
> > >
> > > On Wed, Sep 25, 2013 at 2:22 AM, James Jong 
> > wrote:
> > >
> > > > +1 Separating this from the core into a plugin is a good idea.
> > > >
> > > > Not sure that this fits into any existing plugin though.
> > > >
> > > > -James Jong
> > > >
> > > > On Sep 24, 2013, at 2:37 PM, Shazron  wrote:
> > > >
> > > > > Issue: https://issues.apache.org/jira/browse/CB-3020
> > > > >
> > > > > I've got it mostly working but I'm thinking this really should move
> > to
> > > a
> > > > > plugin, perhaps reside in an existing one?
> > > > >
> > > > > The things we are doing with hiding the keyboard accessory bar and
> > > > > shrinking the view etc are hackish and might break with any iOS
> > update,
> > > > and
> > > > > imo fixes should not be tied to a core release.
> > > > >
> > > > > My proposal is to move the code for the two keyboard preferences
> to a
> > > > > plugin.
> > > >
> > > >
> > >
> >
>

Re: About plugins in 3.1

[Steven Gill]

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 think there's much use in changing instructions to install from
> git+tag urls when the registry exists anyways. The registry has
> 3.0-compatible plugins in it, so that's a better solution.
>
> I do think we should wait some time before making the switch to developing
> on master (and deleting the dev branches), since it'll take some time to
> get the word out. There's even been some tools (yeoman & the like) that
> have been written that hardcode in the git URLs.
>
> Definitely excited about this though! So much nicer!
>
>
> On Tue, Sep 17, 2013 at 5:20 PM, Anis KADRI  wrote:
>
> > @maxw: done!
> >
> > On Tue, Sep 17, 2013 at 1:55 PM, Shazron  wrote:
> > > @Anis yeah this could be a documentation issue. We will have to update
> > the
> > > 3.0.0 specific docs.
> > >
> > >
> > > On Tue, Sep 17, 2013 at 1:35 PM, Anis KADRI 
> > wrote:
> > >
> > >> @maxw Did you create a user account with plugman adduser ? I do not
> > >> see you in the users' list.
> > >>
> > >> Shazron: Very good point. We can always instruct those users to clone
> > >> a 3.0.0 compatible branch from the repositories and install that.
> > >> Maybe we can even update the tools to add the ability to clone from
> > >> any branch (or maybe it's in there already ? I know it's in there for
> > >> dependencies).
> > >>
> > >> On Tue, Sep 17, 2013 at 1:30 PM, Shazron  wrote:
> > >> > I'm all for using master as the branch that we do development on,
> but
> > if
> > >> we
> > >> > switch, that will mean anyone on existing cordova v3.0.0 will get
> > broken
> > >> > plugins, correct?
> > >> >
> > >> >
> > >> > On Tue, Sep 17, 2013 at 1:25 PM, Steven Gill <
> stevengil...@gmail.com>
> > >> wrote:
> > >> >
> > >> >> What would the command look like to install it if we aren't using
> git
> > >> urls?
> > >> >> cordova plugin add camera? Would it automatically take the latest
> > >> version
> > >> >> off the registery?
> > >> >>
> > >> >> I like the idea of working on master and tagging a plugin when it
> is
> > >> ready
> > >> >> to be published.
> > >> >>
> > >> >>
> > >> >>
> > >> >>
> > >> >> On Tue, Sep 17, 2013 at 1:21 PM, Anis KADRI 
> > >> wrote:
> > >> >>
> > >> >> > As far as I understand and following this documentation:
> > >> >> >
> > >> >> >
> > >> >> >
> > >> >>
> > >>
> >
> http://cordova.apache.org/docs/en/3.0.0/guide_cli_index.md.html#The%20Command-line%20Interface
> > >> >> >
> > >> >> > Plugins are currently fetched using git from origin/master. It
> is a
> > >> >> > major problem in my opinion. The main reason (but there are many)
> > is
> > >> >> > that any commit to master can potentially break plugins. Yes, we
> > can
> > >> >> > do a dev branch but some people are forgetful and might commit to
> > >> >> > master anyway. I think the proper development process for plugins
> > >> >> > should be:
> > >> >> > - Always commit to master
> > >> >> > - When you're ready to release a plugin: update the version, tag
> it
> > >> >> > and publish it to the cordova registry.
> > >> >> > - Users can then install the latest version without having to
> > remember
> > >> >> > a git URL and without worrying about getting a broken plugin.
> > >> >> >
> > >> >> > Ideally, every Cordova committer should be granted the right to
> > >> >> > publish to the registry. Right now, I've only added Andrew Grieve
> > (who
> > >> >> > is having issues publishing atm...). If anybody wants to be
> added,
> > let
> > >> >> > me know.
> > >> >> >
> > >> >> > Does that sound good to everyone?
> > >> >> >
> > >> >> > -a
> > >> >> >
> > >> >>
> > >>
> >
>

Re: Updating plugin code on prepare

[Ian Clelland]

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 am not even sure we can make
> Xcode aware of cordova-cli. We've already talked about this prior to
> the 3.0 release and that is why we have the create scripts and plugman
> approach. You should not be using cordova-cli either if you're doing
> some custom native dev that can't be pluginized (changing the main
> Activity.java or AppDelegate.m or whatever). If you're using
> cordova-cli just to create a project and then open an IDE to develop,
> you're probably doing it wrong. You should be creating a native
> project and using plugman instead.
>
>
Oh, man, I'm definitely doing it wrong :)

I'm almost always using the CLI to create projects, and then opening the
platform projects in Eclipse or XCode to run them. When I update code, I
run prepare, and refresh in the IDE before running again. (In XCode, I
generally don't even need to refresh; it just knows when the files have
changed.)

I don't mind using the IDE for debugging if (when) things don't work -- but
I know that all of the assets are ephemeral, and that I need to make the
*real* fixes outside of the platforms directory.

I hope that eventually we can have 'cordova prepare' just be part of the
build step in the IDEs, and let people just edit the master files in www/
and build from there with the IDE, but I think we're a long way from there.
Until then, the IDE is occasionally critical for debugging, even on a CLI
project (wrong as it is ;) )

Ian

Re: [iOS] Keyboard Preferences - move to a plugin for 3.2.0

[Brian LeRoux]

+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 
> wrote:
>
> > 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 until after 3.1 to rip it out.
> >
> >
> > On Wed, Sep 25, 2013 at 2:22 AM, James Jong 
> wrote:
> >
> > > +1 Separating this from the core into a plugin is a good idea.
> > >
> > > Not sure that this fits into any existing plugin though.
> > >
> > > -James Jong
> > >
> > > On Sep 24, 2013, at 2:37 PM, Shazron  wrote:
> > >
> > > > Issue: https://issues.apache.org/jira/browse/CB-3020
> > > >
> > > > I've got it mostly working but I'm thinking this really should move
> to
> > a
> > > > plugin, perhaps reside in an existing one?
> > > >
> > > > The things we are doing with hiding the keyboard accessory bar and
> > > > shrinking the view etc are hackish and might break with any iOS
> update,
> > > and
> > > > imo fixes should not be tied to a core release.
> > > >
> > > > My proposal is to move the code for the two keyboard preferences to a
> > > > plugin.
> > >
> > >
> >
>

RE: 2.9.0 Support

[Brian LeRoux]

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 will continue to support 2.x in a
> long lived branch."
> http://phonegap.com/blog/2013/06/20/coming-soon-phonegap30/
>
> At the time it seemed quite clear there would be a 2.9.1, but now it is
> not clear at all...
>
> Peter
>
> -Original Message-
> From: mmo...@google.com [mailto:mmo...@google.com] On Behalf Of Michal
> Mocny
> Sent: Friday, 27 September 2013 5:24 AM
> To: dev; bows...@apache.org
> Subject: Re: 2.9.0 Support
>
> 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 users say when you suggest moving to 3.x to get the bugfix?
>
> -Michal
>
>
> On Thu, Sep 26, 2013 at 3:09 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 probably should be
> > backporting to 2.9.
> >
> > Have people been doing this.  I've been doing this a bit, but I have
> > to admit that I've been slipping up recently.  What are people's
> > thoughts on this?
> >
> > Joe
> >
>
>

Re: 2.9.0 Support

[Brian LeRoux]

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 probably should be
> backporting to 2.9.
>
> Have people been doing this.  I've been doing this a bit, but I have
> to admit that I've been slipping up recently.  What are people's
> thoughts on this?
>
> Joe
>

Re: 2.9.0 Support

[Ian Clelland]

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 think, though, that as
long as the codebases haven't diverged *so much* (as in a complete re-write
of a given plugin), that we should at least take the time to verify the
issue -- and the fix -- on 2.9, and release 2.9.x versions when it makes
sense.

If we stick with the idea that bugs are testable, and keep all of the tests
in mobile-spec, then hopefully it shouldn't be much more work to run any
new tests against the current 2.9.x before and after applying a patch that
fixes is in 3.x.

Ian

On Thu, Sep 26, 2013 at 3:09 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 probably should be
> backporting to 2.9.
>
> Have people been doing this.  I've been doing this a bit, but I have
> to admit that I've been slipping up recently.  What are people's
> thoughts on this?
>
> Joe

Re: Review Request 14356: Plugins Release draft blog post

[Steven Gill]

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

Updated other errors that I found


Repository: cordova-site


Description
---

I think you have to download the diff. Having a tough time getting it to upload 
properly. This is the blog post for plugins release. Blog post is at the bottom 
of the diff. 


Diffs (updated)
-

  /public/artwork.html 1526343 
  /public/blog/index.html 1526343 
  /public/index.html 1526343 
  /public/rss.xml 1526343 
  /www/_posts/2013-09-26-plugins-release.md PRE-CREATION 

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


Testing
---


Thanks,

Steven Gill

Re: Review Request 14356: Plugins Release draft blog post

[Steven Gill]

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

Fixed spelling mistakes


Repository: cordova-site


Description
---

I think you have to download the diff. Having a tough time getting it to upload 
properly. This is the blog post for plugins release. Blog post is at the bottom 
of the diff. 


Diffs (updated)
-

  /public/artwork.html 1526343 
  /public/blog/index.html 1526343 
  /public/index.html 1526343 
  /public/rss.xml 1526343 
  /www/_posts/2013-09-26-plugins-release.md PRE-CREATION 

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


Testing
---


Thanks,

Steven Gill

Re: Plugins Release blog post

[Steven Gill]

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:

> 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 plugin IDs and ourplugin 
> registery for
> plugin installation instead of directly installing from the plugin git urls.
>
> These plugins are compatitable with Cordova 3.0.0. Feel free to upgrade
> your current plugins if you can’t wait for 3.1.0 next week. Keep in mind
> that after you install these update plugins, if you decide to remove these
> plugins from your project, you will have to reference the new IDs instead
> of the old ones that our docs show. Ex: ‘cordova rm
> org.apache.cordova.camera’ instead of ‘org.apache.cordova.core.camera’.
>
> *Other Notable Changes:*
>
>- Firefox OS support for Vibration and Device Plugin
>- Windows 8 support for multiple plugins
>- Fixed warnings that arose with XCode 5
>- CB-4847 iOS 7 microphone access requires user permission (media
>plugin)
>- CB-4799 Fix incorrect JS references within native code for iOS &
>Andrid (media plugin)
>- CB-4806 Update splashscreen image bounds for iOS 7 (splashscreen
>plugin)
>- CB-4593 Added vibration support for BB10 (vibration plugin)
>
> You can check out the individual release notes in each of the plugin repos
> for more details.
>
>
> On Thu, Sep 26, 2013 at 5:37 PM, Steven Gill wrote:
>
>> 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 permission to access the
>>> > repository in order to view this review request."
>>>
>>> Ya, same here
>>>
>>>
>>> On 26 September 2013 16:37, Shazron  wrote:
>>>
>>> > 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, 2013 at 4:30 PM, Steven Gill 
>>> > wrote:
>>> >
>>> > > Can you guys review it at https://reviews.apache.org/r/14356/
>>> > >
>>> > > I don't think post-review was working properly for me...
>>> > >
>>> >
>>>
>>>
>>>
>>> --
>>> Timothy Kim
>>>
>>
>

Re: [iOS] Keyboard Preferences - move to a plugin for 3.2.0

[Shazron]

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, Shazron  wrote:

> 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 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-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 until after 3.1 to rip it out.
>> >
>> >
>> > On Wed, Sep 25, 2013 at 2:22 AM, James Jong 
>> wrote:
>> >
>> > > +1 Separating this from the core into a plugin is a good idea.
>> > >
>> > > Not sure that this fits into any existing plugin though.
>> > >
>> > > -James Jong
>> > >
>> > > On Sep 24, 2013, at 2:37 PM, Shazron  wrote:
>> > >
>> > > > Issue: https://issues.apache.org/jira/browse/CB-3020
>> > > >
>> > > > I've got it mostly working but I'm thinking this really should move
>> to
>> > a
>> > > > plugin, perhaps reside in an existing one?
>> > > >
>> > > > The things we are doing with hiding the keyboard accessory bar and
>> > > > shrinking the view etc are hackish and might break with any iOS
>> update,
>> > > and
>> > > > imo fixes should not be tied to a core release.
>> > > >
>> > > > My proposal is to move the code for the two keyboard preferences to
>> a
>> > > > plugin.
>> > >
>> > >
>> >
>>
>
>

Review Request 14356: Plugins Release draft blog post

[Steven Gill]

---
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 think you have to download the diff. Having a tough time getting it to upload 
properly. This is the blog post for plugins release. Blog post is at the bottom 
of the diff. 


Diffs
-

  /public/artwork.html 1526343 
  /public/blog/index.html 1526343 
  /public/index.html 1526343 
  /public/rss.xml 1526343 
  /www/_posts/2013-09-26-plugins-release.md PRE-CREATION 

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


Testing
---


Thanks,

Steven Gill

Re: Updating plugin code on prepare

[Tyler Wilson]

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.

Now I know how to create a project for each platform the old bin/create way, 
but then it is unclear how to use the plugins. I looked in the console plugin 
and the README.md file says to read the "Using Plugman to Manage Plugins" with 
a URL of 
"http://cordova.apache.org/docs/en/edge/guide_plugin_ref_plugman.md.html"; which 
does not point to anything.

Perhaps a note in the download that people that want the non-CLI version should 
download the 2.9.0 version, which as I recall still contains the core plugins 
people might need/want.

Thanks,
Tyler


On Sep 26, 2013, at 8:19 PM, Tyler Wilson  wrote:

> 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 
> by Xcode. And you definitely should not edit code within the IDE".
> 
> I just went to the main documentation site here - 
> http://cordova.apache.org/docs/en/3.0.0/guide_overview_index.md.html#Overview 
> - and it appears it only mentions the new CLI interface. No mention of the 
> old bin/create method. Seems to me there may be communication problem here.
> 
> Thanks,
> Tyler
> 
> On Sep 26, 2013, at 6:11 PM, Anis KADRI  wrote:
> 
>> @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) from day 1 and one can only focus on
>> development.
>> 
>> 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 am not even sure we can make
>> Xcode aware of cordova-cli. We've already talked about this prior to
>> the 3.0 release and that is why we have the create scripts and plugman
>> approach. You should not be using cordova-cli either if you're doing
>> some custom native dev that can't be pluginized (changing the main
>> Activity.java or AppDelegate.m or whatever). If you're using
>> cordova-cli just to create a project and then open an IDE to develop,
>> you're probably doing it wrong. You should be creating a native
>> project and using plugman instead.
>> 
>> On Thu, Sep 26, 2013 at 9:01 PM, Michal Mocny  wrote:
>>> 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 part of the command itself.
>>> 
>>> Ideally, "watch" should run "prepare" whenever you would have wanted it to.
>>> Though obviously that cannot be perfect, it can be a useful tool when
>>> iterating.
>>> 
>>> 
 
 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
 as a native piece, and a js piece.
 2. test thoroughly
 3. create a project for a second cordova platform, and develop the native
 bit, preserving the js from 1
 4. test thoroughly
 5. repeat steps 3+4 for any remaining platforms
 6. package featureX as a plugin by organizing relevant bits in the correct
 folder structure, and adding a plugin.xml
 7. test each platform by installing with plugman
 8. publish
 
>>> 
>>> As a plugin developer, that is not my workflow.
>>> 
>>> Typically for me its:
>>> 
>>> Write a sample app/manual test for some new feature that isn't implemented
>>> yet.
>>> Create a new plugin Foo for iOS & Android, and stub the implementation.
>>> Implement feature A of plugin Foo for iOS, test, add it for Android, test.
>>> Implement feature B of plugin Foo for iOS, test, add it for Android, test.
>>> ...
>>> 
>>> Usually the js implementation is shared, the auto tests are shared, and the
>>> sample test app is shared.
>>> 
>>> Sure, I do platform specific stuff for testing and implementation, but I
>>> certainly wouldn't say I do plugin development in platform isolation.
>>> 
>>> Also, right now we do not have a "plugin create" command, and so leaving
>>> the "packaging" step for last doesn't add affect total 

Re: Plugins Release blog post

[Steven Gill]

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 plugin IDs and ourplugin
registery for
plugin installation instead of directly installing from the plugin git urls.

These plugins are compatitable with Cordova 3.0.0. Feel free to upgrade
your current plugins if you can’t wait for 3.1.0 next week. Keep in mind
that after you install these update plugins, if you decide to remove these
plugins from your project, you will have to reference the new IDs instead
of the old ones that our docs show. Ex: ‘cordova rm
org.apache.cordova.camera’ instead of ‘org.apache.cordova.core.camera’.

*Other Notable Changes:*

   - Firefox OS support for Vibration and Device Plugin
   - Windows 8 support for multiple plugins
   - Fixed warnings that arose with XCode 5
   - CB-4847 iOS 7 microphone access requires user permission (media plugin)
   - CB-4799 Fix incorrect JS references within native code for iOS &
   Andrid (media plugin)
   - CB-4806 Update splashscreen image bounds for iOS 7 (splashscreen
   plugin)
   - CB-4593 Added vibration support for BB10 (vibration plugin)

You can check out the individual release notes in each of the plugin repos
for more details.


On Thu, Sep 26, 2013 at 5:37 PM, Steven Gill  wrote:

> 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 permission to access the
>> > repository in order to view this review request."
>>
>> Ya, same here
>>
>>
>> On 26 September 2013 16:37, Shazron  wrote:
>>
>> > 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, 2013 at 4:30 PM, Steven Gill 
>> > wrote:
>> >
>> > > Can you guys review it at https://reviews.apache.org/r/14356/
>> > >
>> > > I don't think post-review was working properly for me...
>> > >
>> >
>>
>>
>>
>> --
>> Timothy Kim
>>
>

Re: Plugins Release blog post

[Steven Gill]

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 permission to access the
> > repository in order to view this review request."
>
> Ya, same here
>
>
> On 26 September 2013 16:37, Shazron  wrote:
>
> > 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, 2013 at 4:30 PM, Steven Gill 
> > wrote:
> >
> > > Can you guys review it at https://reviews.apache.org/r/14356/
> > >
> > > I don't think post-review was working properly for me...
> > >
> >
>
>
>
> --
> Timothy Kim
>

RE: 2.9.0 Support

[Smith, Peter]

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/blog/2013/06/20/coming-soon-phonegap30/

At the time it seemed quite clear there would be a 2.9.1, but now it is
not clear at all...
 
Peter

-Original Message-
From: mmo...@google.com [mailto:mmo...@google.com] On Behalf Of Michal
Mocny
Sent: Friday, 27 September 2013 5:24 AM
To: dev; bows...@apache.org
Subject: Re: 2.9.0 Support

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 users say when you suggest moving to 3.x to get the bugfix?

-Michal


On Thu, Sep 26, 2013 at 3:09 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 probably should be 
> backporting to 2.9.
>
> Have people been doing this.  I've been doing this a bit, but I have 
> to admit that I've been slipping up recently.  What are people's 
> thoughts on this?
>
> Joe
>

Re: Updating plugin code on prepare

[Tyler Wilson]

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 by Xcode. And you 
definitely should not edit code within the IDE".

I just went to the main documentation site here - 
http://cordova.apache.org/docs/en/3.0.0/guide_overview_index.md.html#Overview - 
and it appears it only mentions the new CLI interface. No mention of the old 
bin/create method. Seems to me there may be communication problem here.

Thanks,
Tyler

On Sep 26, 2013, at 6:11 PM, Anis KADRI  wrote:

> @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) from day 1 and one can only focus on
> development.
> 
> 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 am not even sure we can make
> Xcode aware of cordova-cli. We've already talked about this prior to
> the 3.0 release and that is why we have the create scripts and plugman
> approach. You should not be using cordova-cli either if you're doing
> some custom native dev that can't be pluginized (changing the main
> Activity.java or AppDelegate.m or whatever). If you're using
> cordova-cli just to create a project and then open an IDE to develop,
> you're probably doing it wrong. You should be creating a native
> project and using plugman instead.
> 
> On Thu, Sep 26, 2013 at 9:01 PM, Michal Mocny  wrote:
>> 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 part of the command itself.
>> 
>> Ideally, "watch" should run "prepare" whenever you would have wanted it to.
>> Though obviously that cannot be perfect, it can be a useful tool when
>> iterating.
>> 
>> 
>>> 
>>> 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
>>> as a native piece, and a js piece.
>>> 2. test thoroughly
>>> 3. create a project for a second cordova platform, and develop the native
>>> bit, preserving the js from 1
>>> 4. test thoroughly
>>> 5. repeat steps 3+4 for any remaining platforms
>>> 6. package featureX as a plugin by organizing relevant bits in the correct
>>> folder structure, and adding a plugin.xml
>>> 7. test each platform by installing with plugman
>>> 8. publish
>>> 
>> 
>> As a plugin developer, that is not my workflow.
>> 
>> Typically for me its:
>> 
>> Write a sample app/manual test for some new feature that isn't implemented
>> yet.
>> Create a new plugin Foo for iOS & Android, and stub the implementation.
>> Implement feature A of plugin Foo for iOS, test, add it for Android, test.
>> Implement feature B of plugin Foo for iOS, test, add it for Android, test.
>> ...
>> 
>> Usually the js implementation is shared, the auto tests are shared, and the
>> sample test app is shared.
>> 
>> Sure, I do platform specific stuff for testing and implementation, but I
>> certainly wouldn't say I do plugin development in platform isolation.
>> 
>> Also, right now we do not have a "plugin create" command, and so leaving
>> the "packaging" step for last doesn't add affect total work.  But once we
>> do have such a command, plugins could start packaged, and adding the small
>> changes to plugin.xml as you need them is likely a good way to go.
>> 
>> Finally, this workflow would get people out of the habit of making changes
>> to the platform artifacts directly.  I'm not sure that can be entirely
>> avoided in all cases, but why shouldn't we work towards making that easier?
>> 
>> 
>>> We seem to have this notion come up repeatedly that our users + plugin
>>> developers are working on multiple platforms at the same time, which I
>>> think is entirely false.
>>> 
>> 
>> Since we differ in opinion, how can we put this to the test?
>> 
>> Also, we specifically make sure all our features address the needs of those
>> doing single platform development, so in a world of 3.0+ cli, I really
>> don't see how we can not do the same to address the needs of those who do
>> do multi-platform development, especially when we have a good proposal of
>> how to do so and someone willing to d

Re: Plugins Release blog post

[Tim Kim]

>
> "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, Shazron  wrote:

> 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, 2013 at 4:30 PM, Steven Gill 
> wrote:
>
> > Can you guys review it at https://reviews.apache.org/r/14356/
> >
> > I don't think post-review was working properly for me...
> >
>



-- 
Timothy Kim

Re: [iOS] Keyboard Preferences - move to a plugin for 3.2.0

[Shazron]

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 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-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 until after 3.1 to rip it out.
> >
> >
> > On Wed, Sep 25, 2013 at 2:22 AM, James Jong 
> wrote:
> >
> > > +1 Separating this from the core into a plugin is a good idea.
> > >
> > > Not sure that this fits into any existing plugin though.
> > >
> > > -James Jong
> > >
> > > On Sep 24, 2013, at 2:37 PM, Shazron  wrote:
> > >
> > > > Issue: https://issues.apache.org/jira/browse/CB-3020
> > > >
> > > > I've got it mostly working but I'm thinking this really should move
> to
> > a
> > > > plugin, perhaps reside in an existing one?
> > > >
> > > > The things we are doing with hiding the keyboard accessory bar and
> > > > shrinking the view etc are hackish and might break with any iOS
> update,
> > > and
> > > > imo fixes should not be tied to a core release.
> > > >
> > > > My proposal is to move the code for the two keyboard preferences to a
> > > > plugin.
> > >
> > >
> >
>

Re: Plugins Release blog post

[Shazron]

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, 2013 at 4:30 PM, Steven Gill  wrote:

> Can you guys review it at https://reviews.apache.org/r/14356/
>
> I don't think post-review was working properly for me...
>

Plugins Release blog post

[Steven Gill]

Can you guys review it at https://reviews.apache.org/r/14356/

I don't think post-review was working properly for me...

Re: review code CB-4934 plugin-splashscreen stays up on windows8

[Jesse]

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-splashscreen/pull/5
>
>
> --
> Carlos Santana
> 
>

Re: Updating plugin code on prepare

[Anis KADRI]

@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) from day 1 and one can only focus on
development.

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 am not even sure we can make
Xcode aware of cordova-cli. We've already talked about this prior to
the 3.0 release and that is why we have the create scripts and plugman
approach. You should not be using cordova-cli either if you're doing
some custom native dev that can't be pluginized (changing the main
Activity.java or AppDelegate.m or whatever). If you're using
cordova-cli just to create a project and then open an IDE to develop,
you're probably doing it wrong. You should be creating a native
project and using plugman instead.

On Thu, Sep 26, 2013 at 9:01 PM, Michal Mocny  wrote:
> 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 part of the command itself.
>
> Ideally, "watch" should run "prepare" whenever you would have wanted it to.
>  Though obviously that cannot be perfect, it can be a useful tool when
> iterating.
>
>
>>
>> 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
>> as a native piece, and a js piece.
>> 2. test thoroughly
>> 3. create a project for a second cordova platform, and develop the native
>> bit, preserving the js from 1
>> 4. test thoroughly
>> 5. repeat steps 3+4 for any remaining platforms
>> 6. package featureX as a plugin by organizing relevant bits in the correct
>> folder structure, and adding a plugin.xml
>> 7. test each platform by installing with plugman
>> 8. publish
>>
>
> As a plugin developer, that is not my workflow.
>
> Typically for me its:
>
> Write a sample app/manual test for some new feature that isn't implemented
> yet.
> Create a new plugin Foo for iOS & Android, and stub the implementation.
> Implement feature A of plugin Foo for iOS, test, add it for Android, test.
> Implement feature B of plugin Foo for iOS, test, add it for Android, test.
> ...
>
> Usually the js implementation is shared, the auto tests are shared, and the
> sample test app is shared.
>
> Sure, I do platform specific stuff for testing and implementation, but I
> certainly wouldn't say I do plugin development in platform isolation.
>
> Also, right now we do not have a "plugin create" command, and so leaving
> the "packaging" step for last doesn't add affect total work.  But once we
> do have such a command, plugins could start packaged, and adding the small
> changes to plugin.xml as you need them is likely a good way to go.
>
> Finally, this workflow would get people out of the habit of making changes
> to the platform artifacts directly.  I'm not sure that can be entirely
> avoided in all cases, but why shouldn't we work towards making that easier?
>
>
>> We seem to have this notion come up repeatedly that our users + plugin
>> developers are working on multiple platforms at the same time, which I
>> think is entirely false.
>>
>
> Since we differ in opinion, how can we put this to the test?
>
> Also, we specifically make sure all our features address the needs of those
> doing single platform development, so in a world of 3.0+ cli, I really
> don't see how we can not do the same to address the needs of those who do
> do multi-platform development, especially when we have a good proposal of
> how to do so and someone willing to do it.
>
>
>> I also think we're trying to help the wrong people; If I am a developer who
>> is working on multiple platforms at once, and I have a bunch of devices
>> attached, I probably also have the skills to set up my own grunt continuous
>> integration system. Setting up tooling for potential plugin developers is
>> the wrong approach, imho. We should actually just go and implement some new
>> plugin and evaluate the process instead of creating and imposing a specific
>> workflow.
>>
>
> The first part of this argument has some merit, I agree.  We the
> power-users have found ways to address our problems.  However, I think that
> with this change it means that even the end user can make changes to plugin
> folder as they find bugs/etc, and expect to see the change reflected after
> running prepare.  This is principle of least surpri

Re: Issue with FileTransfer plugin identifier [PR]

[Steven Gill]

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

The pull requests can be closed.

Cheers,
-Steve


On Thu, Sep 26, 2013 at 2:47 PM, Michael Gauthier wrote:

> 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 tomorrow, make sure you have signed the
>> ICLA 
>> (http://www.apache.org/**licenses/#clas)
>> since It looks like you have
>> not.
>>
>> Thanks!
>> -Michal
>>
>>
>> On Thu, Sep 26, 2013 at 4:51 PM, Michael Gauthier > >wrote:
>>
>>  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 Issue.
>>>
>>> Can someone take a look and approve/reject them?
>>>
>>> https://github.com/apache/cordova-plugin-file/pull/6
>>> https://github.com/apache/cordova-plugin-file/pull/6>
>>> >
>>> https://github.com/apache/cordova-plugin-file-transfer/pull/7
>>> 
>>> >
>>>
>>>
>>> Thanks,
>>> Mike
>>>
>>>
>>
>

review code CB-4934 plugin-splashscreen stays up on windows8

[Carlos Santana]

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

Re: Issue with FileTransfer plugin identifier [PR]

[Michael Gauthier]

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 tomorrow, make sure you have signed the
ICLA (http://www.apache.org/licenses/#clas) since It looks like you have
not.

Thanks!
-Michal


On Thu, Sep 26, 2013 at 4:51 PM, Michael Gauthier wrote:


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

Can someone take a look and approve/reject them?

https://github.com/apache/**cordova-plugin-file/pull/6
https://github.com/apache/**cordova-plugin-file-transfer/**pull/7


Thanks,
Mike

Re: Issue with FileTransfer plugin identifier [PR]

[Michal Mocny]

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.

Thanks!
-Michal


On Thu, Sep 26, 2013 at 4:51 PM, Michael Gauthier wrote:

> 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 Issue.
>
> Can someone take a look and approve/reject them?
>
> https://github.com/apache/**cordova-plugin-file/pull/6
> https://github.com/apache/**cordova-plugin-file-transfer/**pull/7
>
>
> Thanks,
> Mike
>

Re: [iOS] Keyboard Preferences - move to a plugin for 3.2.0

[Michal Mocny]

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-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 until after 3.1 to rip it out.
>
>
> On Wed, Sep 25, 2013 at 2:22 AM, James Jong  wrote:
>
> > +1 Separating this from the core into a plugin is a good idea.
> >
> > Not sure that this fits into any existing plugin though.
> >
> > -James Jong
> >
> > On Sep 24, 2013, at 2:37 PM, Shazron  wrote:
> >
> > > Issue: https://issues.apache.org/jira/browse/CB-3020
> > >
> > > I've got it mostly working but I'm thinking this really should move to
> a
> > > plugin, perhaps reside in an existing one?
> > >
> > > The things we are doing with hiding the keyboard accessory bar and
> > > shrinking the view etc are hackish and might break with any iOS update,
> > and
> > > imo fixes should not be tied to a core release.
> > >
> > > My proposal is to move the code for the two keyboard preferences to a
> > > plugin.
> >
> >
>

Issue with FileTransfer plugin identifier [PR]

[Michael Gauthier]

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


Can someone take a look and approve/reject them?

https://github.com/apache/cordova-plugin-file/pull/6
https://github.com/apache/cordova-plugin-file-transfer/pull/7


Thanks,
Mike

Re: [iOS] Keyboard Preferences - move to a plugin for 3.2.0

[Andrew Grieve]

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 until after 3.1 to rip it out.


On Wed, Sep 25, 2013 at 2:22 AM, James Jong  wrote:

> +1 Separating this from the core into a plugin is a good idea.
>
> Not sure that this fits into any existing plugin though.
>
> -James Jong
>
> On Sep 24, 2013, at 2:37 PM, Shazron  wrote:
>
> > Issue: https://issues.apache.org/jira/browse/CB-3020
> >
> > I've got it mostly working but I'm thinking this really should move to a
> > plugin, perhaps reside in an existing one?
> >
> > The things we are doing with hiding the keyboard accessory bar and
> > shrinking the view etc are hackish and might break with any iOS update,
> and
> > imo fixes should not be tied to a core release.
> >
> > My proposal is to move the code for the two keyboard preferences to a
> > plugin.
>
>

Re: 2.9.0 Support

[Michal Mocny]

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 users say when you suggest moving to 3.x to get the bugfix?

-Michal


On Thu, Sep 26, 2013 at 3:09 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 probably should be
> backporting to 2.9.
>
> Have people been doing this.  I've been doing this a bit, but I have
> to admit that I've been slipping up recently.  What are people's
> thoughts on this?
>
> Joe
>

code review CB-4929 plguin-splashscreen not loading on windows8

[Carlos Santana]

Can someone review this?

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

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

-- 
Carlos Santana

RE: config.xml discussion, we need to talk

[Michael Sierra]

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 switch from CLI to an 
SDK workflow, you need to use these other files as source for iOS & Android:

  platforms/ios//config.xml
  platforms/android/res/www/config.xml

Question: Do any other platforms' SDK-ready config.xml files live elsewhere 
than what's generated by the CLI in `platforms/*/www/config.xml`? And if so, 
where so they live? Thanks

--Mike S




From: bra...@google.com [bra...@google.com] On Behalf Of Braden Shepherdson 
[bra...@chromium.org]
Sent: Thursday, September 26, 2013 1:40 PM
To: dev@cordova.apache.org
Subject: Re: config.xml discussion, we need to talk

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 same name is also generated by the
CLI, based on settings from the defaults.xml, plugin  edits,
and the top-level config.xml. This file is placed in
platforms/android/res/xml/config.xml on Android, in
platforms/ios/MyProject/config.xml on iOS, and other places.

I repeat, the platforms/android/res/xml/config.xml and
platforms/android/assets/www/config.xml are **different**.

It's the top-level www/config.xml that we want to give  tag
support to, so that you can set platform-specific things without editing
the config.xml files inside those platforms.

Not-CLI: Just the latter file, in eg. res/xml/config.xml. Edited by hand,
always specific to this platform.

As far as the standards, it's the latter, res/xml/config.xml, that sort-of
matches the widget spec. The top-level Cordova one doesn't, and we're
moving farther away with adding  tags.

Braden


On Thu, Sep 26, 2013 at 1:28 PM, Jonathan Bond-Caron <
jbo...@gdesolutions.com> wrote:

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

2.9.0 Support

[Joe Bowser]

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 admit that I've been slipping up recently.  What are people's
thoughts on this?

Joe

code review for CB-4928? plugin-media doesn't load on windows8 change AudioHandler. to media.

[Carlos Santana]

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

Re: Updating plugin code on prepare

[Michal Mocny]

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 part of the command itself.

Ideally, "watch" should run "prepare" whenever you would have wanted it to.
 Though obviously that cannot be perfect, it can be a useful tool when
iterating.


>
> 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
> as a native piece, and a js piece.
> 2. test thoroughly
> 3. create a project for a second cordova platform, and develop the native
> bit, preserving the js from 1
> 4. test thoroughly
> 5. repeat steps 3+4 for any remaining platforms
> 6. package featureX as a plugin by organizing relevant bits in the correct
> folder structure, and adding a plugin.xml
> 7. test each platform by installing with plugman
> 8. publish
>

As a plugin developer, that is not my workflow.

Typically for me its:

Write a sample app/manual test for some new feature that isn't implemented
yet.
Create a new plugin Foo for iOS & Android, and stub the implementation.
Implement feature A of plugin Foo for iOS, test, add it for Android, test.
Implement feature B of plugin Foo for iOS, test, add it for Android, test.
...

Usually the js implementation is shared, the auto tests are shared, and the
sample test app is shared.

Sure, I do platform specific stuff for testing and implementation, but I
certainly wouldn't say I do plugin development in platform isolation.

Also, right now we do not have a "plugin create" command, and so leaving
the "packaging" step for last doesn't add affect total work.  But once we
do have such a command, plugins could start packaged, and adding the small
changes to plugin.xml as you need them is likely a good way to go.

Finally, this workflow would get people out of the habit of making changes
to the platform artifacts directly.  I'm not sure that can be entirely
avoided in all cases, but why shouldn't we work towards making that easier?


> We seem to have this notion come up repeatedly that our users + plugin
> developers are working on multiple platforms at the same time, which I
> think is entirely false.
>

Since we differ in opinion, how can we put this to the test?

Also, we specifically make sure all our features address the needs of those
doing single platform development, so in a world of 3.0+ cli, I really
don't see how we can not do the same to address the needs of those who do
do multi-platform development, especially when we have a good proposal of
how to do so and someone willing to do it.


> I also think we're trying to help the wrong people; If I am a developer who
> is working on multiple platforms at once, and I have a bunch of devices
> attached, I probably also have the skills to set up my own grunt continuous
> integration system. Setting up tooling for potential plugin developers is
> the wrong approach, imho. We should actually just go and implement some new
> plugin and evaluate the process instead of creating and imposing a specific
> workflow.
>

The first part of this argument has some merit, I agree.  We the
power-users have found ways to address our problems.  However, I think that
with this change it means that even the end user can make changes to plugin
folder as they find bugs/etc, and expect to see the change reflected after
running prepare.  This is principle of least surprise, and just good design.

I also don't think we are imposing any specific workflow here, just
enabling a new one.  Personally I think that its quite surprising and
embarrassing that we haven't enabled this workflow since 3.0.


>
>
>
>
>
>
>
>
>
> @purplecabbage
> risingj.com
>
>
> On Thu, Sep 26, 2013 at 10:09 AM, Brian LeRoux  wrote:
>
> > 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 who
> > > do native dev to give cordova-cli a try (only maybe though).
> > >
> > > On Thu, Sep 26, 2013 at 4:25 PM, Braden Shepherdson <
> bra...@chromium.org
> > >
> > > wrote:
> > > > 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 about `cordova watch` which should watch for
> > >

Re: [Android] In-App Browser UI - thenounproject.com

[Shazron]

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:

> Hey
>
> I found these icons from Noun Project which are public domain.  I'm
> wanting to replace are existing non-icon weirdness with these.  I
> would have liked to use other icons to make it look more consistent,
> but I'm worried about licensing.
>
> For Arrows:
> http://thenounproject.com/noun/arrow/#icon-No34
>
> For Done:
> http://thenounproject.com/noun/exit/#icon-No20
>
> I'm going to try to add these at the end of the day and figure out how
> to get plugman to install drawables.  Once the drawables install, I'll
> get the skinning happening.
>
> Frankly, I'm not crazy about using Exit for the Done button.  It would
> have been better to use an X or to override the back button for this.
>
> Joe
>

Re: Updating plugin code on prepare

[Michal Mocny]

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 proposal is
entirely orthogonal, thought a watch feature will certainly be very useful.


> 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 cordova usage
> for cordova contributors workflows like we have today in
> cordova-js\Gruntfile
>
> TLDR: lets eat our own dog food before we adopted as something to support
> in apache cordova for consumer of the project.
>
>
>
>
> On Thu, Sep 26, 2013 at 1:42 PM, Tyler Wilson  >wrote:
>
> > 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 in the iOS project is the platform www folder. And since we
> naturally
> > edit the code directly in Xcode, this watch command would never really do
> > anything for me.
>

This, I consider a major UX bug on our part.  That xcode www/ folder should
just point directly to your top level www/.  Otherwise, you will blow away
your work with each prepare, as you notice.  The solution is not to ignore
the prepare command, indeed that is defeating the point, if not impossible,
when using the CLI.  The solution is not to edit the platform copy of www/.

However, I completely agree that it is more comfortable to edit directly
inside xcode if that is your prefered workflow.  I am not advising against
that.  The answer is perhaps to have a "prepare" hook tred to the xcode
build command, so that your www/ assets are edited directly in, and updated
from, the top level www/ folder automatically whenever you build.

The specifics here are likely topic for another thread since different
parties have different opinions about the idea IDE workflow, but it seems
very clear that what we have right now is confusing to every single user,
like yourself.


> >
> > What I would like a reverse watch, which will detect changes in the
> > platform www and copy them up to the top-level shared www folder. Perhaps
> > this is part of the feature set - more like a 'sync' than a watch.
> >
> > Thanks,
> > Tyler
> >
> > On Sep 26, 2013, at 1:09 PM, Brian LeRoux  wrote:
> >
> > > 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 who
> > >> do native dev to give cordova-cli a try (only maybe though).
> > >>
> > >> On Thu, Sep 26, 2013 at 4:25 PM, Braden Shepherdson <
> > bra...@chromium.org>
> > >> wrote:
> > >>> 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 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
> know
> >  that it's on the wish list.
> > 
> >  As far as the original proposal, I believe it is a descent temporary
> >  solution for plugin developers who want to use cordova-cli.
> > 
> >  On Wed, Sep 25, 2013 at 7:17 PM, Michal Mocny 
> > >> wrote:
> > > Braden, thats has been on the wish list (cordova watch), but I
> > suspect
> >  Anis
> > > was suggesting something different with plugman --watch, to do
> >  specifically
> > > with plugin development.  Am I right, Anis?  How does your idea
> > >> compare
> > > with using --link with cordova watch?  Would plugman --watch be
> > useful
> >  for
> > > non cli projects?
> > >
> > > -Michal
> > >
> > >
> > > On Wed, Sep 25, 2013 at 10:31 AM, Braden Shepherdson <
> >  bra...@chromium.org>wrote:
> > >
> > >> We've had a vague feature planned for a while now to do a cordova
> >  watch. It
> > >> would watch your plugins/, www/, and merges/* for any changes. If
> > any
> > >> changes are detected, it would re-run cordova prepare, so that
> your
> >  native
> > >> projects are always up-to-date.
> > >>
> > >> I'm open to checki

Re: Review request for CB-4926 inappbrowser doesn't load in windows8

[Carlos Santana]

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://issues.apache.org/jira/browse/CB-4926
> >
> > --
> > Carlos Santana
> > 
> >
>



-- 
Carlos Santana

Re: firefoxos memory leak on exec.js?

[Carlos Santana]

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.
> >
> > Can someone with a firefoxos phone double check that the problem is
> present
> > also on that platform.
> >
> > I don't have a phone I can't check one, I'm trying to figure out how to
> > build cordova and run in simulator.
> >
> > https://issues.apache.org/jira/browse/CB-4905
> >
> >
> https://github.com/apache/cordova-js/blob/master/lib/firefoxos/exec.js#L32
> >
> > PS: I was thinking on ordering the FirefoxOS ZTE Open Phone $80
> > http://r.ebay.com/5cIdde
> > Any advice on getting a different one for cordova dev/test? Or this one
> > good enough
> >
> > --
> > Carlos Santana
> > 
>
>


-- 
Carlos Santana

Re: mobile-spec and releases: How do we test?

[Michal Mocny]

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(...) ).
  - Will need a common way to describe/report results (others have
mentioned TAP).
- Any app is free to run those plugin tests in any which way, but we ship a
mobile-spec app which is one opinionated way to do so.
  - It attempts to require the test module for each installed plugin, runs
them, and aggregates results.
  - It could report results to some shared server, allow toggling of tests,
etc, but no plugin should know or care about those features.

Using that as a generic base:

- We ship a "CDVTests" (or whatever) plugin which has a bunch of library
code for creating tests, and plugins can use it to register their tests.
- This makes it easier to register manual tests in a common format for core
plugins, and prevents code duplication for core auto tests.
- External plugins can chose to use our testing library, or not.

-Michal


On Thu, Sep 26, 2013 at 10:34 AM, Braden Shepherdson wrote:

> 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 current
> mobile-spec's
> - That index reads a file akin to cordova_plugins.js (cordova_tests.js,
> maybe?) generated by the CLI, containing the info from the  tags.
> - It has navigation similar to the current mobile-spec, with buttons
> for the automatic and manual sections. Auto has "All" and then each module,
> manual just has the list of modules.
>
> Thoughts?
>
> Braden
>
>
> On Thu, Sep 26, 2013 at 6:33 AM, Carlos Santana  >wrote:
>
> > 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 to include
> > information about testing (i.e. Directory containing tests files, test
> > command, etc..)
> >
> > --Carlos
> >
> > On Thursday, September 26, 2013, Anis KADRI wrote:
> >
> > > 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 the plugins. Its been talked about, but not gone anywhere.
> > > >
> > > > David Kemp
> > > >
> > > >
> > > > On Wed, Sep 25, 2013 at 7:58 PM, Jesse  > >
> > > wrote:
> > > >
> > > >> Yeah, I have pushed some changes to mobile-spec, and when I did I
> also
> > > >> copied the tests into the plugin involved.
> > > >> Until we get the magic test runner happening, I think we just keep
> > > >> duplicating.
> > > >>
> > > >> @purplecabbage
> > > >> risingj.com
> > > >>
> > > >>
> > > >> On Wed, Sep 25, 2013 at 4:38 PM, Steven Gill <
> stevengil...@gmail.com
> > 
> > > >
> > > >> wrote:
> > > >>
> > > >> > We copied over tests into plugins when we first broke them out,
> but
> > I
> > > >> don't
> > > >> > believe they have been updated.
> > > >> >
> > > >> > I would say for now to just add the tests to mobile spec, and
> > > possibly in
> > > >> > the future we go all voltron to build mobile spec and keep tests
> > with
> > > >> their
> > > >> > corresponding plugins.
> > > >> >
> > > >> >
> > > >> > On Wed, Sep 25, 2013 at 4:22 PM, Joe Bowser  > >
> > > wrote:
> > > >> >
> > > >> > > Hey
> > > >> > >
> > > >> > > Right now, I'm working on a weird file issue that requires me to
> > > >> > > update mobile-spec, but I'm wondering where the tests should
> live.
> > > >> > > Should it all keep living in mobile-spec, or is it with the
> > plugins.
> > > >> > > And if it's with the plugins, will there be scripts to assemble
> > > >> > > mobile-spec all Voltron style?
> > > >> > >
> > > >> > > This came up earlier, but I haven't found any fix that needed a
> > > >> > > mobile-spec test.  (Many that need native testing, like
> recursive
> > > file
> > > >> > > copy, etc).  Any thoughts?
> > > >> > >
> > > >> > > Joe
> > > >> > >
> > > >> >
> > > >>
> > >
> >
> >
> > --
> > Carlos Santana
> > 
> >
>

Re: firefoxos memory leak on exec.js?

[Lucas Holmquist]

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 that platform.
> 
> I don't have a phone I can't check one, I'm trying to figure out how to
> build cordova and run in simulator.
> 
> https://issues.apache.org/jira/browse/CB-4905
> 
> https://github.com/apache/cordova-js/blob/master/lib/firefoxos/exec.js#L32
> 
> PS: I was thinking on ordering the FirefoxOS ZTE Open Phone $80
> http://r.ebay.com/5cIdde
> Any advice on getting a different one for cordova dev/test? Or this one
> good enough
> 
> -- 
> Carlos Santana
> 

Re: Review request for CB-4926 inappbrowser doesn't load in windows8

[Jesse]

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

Re: config.xml discussion, we need to talk

[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 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-CLI world,
> there's one file to edit, done. In the CLI world, there's still one file to
> edit (top-level www/config.xml) and the rest is CLI magic you don't need to
> care about as an app developer. I don't see how we can improve on one
> central place to edit.
>
> Braden
>
>
> On Thu, Sep 26, 2013 at 2:05 PM, Carlos Santana  >wrote:
>
> > 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 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 <
> > bra...@chromium.org
> > > > >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. This file is
> > > > > *accidentally* copied into www/config.xml in each platform.
> > > > >
> > > > > A **totally different file** with the same name is also generated
> by
> > > the
> > > > > CLI, based on settings from the defaults.xml, plugin 
> > > edits,
> > > > > and the top-level config.xml. This file is placed in
> > > > > platforms/android/res/xml/config.xml on Android, in
> > > > > platforms/ios/MyProject/config.xml on iOS, and other places.
> > > > >
> > > > > I repeat, the platforms/android/res/xml/config.xml and
> > > > > platforms/android/assets/www/config.xml are **different**.
> > > > >
> > > > > It's the top-level www/config.xml that we want to give 
> tag
> > > > > support to, so that you can set platform-specific things without
> > > editing
> > > > > the config.xml files inside those platforms.
> > > > >
> > > > > Not-CLI: Just the latter file, in eg. res/xml/config.xml. Edited by
> > > hand,
> > > > > always specific to this platform.
> > > > >
> > > > > As far as the standards, it's the latter, res/xml/config.xml, that
> > > > sort-of
> > > > > matches the widget spec. The top-level Cordova one doesn't, and
> we're
> > > > > moving farther away with adding  tags.
> > > > >
> > > > > Braden
> > > > >
> > > > >
> > > > > On Thu, Sep 26, 2013 at 1:28 PM, Jonathan Bond-Caron <
> > > > > jbo...@gdesolutions.com> wrote:
> > > > >
> > > > > > 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
> > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Carlos Santana
> > > > 
> > > >
> > >
> >
> >
> >
> > --
> > Carlos Santana
> > 
> >
>



-- 
Carlos Santana

Re: config.xml discussion, we need to talk

[Braden Shepherdson]

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-CLI world,
there's one file to edit, done. In the CLI world, there's still one file to
edit (top-level www/config.xml) and the rest is CLI magic you don't need to
care about as an app developer. I don't see how we can improve on one
central place to edit.

Braden


On Thu, Sep 26, 2013 at 2:05 PM, Carlos Santana wrote:

> 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 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 <
> bra...@chromium.org
> > > >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. This file is
> > > > *accidentally* copied into www/config.xml in each platform.
> > > >
> > > > A **totally different file** with the same name is also generated by
> > the
> > > > CLI, based on settings from the defaults.xml, plugin 
> > edits,
> > > > and the top-level config.xml. This file is placed in
> > > > platforms/android/res/xml/config.xml on Android, in
> > > > platforms/ios/MyProject/config.xml on iOS, and other places.
> > > >
> > > > I repeat, the platforms/android/res/xml/config.xml and
> > > > platforms/android/assets/www/config.xml are **different**.
> > > >
> > > > It's the top-level www/config.xml that we want to give  tag
> > > > support to, so that you can set platform-specific things without
> > editing
> > > > the config.xml files inside those platforms.
> > > >
> > > > Not-CLI: Just the latter file, in eg. res/xml/config.xml. Edited by
> > hand,
> > > > always specific to this platform.
> > > >
> > > > As far as the standards, it's the latter, res/xml/config.xml, that
> > > sort-of
> > > > matches the widget spec. The top-level Cordova one doesn't, and we're
> > > > moving farther away with adding  tags.
> > > >
> > > > Braden
> > > >
> > > >
> > > > On Thu, Sep 26, 2013 at 1:28 PM, Jonathan Bond-Caron <
> > > > jbo...@gdesolutions.com> wrote:
> > > >
> > > > > 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
> > > > >
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Carlos Santana
> > > 
> > >
> >
>
>
>
> --
> Carlos Santana
> 
>

Review request for CB-4926 inappbrowser doesn't load in windows8

[Carlos Santana]

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

Re: config.xml discussion, we need to talk

[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 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. This file is
> > > *accidentally* copied into www/config.xml in each platform.
> > >
> > > A **totally different file** with the same name is also generated by
> the
> > > CLI, based on settings from the defaults.xml, plugin 
> edits,
> > > and the top-level config.xml. This file is placed in
> > > platforms/android/res/xml/config.xml on Android, in
> > > platforms/ios/MyProject/config.xml on iOS, and other places.
> > >
> > > I repeat, the platforms/android/res/xml/config.xml and
> > > platforms/android/assets/www/config.xml are **different**.
> > >
> > > It's the top-level www/config.xml that we want to give  tag
> > > support to, so that you can set platform-specific things without
> editing
> > > the config.xml files inside those platforms.
> > >
> > > Not-CLI: Just the latter file, in eg. res/xml/config.xml. Edited by
> hand,
> > > always specific to this platform.
> > >
> > > As far as the standards, it's the latter, res/xml/config.xml, that
> > sort-of
> > > matches the widget spec. The top-level Cordova one doesn't, and we're
> > > moving farther away with adding  tags.
> > >
> > > Braden
> > >
> > >
> > > On Thu, Sep 26, 2013 at 1:28 PM, Jonathan Bond-Caron <
> > > jbo...@gdesolutions.com> wrote:
> > >
> > > > 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
> > > >
> > > >
> > >
> >
> >
> >
> > --
> > Carlos Santana
> > 
> >
>



-- 
Carlos Santana

Re: Updating plugin code on prepare

[Carlos Santana]

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 cordova usage
for cordova contributors workflows like we have today in
cordova-js\Gruntfile

TLDR: lets eat our own dog food before we adopted as something to support
in apache cordova for consumer of the project.




On Thu, Sep 26, 2013 at 1:42 PM, Tyler Wilson wrote:

> 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 in the iOS project is the platform www folder. And since we naturally
> edit the code directly in Xcode, this watch command would never really do
> anything for me.
>
> What I would like a reverse watch, which will detect changes in the
> platform www and copy them up to the top-level shared www folder. Perhaps
> this is part of the feature set - more like a 'sync' than a watch.
>
> Thanks,
> Tyler
>
> On Sep 26, 2013, at 1:09 PM, Brian LeRoux  wrote:
>
> > 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 who
> >> do native dev to give cordova-cli a try (only maybe though).
> >>
> >> On Thu, Sep 26, 2013 at 4:25 PM, Braden Shepherdson <
> bra...@chromium.org>
> >> wrote:
> >>> 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 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 know
>  that it's on the wish list.
> 
>  As far as the original proposal, I believe it is a descent temporary
>  solution for plugin developers who want to use cordova-cli.
> 
>  On Wed, Sep 25, 2013 at 7:17 PM, Michal Mocny 
> >> wrote:
> > Braden, thats has been on the wish list (cordova watch), but I
> suspect
>  Anis
> > was suggesting something different with plugman --watch, to do
>  specifically
> > with plugin development.  Am I right, Anis?  How does your idea
> >> compare
> > with using --link with cordova watch?  Would plugman --watch be
> useful
>  for
> > non cli projects?
> >
> > -Michal
> >
> >
> > On Wed, Sep 25, 2013 at 10:31 AM, Braden Shepherdson <
>  bra...@chromium.org>wrote:
> >
> >> We've had a vague feature planned for a while now to do a cordova
>  watch. It
> >> would watch your plugins/, www/, and merges/* for any changes. If
> any
> >> changes are detected, it would re-run cordova prepare, so that your
>  native
> >> projects are always up-to-date.
> >>
> >> I'm open to checking (hashes?) which files have changed and which
> >> have
>  not,
> >> but hashing them all is touching them all anyway, and it might be
> >> faster
> >> for small files to just copy them instead of checking first. We'll
> >> have
>  to
> >> try it and see; for v1 I'm going with the simple option of copying
> >> everything.
> >>
> >> Braden
> >>
> >>
> >> On Wed, Sep 25, 2013 at 9:44 AM, Michal Mocny 
>  wrote:
> >>
> >>> The idea for plugin dev outside of plugins/ folder was to use
> >> "plugin
>  add
> >>> --link".  Matter of fact, braden suggested that "plugin create"
> >> should
> >>> default to --link-ing to some external location so that you don't
> >> risk
> >>> deleting your only copy inside plugins/.  (I personally don't think
> >> thats a
> >>> necessary concern, but I think its a conversation for later).
> >>>
> >>> I'm not even sure what a 'watch' would do, just uninstall & install
>  each
> >>> time the plugin changes?  I think that ends up being just slightly
>  worse
> >>> than the current proposal if you factor in that we already do
> >> support
> >>> --link (except without the above change its been useless).
> >>>
> >>>
> >>> However, we may still want some form of 'watch' command for devs
> >> using
> >>> plugman directly.  I had assumed that those devs just edit in
> >> place,
> >> since
> >>> 

Re: config.xml discussion, we need to talk

[Braden Shepherdson]

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. This file is
> > *accidentally* copied into www/config.xml in each platform.
> >
> > A **totally different file** with the same name is also generated by the
> > CLI, based on settings from the defaults.xml, plugin  edits,
> > and the top-level config.xml. This file is placed in
> > platforms/android/res/xml/config.xml on Android, in
> > platforms/ios/MyProject/config.xml on iOS, and other places.
> >
> > I repeat, the platforms/android/res/xml/config.xml and
> > platforms/android/assets/www/config.xml are **different**.
> >
> > It's the top-level www/config.xml that we want to give  tag
> > support to, so that you can set platform-specific things without editing
> > the config.xml files inside those platforms.
> >
> > Not-CLI: Just the latter file, in eg. res/xml/config.xml. Edited by hand,
> > always specific to this platform.
> >
> > As far as the standards, it's the latter, res/xml/config.xml, that
> sort-of
> > matches the widget spec. The top-level Cordova one doesn't, and we're
> > moving farther away with adding  tags.
> >
> > Braden
> >
> >
> > On Thu, Sep 26, 2013 at 1:28 PM, Jonathan Bond-Caron <
> > jbo...@gdesolutions.com> wrote:
> >
> > > 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
> > >
> > >
> >
>
>
>
> --
> Carlos Santana
> 
>

Re: config.xml discussion, we need to talk

[Carlos Santana]

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. This file is
> *accidentally* copied into www/config.xml in each platform.
>
> A **totally different file** with the same name is also generated by the
> CLI, based on settings from the defaults.xml, plugin  edits,
> and the top-level config.xml. This file is placed in
> platforms/android/res/xml/config.xml on Android, in
> platforms/ios/MyProject/config.xml on iOS, and other places.
>
> I repeat, the platforms/android/res/xml/config.xml and
> platforms/android/assets/www/config.xml are **different**.
>
> It's the top-level www/config.xml that we want to give  tag
> support to, so that you can set platform-specific things without editing
> the config.xml files inside those platforms.
>
> Not-CLI: Just the latter file, in eg. res/xml/config.xml. Edited by hand,
> always specific to this platform.
>
> As far as the standards, it's the latter, res/xml/config.xml, that sort-of
> matches the widget spec. The top-level Cordova one doesn't, and we're
> moving farther away with adding  tags.
>
> Braden
>
>
> On Thu, Sep 26, 2013 at 1:28 PM, Jonathan Bond-Caron <
> jbo...@gdesolutions.com> wrote:
>
> > 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
> >
> >
>



-- 
Carlos Santana

Re: Updating plugin code on prepare

[Tyler Wilson]

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 in the iOS 
project is the platform www folder. And since we naturally edit the code 
directly in Xcode, this watch command would never really do anything for me.

What I would like a reverse watch, which will detect changes in the platform 
www and copy them up to the top-level shared www folder. Perhaps this is part 
of the feature set - more like a 'sync' than a watch.

Thanks,
Tyler
 
On Sep 26, 2013, at 1:09 PM, Brian LeRoux  wrote:

> 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 who
>> do native dev to give cordova-cli a try (only maybe though).
>> 
>> On Thu, Sep 26, 2013 at 4:25 PM, Braden Shepherdson 
>> wrote:
>>> 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 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 know
 that it's on the wish list.
 
 As far as the original proposal, I believe it is a descent temporary
 solution for plugin developers who want to use cordova-cli.
 
 On Wed, Sep 25, 2013 at 7:17 PM, Michal Mocny 
>> wrote:
> Braden, thats has been on the wish list (cordova watch), but I suspect
 Anis
> was suggesting something different with plugman --watch, to do
 specifically
> with plugin development.  Am I right, Anis?  How does your idea
>> compare
> with using --link with cordova watch?  Would plugman --watch be useful
 for
> non cli projects?
> 
> -Michal
> 
> 
> On Wed, Sep 25, 2013 at 10:31 AM, Braden Shepherdson <
 bra...@chromium.org>wrote:
> 
>> We've had a vague feature planned for a while now to do a cordova
 watch. It
>> would watch your plugins/, www/, and merges/* for any changes. If any
>> changes are detected, it would re-run cordova prepare, so that your
 native
>> projects are always up-to-date.
>> 
>> I'm open to checking (hashes?) which files have changed and which
>> have
 not,
>> but hashing them all is touching them all anyway, and it might be
>> faster
>> for small files to just copy them instead of checking first. We'll
>> have
 to
>> try it and see; for v1 I'm going with the simple option of copying
>> everything.
>> 
>> Braden
>> 
>> 
>> On Wed, Sep 25, 2013 at 9:44 AM, Michal Mocny 
 wrote:
>> 
>>> The idea for plugin dev outside of plugins/ folder was to use
>> "plugin
 add
>>> --link".  Matter of fact, braden suggested that "plugin create"
>> should
>>> default to --link-ing to some external location so that you don't
>> risk
>>> deleting your only copy inside plugins/.  (I personally don't think
>> thats a
>>> necessary concern, but I think its a conversation for later).
>>> 
>>> I'm not even sure what a 'watch' would do, just uninstall & install
 each
>>> time the plugin changes?  I think that ends up being just slightly
 worse
>>> than the current proposal if you factor in that we already do
>> support
>>> --link (except without the above change its been useless).
>>> 
>>> 
>>> However, we may still want some form of 'watch' command for devs
>> using
>>> plugman directly.  I had assumed that those devs just edit in
>> place,
>> since
>>> they don't use a prepare step anyway.
>>> 
>>> -Michal
>>> 
>>> 
>>> 
>>> On Wed, Sep 25, 2013 at 7:50 AM, Anis KADRI 
>> wrote:
>>> 
 If we're talking about developing plugins inside the
 plugins/org.myplugin.id folder than I think it's a great
>> workflow
 and
 I would just hide the cached version of plugin.xml inside that
 plugins/org.myplugin.id folder.
 
 However, if you're developing a plugin outside of a cordova CLI
 project, I think a `watch` (and add --watch) command is more
 appropriate. One of the reasons you would develop a plugin
>> outside
 of
 a cordova CLI project is for easier version control (each plugin
 would
 have its own repository). The other cool t

Re: config.xml discussion, we need to talk

[Braden Shepherdson]

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 same name is also generated by the
CLI, based on settings from the defaults.xml, plugin  edits,
and the top-level config.xml. This file is placed in
platforms/android/res/xml/config.xml on Android, in
platforms/ios/MyProject/config.xml on iOS, and other places.

I repeat, the platforms/android/res/xml/config.xml and
platforms/android/assets/www/config.xml are **different**.

It's the top-level www/config.xml that we want to give  tag
support to, so that you can set platform-specific things without editing
the config.xml files inside those platforms.

Not-CLI: Just the latter file, in eg. res/xml/config.xml. Edited by hand,
always specific to this platform.

As far as the standards, it's the latter, res/xml/config.xml, that sort-of
matches the widget spec. The top-level Cordova one doesn't, and we're
moving farther away with adding  tags.

Braden


On Thu, Sep 26, 2013 at 1:28 PM, Jonathan Bond-Caron <
jbo...@gdesolutions.com> wrote:

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

Re: Updating plugin code on prepare

[Jesse]

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
as a native piece, and a js piece.
2. test thoroughly
3. create a project for a second cordova platform, and develop the native
bit, preserving the js from 1
4. test thoroughly
5. repeat steps 3+4 for any remaining platforms
6. package featureX as a plugin by organizing relevant bits in the correct
folder structure, and adding a plugin.xml
7. test each platform by installing with plugman
8. publish

We seem to have this notion come up repeatedly that our users + plugin
developers are working on multiple platforms at the same time, which I
think is entirely false.
I also think we're trying to help the wrong people; If I am a developer who
is working on multiple platforms at once, and I have a bunch of devices
attached, I probably also have the skills to set up my own grunt continuous
integration system. Setting up tooling for potential plugin developers is
the wrong approach, imho. We should actually just go and implement some new
plugin and evaluate the process instead of creating and imposing a specific
workflow.









@purplecabbage
risingj.com


On Thu, Sep 26, 2013 at 10:09 AM, Brian LeRoux  wrote:

> 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 who
> > do native dev to give cordova-cli a try (only maybe though).
> >
> > On Thu, Sep 26, 2013 at 4:25 PM, Braden Shepherdson  >
> > wrote:
> > > 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 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 know
> > >> that it's on the wish list.
> > >>
> > >> As far as the original proposal, I believe it is a descent temporary
> > >> solution for plugin developers who want to use cordova-cli.
> > >>
> > >> On Wed, Sep 25, 2013 at 7:17 PM, Michal Mocny 
> > wrote:
> > >> > Braden, thats has been on the wish list (cordova watch), but I
> suspect
> > >> Anis
> > >> > was suggesting something different with plugman --watch, to do
> > >> specifically
> > >> > with plugin development.  Am I right, Anis?  How does your idea
> > compare
> > >> > with using --link with cordova watch?  Would plugman --watch be
> useful
> > >> for
> > >> > non cli projects?
> > >> >
> > >> > -Michal
> > >> >
> > >> >
> > >> > On Wed, Sep 25, 2013 at 10:31 AM, Braden Shepherdson <
> > >> bra...@chromium.org>wrote:
> > >> >
> > >> >> We've had a vague feature planned for a while now to do a cordova
> > >> watch. It
> > >> >> would watch your plugins/, www/, and merges/* for any changes. If
> any
> > >> >> changes are detected, it would re-run cordova prepare, so that your
> > >> native
> > >> >> projects are always up-to-date.
> > >> >>
> > >> >> I'm open to checking (hashes?) which files have changed and which
> > have
> > >> not,
> > >> >> but hashing them all is touching them all anyway, and it might be
> > faster
> > >> >> for small files to just copy them instead of checking first. We'll
> > have
> > >> to
> > >> >> try it and see; for v1 I'm going with the simple option of copying
> > >> >> everything.
> > >> >>
> > >> >> Braden
> > >> >>
> > >> >>
> > >> >> On Wed, Sep 25, 2013 at 9:44 AM, Michal Mocny  >
> > >> wrote:
> > >> >>
> > >> >> > The idea for plugin dev outside of plugins/ folder was to use
> > "plugin
> > >> add
> > >> >> > --link".  Matter of fact, braden suggested that "plugin create"
> > should
> > >> >> > default to --link-ing to some external location so that you don't
> > risk
> > >> >> > deleting your only copy inside plugins/.  (I personally don't
> think
> > >> >> thats a
> > >> >> > necessary concern, but I think its a conversation for later).
> > >> >> >
> > >> >> > I'm not even sure what a 'watch' would do, just uninstall &
> install
> > >> each
> > >> >> > time the plugin changes?  I think that ends up being just
> slightly
> > >> worse
> > >> >> > than the current proposal if you factor in that we already do
> > support
> > >> >> > --link (except without the above change its been useless).
> > >> >> >
> > >> >> >
> > >> >> > However, we may still want some form of 'watch' command for devs
> > using
> > >> >> > 

RE: config.xml discussion, we need to talk

[Jonathan Bond-Caron]

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 config.xml has nothing to do with an HTML5 application, it's a cordova 
specific thing (hybrid app config).

It's nice to have it align with the w3c spec for widgets but we're talking 
about 2 different things:
- Hybrid application configuration (which may have enable platform specific 
features)
- HTML5 application configuration (~ w3c widget spec which I'm personally not a 
fan)
The scope of the HTML5 app configuration IMHO is outside of cordova and 
certainly up for debate.

Re: config.xml discussion, we need to talk

[Carlos Santana]

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


-- 
Carlos Santana

RE: config.xml discussion, we need to talk

[Jonathan Bond-Caron]

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

Re: w3c DAP WG discussing vibration strength

[Jesse]

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 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 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 vibration spec?
> >
> > proposal example:
> >
> > Vibration API strength proposal with stair-stepping/smooth volume
> > reduce/increase:
> >
> > navigator.vibrate([
> > {
> > "time": 200, // Required property.
> > "volume": [0, 80] // Minimum 0, maximum 100, default 100. [0, 80] smooth
> > volume increase - starts volume strength at 0 and smoothly increases to
> 80
> > till end.
> > },
> > {
> > "time": 1000, // 1000 ms
> > "delay": 50, // Will start vibrate after 50 ms. Default 0 ms
> > "volume": [0, 100, 0] // Smooth volume reduce-increas-reduce - starts at
> > 0, smoothly increases to 100 in 50 ms and smooth reduce to 0 at end.
> > },
> > {
> > "time": 200,
> > "volume": [50] // Stair-stepping volume - will start and end volume
> > strength 50.
> > }
> > ]);
> >
> > or the same in simplified version without strings:
> >
> > navigator.vibrate([{200, [0, 80]}, {1000, 50, [0, 100, 0]}, {200,
> [50]}]);
> >
> >
> >
> > Lisa Seacat DeLuca
> > ldel...@apache.org
>

Re: Updating plugin code on prepare

[Brian LeRoux]

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 who
> do native dev to give cordova-cli a try (only maybe though).
>
> On Thu, Sep 26, 2013 at 4:25 PM, Braden Shepherdson 
> wrote:
> > 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 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 know
> >> that it's on the wish list.
> >>
> >> As far as the original proposal, I believe it is a descent temporary
> >> solution for plugin developers who want to use cordova-cli.
> >>
> >> On Wed, Sep 25, 2013 at 7:17 PM, Michal Mocny 
> wrote:
> >> > Braden, thats has been on the wish list (cordova watch), but I suspect
> >> Anis
> >> > was suggesting something different with plugman --watch, to do
> >> specifically
> >> > with plugin development.  Am I right, Anis?  How does your idea
> compare
> >> > with using --link with cordova watch?  Would plugman --watch be useful
> >> for
> >> > non cli projects?
> >> >
> >> > -Michal
> >> >
> >> >
> >> > On Wed, Sep 25, 2013 at 10:31 AM, Braden Shepherdson <
> >> bra...@chromium.org>wrote:
> >> >
> >> >> We've had a vague feature planned for a while now to do a cordova
> >> watch. It
> >> >> would watch your plugins/, www/, and merges/* for any changes. If any
> >> >> changes are detected, it would re-run cordova prepare, so that your
> >> native
> >> >> projects are always up-to-date.
> >> >>
> >> >> I'm open to checking (hashes?) which files have changed and which
> have
> >> not,
> >> >> but hashing them all is touching them all anyway, and it might be
> faster
> >> >> for small files to just copy them instead of checking first. We'll
> have
> >> to
> >> >> try it and see; for v1 I'm going with the simple option of copying
> >> >> everything.
> >> >>
> >> >> Braden
> >> >>
> >> >>
> >> >> On Wed, Sep 25, 2013 at 9:44 AM, Michal Mocny 
> >> wrote:
> >> >>
> >> >> > The idea for plugin dev outside of plugins/ folder was to use
> "plugin
> >> add
> >> >> > --link".  Matter of fact, braden suggested that "plugin create"
> should
> >> >> > default to --link-ing to some external location so that you don't
> risk
> >> >> > deleting your only copy inside plugins/.  (I personally don't think
> >> >> thats a
> >> >> > necessary concern, but I think its a conversation for later).
> >> >> >
> >> >> > I'm not even sure what a 'watch' would do, just uninstall & install
> >> each
> >> >> > time the plugin changes?  I think that ends up being just slightly
> >> worse
> >> >> > than the current proposal if you factor in that we already do
> support
> >> >> > --link (except without the above change its been useless).
> >> >> >
> >> >> >
> >> >> > However, we may still want some form of 'watch' command for devs
> using
> >> >> > plugman directly.  I had assumed that those devs just edit in
> place,
> >> >> since
> >> >> > they don't use a prepare step anyway.
> >> >> >
> >> >> > -Michal
> >> >> >
> >> >> >
> >> >> >
> >> >> > On Wed, Sep 25, 2013 at 7:50 AM, Anis KADRI 
> >> >> wrote:
> >> >> >
> >> >> > > If we're talking about developing plugins inside the
> >> >> > > plugins/org.myplugin.id folder than I think it's a great
> workflow
> >> and
> >> >> > > I would just hide the cached version of plugin.xml inside that
> >> >> > > plugins/org.myplugin.id folder.
> >> >> > >
> >> >> > > However, if you're developing a plugin outside of a cordova CLI
> >> >> > > project, I think a `watch` (and add --watch) command is more
> >> >> > > appropriate. One of the reasons you would develop a plugin
> outside
> >> of
> >> >> > > a cordova CLI project is for easier version control (each plugin
> >> would
> >> >> > > have its own repository). The other cool thing about `watch` is
> that
> >> >> > > it would copy the files that have actually changed and not
> >> everything
> >> >> > > (some plugins have a LOT of files [1]).
> >> >> > >
> >> >> > > [1] https://github.com/phonegap/phonegap-facebook-plugin
> >> >> > >
> >> >> > > On Wed, Sep 25, 2013 at 3:30 AM, James Jong <
> wjamesj...@gmail.com>
> >> >> > wrote:
> >> >> > > > +1 This is a cleaner workflow and should reduce some confusion.
> >> >> > > >
> >> >> > > > -James Jong
> >> >> > > >
> >> >> > > > On Sep 24, 2013, at 3:09 PM, Michal Mocny  >
> >> >> wrote:
> >> >> > > >
> >> >> > > >> Just to add, the reason for the "if" statement in step (2) is
> >> that
> >> >> > > >> uninstall & re

Re: w3c DAP WG discussing vibration strength

[Brian LeRoux]

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 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 vibration spec?
>
> proposal example:
>
> Vibration API strength proposal with stair-stepping/smooth volume
> reduce/increase:
>
> navigator.vibrate([
> {
> "time": 200, // Required property.
> "volume": [0, 80] // Minimum 0, maximum 100, default 100. [0, 80] smooth
> volume increase - starts volume strength at 0 and smoothly increases to 80
> till end.
> },
> {
> "time": 1000, // 1000 ms
> "delay": 50, // Will start vibrate after 50 ms. Default 0 ms
> "volume": [0, 100, 0] // Smooth volume reduce-increas-reduce - starts at
> 0, smoothly increases to 100 in 50 ms and smooth reduce to 0 at end.
> },
> {
> "time": 200,
> "volume": [50] // Stair-stepping volume - will start and end volume
> strength 50.
> }
> ]);
>
> or the same in simplified version without strings:
>
> navigator.vibrate([{200, [0, 80]}, {1000, 50, [0, 100, 0]}, {200, [50]}]);
>
>
>
> Lisa Seacat DeLuca
> ldel...@apache.org

Re: config.xml discussion, we need to talk

[Carlos Santana]

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 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 the www folder can live in different places on different
> devices implies that it is okay for config.xml to live in different places
> also.
> I don't think it would be worthwhile to move files at loadtime, as Joe
> warns.
> I also don't think it is worth having a build time script to 'magically'
> move files around before they get packaged.
>
>
> @purplecabbage
> risingj.com
>
>
> On Thu, Sep 26, 2013 at 8:57 AM, Joe Bowser  wrote:
>
> > 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 we should tell people not using the CLI where it's located on
> > each of the platforms.  The CLI can play pretend with the spec, and
> > the platforms can move on with actually making things more usable.
> >
>



-- 
Carlos Santana

Re: config.xml discussion, we need to talk

[Carlos Santana]

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
runtime inside with the payload.

At least in mobile performance is king!

Like I said not very familiar with Android yet :-(

--Carlos



On Thu, Sep 26, 2013 at 11:53 AM, Joe Bowser  wrote:

> 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 unzip the jar just to get the
> config.xml is not something that I want to do, especially since this
> can slow down the PluginManager and make Cordova slower.
>
> There's a point where making things easier for the Web Developer will
> make the app suck more.  I honestly think that we should focus on
> actually enabling developers to make apps that don't suck, which means
> that delays for deviceReady for things like this don't belong here.
> We have more than enough already.
>



-- 
Carlos Santana

Re: config.xml discussion, we need to talk

[Joe Bowser]

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 unzip the jar just to get the
config.xml is not something that I want to do, especially since this
can slow down the PluginManager and make Cordova slower.

There's a point where making things easier for the Web Developer will
make the app suck more.  I honestly think that we should focus on
actually enabling developers to make apps that don't suck, which means
that delays for deviceReady for things like this don't belong here.
We have more than enough already.

Re: config.xml discussion, we need to talk

[Jesse]

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 the www folder can live in different places on different
devices implies that it is okay for config.xml to live in different places
also.
I don't think it would be worthwhile to move files at loadtime, as Joe
warns.
I also don't think it is worth having a build time script to 'magically'
move files around before they get packaged.


@purplecabbage
risingj.com


On Thu, Sep 26, 2013 at 8:57 AM, Joe Bowser  wrote:

> 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 we should tell people not using the CLI where it's located on
> each of the platforms.  The CLI can play pretend with the spec, and
> the platforms can move on with actually making things more usable.
>

Re: config.xml discussion, we need to talk

[Joe Bowser]

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 we should tell people not using the CLI where it's located on
each of the platforms.  The CLI can play pretend with the spec, and
the platforms can move on with actually making things more usable.

Re: config.xml discussion, we need to talk

[Lindsey Simon]

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 don't know much about Android so maybe I'm putting my foot in my mouth
> because it's too complex to read the file from www/
>

When you say www are you referring to project/www or
project/platform/android/assets/www?


>
>
> --Carlos
>
>
> On Thursday, September 26, 2013, 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.
> >
> > There are good reasons why the CLI moves the config.xml on some
> platforms.
> > On Android, it's really easy to load XML files from res/xml/foo.xml, so
> > that's where we put it. We should be deleting the
> > platforms/android/assets/www/config.xml though, since it's an unused
> > duplicate and confusing.
> >
> > Braden
> >
> >
> > On Wed, Sep 25, 2013 at 4:59 PM, Carlos Santana  
> > >wrote:
> >
> > > I was not trying to be purist with the w3c www/config.xml
> > >
> > > I just want to see some consistency across all platforms for
> > configuration
> > > settings for a Cordova App.
> > >
> > > The same way I have a single index.html, app.css and app.js. I want see
> > one
> > > config.xml for all platforms inside www/ or many config.xml per
> platform
> > > config.ios.xml, config.android.xml, etc... But as a web developer I'm
> > > excepting all the files that I need to modify inside www/ using CLI or
> > not
> > >
> > > Even if I have to run something like ./bin/processconfig.sh to
> propagate
> > > changes from the /www/config.xml
> > >
> > > As web developer I might update the config.xml once for every 100 edits
> > to
> > > my app web files (HTML, JS, CSS)
> > >
> > > TLDR: consistency wins over correctness
> > >
> > > PS: what is the phonegap team doing? I think you tell users to edit one
> > > config.xml for the web app and pgbuild takes care of the rest
> > >
> > >
> > > -- Carlos
> > >
> > > On Wednesday, September 25, 2013, Braden Shepherdson wrote:
> > >
> > > > I'm in favour of CLI (platform parsers, probably) deleting this
> > > > www/config.xml that they don't use. It's a waste of space and has
> > > confused
> > > > people in the past.
> > > >
> > > > It even confused the iOS prepare code and caused that odd "my project
> > > > doesn't work if it starts with x, y or z" bug (because
> > xFactor/config.xml
> > > > sorts after www/config.xml, and it was blindly taking the first one).
> > > >
> > > > Braden
> > > >
> > > >
> > > > On Wed, Sep 25, 2013 at 4:22 PM, Bryan Higgins <
> > bhigg...@blackberry.com 
> > > 
> > > > >wrote:
> > > >
> > > > > Thanks for the clarification. BlackBerry happened to luck out
> because
> > > we
> > > > > expect config.xml in www.
> > > > >
> > > > > Perhaps copying of config.xml should become a responsibility of the
> > > > > platform parsers.
> > > > >
> > > > > I can understand moving config.xml to root or cordova for the
> reason
> > > > stated
> > > > > in the JIRA, but my vote would be to keep it "config.xml" rather
> than
> > > > > "app.xml".
> > > > >
> > > > >
> > > > > On Wed, Sep 25, 2013 at 3:55 PM, Jesse 
> > > wrote:
> > > > >
> > > > > > I am not saying deviate, I am saying, what is it supposed to be?
> If
> > > you
> > > > > > look at the various platforms you will see it is all over the
> map.
> > > > > >
> > > > > > Looking at Android code, and talking to Joe, the only location
> that
> > > the
> > > > > > config.xml file is loaded from is in res/xml, and the fact that
> > > > > cordova-cli
> > > > > > creates another one sitting in the www folder is just irrelevant
> > > > > > sloppiness.
> > > > > >
> > > > > > It may make sense for the config.xml file to sit in the root/www
> > > folder
> > > > > of
> > > > > > the CLI project, but in reality at runtime, it's location will
> vary
> > > by
> > > > > > platform.
> > > > > >
> > > > > >
> > > > > >
> > > > > > @purplecabbage
> > > > > > risingj.com
> > > > > >
> > > > > >
> > > > > > On Wed, Sep 25, 2013 at 12:29 PM, Bryan Higgins <
> > > > bhigg...@blackberry.com
> > > > > > >wrote:
> > > > > >
> > > > > > > www/config.xml aligns nicely with the w3c widget spec [1]. Why
> > > would
> > > > we
> > > > > > > want to deviate?
> > > > > > >
> > > > > > > [1]
> http://www.w3.org/TR/widgets/#reserved-file-and-folder-names
> > > > > > >
> > > > > > >
> > > > > > > On Wed, Sep 25, 2013 at 3:23 PM, Jesse <
> purplecabb...@gmail.com>
> > > > > wrote:
> > > > > > >
> > > > > > > > Seems any project created with the CLI has a config.xml in
> the
> > > www
> > > > > > > folder.
> > > > > > > > [1]
> > > > > > > > Why do we have 2 of these?
> > > > > > > >
> > > > > > > > I also recently closed a defect created by Carlos, stat

Re: config.xml discussion, we need to talk

[Jesse]

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


is already cross device

The access tags for whitelisting have some minor differences but there is
an open issue for that already. [1]


As far as the location of the file, I agree it would be nice if it was
consistent, but I think we should worry first about the contents of the
file being consistent, then the location.  It does make sense for the file
to sit in the www folder so that this folder is portable, and can be
dropped in another location, however this expectation is already broken by
the different cordova.js files.


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


@purplecabbage
risingj.com


On Thu, Sep 26, 2013 at 8:07 AM, Braden Shepherdson wrote:

> 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 config.xml.
> >
> > Agreed.  I'm not sure if Android actually supports this.  We should
> > probably write some JUnit tests against a multi-platform config.xml to
> > test this and make sure that our parser actually works well.
> >
> >
> Let me clarify: I was talking about adding  tags to CLI's
> top-level www/config.xml. The actual entries would be extracted into that
> platform's final config.xml, without a  tag.
>
>
>
> > >
> > > There are good reasons why the CLI moves the config.xml on some
> > platforms.
> > > On Android, it's really easy to load XML files from res/xml/foo.xml, so
> > > that's where we put it. We should be deleting the
> > > platforms/android/assets/www/config.xml though, since it's an unused
> > > duplicate and confusing.
> > >
> >
> > +1 on this as well. The problem is that the documentation covers the
> > PhoneGap Build use case and the CLI use case, but not the stand-alone
> > use case.  We should document the stand-alone use case, since that's
> > really for people who are detail-oriented, and are using things such
> > as the CordovaWebView component.
> >
>

Re: config.xml discussion, we need to talk

[Carlos Santana]

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
because it's too complex to read the file from www/


--Carlos


On Thursday, September 26, 2013, 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.
>
> There are good reasons why the CLI moves the config.xml on some platforms.
> On Android, it's really easy to load XML files from res/xml/foo.xml, so
> that's where we put it. We should be deleting the
> platforms/android/assets/www/config.xml though, since it's an unused
> duplicate and confusing.
>
> Braden
>
>
> On Wed, Sep 25, 2013 at 4:59 PM, Carlos Santana 
> 
> >wrote:
>
> > I was not trying to be purist with the w3c www/config.xml
> >
> > I just want to see some consistency across all platforms for
> configuration
> > settings for a Cordova App.
> >
> > The same way I have a single index.html, app.css and app.js. I want see
> one
> > config.xml for all platforms inside www/ or many config.xml per platform
> > config.ios.xml, config.android.xml, etc... But as a web developer I'm
> > excepting all the files that I need to modify inside www/ using CLI or
> not
> >
> > Even if I have to run something like ./bin/processconfig.sh to propagate
> > changes from the /www/config.xml
> >
> > As web developer I might update the config.xml once for every 100 edits
> to
> > my app web files (HTML, JS, CSS)
> >
> > TLDR: consistency wins over correctness
> >
> > PS: what is the phonegap team doing? I think you tell users to edit one
> > config.xml for the web app and pgbuild takes care of the rest
> >
> >
> > -- Carlos
> >
> > On Wednesday, September 25, 2013, Braden Shepherdson wrote:
> >
> > > I'm in favour of CLI (platform parsers, probably) deleting this
> > > www/config.xml that they don't use. It's a waste of space and has
> > confused
> > > people in the past.
> > >
> > > It even confused the iOS prepare code and caused that odd "my project
> > > doesn't work if it starts with x, y or z" bug (because
> xFactor/config.xml
> > > sorts after www/config.xml, and it was blindly taking the first one).
> > >
> > > Braden
> > >
> > >
> > > On Wed, Sep 25, 2013 at 4:22 PM, Bryan Higgins <
> bhigg...@blackberry.com 
> > 
> > > >wrote:
> > >
> > > > Thanks for the clarification. BlackBerry happened to luck out because
> > we
> > > > expect config.xml in www.
> > > >
> > > > Perhaps copying of config.xml should become a responsibility of the
> > > > platform parsers.
> > > >
> > > > I can understand moving config.xml to root or cordova for the reason
> > > stated
> > > > in the JIRA, but my vote would be to keep it "config.xml" rather than
> > > > "app.xml".
> > > >
> > > >
> > > > On Wed, Sep 25, 2013 at 3:55 PM, Jesse 
> > wrote:
> > > >
> > > > > I am not saying deviate, I am saying, what is it supposed to be? If
> > you
> > > > > look at the various platforms you will see it is all over the map.
> > > > >
> > > > > Looking at Android code, and talking to Joe, the only location that
> > the
> > > > > config.xml file is loaded from is in res/xml, and the fact that
> > > > cordova-cli
> > > > > creates another one sitting in the www folder is just irrelevant
> > > > > sloppiness.
> > > > >
> > > > > It may make sense for the config.xml file to sit in the root/www
> > folder
> > > > of
> > > > > the CLI project, but in reality at runtime, it's location will vary
> > by
> > > > > platform.
> > > > >
> > > > >
> > > > >
> > > > > @purplecabbage
> > > > > risingj.com
> > > > >
> > > > >
> > > > > On Wed, Sep 25, 2013 at 12:29 PM, Bryan Higgins <
> > > bhigg...@blackberry.com
> > > > > >wrote:
> > > > >
> > > > > > www/config.xml aligns nicely with the w3c widget spec [1]. Why
> > would
> > > we
> > > > > > want to deviate?
> > > > > >
> > > > > > [1] http://www.w3.org/TR/widgets/#reserved-file-and-folder-names
> > > > > >
> > > > > >
> > > > > > On Wed, Sep 25, 2013 at 3:23 PM, Jesse 
> > > > wrote:
> > > > > >
> > > > > > > Seems any project created with the CLI has a config.xml in the
> > www
> > > > > > folder.
> > > > > > > [1]
> > > > > > > Why do we have 2 of these?
> > > > > > >
> > > > > > > I also recently closed a defect created by Carlos, stating that
> > WP8
> > > > did
> > > > > > NOT
> > > > > > > have it's config.xml in the www folder. [2] Now I am not sure I
> > > > should
> > > > > > have
> > > > > > > called this invalid, however, after creating a new WP8 project
> > with
> > > > the
> > > > > > > CLI, I see a config.xml in the www folder AND one in the app
> > root.
> > > > wtf?
> > > > > > >
> > > > > > > There is an open issue [3] to re-org config files, where Braden
> > > > states
> > > > > > "We
> > > 

Re: config.xml discussion, we need to talk

[Braden Shepherdson]

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 config.xml.
>
> Agreed.  I'm not sure if Android actually supports this.  We should
> probably write some JUnit tests against a multi-platform config.xml to
> test this and make sure that our parser actually works well.
>
>
Let me clarify: I was talking about adding  tags to CLI's
top-level www/config.xml. The actual entries would be extracted into that
platform's final config.xml, without a  tag.



> >
> > There are good reasons why the CLI moves the config.xml on some
> platforms.
> > On Android, it's really easy to load XML files from res/xml/foo.xml, so
> > that's where we put it. We should be deleting the
> > platforms/android/assets/www/config.xml though, since it's an unused
> > duplicate and confusing.
> >
>
> +1 on this as well. The problem is that the documentation covers the
> PhoneGap Build use case and the CLI use case, but not the stand-alone
> use case.  We should document the stand-alone use case, since that's
> really for people who are detail-oriented, and are using things such
> as the CordovaWebView component.
>

Re: config.xml discussion, we need to talk

[Joe Bowser]

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.  We should
probably write some JUnit tests against a multi-platform config.xml to
test this and make sure that our parser actually works well.

>
> There are good reasons why the CLI moves the config.xml on some platforms.
> On Android, it's really easy to load XML files from res/xml/foo.xml, so
> that's where we put it. We should be deleting the
> platforms/android/assets/www/config.xml though, since it's an unused
> duplicate and confusing.
>

+1 on this as well. The problem is that the documentation covers the
PhoneGap Build use case and the CLI use case, but not the stand-alone
use case.  We should document the stand-alone use case, since that's
really for people who are detail-oriented, and are using things such
as the CordovaWebView component.

Re: Updating plugin code on prepare

[Anis KADRI]

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, Braden Shepherdson  wrote:
> 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 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 know
>> that it's on the wish list.
>>
>> As far as the original proposal, I believe it is a descent temporary
>> solution for plugin developers who want to use cordova-cli.
>>
>> On Wed, Sep 25, 2013 at 7:17 PM, Michal Mocny  wrote:
>> > Braden, thats has been on the wish list (cordova watch), but I suspect
>> Anis
>> > was suggesting something different with plugman --watch, to do
>> specifically
>> > with plugin development.  Am I right, Anis?  How does your idea compare
>> > with using --link with cordova watch?  Would plugman --watch be useful
>> for
>> > non cli projects?
>> >
>> > -Michal
>> >
>> >
>> > On Wed, Sep 25, 2013 at 10:31 AM, Braden Shepherdson <
>> bra...@chromium.org>wrote:
>> >
>> >> We've had a vague feature planned for a while now to do a cordova
>> watch. It
>> >> would watch your plugins/, www/, and merges/* for any changes. If any
>> >> changes are detected, it would re-run cordova prepare, so that your
>> native
>> >> projects are always up-to-date.
>> >>
>> >> I'm open to checking (hashes?) which files have changed and which have
>> not,
>> >> but hashing them all is touching them all anyway, and it might be faster
>> >> for small files to just copy them instead of checking first. We'll have
>> to
>> >> try it and see; for v1 I'm going with the simple option of copying
>> >> everything.
>> >>
>> >> Braden
>> >>
>> >>
>> >> On Wed, Sep 25, 2013 at 9:44 AM, Michal Mocny 
>> wrote:
>> >>
>> >> > The idea for plugin dev outside of plugins/ folder was to use "plugin
>> add
>> >> > --link".  Matter of fact, braden suggested that "plugin create" should
>> >> > default to --link-ing to some external location so that you don't risk
>> >> > deleting your only copy inside plugins/.  (I personally don't think
>> >> thats a
>> >> > necessary concern, but I think its a conversation for later).
>> >> >
>> >> > I'm not even sure what a 'watch' would do, just uninstall & install
>> each
>> >> > time the plugin changes?  I think that ends up being just slightly
>> worse
>> >> > than the current proposal if you factor in that we already do support
>> >> > --link (except without the above change its been useless).
>> >> >
>> >> >
>> >> > However, we may still want some form of 'watch' command for devs using
>> >> > plugman directly.  I had assumed that those devs just edit in place,
>> >> since
>> >> > they don't use a prepare step anyway.
>> >> >
>> >> > -Michal
>> >> >
>> >> >
>> >> >
>> >> > On Wed, Sep 25, 2013 at 7:50 AM, Anis KADRI 
>> >> wrote:
>> >> >
>> >> > > If we're talking about developing plugins inside the
>> >> > > plugins/org.myplugin.id folder than I think it's a great workflow
>> and
>> >> > > I would just hide the cached version of plugin.xml inside that
>> >> > > plugins/org.myplugin.id folder.
>> >> > >
>> >> > > However, if you're developing a plugin outside of a cordova CLI
>> >> > > project, I think a `watch` (and add --watch) command is more
>> >> > > appropriate. One of the reasons you would develop a plugin outside
>> of
>> >> > > a cordova CLI project is for easier version control (each plugin
>> would
>> >> > > have its own repository). The other cool thing about `watch` is that
>> >> > > it would copy the files that have actually changed and not
>> everything
>> >> > > (some plugins have a LOT of files [1]).
>> >> > >
>> >> > > [1] https://github.com/phonegap/phonegap-facebook-plugin
>> >> > >
>> >> > > On Wed, Sep 25, 2013 at 3:30 AM, James Jong 
>> >> > wrote:
>> >> > > > +1 This is a cleaner workflow and should reduce some confusion.
>> >> > > >
>> >> > > > -James Jong
>> >> > > >
>> >> > > > On Sep 24, 2013, at 3:09 PM, Michal Mocny 
>> >> wrote:
>> >> > > >
>> >> > > >> Just to add, the reason for the "if" statement in step (2) is
>> that
>> >> > > >> uninstall & reinstall take a lot longer than just moving a few
>> >> files,
>> >> > > which
>> >> > > >> is the 99.9% case for most end users who aren't making
>> modifications
>> >> > to
>> >> > > >> plugins.
>> >> > > >>
>> >> > > >> This way, we only do the heavy lifting if your plugin structure
>> >> > actually
>> >> > > >> changed.  Doing it automatically means we no longer have to
>> advise
>> >> >

Re: mobile-spec and releases: How do we test?

[Braden Shepherdson]

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 current
mobile-spec's
- That index reads a file akin to cordova_plugins.js (cordova_tests.js,
maybe?) generated by the CLI, containing the info from the  tags.
- It has navigation similar to the current mobile-spec, with buttons
for the automatic and manual sections. Auto has "All" and then each module,
manual just has the list of modules.

Thoughts?

Braden


On Thu, Sep 26, 2013 at 6:33 AM, Carlos Santana wrote:

> 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 to include
> information about testing (i.e. Directory containing tests files, test
> command, etc..)
>
> --Carlos
>
> On Thursday, September 26, 2013, Anis KADRI wrote:
>
> > 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 the plugins. Its been talked about, but not gone anywhere.
> > >
> > > David Kemp
> > >
> > >
> > > On Wed, Sep 25, 2013 at 7:58 PM, Jesse  >
> > wrote:
> > >
> > >> Yeah, I have pushed some changes to mobile-spec, and when I did I also
> > >> copied the tests into the plugin involved.
> > >> Until we get the magic test runner happening, I think we just keep
> > >> duplicating.
> > >>
> > >> @purplecabbage
> > >> risingj.com
> > >>
> > >>
> > >> On Wed, Sep 25, 2013 at 4:38 PM, Steven Gill  
> > >
> > >> wrote:
> > >>
> > >> > We copied over tests into plugins when we first broke them out, but
> I
> > >> don't
> > >> > believe they have been updated.
> > >> >
> > >> > I would say for now to just add the tests to mobile spec, and
> > possibly in
> > >> > the future we go all voltron to build mobile spec and keep tests
> with
> > >> their
> > >> > corresponding plugins.
> > >> >
> > >> >
> > >> > On Wed, Sep 25, 2013 at 4:22 PM, Joe Bowser  >
> > wrote:
> > >> >
> > >> > > Hey
> > >> > >
> > >> > > Right now, I'm working on a weird file issue that requires me to
> > >> > > update mobile-spec, but I'm wondering where the tests should live.
> > >> > > Should it all keep living in mobile-spec, or is it with the
> plugins.
> > >> > > And if it's with the plugins, will there be scripts to assemble
> > >> > > mobile-spec all Voltron style?
> > >> > >
> > >> > > This came up earlier, but I haven't found any fix that needed a
> > >> > > mobile-spec test.  (Many that need native testing, like recursive
> > file
> > >> > > copy, etc).  Any thoughts?
> > >> > >
> > >> > > Joe
> > >> > >
> > >> >
> > >>
> >
>
>
> --
> Carlos Santana
> 
>

w3c DAP WG discussing vibration strength

[Lisa Seacat DeLuca]

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 vibration spec?

proposal example:

Vibration API strength proposal with stair-stepping/smooth volume 
reduce/increase:

navigator.vibrate([
{
"time": 200, // Required property.
"volume": [0, 80] // Minimum 0, maximum 100, default 100. [0, 80] smooth 
volume increase - starts volume strength at 0 and smoothly increases to 80 
till end.
},
{
"time": 1000, // 1000 ms
"delay": 50, // Will start vibrate after 50 ms. Default 0 ms
"volume": [0, 100, 0] // Smooth volume reduce-increas-reduce - starts at 
0, smoothly increases to 100 in 50 ms and smooth reduce to 0 at end.
},
{
"time": 200,
"volume": [50] // Stair-stepping volume - will start and end volume 
strength 50.
}
]);

or the same in simplified version without strings:

navigator.vibrate([{200, [0, 80]}, {1000, 50, [0, 100, 0]}, {200, [50]}]); 



Lisa Seacat DeLuca
ldel...@apache.org

Re: Updating plugin code on prepare

[Braden Shepherdson]

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 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 know
> that it's on the wish list.
>
> As far as the original proposal, I believe it is a descent temporary
> solution for plugin developers who want to use cordova-cli.
>
> On Wed, Sep 25, 2013 at 7:17 PM, Michal Mocny  wrote:
> > Braden, thats has been on the wish list (cordova watch), but I suspect
> Anis
> > was suggesting something different with plugman --watch, to do
> specifically
> > with plugin development.  Am I right, Anis?  How does your idea compare
> > with using --link with cordova watch?  Would plugman --watch be useful
> for
> > non cli projects?
> >
> > -Michal
> >
> >
> > On Wed, Sep 25, 2013 at 10:31 AM, Braden Shepherdson <
> bra...@chromium.org>wrote:
> >
> >> We've had a vague feature planned for a while now to do a cordova
> watch. It
> >> would watch your plugins/, www/, and merges/* for any changes. If any
> >> changes are detected, it would re-run cordova prepare, so that your
> native
> >> projects are always up-to-date.
> >>
> >> I'm open to checking (hashes?) which files have changed and which have
> not,
> >> but hashing them all is touching them all anyway, and it might be faster
> >> for small files to just copy them instead of checking first. We'll have
> to
> >> try it and see; for v1 I'm going with the simple option of copying
> >> everything.
> >>
> >> Braden
> >>
> >>
> >> On Wed, Sep 25, 2013 at 9:44 AM, Michal Mocny 
> wrote:
> >>
> >> > The idea for plugin dev outside of plugins/ folder was to use "plugin
> add
> >> > --link".  Matter of fact, braden suggested that "plugin create" should
> >> > default to --link-ing to some external location so that you don't risk
> >> > deleting your only copy inside plugins/.  (I personally don't think
> >> thats a
> >> > necessary concern, but I think its a conversation for later).
> >> >
> >> > I'm not even sure what a 'watch' would do, just uninstall & install
> each
> >> > time the plugin changes?  I think that ends up being just slightly
> worse
> >> > than the current proposal if you factor in that we already do support
> >> > --link (except without the above change its been useless).
> >> >
> >> >
> >> > However, we may still want some form of 'watch' command for devs using
> >> > plugman directly.  I had assumed that those devs just edit in place,
> >> since
> >> > they don't use a prepare step anyway.
> >> >
> >> > -Michal
> >> >
> >> >
> >> >
> >> > On Wed, Sep 25, 2013 at 7:50 AM, Anis KADRI 
> >> wrote:
> >> >
> >> > > If we're talking about developing plugins inside the
> >> > > plugins/org.myplugin.id folder than I think it's a great workflow
> and
> >> > > I would just hide the cached version of plugin.xml inside that
> >> > > plugins/org.myplugin.id folder.
> >> > >
> >> > > However, if you're developing a plugin outside of a cordova CLI
> >> > > project, I think a `watch` (and add --watch) command is more
> >> > > appropriate. One of the reasons you would develop a plugin outside
> of
> >> > > a cordova CLI project is for easier version control (each plugin
> would
> >> > > have its own repository). The other cool thing about `watch` is that
> >> > > it would copy the files that have actually changed and not
> everything
> >> > > (some plugins have a LOT of files [1]).
> >> > >
> >> > > [1] https://github.com/phonegap/phonegap-facebook-plugin
> >> > >
> >> > > On Wed, Sep 25, 2013 at 3:30 AM, James Jong 
> >> > wrote:
> >> > > > +1 This is a cleaner workflow and should reduce some confusion.
> >> > > >
> >> > > > -James Jong
> >> > > >
> >> > > > On Sep 24, 2013, at 3:09 PM, Michal Mocny 
> >> wrote:
> >> > > >
> >> > > >> Just to add, the reason for the "if" statement in step (2) is
> that
> >> > > >> uninstall & reinstall take a lot longer than just moving a few
> >> files,
> >> > > which
> >> > > >> is the 99.9% case for most end users who aren't making
> modifications
> >> > to
> >> > > >> plugins.
> >> > > >>
> >> > > >> This way, we only do the heavy lifting if your plugin structure
> >> > actually
> >> > > >> changed.  Doing it automatically means we no longer have to
> advise
> >> > users
> >> > > >> that making edits inside plugin/ folder is useless.  Now we just
> >> > advise
> >> > > >> them to run "prepare" after making changes to either www/ or
> >> plugins/.
> >> > > >>
> >> > > >> This key insight was Braden's idea and I think its just an
> awesome
> >> > > change
> >> > > >> for workflow.
> >> > > >>
> >> > > >> -Michal
> >> > > >>
> >> > > >>
> >> > > >> On Tue, Sep 24, 2013 at 2:58 PM, Braden Shepherdson <
> >> > > bra...

Re: config.xml discussion, we need to talk

[Braden Shepherdson]

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 from res/xml/foo.xml, so
that's where we put it. We should be deleting the
platforms/android/assets/www/config.xml though, since it's an unused
duplicate and confusing.

Braden


On Wed, Sep 25, 2013 at 4:59 PM, Carlos Santana wrote:

> I was not trying to be purist with the w3c www/config.xml
>
> I just want to see some consistency across all platforms for configuration
> settings for a Cordova App.
>
> The same way I have a single index.html, app.css and app.js. I want see one
> config.xml for all platforms inside www/ or many config.xml per platform
> config.ios.xml, config.android.xml, etc... But as a web developer I'm
> excepting all the files that I need to modify inside www/ using CLI or not
>
> Even if I have to run something like ./bin/processconfig.sh to propagate
> changes from the /www/config.xml
>
> As web developer I might update the config.xml once for every 100 edits to
> my app web files (HTML, JS, CSS)
>
> TLDR: consistency wins over correctness
>
> PS: what is the phonegap team doing? I think you tell users to edit one
> config.xml for the web app and pgbuild takes care of the rest
>
>
> -- Carlos
>
> On Wednesday, September 25, 2013, Braden Shepherdson wrote:
>
> > I'm in favour of CLI (platform parsers, probably) deleting this
> > www/config.xml that they don't use. It's a waste of space and has
> confused
> > people in the past.
> >
> > It even confused the iOS prepare code and caused that odd "my project
> > doesn't work if it starts with x, y or z" bug (because xFactor/config.xml
> > sorts after www/config.xml, and it was blindly taking the first one).
> >
> > Braden
> >
> >
> > On Wed, Sep 25, 2013 at 4:22 PM, Bryan Higgins  
> > >wrote:
> >
> > > Thanks for the clarification. BlackBerry happened to luck out because
> we
> > > expect config.xml in www.
> > >
> > > Perhaps copying of config.xml should become a responsibility of the
> > > platform parsers.
> > >
> > > I can understand moving config.xml to root or cordova for the reason
> > stated
> > > in the JIRA, but my vote would be to keep it "config.xml" rather than
> > > "app.xml".
> > >
> > >
> > > On Wed, Sep 25, 2013 at 3:55 PM, Jesse 
> wrote:
> > >
> > > > I am not saying deviate, I am saying, what is it supposed to be? If
> you
> > > > look at the various platforms you will see it is all over the map.
> > > >
> > > > Looking at Android code, and talking to Joe, the only location that
> the
> > > > config.xml file is loaded from is in res/xml, and the fact that
> > > cordova-cli
> > > > creates another one sitting in the www folder is just irrelevant
> > > > sloppiness.
> > > >
> > > > It may make sense for the config.xml file to sit in the root/www
> folder
> > > of
> > > > the CLI project, but in reality at runtime, it's location will vary
> by
> > > > platform.
> > > >
> > > >
> > > >
> > > > @purplecabbage
> > > > risingj.com
> > > >
> > > >
> > > > On Wed, Sep 25, 2013 at 12:29 PM, Bryan Higgins <
> > bhigg...@blackberry.com
> > > > >wrote:
> > > >
> > > > > www/config.xml aligns nicely with the w3c widget spec [1]. Why
> would
> > we
> > > > > want to deviate?
> > > > >
> > > > > [1] http://www.w3.org/TR/widgets/#reserved-file-and-folder-names
> > > > >
> > > > >
> > > > > On Wed, Sep 25, 2013 at 3:23 PM, Jesse 
> > > wrote:
> > > > >
> > > > > > Seems any project created with the CLI has a config.xml in the
> www
> > > > > folder.
> > > > > > [1]
> > > > > > Why do we have 2 of these?
> > > > > >
> > > > > > I also recently closed a defect created by Carlos, stating that
> WP8
> > > did
> > > > > NOT
> > > > > > have it's config.xml in the www folder. [2] Now I am not sure I
> > > should
> > > > > have
> > > > > > called this invalid, however, after creating a new WP8 project
> with
> > > the
> > > > > > CLI, I see a config.xml in the www folder AND one in the app
> root.
> > > wtf?
> > > > > >
> > > > > > There is an open issue [3] to re-org config files, where Braden
> > > states
> > > > > "We
> > > > > > already have plans to move $PROJECT/www/config.xml to
> > > $PROJECT/app.xml,
> > > > > > which more or less addresses ..."Have we formalized what
> > exactly
> > > > this
> > > > > > is?
> > > > > >
> > > > > > Seems we still have a lot of discussion that has to happen before
> > we
> > > > can
> > > > > > move ahead on these items.  I am currently adding config.xml
> > support
> > > to
> > > > > > Windows 8, and was hoping to have a nice clear path of what to
> do,
> > > but
> > > > it
> > > > > > still looks pretty muddy. [4]
> > > > > >
> > > > > >
> > > > > > [1] https://issues.apache.org/jira/browse/CB-4476
> > > > > > [2] https://issues.apache.org/jira/browse/CB-46<
> > > > > > https://issues.apache.org/jira/

Re: mobile-spec and releases: How do we test?

[Carlos Santana]

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 to include
information about testing (i.e. Directory containing tests files, test
command, etc..)

--Carlos

On Thursday, September 26, 2013, Anis KADRI wrote:

> 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 the plugins. Its been talked about, but not gone anywhere.
> >
> > David Kemp
> >
> >
> > On Wed, Sep 25, 2013 at 7:58 PM, Jesse 
> > >
> wrote:
> >
> >> Yeah, I have pushed some changes to mobile-spec, and when I did I also
> >> copied the tests into the plugin involved.
> >> Until we get the magic test runner happening, I think we just keep
> >> duplicating.
> >>
> >> @purplecabbage
> >> risingj.com
> >>
> >>
> >> On Wed, Sep 25, 2013 at 4:38 PM, Steven Gill 
> >> 
> >
> >> wrote:
> >>
> >> > We copied over tests into plugins when we first broke them out, but I
> >> don't
> >> > believe they have been updated.
> >> >
> >> > I would say for now to just add the tests to mobile spec, and
> possibly in
> >> > the future we go all voltron to build mobile spec and keep tests with
> >> their
> >> > corresponding plugins.
> >> >
> >> >
> >> > On Wed, Sep 25, 2013 at 4:22 PM, Joe Bowser 
> >> > >
> wrote:
> >> >
> >> > > Hey
> >> > >
> >> > > Right now, I'm working on a weird file issue that requires me to
> >> > > update mobile-spec, but I'm wondering where the tests should live.
> >> > > Should it all keep living in mobile-spec, or is it with the plugins.
> >> > > And if it's with the plugins, will there be scripts to assemble
> >> > > mobile-spec all Voltron style?
> >> > >
> >> > > This came up earlier, but I haven't found any fix that needed a
> >> > > mobile-spec test.  (Many that need native testing, like recursive
> file
> >> > > copy, etc).  Any thoughts?
> >> > >
> >> > > Joe
> >> > >
> >> >
> >>
>


-- 
Carlos Santana

Re: Major refactoring of Plugman and CLI

[Tommy Williams]

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 shell.exec
> because it leaks filehandles and sometimes causes fatal errors.
> - I adopted promises to control the horribly deep callback trees we were
> building up.
> - That improved the code so much that it spread to the rest of the tools
> and became a large refactoring.
> - I was worried that I now needed to bring this up with the list and get
> buy-in, since it had become bigger than fixing a few bugs.
> - On consulting with the others who happened to be in the room at the time,
> the feeling was that since the outside API hadn't changed, this was fine.
> Bug fixes and code cleanup don't need buy-in from everyone. However, I
> should definitely announce the change.
> - Here we are.
>
> I guess I haven't found the balance of what should be done silently, what
> announced as it goes out, and what discussed ahead of time. Since the
> feeling is that this should have been mentioned in advance, I will adjust
> in the future.
>
> Braden
>
> On Tue, Sep 24, 2013 at 2:20 PM, Shazron  wrote:
>
> > Definitely. Talking about changes is cool, not talking about it -- not
> > cool.
> >
> >
> > On Tue, Sep 24, 2013 at 11:01 AM, purplecabbage  > >wrote:
> >
> > > Q is a good choice. Not talking about it was absolutely the wrong
> choice.
> > > There are no internal teams , there is only this list.
> > >
> > > Sent from my iPhone
> > >
> > > > On Sep 24, 2013, at 6:48 AM, Braden Shepherdson  >
> > > wrote:
> > > >
> > > > We debated internally at Google how much to talk about this. In the
> end
> > > we
> > > > decided that since the external APIs were not changing, this could be
> > > > claimed as an internal refactoring. I'm not sure whether that was the
> > > right
> > > > call.
> > > >
> > > > About fetch and platforms, to be clear, those are far from the only
> > > modules
> > > > that have changes, they're just the examples I chose. Using almost
> any
> > of
> > > > the internal modules directly will require refactoring.
> > > >
> > > > Braden
> > > >
> > > >
> > > >> On Tue, Sep 24, 2013 at 6:56 AM, Anis KADRI 
> > > wrote:
> > > >>
> > > >> cool.
> > > >>
> > > >> I don't think we're using fetch/platforms directly.
> > > >>
> > > >> -a
> > > >>
> > > >>> On Tue, Sep 24, 2013 at 11:35 AM, Brian LeRoux  wrote:
> > > >>> Kewl. I'm down and happen to really like Q. Not sure everyone will
> > > agree.
> > > >>> Maybe next time a heads up to the list so we can discuss arch
> changes
> > > >> like
> > > >>> this.
> > > >>>
> > > >>>
> > > >>> On Mon, Sep 23, 2013 at 8:13 PM, Braden Shepherdson <
> > > bra...@chromium.org
> > > >>> wrote:
> > > >>>
> > >  Whoops, I forgot to mention, I created and pushed a cordova-3.1.x
> > > >> branch of
> > >  both tools before merging this; fixes for the 3.1.0 release should
> > be
> > > in
> > >  there. I don't intend to launch the refactored code to NPM until
> > we've
> > > >> had
> > >  at least a week of trying it out.
> > > 
> > >  Braden
> > > 
> > > 
> > >  On Mon, Sep 23, 2013 at 2:08 PM, Braden Shepherdson <
> > > >> bra...@chromium.org
> > > > wrote:
> > > 
> > > > tl;dr: Plugman and CLI now uses Q.js[1] Promises internally
> instead
> > > of
> > > > callbacks. This has significantly clarified and shortened the
> code.
> > > >> The
> > > > public API (plugman.fetch, cordova.platform, etc.) HAVE NOT
> > changed!
> > > >
> > > > If you use CLI on the command line, nothing has changed.
> > > >
> > > > If you downstream CLI and/or Plugman, but use cordova.foo and
> > >  plugman.foo,
> > > > nothing has changed (except possibly that a few calls are a bit
> > more
> > >  async
> > > > than before, so code that cheats and pretends they're sync might
> > fail
> > >  now).
> > > >
> > > > If you downstream either one, but require internal modules like
> > > >> fetch.js
> > > > or platform.js directly, you should stop doing that and use
> > > >> plugman.fetch
> > > > etc. instead. If you want to continue calling them directly,
> you'll
> > > >> need
> > >  to
> > > > port to use promises.
> > > >
> > > > If you've been working on Plugman or CLI and I just broke
> > everything,
> > >  feel
> > > > free to yell at me on IRC (#cordova, shepheb) or Gtalk (braden at
> > > >> google
> > > > dot com) or email. It's not hard to port things to handle
> promises
> > > >> (see
> > > > below), and their basic use is not hard to understand (see the
> > >  tutorial[1]).
> > > >
> > > > If you really do need to port something, and you used to do a
> > > function
> > > > call like this:
> > > >
> > > > whateverFunc(args..., function(err){
> >

Re: Updating plugin code on prepare

[Anis KADRI]

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 know
that it's on the wish list.

As far as the original proposal, I believe it is a descent temporary
solution for plugin developers who want to use cordova-cli.

On Wed, Sep 25, 2013 at 7:17 PM, Michal Mocny  wrote:
> Braden, thats has been on the wish list (cordova watch), but I suspect Anis
> was suggesting something different with plugman --watch, to do specifically
> with plugin development.  Am I right, Anis?  How does your idea compare
> with using --link with cordova watch?  Would plugman --watch be useful for
> non cli projects?
>
> -Michal
>
>
> On Wed, Sep 25, 2013 at 10:31 AM, Braden Shepherdson 
> wrote:
>
>> We've had a vague feature planned for a while now to do a cordova watch. It
>> would watch your plugins/, www/, and merges/* for any changes. If any
>> changes are detected, it would re-run cordova prepare, so that your native
>> projects are always up-to-date.
>>
>> I'm open to checking (hashes?) which files have changed and which have not,
>> but hashing them all is touching them all anyway, and it might be faster
>> for small files to just copy them instead of checking first. We'll have to
>> try it and see; for v1 I'm going with the simple option of copying
>> everything.
>>
>> Braden
>>
>>
>> On Wed, Sep 25, 2013 at 9:44 AM, Michal Mocny  wrote:
>>
>> > The idea for plugin dev outside of plugins/ folder was to use "plugin add
>> > --link".  Matter of fact, braden suggested that "plugin create" should
>> > default to --link-ing to some external location so that you don't risk
>> > deleting your only copy inside plugins/.  (I personally don't think
>> thats a
>> > necessary concern, but I think its a conversation for later).
>> >
>> > I'm not even sure what a 'watch' would do, just uninstall & install each
>> > time the plugin changes?  I think that ends up being just slightly worse
>> > than the current proposal if you factor in that we already do support
>> > --link (except without the above change its been useless).
>> >
>> >
>> > However, we may still want some form of 'watch' command for devs using
>> > plugman directly.  I had assumed that those devs just edit in place,
>> since
>> > they don't use a prepare step anyway.
>> >
>> > -Michal
>> >
>> >
>> >
>> > On Wed, Sep 25, 2013 at 7:50 AM, Anis KADRI 
>> wrote:
>> >
>> > > If we're talking about developing plugins inside the
>> > > plugins/org.myplugin.id folder than I think it's a great workflow and
>> > > I would just hide the cached version of plugin.xml inside that
>> > > plugins/org.myplugin.id folder.
>> > >
>> > > However, if you're developing a plugin outside of a cordova CLI
>> > > project, I think a `watch` (and add --watch) command is more
>> > > appropriate. One of the reasons you would develop a plugin outside of
>> > > a cordova CLI project is for easier version control (each plugin would
>> > > have its own repository). The other cool thing about `watch` is that
>> > > it would copy the files that have actually changed and not everything
>> > > (some plugins have a LOT of files [1]).
>> > >
>> > > [1] https://github.com/phonegap/phonegap-facebook-plugin
>> > >
>> > > On Wed, Sep 25, 2013 at 3:30 AM, James Jong 
>> > wrote:
>> > > > +1 This is a cleaner workflow and should reduce some confusion.
>> > > >
>> > > > -James Jong
>> > > >
>> > > > On Sep 24, 2013, at 3:09 PM, Michal Mocny 
>> wrote:
>> > > >
>> > > >> Just to add, the reason for the "if" statement in step (2) is that
>> > > >> uninstall & reinstall take a lot longer than just moving a few
>> files,
>> > > which
>> > > >> is the 99.9% case for most end users who aren't making modifications
>> > to
>> > > >> plugins.
>> > > >>
>> > > >> This way, we only do the heavy lifting if your plugin structure
>> > actually
>> > > >> changed.  Doing it automatically means we no longer have to advise
>> > users
>> > > >> that making edits inside plugin/ folder is useless.  Now we just
>> > advise
>> > > >> them to run "prepare" after making changes to either www/ or
>> plugins/.
>> > > >>
>> > > >> This key insight was Braden's idea and I think its just an awesome
>> > > change
>> > > >> for workflow.
>> > > >>
>> > > >> -Michal
>> > > >>
>> > > >>
>> > > >> On Tue, Sep 24, 2013 at 2:58 PM, Braden Shepherdson <
>> > > bra...@chromium.org>wrote:
>> > > >>
>> > > >>> Michal and I were discussing how to make the plugin developer
>> > > experience
>> > > >>> better, by having `cordova prepare` update the platform projects
>> > > properly
>> > > >>> when you change a plugin in place.
>> > > >>>
>> > > >>> I propose the following changes:
>> > > >>>
>> > > >>> 1. On plugin install, we cache the plugin.xml in $PROJECT/.cordova
>> > > >>> somewhere.
>> > > >>> 2. On 'cordova prepare'

Re: mobile-spec and releases: How do we test?

[Anis KADRI]

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 the plugins. Its been talked about, but not gone anywhere.
>
> David Kemp
>
>
> On Wed, Sep 25, 2013 at 7:58 PM, Jesse  wrote:
>
>> Yeah, I have pushed some changes to mobile-spec, and when I did I also
>> copied the tests into the plugin involved.
>> Until we get the magic test runner happening, I think we just keep
>> duplicating.
>>
>> @purplecabbage
>> risingj.com
>>
>>
>> On Wed, Sep 25, 2013 at 4:38 PM, Steven Gill 
>> wrote:
>>
>> > We copied over tests into plugins when we first broke them out, but I
>> don't
>> > believe they have been updated.
>> >
>> > I would say for now to just add the tests to mobile spec, and possibly in
>> > the future we go all voltron to build mobile spec and keep tests with
>> their
>> > corresponding plugins.
>> >
>> >
>> > On Wed, Sep 25, 2013 at 4:22 PM, Joe Bowser  wrote:
>> >
>> > > Hey
>> > >
>> > > Right now, I'm working on a weird file issue that requires me to
>> > > update mobile-spec, but I'm wondering where the tests should live.
>> > > Should it all keep living in mobile-spec, or is it with the plugins.
>> > > And if it's with the plugins, will there be scripts to assemble
>> > > mobile-spec all Voltron style?
>> > >
>> > > This came up earlier, but I haven't found any fix that needed a
>> > > mobile-spec test.  (Many that need native testing, like recursive file
>> > > copy, etc).  Any thoughts?
>> > >
>> > > Joe
>> > >
>> >
>>

Re: 3.1 Release

[Anis KADRI]

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 send a review request for the plugin release blog once I finish
> it tomorrow.
>
> Tracking everything at https://issues.apache.org/jira/browse/CB-4915
>
> -Steve
>
>
> On Wed, Sep 25, 2013 at 10:26 AM, Steven Gill wrote:
>
>> Michael,
>>
>> Good point. I think the issue arrises if some of our users keep using 3.0,
>> install plugins using the git url (master branch) and then try to remove
>> the plugins using the 3.0 documentation. When the master branch gets
>> updated, it won't have core in the ID. This will make the remove
>> instructions incorrect.
>>
>> An upgrade guide/blog post actually sounds like the best way to handle
>> this issue.
>>
>> I am going to pick up where Anis left of and aim to do a plugin release
>> later this afternoon
>>
>> -Steve
>>
>>
>> On Wed, Sep 25, 2013 at 6:45 AM, Carlos Santana wrote:
>>
>>> It could be a doc or or blog post, I would suggest blog post for plugins
>>> for more details about dealing with registry since those have a faster
>>> pace
>>>
>>> --Carlos
>>>
>>>
>>>
>>> On Wed, Sep 25, 2013 at 9:43 AM, Carlos Santana >> >wrote:
>>>
>>> > Would suggest we document a simple workflow document "Upgrade Guide
>>> > Cordova CLI/PlugMan 3.0 to 3.1"
>>> > Same way that we do for the platforms on going over the details in a
>>> > single document.
>>> >
>>> > --Carlos
>>> >
>>> >
>>> > On Wed, Sep 25, 2013 at 9:38 AM, Michal Mocny 
>>> wrote:
>>> >
>>> >> I think the 3.0 instructions of removing the old plugin with the old ID
>>> >> remain correct even after we update the registry.  Thats because when
>>> >> removing plugins from a workspace you use the ID of whats locally
>>> >> installed.
>>> >>
>>> >> So, to upgrade, users would have the use the 3.0 uninstall guide and
>>> the
>>> >> 3.1 install guide.. I think?
>>> >>
>>> >> -Michal
>>> >>
>>> >>
>>> >> On Wed, Sep 25, 2013 at 7:31 AM, Anis KADRI 
>>> wrote:
>>> >>
>>> >> > That's a good summary. I am going to be fixing the reference problem
>>> >> > shortly and merge them back to the `dev` branch. Not sure if all of
>>> >> > Jesse's changes have made it to the `dev` branch yet.
>>> >> >
>>> >> > The `edge` docs have already been updated (see CB-4493)
>>> >> >
>>> >> > The `3.0` docs will have to be updated once we merge `dev` back to
>>> >> > `master` (which I hope we will before we release 3.1).
>>> >> >
>>> >> >
>>> >> > On Wed, Sep 25, 2013 at 1:25 AM, Steven Gill >> >
>>> >> > wrote:
>>> >> > > I realize why Anis decided to do a new branch (3.1.0) because he
>>> >> didn't
>>> >> > > want to mess up dev/master. Before we release 3.1.0 we need to do a
>>> >> > plugin
>>> >> > > release based off of
>>> >> > http://wiki.apache.org/cordova/StepsForPluginRelease.
>>> >> > > Jesse has changes for the plugins that he has pushed to dev now
>>> based
>>> >> on
>>> >> > > this email thread. He needs these changes to be in the next plugin
>>> >> > release
>>> >> > > we are doing for the 3.1.0 release.
>>> >> > >
>>> >> > > If I am understanding this correctly, removing core from ID was not
>>> >> > > something we want in master due to 3.0.0 support. But this ID
>>> change
>>> >> > should
>>> >> > > have been done on dev before creating the 3.1.0 branch. The 3.0.0
>>> docs
>>> >> > get
>>> >> > > users to install plugins using the git url. The problem is that the
>>> >> 3.0.0
>>> >> > > docs instruct our users to use the ID for plugin removal. Obviously
>>> >> if we
>>> >> > > change the ID, the remove documentation for 3.0.0 would be wrong.
>>> >> > >
>>> >> > > We have two options here as far as I can tell
>>> >> > >
>>> >> > > 1) Leave master alone for the next month or two and give people
>>> time
>>> >> to
>>> >> > > migrate to 3.1
>>> >> > > 2) Update the 3.0 documentation to refer to updated id, Push the
>>> >> updated
>>> >> > ID
>>> >> > > to dev then master.
>>> >> > >
>>> >> > > Things that need to be done
>>> >> > >  - Fix incorrect references to the old ID (last comment on
>>> >> > > https://issues.apache.org/jira/browse/CB-4889)
>>> >> > >  - Merge these changes into dev (they really should be on dev if
>>> that
>>> >> is
>>> >> > > where we all the work done)
>>> >> > >  - Follow steps on
>>> >> http://wiki.apache.org/cordova/StepsForPluginReleaseand
>>> >> > > publish these plugins on our registry. This should include Jesse's
>>> >> work
>>> >> > as
>>> >> > > well.
>>> >> > >  - Update edge docs to refer to registry for plugin installation
>>> (not
>>> >> > sure
>>> >> > > if this has been done)
>>> >> > >  - Update 3.0.0 documentation if we decide option 2 from above is
>>> the
>>> >> way
>>> >> > > to go
>>> >> > >  - Tag docs 3.1.0-rc1
>>> >> > >
>>> >> > > I volunteer to take the lead on getting the plugins rele