I'm a CM Engineer and would like to help with any build/release work that’s
needed. How do I get started? Thanks
Thomas Dao
-Original Message-
From: Andrew Grieve (JIRA) [mailto:j...@apache.org]
Sent: Monday, February 04, 2013 4:40 PM
To: callback-...@incubator.apache.org
Subject:
I would love to...
But it seems I am not yet a double zero committer
I Mean with the permission to commit ;-)
-Original Message-
From: Filip Maj [mailto:f...@adobe.com]
Sent: Wednesday, February 06, 2013 1:21 AM
To: dev@cordova.apache.org
Subject: Re: a Cordova Jake Error ?
Hey Paul, I
Hi,
On Wed, Jan 23, 2013 at 1:50 PM, Jukka Zitting jukka.zitt...@gmail.com wrote:
On Thu, Jan 10, 2013 at 2:15 PM, Jukka Zitting jukka.zitt...@gmail.com
wrote:
I guess we should file an INFRA request to get the notification scheme
updated to use the new list address.
Before doing that, is
I can clean this up today
Sent from my iPhone
On 2013-02-06, at 4:28 AM, Plaquette, Paul paul.plaque...@intel.com wrote:
I would love to...
But it seems I am not yet a double zero committer
I Mean with the permission to commit ;-)
-Original Message-
From: Filip Maj
I just updated http://cordova.apache.org to include this new list.
-- Marcel Kinard
On Feb 6, 2013, at 6:11 AM, Jukka Zitting jukka.zitt...@gmail.com wrote:
Before doing that, is there interest in directing the notifications from
dev@ to a separate issues@ list?
Sounds like there's lazy
Great! I like the spec-based names. I think I have the opposite thought as
Becky. Our current media plugin doesn't follow the WebAudio spec at all.
How about we call it cordova-media for now since that's what it's called in
our docs, and then if we ever implement WebAudio, then we'll have the name
Good point about their being the possibility of multiple shared media. Last
night I convinced myself that adding new constants may not be the best path
forward, and instead proposed a new API (on the JIRA issue.).
On Tue, Feb 5, 2013 at 2:50 PM, Bryan Higgins br...@bryanhiggins.netwrote:
Some of our APIs are meant to be polyfills, and some of them are not.
It's great to expose the polyfill-type ones using the standards-based
symbols. E.g. FileEntry, requestFileSystem.
For the custom ones though, I think it's important for devs to realize that
the APIs they are using are custom
Dear Cordova,
We recently had a crash in iOS because we accidentally wrote this javascript…
Cordova.exec(frontPage.updatePublicationList,frontPage.Error,MyPlugin,update-list,
null);
I may have messed up the exact syntax during copy/paste/obfusticate but the
essence is that passing null for
I like the proposal, and do think our extensions should be namespaced.
However, your one example of InAppBrowser is debatable if it is a polyfill
or extension, and has good arguments for either side. So, perhaps we can
leave that example (or any other specific plugin) aside, and focus on the
I thought FileTransfer was a part of File. Maybe it makes sense to separate
them though?
On Wed, Feb 6, 2013 at 12:00 PM, Becky Gibson gibson.be...@gmail.comwrote:
Yes, I shouldn't have confused the issue about audio and media! I guess I
just get annoyed when I go to mobile spec and it is
Totally makes sense to separate them.
File is spec-based, FileTransfer is not.
On 2/6/13 10:16 AM, Andrew Grieve agri...@chromium.org wrote:
I thought FileTransfer was a part of File. Maybe it makes sense to
separate
them though?
On Wed, Feb 6, 2013 at 12:00 PM, Becky Gibson
Hey Thomas,
Check out our webpage: http://cordova.apache.org/ under the contribute
section. Make sure to sign an ICLA and send it in. Then depending on your
area of interest, there are plenty of opportunities to help out. Check out
our issue tracker (https://issues.apache.org/jira/browse/CB) and
I was thinkin we'd just deprecate the media spec altogether for a
starter/subset of the web audio api (perhaps polyfil the audio element
while we're at it).
should we kick up a thread about that?
(Added file transfer to the non-spec plugins.)
On Wed, Feb 6, 2013 at 10:22 AM, Filip Maj
Bump
On Mon, Feb 4, 2013 at 4:47 PM, Andrew Grieve agri...@chromium.org wrote:
I've taken the result of the previous thread of
CB-2214https://issues.apache.org/jira/browse/CB-2214,
and turned it into a proposal doc:
SGTM. First step towards deprecation is turning it into a plugin so that
people can not install it :)
On Wed, Feb 6, 2013 at 1:41 PM, Brian LeRoux b...@brian.io wrote:
I was thinkin we'd just deprecate the media spec altogether for a
starter/subset of the web audio api (perhaps polyfil the
exactly! And plugins, I think, will end up being independently
versioned so if ppl want old and busted they can have it. =P
On Wed, Feb 6, 2013 at 10:48 AM, Andrew Grieve agri...@chromium.org wrote:
SGTM. First step towards deprecation is turning it into a plugin so that
people can not install
So... back to cordova-plugin-media then?
On Wed, Feb 6, 2013 at 1:59 PM, Brian LeRoux b...@brian.io wrote:
exactly! And plugins, I think, will end up being independently
versioned so if ppl want old and busted they can have it. =P
On Wed, Feb 6, 2013 at 10:48 AM, Andrew Grieve
Also developing a platform during a hackathon ;)
#WorksOnMyMachine
https://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=commitdiff;h=5ec7041147258854d34935ddcfc224af13d0b583
On Wed, Feb 6, 2013 at 2:11 PM, Anis KADRI anis.ka...@gmail.com wrote:
The beauty of Mac OS X users and their
I've added a few detail explanations to the document, but moved the
discussion to the ML.
Should be easy to install / remove plugins (no need to manually
add/remove script tags)
I think adding/removing script tags is the way to go. Concatenating all
javascript relevant to your project
So instead of revisiting it just let it die and kick up a new one for web audio?
On Wed, Feb 6, 2013 at 11:23 AM, Andrew Grieve agri...@chromium.org wrote:
So... back to cordova-plugin-media then?
On Wed, Feb 6, 2013 at 1:59 PM, Brian LeRoux b...@brian.io wrote:
exactly! And plugins, I
On Wed, Feb 6, 2013 at 2:33 PM, Filip Maj f...@adobe.com wrote:
I've added a few detail explanations to the document, but moved the
discussion to the ML.
Should be easy to install / remove plugins (no need to manually
add/remove script tags)
I think adding/removing script tags is
+1
On Wed, Feb 6, 2013 at 2:41 PM, Brian LeRoux b...@brian.io wrote:
So instead of revisiting it just let it die and kick up a new one for web
audio?
On Wed, Feb 6, 2013 at 11:23 AM, Andrew Grieve agri...@chromium.org
wrote:
So... back to cordova-plugin-media then?
On Wed, Feb 6,
On 2/6/13 11:51 AM, Andrew Grieve agri...@chromium.org wrote:
On Wed, Feb 6, 2013 at 2:33 PM, Filip Maj f...@adobe.com wrote:
I've added a few detail explanations to the document, but moved the
discussion to the ML.
Should be easy to install / remove plugins (no need to manually
In light of recent discussion re: figuring out whether to add new
constants for various FileSystem locations (I.e. PERSISTENT vs TEMPORARY
vs APP vs SOMENEWDIRECTORYLOCATION), perhaps we should chime in on this
new thread that came into the web apps WG?
On 2/6/13 11:58 AM, Arun Ranganathan
Well, we still need an API/plugin for playing audio. The w3c spec is pretty
involved. In the past Simon has suggested we try to unify around HTML audio.
At any rate I don't think we can just get rid of it.
Sent from my iPhone
On Feb 6, 2013, at 2:52 PM, Andrew Grieve agri...@chromium.org
On Wed, Feb 6, 2013 at 3:00 PM, Filip Maj f...@adobe.com wrote:
On 2/6/13 11:51 AM, Andrew Grieve agri...@chromium.org wrote:
On Wed, Feb 6, 2013 at 2:33 PM, Filip Maj f...@adobe.com wrote:
I've added a few detail explanations to the document, but moved the
discussion to the ML.
I think it's fine to have the default behavior be to inject script tags.
That will suffice for 90% of our users, probably more. If you fall into the
10% that have some more complicated setup, we should provide a flag like
cordova plugin add --no-inject-js myplugin
that prevents us from doing it
I am leaning towards Fil's points.
The advantage of script tags is everyone understands how they work. Only
use magic when magic is required.
On Wed, Feb 6, 2013 at 12:45 PM, Braden Shepherdson bra...@chromium.orgwrote:
I think it's fine to have the default behavior be to inject script tags.
Right now you insert a single cordova.js for bridge and all core plugins.
If we do *not* inject scripts, then all users will need to update all apps
to include potentially a lot of script tags, right?
On Wed, Feb 6, 2013 at 3:52 PM, Jesse purplecabb...@gmail.com wrote:
I am leaning towards
Maybe another motivating use-case is when plugin authors add new .js files
(or remove them, or rename them). Then we'd need to tell each app to update
their html files.
On Wed, Feb 6, 2013 at 4:01 PM, Michal Mocny mmo...@chromium.org wrote:
Right now you insert a single cordova.js for bridge
I am not in favor of prescribing any part of the development stack.
Some ppl like requirejs. Etc. This is really not a problem we need to
add to the list of things we need to solve!
(More detailed feedback on the way.)
On Wed, Feb 6, 2013 at 12:52 PM, Jesse purplecabb...@gmail.com wrote:
I am
Then, if we don't inject the js automatically, how does a developer get the
list of scripts they need to include?
Will the docs say to include everything from
*project/platforms/cordova-js/lib/...
dir, or should cordova-cli have a list-scripts command?*
*
*
*-Michal*
On Wed, Feb 6, 2013 at 4:07
I don't think we should be automatically injecting javascript tags.
Instruct users to do so when they add a plugin by displaying the tag.
Everyone has different needs/requirements.
Also
*cordova plugin add file
- Download plugin files to project/plugins
- Runs plugman to install native parts of
I also disagree with automagically injecting the script tags. If
we're adding the script tags, we have the ability of adding the script
tags wrong, and breaking people's apps with magic. We have enough
trouble directing our users to use Cordova/PhoneGap without us trying
to make things more
For a project who's main language is JS, I'm a bit surprised that injecting
a script tag through DOM manipulation would put us into the magic
category...
Brian - Your sentiments about the development stack don't make sense to me.
The development stack is *the* job of CLI. We are prescribing a way
Thanks Carl!
We usually do pull requests for this:
http://wiki.apache.org/cordova/ContributorWorkflow
https://help.github.com/articles/using-pull-requests
This is for attribution purposes.
Since it's a very small patch, I suppose you could save the trouble and use
git format-patch and attach it
I agree with Michal that hanging things off the cordova object can get
pretty unmanageable after a while, and having it namespaced under
cordova.plugins or something similar would be better.
InAppBrowser is a weird one since window.open will work in browsers, but
not everything it supports is
I'm looking at the task goal:
*Should be easy to install / remove plugins (no need to manually
add/remove script tags) and inserting the script tags seems the best
solution, what alternative is there? If devs don't agree with this goal,
then it should be removed, and we keep the hard to install
Well, it's an interesting idea but I don't know if there will be enthusiasm
for supporting Vista/XP. In any case, you should file an enhancement
request so this can be evaluated and won't be forgotten:
https://issues.apache.org/jira/browse/CB
On Wed, Feb 6, 2013 at 6:07 AM, Jared Albers
Using Chrome Frame is not necessarily just to gain Vista/XP support. It
would also allow web developers to avoid Win7's IE9 and instead use the
webkit/v8 setup that is always improving and well supported (Chrome Frame
auto-updates just like regular Chrome).
I will indeed file an enhancement
So JIRA does not have a Win32 or Windows Component only a Windows 8.
What component should I file this enhancement under?
On Wed, Feb 6, 2013 at 8:11 PM, Jared Albers jalb...@mymail.mines.eduwrote:
Using Chrome Frame is not necessarily just to gain Vista/XP support. It
would also allow web
On Wed, Feb 6, 2013 at 9:27 PM, Jesse purplecabb...@gmail.com wrote:
I would prefer cordova.plugins instead of directly on cordova.
+1
I agree, and like having core plugins live under cordova.plugins.*, but I
don't think this should be a requirement of other plugins.
required, no, but I
43 matches
Mail list logo
