I don't think there's a better place for that transition than moving to
3.0, though. It's already a huge change with the CLI and plugins and the
rest. Also one of the key advantages to splitting up the core into plugins
is that we wanted to separate the permissions so that Cordova apps don't
ask
Permissions require more clever handling than naive XML injection. I'll be
talking about that somewhat later. Permissions on Android need de-duping,
and making sure that deleting one plugin that requires permission X doesn't
remove that permission if another plugin still needs it.
Braden
On
+1 to killing WebSQL after we have IndexedDB support. It's no longer the
standard and only exists in Webkit. The IndexedDB support doesn't exist at
all in Android browser or iOS Safari though (a surprise to me, at least),
according to caniuse.com[1]
It isn't our job to maintain APIs that have
+1 to templates and a plugin creation command.
I don't like the idea of the friction to switch to JSON - a big change to
both tools and to our existing plugins - but I despise XML with the fury of
a thousand suns. I would be happy to make the switch to JSON, for my
plugins and in both tools.
+1
A big +1 from me for this world, Michal's option 2.
I want to be able to cordova create some-git-URL, and have it create an
empty project where the app/ directory is the git repo.
Then a full project might look like this:
platforms/
android/
ios/
plugins/
...
app/
merges/
+1 for app folder and cordova create app location
I would like to see it support a git-URL or local. It's nice to have it all
neatly in app/ but can also see arguments for having www/ as top-level.
-James Jong
On Mar 25, 2013, at 10:32 AM, Braden Shepherdson bra...@chromium.org wrote:
A
+1 for Geolocation
Joe's reasoning is convincing: when native functionality exceeds/matches
what were providing, what's the point?
and a huge +1 for WebSQL, I believe W3C deprecated the spec in November
2011? 2010?! http://www.w3.org/TR/webdatabase/
Being proactive about this and
The thing that worries me about killing our websql support is that we
will get a situation where websql will be available on some versions
of Android but not on others because we have removed our polyfil.
Simon Mac Donald
http://hi.im/simonmacdonald
On Mon, Mar 25, 2013 at 12:12 PM, Lorin Beer
it's a valid point, and I'm not too sure how to handle that. Deprecating
our polyfill would be the obvious suggestion, but the whole point is to let
these plugins die, not continue to include potentially broken/breakable
code in future releases.
How far back does WebSQL support go on Droid?
On
Is there some magic script to create all the sub issues for the platform?
Fil added one recently in cordova-labs. See README.md here:
https://git-wip-us.apache.org/repos/asf?p=cordova-labs.git;a=tree;h=refs/heads/jira;hb=refs/heads/jira
-James Jong
On Mar 24, 2013, at 9:23 PM, Simon
Originally it was for the 1.x stream but we found out we needed it for
some broken implementations of Android 3.0 and one of the Android 4.x
versions as well.
Simon Mac Donald
http://hi.im/simonmacdonald
On Mon, Mar 25, 2013 at 12:24 PM, Lorin Beer lorin.beer@gmail.com wrote:
it's a valid
So, what if you want to version the ./platorms folder? I don't like
it, but ppl will do.
On Mon, Mar 25, 2013 at 9:10 AM, James Jong wjamesj...@gmail.com wrote:
+1 for app folder and cordova create app location
I would like to see it support a git-URL or local. It's nice to have it all
(Btw this isn't a vote thread guys.)
On Mon, Mar 25, 2013 at 9:37 AM, Brian LeRoux b...@brian.io wrote:
So, what if you want to version the ./platorms folder? I don't like
it, but ppl will do.
On Mon, Mar 25, 2013 at 9:10 AM, James Jong wjamesj...@gmail.com wrote:
+1 for app folder and
hrm, that makes things trickier. Our deprecation policy is officially 3
releases now, yeah?
It strikes me that the solution is to still deprecate WebSQL and push
for IndexedDB
support.
Please correct me if I'm wrong, but deprecating WebSQL won't affect any
releases out in the wild with the
I think its useful for us to have the conversation, but lets not
forget that we're going to be moving to this plugin reality so what
gets supported and doesn't isn't as big of a deal.
On Mon, Mar 25, 2013 at 9:53 AM, Lorin Beer lorin.beer@gmail.com wrote:
hrm, that makes things trickier. Our
+1 is still a handy means of displaying your support or otherwise.
If you do want to version the platforms/ and plugins/ folders at the top
level, you can do that. If you're versioning everything, then you should be
checking out that master repo, rather than the master repo and then the app
repo
Ok, let me try again. What is precisely problem we are solving by
changing the structure? To be clear, I'm not really against or for it.
I just don't understand why this is important.
On Mon, Mar 25, 2013 at 10:06 AM, Braden Shepherdson
bra...@chromium.org wrote:
+1 is still a handy means of
It allows easier cloning of your app (meaning the www, config.xml, and any
samples and so on) into a self-contained directory. It also lets us keep
the user's app within a single top-level directory (rather than www and
merges and potentially more later).
Because only the www (and merges) would
We currently copy all of www/ into platform www/ so all those resources
ship with the app. For that reason, ideally not all app resources go
inside the www/ folder, such as we've already decided to take merges/ out
(others are docs/ and sample/ etc).
So packaging an app right now already
To be clear, I am certain we all agree, but this is the future. We're
working towards that future. We simply have too many users to not
build the transition path into our releases. Maybe 3.0 is that time.
Four months to move everything to plugins only. We'll see if we make
it.
On Mon, Mar 25,
Four months? I thought we had agreed that 3.0 doesn't come after 2.9, it
comes when we're ready. We can do 2.12 if we need to, or having 2.8
followed by 3.0. Is there some other timeline I don't know about?
Braden
On Mon, Mar 25, 2013 at 1:39 PM, Brian LeRoux b...@brian.io wrote:
To be clear,
But, if you go up one level, the same is true w/ the current
structure. Its just an organizational difference? (Thats a perfectly
ok answer of course. Aesthetics and symmetry are plenty convincing
arguments.)
In my view ./merges isn't your app. The ./merges dir is in parts of
your app on a per
+1 for ./platforms becoming a build artifact.
I totally support this goal Braden.
When we make the platforms/ a build artifact, I'd like to move the
platforms directory to:
/my-app/.cordova/platform/
Michael
On Fri, Mar 22, 2013 at 3:07 PM, Michael Wolf michael.w...@cynergy.comwrote:
While this might be our goal it is in no way true that ./platforms ia
build artifact today or anytime soon.
On Mon, Mar 25, 2013 at 10:55 AM, Braden Shepherdson
bra...@chromium.org wrote:
The same is /not/ true of the current structure, because one (probably)
doesn't want to be committing build
I'm not sure about moving the platforms folder, build artifact or no,
because one may be loading it in Eclipse/Xcode/etc. and burying it in a
hidden folder makes the tools more magical.
One of the other goals here is to make the tools magically convenient
without becoming voodoo. That's the
They are, right now, a kind of middle ground. If you rm -rf'd the
directory, it wouldn't be all better on the next cordova prepare; that's
where we hope to reach soon.
On the other hand, you definitely shouldn't be having code in them - native
or otherwise - that didn't come from a plugin or from
This is for 2.7.0 right? The feature is not in 2.6.0 so it shouldn't be in
2.6.0 docs. (the 2.6.x docs should branch off master before this commit
since it hasn't been created yet)
On Mon, Mar 25, 2013 at 8:37 AM, mwbro...@apache.org wrote:
Updated Branches:
refs/heads/master a897edd1f -
Where does firefox os fit in in here?
On 3/24/13 8:21 PM, Brian LeRoux b...@brian.io wrote:
Thanks Steve!
On Sunday, March 24, 2013, Steven Gill wrote:
Yup
On Sun, Mar 24, 2013 at 2:23 PM, Brian LeRoux b...@brian.io wrote:
Good enough for me. Steve you got that?
On Sat, Mar 23, 2013
Righ so that becomes a plugman responsibility.
This shiet's hard!
On 3/25/13 7:17 AM, Braden Shepherdson bra...@chromium.org wrote:
Permissions require more clever handling than naive XML injection. I'll be
talking about that somewhat later. Permissions on Android need de-duping,
and making
I figure it is not ready to be included in the release yet. Maybe once we
do more work on it + developer devices start getting shipped we can talk
about including it in for exposure.
-Steve
On Mon, Mar 25, 2013 at 11:30 AM, Filip Maj f...@adobe.com wrote:
Where does firefox os fit in in here?
I'm going to guess 'too soon' given there are no platform scripts as
of yet but leave that to Herm to qualify.
On Mon, Mar 25, 2013 at 11:30 AM, Filip Maj f...@adobe.com wrote:
Where does firefox os fit in in here?
On 3/24/13 8:21 PM, Brian LeRoux b...@brian.io wrote:
Thanks Steve!
On
Braden's got this, +1
On 3/25/13 11:20 AM, Braden Shepherdson bra...@chromium.org wrote:
I'm not sure about moving the platforms folder, build artifact or no,
because one may be loading it in Eclipse/Xcode/etc. and burying it in a
hidden folder makes the tools more magical.
One of the other
Hello,
can anybody tell me if it's possible to create Cordova BB10 plugins using
native C++ code ?
Thanks
Andrea
Hi Andrea,
Yes - you will need to write it as a JNEXT extension. You might find this
template handy:
https://github.com/blackberry/WebWorks-Community-APIs/tree/master/BB10/Template
For now you will have to drop it into the ext folder of your webworks app,
but we're working on aligning with the
In seriousness I am excited! We get to talk about everything that
happened this past year. (Lots.)
On Mon, Mar 25, 2013 at 12:42 PM, Andrew Grieve agri...@chromium.org wrote:
Couldn't find the thread, but I also thought there we had discussed having
the 3.0 release == moving to CLI having
Couldn't find the thread, but I also thought there we had discussed having
the 3.0 release == moving to CLI having plugins separated.
I know PhoneGap Day is in July, and I agree 3.0 for PGD is a great goal,
but a major version number bump shouldn't indicate that time has elapsed.
There should be
To be absolutely clear, the above is NOT the motivation for changing this
stuff around. Cordova-cli needs consistency across platforms. This is the
motivation.
Yep, as long as we can guarantee that each script follows a predictable
input and output, I don't care how we implement it.
If you
Check out the other platforms. Things have standardized on
./bin/create and in a generated project ./cordova/*.
On Mon, Mar 25, 2013 at 1:38 PM, Benn Mapes benn.ma...@gmail.com wrote:
Right now most of the scripts for windows phone except create are in
/tooling/scripts/
and there are duplicate
One of the other goals here is to make the tools magically convenient
without becoming voodoo. That's the fundamental goal behind turning
platforms/ into a build artifact: then the answer to what files in here
can I edit, and which ones get updated when I run some command? is an
easy,
Yea, the docs 2.6.x branch will happen before the above commit.
Docs are typically tagged last, in case other platforms want to get in some
last minutes updates. I've been waiting on Windows, but I can go ahead and
create the branch now to avoid confusion.
On Mon, Mar 25, 2013 at 1:10 PM, Filip
K. I'll update my jira helper script to a) axe firefox os from the
core/default platforms and b) add cordova-mac. Thanks guys.
On 3/25/13 11:43 AM, Brian LeRoux b...@brian.io wrote:
I'm going to guess 'too soon' given there are no platform scripts as
of yet but leave that to Herm to qualify.
On
Just like to provide an alternative suggestion to the merges/ directory and
here everyone's thoughts.
While doing client work at Nitobi, each of our build scripts had similar
functionality to merging platform-specific web assets. Below, I'll describe
what I've experienced and make a suggestion on
I think the issue here is: how far do we want to dictate the project
structure for a cordova-cli-generated app?
Merges kind of evolved out of an actual user who needed a viable use
case covered (thanks Michael Wolf!). It is where it is for really no
reason other than this is a good feature to
I'm apprehensive about returning to a naming convention. In a larger
app this would lead to a very cluttered dir.
The other consideration for ./merges are other assets: icons, and
splashscreens. (Which would then require 2x or something for
retina/hdpi situations.)
On Mon, Mar 25, 2013 at 2:34
I agree that this recreation is a goal, but I don't think moving plugins/
under app/ is the right way to do it.
I think the right way to do it is to specify the plugin dependencies of the
app in app/. Currently that means in the documentation or a script, in the
future probably in config.xml.
Hey All,
Last week I did some work around pulling out the Accelerometer plugin from
the cordova-android code and setting up how the plugin repo would look. I
have gone ahead and pushed my work onto the newly created device motion
repo (
Really like this. It a) slims down the cli tools by lazy loading the
libraries as they are needed and b) solves the upgrade/downgrade story,
since eventually you'll be able to simply change the version of the
cordova npm dependency at a project-level.
The only downside (not really) is that every
We already have established spots for scripts.
Global scripts:
cordova-platform/bin/create
cordova-platform/bin/check_reqs (in the works)
Project-level scripts:
Myapp/cordova
Myapp/cordova/lib (soon to come)
On 3/25/13 1:38 PM, Benn Mapes benn.ma...@gmail.com wrote:
Right now most of the
This possibly falls into the category of something that should be on the
Google group (and actually I did ask there too ;) but I think it also
exposes something not documented very well and maybe this discussion can
lead to something that can be added to the docs.
I've worked with the
Precisely! I thought plugin dependancies for apps was already on the
roadmap. Is that request still debatable?
On Mon, Mar 25, 2013 at 6:01 PM, Braden Shepherdson bra...@chromium.orgwrote:
I agree that this recreation is a goal, but I don't think moving plugins/
under app/ is the right way
With respect to the lazy-loading suggestion, I know Brian has raised the
offline scenario on a previous thread.
At install time of the CLI (`npm install -g cordova`), we can lazy-load all
platforms and sample app(s) for a given version.
At install time of the CLI as a library (`npm install
Awesome. So the docs should be updated to say that BB supports close().
Jesse - do you know if WP supports IAB?
On Mon, Mar 25, 2013 at 5:33 PM, Tim Kim timki...@gmail.com wrote:
Ok, I just checked on my blackberry z10.
The close() function works but not events. It seems like there might be
Not at all, I think it would be a great feature to land.
Agree that specifying dependencies in the app manifest, config.xml
currently, is the way to go.
I'm trying to organize the goal/direction of moving to this approach in my
head together with all the other moves we are making. Keeping the
Thanks Fil.
Theres a long list of feature requests we've just pushed on y'all so I
understand.
On Mon, Mar 25, 2013 at 6:31 PM, Filip Maj f...@adobe.com wrote:
Not at all, I think it would be a great feature to land.
Agree that specifying dependencies in the app manifest, config.xml
I feel pretty strongly that we shouldn't try to shove this in for 2.6.0.
Regressions only at this point (since the branches have been cut).
Excited to see progress here though!
by namespace - are you referring to Java namespaces? or plugin IDs?
To answer your question about the JS, refer to
I think Jesse is away - but:
1.
https://github.com/apache/cordova-wp8/commit/d9bd6abece9821201b2784799337430d29247035
2.
https://github.com/apache/cordova-wp7/commit/2a94c1279d929191857ebb2fefca00359823d3ea
... seems to suggest it is supported on WP7 and WP8.
On Mon, Mar 25, 2013 at 3:27 PM,
I don't think it should go in for 2.6.0 as well, for the already mentioned
reasons.
On Mon, Mar 25, 2013 at 3:38 PM, Andrew Grieve agri...@chromium.org wrote:
I feel pretty strongly that we shouldn't try to shove this in for 2.6.0.
Regressions only at this point (since the branches have been
The docs should be a strong suggestion as well.
Cheers,
Jesse
Sent from my iPhone5
On 2013-03-25, at 4:05 PM, Shazron shaz...@gmail.com wrote:
I think Jesse is away - but:
1.
https://github.com/apache/cordova-wp8/commit/d9bd6abece9821201b2784799337430d29247035
2.
firefox os definitely isn't ready yet; we still need to implement more APIs and
I'm still working with Mozilla on improving CLI support.
From: f...@adobe.com
To: dev@cordova.apache.org
Date: Mon, 25 Mar 2013 13:11:10 -0700
Subject: Re: 2.6 platform support and redux
K. I'll update my
RE: Geolocation… wouldn't moving to the browser implementation lead to a sub
par experience when (as I have mentioned) the end user is asked for permission
(in iOS as an example)?
I really wouldn't want users of my apps to have a dialog pop up telling them
that index.html wants something :)
I could be reading your responses wrong but, this does not answer my
proposal, maybe I wasn't clear enough.
For the windows platform there are multiple templates, there is the full
template which includes a dll of the cordovaLib(native code) and a
standalone template which uses the source code.
In this particular case Joe was just speaking about Android.
On 3/25/13 5:45 PM, Tommy-Carlos Williams to...@devgeeks.org wrote:
RE: GeolocationŠ wouldn't moving to the browser implementation lead to a
sub par experience when (as I have mentioned) the end user is asked for
permission (in iOS as
Hey Michael (and anyone else interested),
I've written up a requirements doc for this:
https://docs.google.com/document/d/14LG1IiEiQ9npc2RmPo5_UEKQTfsg-3ivJu7R2iPBmsw/edit?usp=sharing
It's a bit biased towards hosting Chrome Apps, but I think the majority of
the app will be generic. The chrome
Ah. Then I'll shut up ;)
On 26/03/2013, at 11:56 AM, Filip Maj f...@adobe.com wrote:
In this particular case Joe was just speaking about Android.
On 3/25/13 5:45 PM, Tommy-Carlos Williams to...@devgeeks.org wrote:
RE: GeolocationŠ wouldn't moving to the browser implementation lead to a
FYI, my employer does use Windows 8 for our product. So thank you, Jesse!
-- Marcel Kinard
On Mar 24, 2013, at 12:54 AM, Jesse MacFadyen purplecabb...@gmail.com wrote:
+1 for windows 8
Cheers,
Jesse
Would it make sense to add these new repos to the list on
http://cordova.apache.org? The intent is to encourage contributions. I'd be
fine to do that, but wanted to get a sanity check on that first.
-- Marcel
On Mar 22, 2013, at 8:54 PM, Andrew Grieve agri...@google.com wrote:
Would it make sense to add these new repos to the list on
http://cordova.apache.org? The intent is to encourage contributions. I'd
be fine to do that, but wanted to get a sanity check on that first.
I think that makes sense.
Originally, we tried to keep platforms on the left column and
Yes sounds good. Most other platforms implement it in this way:
- Android's create script [1] uses a templates folder [2] that it makes
copies of on-create, which contains (among other things) the cordova
folder [3].
- Blackberry does a similar thing [4]
- so does iOS [5]
[1]
Correct me if I'm wrong, but it doesn't look like there's any (simple) way to
get the project's root directory if the hook is a shell script. When I echo $#,
I have 0 incoming arguments, and so my script is currently limited to throwing
an error if the cordova-cli isn't executed from an
Good call, should be easy to add.
On 3/25/13 8:54 PM, Kerri Shotts kerrisho...@gmail.com wrote:
Correct me if I'm wrong, but it doesn't look like there's any (simple)
way to get the project's root directory if the hook is a shell script.
When I echo $#, I have 0 incoming arguments, and so my
Hate to 'make work' but we might want to drop a README in them
explaining what is supposed to go there (maybe a link to plugman) and
the mailing list before we open those up to speculation.
On Mon, Mar 25, 2013 at 7:21 PM, Michael Brooks
mich...@michaelbrooks.ca wrote:
Would it make sense to
Mmm ice floes (9m21s in): http://www.youtube.com/watch?v=KKh0P9o6y18t=9m21s
On Mon, Mar 25, 2013 at 6:02 PM, Tommy-Carlos Williams
to...@devgeeks.orgwrote:
Ah. Then I'll shut up ;)
On 26/03/2013, at 11:56 AM, Filip Maj f...@adobe.com wrote:
In this particular case Joe was just speaking
72 matches
Mail list logo
