+1 to negligence, or might it be ignorance?
The attic sounds like its where you put code you're ashamed of.
Cheers,
Jesse
Sent from my iPhone5.5
On 2013-03-21, at 3:41 PM, Brian LeRoux b...@brian.io wrote:
Attic seems like more work than outright neglect. Might be for
conceptual purity we
Sounds good to me!
On Thu, Mar 21, 2013 at 9:09 PM, denis.verg...@orange.com wrote:
Hi all,
We have an android application mixing native views and a CordovaWebView.
The problem is the CordovaWebView request the focus when launching the
application even in our case it should not be the
Let's use this gdoc as an agenda / place to take notes:
https://docs.google.com/document/d/1BR7WVK1MT7zE8Oj18F1cAAQ4XZCvym-5lma5JPgx1fA/edit?usp=sharing
On Thu, Mar 21, 2013 at 6:25 PM, Filip Maj f...@adobe.com wrote:
I'll be likely doing it from home. Some of the other committers too. It's
Propose we add ./bin/check_requirements to each platforms in 2.7
timeframe so as to remove that logic from the cordova-cli tool.
Right now the cordova-cli has a lot of logic looking at parsing the
config.xml and some stuff is existing in the platforms. This is more
of a discussion thread for that. I don't have any concrete to talk
about here but Fil can elaborate.
+1
On 13-03-22 1:32 PM, Anis KADRI anis.ka...@gmail.com wrote:
+1
On Fri, Mar 22, 2013 at 10:29 AM, Brian LeRoux b...@brian.io wrote:
Propose we add ./bin/check_requirements to each platforms in 2.7
timeframe so as to remove that logic from the cordova-cli tool.
+1
On Fri, Mar 22, 2013 at 10:33 AM, Jeffrey Heifetz
jheif...@blackberry.comwrote:
+1
On 13-03-22 1:32 PM, Anis KADRI anis.ka...@gmail.com wrote:
+1
On Fri, Mar 22, 2013 at 10:29 AM, Brian LeRoux b...@brian.io wrote:
Propose we add ./bin/check_requirements to each platforms in 2.7
Right now we put the release of Cordova into the npm package for
cordova-cli and we version lock the two. (Codova/CLI 2.5.x ===
Cordova/Platform 2.5.latest).
We did this because:
- has to work offline
- cannot have a Git dep to do development
- issue tracking locked to the real version of
I'm content to have the vendoring, it has some advantages as you wrote.
However, I would also very much like to add a platform that's running from
somewhere on my local disk, as I described in my feature request in the doc.
So I propose a flag like cordova platform add android
Right now the global executable is version locked to a Cordova
release. If you have a project running 2.5 you are required to have
Cordova/CLI 2.5. If you need to then work in Cordova 2.4 you need to
downgrade (not really but you would to be safe).
In Grunt .4 the global executable is dumb. It
I think this bleeds back into other discussions. It was mentioned in
the call earlier. I think some tacit agreement that ./serve goes away
and Ripple is the default ./emulate command. But lets discuss. (Just
this. Lets keep thread focused.)
...
Thoughts? I'm down. But maybe post 3.x since neither is a real issue atm.
None have support currently in the CLI tools.
- Herm is pursuing platform level scripts so support for FxOS can happen.
- Mapes is doing the same in Windows land.
Both cases we could use some help. If any on this list care about
those platforms and would like to pitch in this is the thread to
I am sure we all agree to this. Want to get a sense of how it will
happen. Anis you mentioned you need Braden to commit the JS stuff
first?
0
On Fri, Mar 22, 2013 at 10:56 AM, Brian LeRoux b...@brian.io wrote:
Thoughts? I'm down. But maybe post 3.x since neither is a real issue atm.
A plugin should specify the Cordova versions it supports too.
On Fri, Mar 22, 2013 at 10:59 AM, Brian LeRoux b...@brian.io wrote:
I am sure we all agree to this. Want to get a sense of how it will
happen. Anis you mentioned you need Braden to commit the JS stuff
first?
I assume you mean the top-level plugins/ folder in the CLI?
That is where plugins are cached when you cordova plugin add them. Whether
they're coming from local directories or git or wherever, they get copied
here. Then on a prepare this is where the plugin's assets are copied from.
Braden
On
There was some issues over download size for our cli, any idea what the size of
all the platforms are?
Sent from my iPhone
On 2013-03-22, at 1:42 PM, Braden Shepherdson bra...@chromium.org wrote:
I'm content to have the vendoring, it has some advantages as you wrote.
However, I would also
Would have the benefit of enabling a plugin, and plugin-test existence
in a single repo. Consolidates a lot of tooling. Lets discuss more
herein
+1
With this I would want to add the ability to add a platform to a project even
if we don't have the build dependencies.
Emulate would just default to ripple so is still usable if we can't build/deploy
Sent from my iPhone
On 2013-03-22, at 1:55 PM, Brian LeRoux b...@brian.io wrote:
I
The platforms already look at config.xml at runtime to load plugins, set
certain app preferences, etc.
The one thing that this current functionality can't do (in most cases I
think) is changing certain bits of app metadata before compile-time.
Things like app package/id and app name. Maybe other
+1 !
On 3/22/13 10:34 AM, Shazron shaz...@gmail.com wrote:
+1
On Fri, Mar 22, 2013 at 10:33 AM, Jeffrey Heifetz
jheif...@blackberry.comwrote:
+1
On 13-03-22 1:32 PM, Anis KADRI anis.ka...@gmail.com wrote:
+1
On Fri, Mar 22, 2013 at 10:29 AM, Brian LeRoux b...@brian.io wrote:
The main technical ask here is the ability to specify a plugin as { git
repo, commit hash, subdirectory } instead of just { git repo, commit hash }.
On Fri, Mar 22, 2013 at 2:05 PM, Brian LeRoux b...@brian.io wrote:
Would have the benefit of enabling a plugin, and plugin-test existence
in a
Cool. So, is this interim or necessary to exist for all of time?
(Would assume you need some sort of staging area but not sure you need
to keep em around if we can cache the manifest info or something.)
On Fri, Mar 22, 2013 at 11:01 AM, Braden Shepherdson
bra...@chromium.org wrote:
I assume you
It big. Certainly would be more efficient to lazy load, and cache so
offline works.
On Fri, Mar 22, 2013 at 11:04 AM, Gord Tanner gtan...@gmail.com wrote:
There was some issues over download size for our cli, any idea what the size
of all the platforms are?
Sent from my iPhone
On
omg I just realized this would fulfill offline use case vs lazy load vendoring
caching could be a future thing
might be a really nice path
On Fri, Mar 22, 2013 at 11:06 AM, Gord Tanner gtan...@gmail.com wrote:
+1
With this I would want to add the ability to add a platform to a project even
I'm into it.
On Fri, Mar 22, 2013 at 11:11 AM, Max Woghiren m...@chromium.org wrote:
The main technical ask here is the ability to specify a plugin as { git
repo, commit hash, subdirectory } instead of just { git repo, commit hash }.
On Fri, Mar 22, 2013 at 2:05 PM, Brian LeRoux b...@brian.io
I've messed around with programmatic view manipulation in native apps, on
droid and iOS primarily. There's no reason that I'm aware of that these
methods need to be private, and making sure that plugins/native code can
change the view layout is important for overall architecture flexibility.
It
+1
@Jesse
The attic sounds like its where you put code you're ashamed of.
I prefer to look at it as the place to put code that you don't want getting
in the way, or biting guests to your home.
On Thu, Mar 21, 2013 at 11:49 PM, Jesse MacFadyen
purplecabb...@gmail.comwrote:
+1 to negligence,
We want this to stick around. One of my goals for the CLI is to make the
platforms/foo subdirectories completely build artifacts. Native code, web
assets, JS code, all get copied on every prepare. That's not currently true
for native code, but it is for the rest.
Since we're doing that, we need
This has all of my +1s. Especially if our testing story is a dependent
plugin, this is way more convenient than two repos.
Braden
On Fri, Mar 22, 2013 at 2:19 PM, Brian LeRoux b...@brian.io wrote:
I'm into it.
On Fri, Mar 22, 2013 at 11:11 AM, Max Woghiren m...@chromium.org wrote:
The
I don't think we can put unused platforms in the Apache Attic - I think its
for complete projects AFAIK
http://attic.apache.org/
On Fri, Mar 22, 2013 at 11:22 AM, Lorin Beer lorin.beer@gmail.comwrote:
+1
@Jesse
The attic sounds like its where you put code you're ashamed of.
I prefer
Hi Fil,
Since cordova-osx is functional now -- how do I add JIRA tasks to the
script (not sure where it is exactly) you used to add subtasks for a
release? I want to add Update www/ application for OS X and Update
JavaScript for OS X sub-tasks.
On Thu, Mar 21, 2013 at 10:09 AM, Filip Maj
Here are the meeting notes:
Meeting Notes
1.
Fil describing the tools
-
command line tools, readme from github
-
application assets are platform agnostic
-
platform, plugin, prepare, compile, build, emulate, serve
-
www/config.xml
-1
I don't want anything public until we have a process to decide on what
we should or should not support. We've been burned in the past by
making certain things public, and then not being able to change those
methods because someone somewhere depends on it for their app.
Architectural
Should the universe just keep a copy of a plugin.xml so that it can have a
list of plugin dependancies and everything? plugin.xml will already have a
list of compatible cordova versions, right?
Then the universe can manage a reverse mapping if it wants fast access.
-Michal
On Fri, Mar 22,
I don't have much to add except that I really like this about Grunt.
However, it would get interesting with Cordova since the global is what
creates a project in the first place. I still think it could work and have the
global only responsible for creating dirs and setting up package.json
+1 for ./platforms becoming a build artifact.
That is already how we are attempting to roll in our project using the cli,
though its not quite right yet.
On 23/03/2013, at 5:26, Braden Shepherdson bra...@chromium.org wrote:
We want this to stick around. One of my goals for the CLI is to
Very interesting. Combined with Bradens proposal to support pointing to a
local platform, looks very good.
Also note, offline isn't the only reason, platform support on a given
machine as well: ie, can test iPhone (sorta) on a linux box through
Ripple.
On Fri, Mar 22, 2013 at 2:15 PM, Brian
Huge +1.
Questions:
1. Could we allow installing multiple plugins/subdirectories from within
the same repo in one step. Support wildcards? (i.e. cordova plugin add
--repo=git --version=hash --name=*)
2. Should we cache git repos so we dont need clone over and over for each
plugin and app.
(1) That seems useful (eg. install plugin_foo and plugin_foo_test in one
command). Maybe, by default, omitting the `--name` parameter could install
all plugins found in the specified repo/hash.
(2) I think there's theoretical value in this, but cloning is somewhat
cheap so it's probably not
Yeah Michal,
That is the exact use case I had in mind. When we were a startup we
couldn't afford mac's so just used linux and ripple for all our contract
work and borrowed a friends macbook when we needed to compile.
On Fri, Mar 22, 2013 at 3:12 PM, Michal Mocny mmo...@chromium.org wrote:
Yep, my biggest concern is that we are able to use CLI but still work
against master. I think braden's ask covers that though.
What good is working offline if you have no plugins? Are you suggesting
that we also include some set of plugins inside of cordova-cli?
On Fri, Mar 22, 2013 at 2:13
Thats awesome ;)
On Fri, Mar 22, 2013 at 3:51 PM, Gord Tanner gtan...@gmail.com wrote:
Yeah Michal,
That is the exact use case I had in mind. When we were a startup we
couldn't afford mac's so just used linux and ripple for all our contract
work and borrowed a friends macbook when we
Just for clarity's sake, I want to point out that this would add a new
dependency to cordova-android as a standalone project. Worth taking that
into consideration.
On 3/22/13 11:00 AM, Anis KADRI anis.ka...@gmail.com wrote:
0
On Fri, Mar 22, 2013 at 10:56 AM, Brian LeRoux b...@brian.io wrote:
If you previously cloned platforms and plugins into some global location,
you should be able to create a new HelloWorld app while offline, by using
--link (for both platforms and plugins).
Does that work?
On Fri, Mar 22, 2013 at 3:51 PM, Andrew Grieve agri...@chromium.org wrote:
Yep, my
It's under cordova-labs' jira branch.
Start at line 151 of jira.js [1]. Increment the num_callbacks var. Check
out the flow a little bit to get an idea of what you need to do. Then
copy/paste to add the new subtasks.
Cathc me on gtalk if you have more qs.
[1]
Good question.
My intuition is saying for as long as 3.x is around we preload w/ core
plugins. We'll do as such w/ the PhoneGap distribution to minimize
pain. Once ppl are used to the tools they'll be asking for us to
default to none.
My thoughts where that we'd start that way w/ Cordova but
Yeah, this was a concern for me as well, but I figured I'd wait and see
what the pull request looked like to know whether it would be a hard thing
to maintain.
- Could you call requestFocusFromTouch() on your other component after the
WebView calls it?
On Fri, Mar 22, 2013 at 2:50 PM, Joe
Agree with everything Braden said
On 3/22/13 12:05 PM, tommy-carlos Williams to...@devgeeks.org wrote:
+1 for ./platforms becoming a build artifact.
That is already how we are attempting to roll in our project using the
cli, though its not quite right yet.
On 23/03/2013, at 5:26, Braden
Maybe a good first stab at this (and maybe this works already), is to
ensure multiple versions of CLI can be installed at the same time.
e.g.
/usr/loca/cordova-cli/2.4
/usr/loca/cordova-cli/2.5
/usr/loca/cordova-cli/2.6
The global symlink in /usr/local/bin would point to the latest, but your
Hmm, but then the versioning of the core plugins is tied to the version of
your cordova-cli tool at install time?
I'm not opposed to installing cordova-core plugins by default which can
optionally be used as a fallback when or something, but I'm not sure that
every app you create should by
As Tommay pointed out, you need to create the cordova project structure in
the first place with some manner of tool..
On 3/22/13 11:58 AM, tommy-carlos Williams to...@devgeeks.org wrote:
I don't have much to add except that I really like this about Grunt.
However, it would get interesting with
Ya love it. =)
On Fri, Mar 22, 2013 at 1:02 PM, Filip Maj f...@adobe.com wrote:
Agree with everything Braden said
On 3/22/13 12:05 PM, tommy-carlos Williams to...@devgeeks.org wrote:
+1 for ./platforms becoming a build artifact.
That is already how we are attempting to roll in our project
Paraphrasing our meeting notes today:
* currently www/ has to have config.xml inside it, docs inside it, README
etc
* merges folder is already a sibling of www/ but its logically part of the
app.
* So, why not move everything that isn't the actual assets of the app
itself out of www?
* Option
Paraphrasing from meeting notes today:
* plugins are getting awesome treatment:
* universe
* dependencies
* versioning
* add/remove/upgrade
* access to native
* multiple plugins in one repo
* apps are getting some treatment:
* the app manifest has access to platform properties
*
makes sense to me; we'll likely want to query on that stuff eventually
On Fri, Mar 22, 2013 at 11:53 AM, Michal Mocny mmo...@chromium.org wrote:
Should the universe just keep a copy of a plugin.xml so that it can have a
list of plugin dependancies and everything? plugin.xml will already have a
Currently a release consists of some boilerplate:
DISCLAIMER
LICENSE
NOTICE
README.md
changelog
And the guts:
cordova-android.zip
cordova-app-hello-world.zip
cordova-bada-wac.zip
cordova-bada.zip
cordova-blackberry.zip
cordova-cli.zip
cordova-docs.zip
cordova-ios.zip
cordova-js.zip
Like that plan. Say we proceed and land it in 2.6 to feel out.
On Fri, Mar 22, 2013 at 2:50 PM, Filip Maj f...@adobe.com wrote:
I'm fine with removing server. In my mind ripple is just a serve command
on steroids. At this morning's meeting I believe some of the Googlers
expressed concerns
YES. Do it.
On Fri, Mar 22, 2013 at 2:38 PM, Filip Maj f...@adobe.com wrote:
Hai gaiz!
Main contention between the two camps in this debate is four vs eight
scripts.. But Brian points out that refactoring smaller bits of
functionality into their own script allows us to have our cake and eat
+1. I will create issues for coho in regards to this.
-Steve
On Fri, Mar 22, 2013 at 2:35 PM, Filip Maj f...@adobe.com wrote:
+1
On 3/22/13 2:26 PM, Brian LeRoux b...@brian.io wrote:
Currently a release consists of some boilerplate:
DISCLAIMER
LICENSE
NOTICE
README.md
changelog
Given that plugins will be independently versioned once they break off
I think it will be a whole new world for where we focus our efforts
next year. I suspect most of what you propose will be without
contention.
On Fri, Mar 22, 2013 at 2:54 PM, Joe Bowser bows...@gmail.com wrote:
Hey
I'm
Agreed +1
On 3/22/13 4:23 PM, Brian LeRoux b...@brian.io wrote:
Ya love it. =)
On Fri, Mar 22, 2013 at 1:02 PM, Filip Maj f...@adobe.com wrote:
Agree with everything Braden said
On 3/22/13 12:05 PM, tommy-carlos Williams to...@devgeeks.org wrote:
+1 for ./platforms becoming a build
Offline happens!
I think by default nobody needs ANY of our APIs but the transition to
that thinking will be the trick.
On Fri, Mar 22, 2013 at 1:07 PM, Michal Mocny mmo...@chromium.org wrote:
Hmm, but then the versioning of the core plugins is tied to the version of
your cordova-cli tool at
Sounds good to me, though the prompting with a timeout seems a little
weird. If there is multiple I think it would be better just to prompt and
wait for a response
On Fri, Mar 22, 2013 at 3:03 PM, Brian LeRoux b...@brian.io wrote:
YES. Do it.
On Fri, Mar 22, 2013 at 2:38 PM, Filip Maj
I like this.
mw
On 3/22/13 6:03 PM, Brian LeRoux b...@brian.io wrote:
YES. Do it.
On Fri, Mar 22, 2013 at 2:38 PM, Filip Maj f...@adobe.com wrote:
Hai gaiz!
Main contention between the two camps in this debate is four vs eight
scripts.. But Brian points out that refactoring smaller bits of
I'm ok with ./merges at the same level as ./www but the config.xml
inside of ./www bugs me too. I think having a root level ./www just
works well mentally in that its obvious whats there, what it does, and
who it effects. The ./merges folder is really just stuff that gets
added to ./www in the
On merges in the root, in our internal implementation it was under www,
however this became problematic to devs understanding. It became far to
easy for root level www code to end up in merges. We even named ours
_platformOverrides to try and make it pretty explicit, but no one liked
the mixing
K lets try to land it in 2.6.0rc1. There is still time Gord! Blackberry +
iOS not tagged yet so we can land some more commits in cordova-cli
On 3/22/13 3:02 PM, Brian LeRoux b...@brian.io wrote:
Like that plan. Say we proceed and land it in 2.6 to feel out.
On Fri, Mar 22, 2013 at 2:50 PM,
On Fri, Mar 22, 2013 at 1:01 PM, Andrew Grieve agri...@chromium.org wrote:
Could you call requestFocusFromTouch() on your other component after the
WebView calls it?
I was going to ask the same question.
I also got frustrated with methods being protected or private but there are
usually ways
+1
Sorry I'm late to the game, I was judging frisbee throwing, pyramid
climbing robots all day :-)
https://twitter.com/confusement/status/315162754619162625
On Fri, Mar 22, 2013 at 6:35 PM, Filip Maj f...@adobe.com wrote:
K lets try to land it in 2.6.0rc1. There is still time Gord!
To clarify - I don't mind if serve gets axed for now.
On Fri, Mar 22, 2013 at 6:02 PM, Brian LeRoux b...@brian.io wrote:
Like that plan. Say we proceed and land it in 2.6 to feel out.
On Fri, Mar 22, 2013 at 2:50 PM, Filip Maj f...@adobe.com wrote:
I'm fine with removing server. In my mind
+1
On Fri, Mar 22, 2013 at 3:04 PM, Steven Gill stevengil...@gmail.com wrote:
+1. I will create issues for coho in regards to this.
-Steve
On Fri, Mar 22, 2013 at 2:35 PM, Filip Maj f...@adobe.com wrote:
+1
On 3/22/13 2:26 PM, Brian LeRoux b...@brian.io wrote:
Currently a
Merged into next [1].
I am currently at the pub and a beer or two in so I am not going to code to
much. If someone wants to axe serve (or refactor it to just use ripple)
that would be awesome.
[1] -
https://git-wip-us.apache.org/repos/asf?p=cordova-cli.git;a=shortlog;h=refs/heads/next
On
+1
…however, currently the prompt is never shown when using the cli tools as they
are super-mega-secret-silent.
I only ever know that it wanted me to choose which emulator of the ones I have
available (android avd) when it times out and shows it as part of the error.
Something to keep in
+1
I think that would be a good place for the check_reqs script
On Fri, Mar 22, 2013 at 3:50 PM, Filip Maj f...@adobe.com wrote:
One more addition: based on responses from the cordova-cli threads, it
looks like we'll also add a `check_reqs` script to each platform (perhaps
under
Can I just ask a question about this?
Is the config.xml supposed to be compatible with build.phonegap.com at all?
I ask because I could see a scenario where you might want to use the cli tools,
but still utilise build.phonegap.com for other platforms (or even for the ones
supported by the
+1
On Fri, Mar 22, 2013 at 3:42 PM, Benn Mapes benn.ma...@gmail.com wrote:
+1
On Fri, Mar 22, 2013 at 3:04 PM, Steven Gill stevengil...@gmail.com
wrote:
+1. I will create issues for coho in regards to this.
-Steve
On Fri, Mar 22, 2013 at 2:35 PM, Filip Maj f...@adobe.com wrote:
Also worth pointing out that as much as node is cross-platforms you will
have to consider/test both platforms every time you make a modification to
the scripts. How often do you guys fire up your Windows bootcamp, VM or
partition to test a tiny change ? How much would you like that ?
On Fri, Mar
Actually, related to that and an outstanding request for cordova-cli to
accept a --verbose option: to add that option to all of these proposed
scripts.
On 3/22/13 3:55 PM, Tommy-Carlos Williams to...@devgeeks.org wrote:
+1
...however, currently the prompt is never shown when using the cli tools
I like this solution to platform scripts, the only addition I would add is that
if the platform allows multiple targets, perhaps it could be possible to set a
default one that would be used instead of the timeout to first one (although I
suppose that makes first entry inherent default).
Sent
Yeah the only issue with plugin.xml is that it's XML :-D
It would be so much easier to have it stored in JSON. We can make plugman
parse the XML from a remote source but I would rather store everything in
JSON.
Also there can be multiple versions of plugin.xml. I think that is a good
enough
Well at least if you're making changes to the BASH ones you're not breaking
the cscript ones unless you're changing the whole flow of operations.
Also as you mentioned node is a new dependency.
On Fri, Mar 22, 2013 at 4:45 PM, Filip Maj f...@adobe.com wrote:
Well, we *should* be doing this
What's the alternative to Camera?
On Fri, Mar 22, 2013 at 6:04 PM, Filip Maj f...@adobe.com wrote:
+1 geo and websql deprecation
I would wait on camera until we actually do the api audit
On 3/22/13 2:54 PM, Joe Bowser bows...@gmail.com wrote:
Hey
I'm currently looking through the
I would map them.
On Fri, Mar 22, 2013 at 2:35 PM, Don Coleman don.cole...@gmail.com wrote:
I'm looking at adding video quality to CaptureVideoOptions.
Android has 2 options, iOS has 5.
Should I attempt to map some generic high_quality, medium_quality,
low_quality options to platform
Andrew: Capture API. But that's going away I reckon as well (there is a new
spec)
On Fri, Mar 22, 2013 at 5:29 PM, Andrew Grieve agri...@chromium.org wrote:
What's the alternative to Camera?
On Fri, Mar 22, 2013 at 6:04 PM, Filip Maj f...@adobe.com wrote:
+1 geo and websql deprecation
What's the rationale for removing desktop platforms?
On Fri, Mar 22, 2013 at 4:33 PM, Anis KADRI anis.ka...@gmail.com wrote:
+1
On Fri, Mar 22, 2013 at 3:42 PM, Benn Mapes benn.ma...@gmail.com wrote:
+1
On Fri, Mar 22, 2013 at 3:04 PM, Steven Gill stevengil...@gmail.com
wrote:
Given that cordova-cli will be the end goal for people typing in commands,
I guess I don't really care what the scripts look like as long as they are
consistent.
So.. I guess I'd be fine to have build-release and build-debug as top-level
scripts. Since:
It would seem weird to me to have a
https://issues.apache.org/jira/browse/INFRA-5839
Mostly that they are not super critical / nobody dedicated to them
explicitly. I know you keep Mac alive (and well) and Jesse on Win78.. If
you guys want to continue that sure.
On Friday, March 22, 2013, Shazron wrote:
What's the rationale for removing desktop platforms?
On Fri, Mar 22, 2013
But isn't the app incomplete without the merges folder? Most apps probably
don't use it, but for those that do, a zip of www isn't enough, you already
need to ship more than just the www folder. Creating an app folder would
actually make the situation easier I think.
project
- platforms
- ..
What spec is that? I would like to research that, I was not aware there was a
new one.
Thanks!
Sent from my BlackBerry Z10 smartphone.
From: Shazron
Sent: Friday, March 22, 2013 8:43 PM
To: dev@cordova.apache.org
Reply To: dev@cordova.apache.org
Subject: Re: [Android] Plugins to send on the ice
I generally prefer json whenever possible as well, so if its feasible to
change I'de give that a +1, but I'm not sure how many plugins out there
already use the manifest based structure.
As far as creating a second manifest just to register with a universe, this
isn't unheard of may have
I just mean that build expects config.xml to be in www, yeah?
On 23/03/2013, at 1:12 PM, Michal Mocny mmo...@chromium.org wrote:
But isn't the app incomplete without the merges folder? Most apps probably
don't use it, but for those that do, a zip of www isn't enough, you already
need to
As long as the alerts for asking for permission (as an example) don't say
index.html would like to use your position or whatever it is without the
PhoneGap/Cordova API over the top…
On 23/03/2013, at 9:04 AM, Filip Maj f...@adobe.com wrote:
+1 geo and websql deprecation
I would wait on
The barrier of having more config files is real and change is starting to cause
fatigue amongst the plugin authors I deal with regularly.
Having said that, I think JSON would be a welcome change overall…
There really are not that many plugins that are set up with a plugin.xml yet
that I know
Yeah exactly… I think it would a great bridge over the moat that has been built
up around plugin authoring over the last year or so…
- tommy
On 23/03/2013, at 1:46 PM, Michal Mocny mmo...@chromium.org wrote:
Huge +1 to plugin templates.
(we already have an app template, right?)
-Michal
Yes, templates are definitely in the roadmap. A lot of people have
requested it. The goal is to make it super easy for plugin authors to make
their plugins install-able/discoverable.
I didn't ask for a second manifest. Right now plugin authors can register
plugins to the cordova universe via a
And so the consensus seems to involve breaking down that logic in
cordova.js and cordova into multiple files inside a lib sub-directory. I
don't really like the idea but I don't really care either as long as the
same set of commands is available across platforms.
Hopefully, next time we will
1 - 100 of 101 matches
Mail list logo
