well, we use whatever browser is default currently or we run in jsdom but I
suspect neither gets run very often given the tests I'm seeing
(frankly this part of the platform has been rather static for a while)
ideally the solution is drop in, closer to what the env we're targeting,
and has an IE
I think I may want plugins compatible with Cordova version X or license Y.
(License may be not in Z...)
-
This transmission (including any attachments) may contain confidential
information, privileged material (including
last night a commit to change tests seems to have created a problem with
the iOS and android testing. The grunt test for iOS failed with:
deviceready has not fired after 5 seconds.
Channel not fired: onNativeReady
Channel not fired: onCordovaReady
command timed out: 1200 seconds without output,
Le 12/12/2013 03:21, Carlos Santana a écrit :
CLI design contract is to just run platforms/platfomid/bin/create nothing
about running npm install on platform repo files.
If your platform scripts have dependencies platform is responsible to
satisfy its dependencies.
BlackBerry and Android have
Le 11/12/2013 23:49, Steven Gill a écrit :
The master branch on CLI now depends on the correct plugman. That problem
should be good.
I will review the two pull requests and merge in if they look good.
And there is a 3rd one to make it run more reliably:
UX looks great!! Thanks for the efforts!
2. For search, perhaps the ability to add/remove filters?
+1 to making it responsive
-James Jong
On Dec 11, 2013, at 10:26 PM, Joni Rustulka j...@adobe.com wrote:
Hi all,
I'm Joni. I work at Adobe as a UX designer on the PhoneGap team, and I have
Those comps look great Joni! Nice work!
The details page needs a way to view prior versions.
On Thu, Dec 12, 2013 at 8:38 AM, James Jong wjamesj...@gmail.com wrote:
UX looks great!! Thanks for the efforts!
2. For search, perhaps the ability to add/remove filters?
+1 to making it
Nice Joni!
Really love the plugin robot! :)
Also a +1 for making it responsive.
Subject: Re: plugins.cordova.io: UX redesign
From: wjamesj...@gmail.com
Date: Thu, 12 Dec 2013 08:38:06 -0500
CC: yo...@adobe.com
To: dev@cordova.apache.org
UX looks great!! Thanks for the efforts!
2.
Looks awesome! We've been needing this for a while! Great job, thanks!
+1 to Carlos' suggestion above of providing users a readme.md template that
they can fill out that we just display on the plugin info page. If they
provide nothing, we can probably auto fill this with the registry
information.
cordova-js ?? (Should be passing now but gruntfile was refactored.)
On Dec 13, 2013 12:06 AM, David Kemp drk...@google.com wrote:
last night a commit to change tests seems to have created a problem with
the iOS and android testing. The grunt test for iOS failed with:
deviceready has not fired
Sorry - I did sort of forget to say which test..
Yes the failure is in cordova-js.
On Thu, Dec 12, 2013 at 10:15 AM, Brian LeRoux b...@brian.io wrote:
cordova-js ?? (Should be passing now but gruntfile was refactored.)
On Dec 13, 2013 12:06 AM, David Kemp drk...@google.com wrote:
last
Looks great indeed!
On Wed, Dec 11, 2013 at 10:26 PM, Joni Rustulka j...@adobe.com wrote:
Hi all,
I'm Joni. I work at Adobe as a UX designer on the PhoneGap team, and I
have recently thrown some time at redesigning the
http://plugins.cordova.io site. I'm looking for feedback prior to
Looks good Joni. Great tone, character and feel.
Some of the utilitarian pieces I think need fine tuning.
Re: 1. ( opinions, which may be misguided )
- Search prominence is great, but I am confused about the difference
between what the 'Find Plugins' link at the top does, and the search box.
-
Awesome Job Joni! Love it!
Carlos, I think the plan for 3 is to display the readme npm style. Good
suggestion ;). A template to give out would be a great idea. Maybe it gets
generated in the plugin create command (did that ever make it in?)
On Thu, Dec 12, 2013 at 11:36 AM, Josh Soref
Looks awesome, great work and sorely needed!
I assume the filter is an ³and² operation?
--
Ken Wallis
Senior Product Manager - WebWorks
BlackBerry
650-620-2404
-Original Message-
From: Steven Gill stevengil...@gmail.com
Reply-To: dev@cordova.apache.org dev@cordova.apache.org
Date:
Thanks for looking at iOS James
3.3 iOS is essentially 3.2 since most of the work has gone into plugins.
I will be tagging 3.3 iOS final soon.
On Thu, Dec 12, 2013 at 5:34 AM, David Barth david.ba...@canonical.comwrote:
Le 11/12/2013 23:49, Steven Gill a écrit :
The master branch on CLI now
Reminds me of the iOS LocalStorage (CDVLocalStorage plugin) bs that needed
to be handled - we definitely need a migration path (automatic hopefully)
if not users are in for a world of hurt...
On Wed, Dec 11, 2013 at 11:33 AM, Tommy Williams to...@devgeeks.org wrote:
+1
On 12/12/2013 6:26 am,
Le 12/12/2013 14:34, David Barth a écrit :
Other platforms ran into the permission issue you mentioned. I think
https://issues.apache.org/jira/browse/CB-3812 should have fixed it.
Maybe
others can chime in with some suggestions here too.
Yes, I couldn't re-install support for android in a
The docs will also be going out today :).
I will review your pull requests after lunch and catch you on IRC.
On Thu, Dec 12, 2013 at 12:19 PM, David Barth david.ba...@canonical.comwrote:
Le 12/12/2013 14:34, David Barth a écrit :
Other platforms ran into the permission issue you mentioned.
Brian,
The new tests also appear to open a tab on my chrome browser to display the
jasmine results after every test. This results in a rather unmanageable
number of tabs on the slave machine after a while.
I still have all master tests failing.
On Thu, Dec 12, 2013 at 10:42 AM, David Kemp
Mark wrote:
https://reviews.apache.org/r/15775/
--link was a boolean before, now it accepts a path, so it's either
--src=path or --link=path.
Added a check in config_parser to make sure we are looking at an xml file
that looks like Cordova config.xml to avoid overwriting some unrelated
config.xml
I have some feedback about versions and the download counts.
When a particular plugin (eg org.apache.cordova.XYZ) has multiple
versions 0.1.0, 0.1.5, 0.2.0, 0.2.1, 0.2.3, 0.2.4 then how will the list
of all those different versions displayed? And what does the download
count mean in that case -
I have removed btests from running for now. We can add them back in once we
get them to a working state. This should fix the CI issues you are seeing
David.
On Thu, Dec 12, 2013 at 1:51 PM, Brian LeRoux b...@brian.io wrote:
The tests aren't new. They just run now instead of silent failure.
Seems like it. I am seeing some passes now. I will check into the details
in a bit.
On Dec 12, 2013 5:52 PM, Steven Gill stevengil...@gmail.com wrote:
I have removed btests from running for now. We can add them back in once we
get them to a working state. This should fix the CI issues you are
I've had some time to revisit our codebase and been doing some refactoring.
Its fun. Cordova is an somewhat mature project (or maturing) and with age
comes a few wrinkles.
I'd like for not only our code to get better but all of committership.
Programming is a lifelong learning exercise, and we
Create modules that are the smallest possible unit of code. Less code is
fast code. Faster to write. Faster to maintain. Faster to test. On the
extreme end characters in the Node community such as Substack advocate a
single function per module definition.
module.exports = function() {
// my
Flatten your async code. New fashion advocates promises, generators,
events, or one of the streams apis.
The classic method is to write small testable modules (see part 1) and
flatten your tree.
Turn code that looks like this [1] into this [2].
[1]
I also agree with this except for returning a function from module.exports.
It is possible but makes mocking much much harder for testing.
think of:
var foo = require('foo');
module.exports = {
awesome: function (a) {
foo(a+1);
}
};
It is kind of awkward to test this module's
Maybe. Have a look at Substack's code and you'll see he has no trouble
testing. The reason being he tests interfaces and outputs instead of
implementations. That will be another Node 101!
On Fri, Dec 13, 2013 at 10:24 AM, Gord Tanner gtan...@gmail.com wrote:
I also agree with this except for
ALSO: lets avoid using terms like 'I agree' or 'I disagree'. Its
programming. The answer is ALWAYS 'it depends'. No absolutes in the sea of
change.
On Fri, Dec 13, 2013 at 10:34 AM, Brian LeRoux b...@brian.io wrote:
Maybe. Have a look at Substack's code and you'll see he has no trouble
Brian wrote:
Flatten your async code. New fashion advocates promises, generators,
events, or one of the streams apis.
While flattening with promises is greatŠ
The classic method is to write small testable modules (see part 1) and
flatten your tree.
Turn code that looks like this [1] into this
It depends what you define as outputs.
in a given module:
var foo = require('foo'), bar = require('bar'), baz = require('baz');
module.exports = function(a, b) {
foo(3);
bar.method(a);
baz(b);
return done;
}
I have always counted the calls to foo, bar and baz as output that
And yes promises are great. I find them to be more sugar than actual help
but to each his own. Same practices apply.
On Fri, Dec 13, 2013 at 11:32 AM, Brian LeRoux b...@brian.io wrote:
Sorry, lets see if I can make it more obvious.
https://gist.github.com/brianleroux/7938149
On Fri, Dec
Sorry, lets see if I can make it more obvious.
https://gist.github.com/brianleroux/7938149
On Fri, Dec 13, 2013 at 10:41 AM, Josh Soref jso...@blackberry.com wrote:
Brian wrote:
Flatten your async code. New fashion advocates promises, generators,
events, or one of the streams apis.
While
I vote that we call him Plugman
(But his friends call him Pluggy =)
On Fri, Dec 13, 2013 at 10:57 AM, Shazron shaz...@gmail.com wrote:
Awesome, love Pluggy(?) the robot.
Some comments if I may:
1. Plugin Details - maintainers should be linkable, so we can go to a list
of their authored
35 matches
Mail list logo
