+ 1 love "watch command" idea :)
Best Regards!
On 2013-9-3, at 上午7:34, Brian LeRoux wrote:
> automate
> add/remove with some sort of watch command. That way ppl are writing to the
> plugin spec from the beginning instead of refactoring a plugin out of a
> native project.
+ 1 It's great
Best Regards!
On 2013-9-3, at 上午8:37, Brian LeRoux wrote:
> love this idea
>
>
> On Sat, Aug 31, 2013 at 2:36 PM, Jonathan Bond-Caron <
> jbo...@gdesolutions.com> wrote:
>
>> Setting up the mobile spec app was tedious since I didn't know the
>> dependencies.
>>
>> I wrote
Hey Bruno,
There are speech recognition plugins available for Android but to my
knowledge none of them provide access to the audio input stream on the
fly. So, you'd need to write that yourself.
http://docs.phonegap.com/en/3.0.0/guide_hybrid_plugins_index.md.html#Plugin%20Development%20Guide
Sim
Good news!
I have a branch that is booting projects made with cordova 3.0 [1].
It is basically a stripped down platform and I tested it booting a project
with android and ios.
To run:
> cordova create Baz
> cordova platform add android
> cordova prepare
> ripple emulate
(make sure you pick cor
love this idea
On Sat, Aug 31, 2013 at 2:36 PM, Jonathan Bond-Caron <
jbo...@gdesolutions.com> wrote:
> Setting up the mobile spec app was tedious since I didn't know the
> dependencies.
>
> I wrote a small patch that allows to pull a plugin from a git subdirectory
> e.g. cordova plugin add
> ht
Another use case is configuration meta data for native projects. Anyhow,
look fwd to the proposal.
On Wed, Aug 28, 2013 at 10:49 AM, Braden Shepherdson wrote:
> So we have several bugs[1][2][3] about fixing the handling of config.xml
> and of upgrading CLI projects. Upgrading platforms is hard b
+1
I am surprised that once a plugin has been added to ./platforms/**/* it is
never refreshed from the version in ./plugins/**/*
It means that plugin dev has to happen in ./platforms instead of in ./plugins
at the very least. If I could create a plugin or even add a scaffold of a
plugin to ./p
So, first of all I agree, this is probably the ideal flow today. A good
reason for this list is to figure out how we can make the best possible
developer experience going forward. With the Discovery side of things all
but deployed I'd love for us to look at making this part a little more sane
for o
