On 3/12/13 5:26 PM, "Andrew Grieve" wrote:
>One possible solution: Have JS-only plugins add a tag with a name
>but no value.
Thinking more generally here, as Anis said, the problem here is
dependencies. I think determining how aware plugman needs to be of the
project is important. Pretty sure p
Please star me :)
>Subject: Re: Who's who at cordova
>I have starred it. If anyone else here is missing a star, let me know.
>-Steve
Nice!
Seems to be missing one commit:
https://git-wip-us.apache.org/repos/asf?p=cordova-labs.git;a=commitdiff;h=76ecc678a888932695eb62695711b8a83f85ae87
Still waiting for Mozilla to send me the dev phone.
Sent from my iPhone
On 2013-03-14, at 1:18 AM, Brian LeRoux wrote:
> *guitar solo*
>
>
I'm working on a high-level what-not-how sort of document for the whole
plugin tools story, and this is something I keep coming back to. It's
looking like we'll need to know what plugins are installed and where files
have been placed where. This is important for uninstalling and also for
updating t
My suggestion was just to prevent the UI thread from locking up so that you
app doesn't appear to be frozen when the plugin is doing its thing.
On Wed, Mar 13, 2013 at 5:03 PM, Aaron Charbonneau wrote:
> Yah that's how I have it working now :) No problem with that approach for
> working with Jas
I think this falls into the same category as the KeyboardShrinksView
setting I added recently. Both properties would be useful to toggle at
runtime, and I we had a thread discussing the possibility of an API to
toggle settings at runtime. Also note that a hidden accessory will probably
require extr
Becky wrote:
> The basic contacts object is pretty much the same but there have been
> several enhancements. Most notably the find method is actual useful enough
> to perform an efficient search! There is a result object defined as well
> as events to indicate when a procedure is completed. And
Profile created. Star needed.
On Thu, Mar 14, 2013 at 5:59 AM, Leutwyler, Markus
wrote:
> Please star me :)
>
>
> >Subject: Re: Who's who at cordova
> >I have starred it. If anyone else here is missing a star, let me know.
> >-Steve
>
>
I have initialized a dossier and require enstellation.
On Thu, Mar 14, 2013 at 11:27 AM, Andrew Grieve wrote:
> Profile created. Star needed.
>
>
> On Thu, Mar 14, 2013 at 5:59 AM, Leutwyler, Markus
> wrote:
>
> > Please star me :)
> >
> >
> > >Subject: Re: Who's who at cordova
> > >I have starr
I'm wary of creating an additional manifest..
What if we came up with a convention for storing each plugin's plugin.xml
within the native project structure that the plugin got installed into? It
IS extra space needed, but a few kb per plugin doesn't seem so bad (this
is just my naïve first-pass ty
Copying the plugin.xml into the platform's project somewhere sounds like a
good idea to me.
I don't think we'd need to look in the config.xml to see what's installed
then. We can just look at what plugin.xml files exist.
On Thu, Mar 14, 2013 at 12:15 PM, Filip Maj wrote:
> I'm wary of creating
Hi, Josh,
Yes, I've worked in W3C working groups - I know the risks of implementing
too early in the process! However, when we wanted to add an API for
contacts into PhoneGap we needed a place to start so we used the W3C
working draft available at the time. We realized that it would likely
chang
It has been done
On Thu, Mar 14, 2013 at 8:44 AM, Braden Shepherdson wrote:
> I have initialized a dossier and require enstellation.
>
>
> On Thu, Mar 14, 2013 at 11:27 AM, Andrew Grieve >wrote:
>
> > Profile created. Star needed.
> >
> >
> > On Thu, Mar 14, 2013 at 5:59 AM, Leutwyler, Markus
>
I don't think it matters either way. Copying plugin.xml to the target
project folder might be easier to start. The hard stuff is dealing with
plugin versions, dependencies and Cordova versions.
Example: Plugin A depends on version 0.1.0 of Plugin B and Plugin C depends
on version 0.2.0 of plugin B
I wish we could use npm's solution for that (let every package in
node_modules have its own copy of its dependencies). That works for node
but not for us, because these classes need to go into a single global
namespace that's getting called by the bridge.
I do like the idea of using the plugin.xml
Sounds good to me Anis. More comments inline below.
On 3/14/13 10:47 AM, "Anis KADRI" wrote:
>The hard stuff is dealing with
>plugin versions, dependencies and Cordova versions.
If we think of these problems in light of a single cordova project, I
think it gets easier because:
- Cordova versio
>Cordova versions: we have tags. A single cordova project is
>stuck to a single cordova version. Attempting to install a plugin into a
>project running a different version of cordova should fail. Simple as that.
I'm more comfortable with a warning. While warnings are often (re:always)
ignored by
Tried sending a message to this list, but not sure if it went anywhere.
Tried then emailing private-subscr...@cordova.apache.org and sent another
email. Again, not sure if it got through.
Did anyone on the list see an email come through? Is there some special
step for getting onto the private@ li
On Thu, Mar 14, 2013 at 8:03 PM, Andrew Grieve wrote:
> Tried sending a message to this list, but not sure if it went anywhere.
>
> Tried then emailing private-subscr...@cordova.apache.org and sent another
> email. Again, not sure if it got through.
>
> Did anyone on the list see an email come thr
Gotcha! Thanks. I've added a note about this to our wiki.
On Thu, Mar 14, 2013 at 3:07 PM, Christian Grobmeier wrote:
> On Thu, Mar 14, 2013 at 8:03 PM, Andrew Grieve wrote:
> > Tried sending a message to this list, but not sure if it went anywhere.
> >
> > Tried then emailing private-subscr...
Even if we can do something clever with the code for those two versions of
a plugin, the exec call names are still in one namespace.
Adding versions to them would, in my opinion, make the cure worse than the
disease. Then a plugin author would have to update his code every time any
of his dependen
I agree. This is not a problem worth solving (if you have ever worked with
Ruby gems, you know what I'm talking about)
And the plugin-depending-on-a-plugin is already happening. Some plugins
require Facebook Connect already.. IMO drawing a line in the sand here is
a good first step.
On 3/14/13 12
Becky wrote:
> Yes, I've worked in W3C working groups
I'm glad you do, I'm concerned about messaging - that others might not
understand what it means. I've seen various groups really fail to understand
such a detail.
> - I know the risks of implementing too early in the process!
> However, when
Thanks for catching that Gord, I'll get that commit merged in.
Anyone have any idea when the repo will propagate over to github?
> Subject: Re: cordova-firefoxos repo has been created
> From: gtan...@gmail.com
> Date: Thu, 14 Mar 2013 09:44:02 -0400
> To: dev@cordova.apache.org
>
> Nice!
>
> See
It's not automatic. Someone needs to do something somewhere for it to
propagate. Same issue with cordova-plugman.
On Thu, Mar 14, 2013 at 2:12 PM, Herm Wong wrote:
> Thanks for catching that Gord, I'll get that commit merged in.
> Anyone have any idea when the repo will propagate over to github?
Do I need to log another Infra issue to get it done?
> Date: Thu, 14 Mar 2013 14:22:46 -0700
> Subject: Re: cordova-firefoxos repo has been created
> From: anis.ka...@gmail.com
> To: dev@cordova.apache.org
>
> It's not automatic. Someone needs to do something somewhere for it to
> propagate. Same
Well, I know that people do use find a lot and are frequently tripped up by
it. They get confused over the fact that the fields array is the list of
fields that are returned AND are searched. Most people expect all of the
contact information returned and they think that the fields are just the
fi
Welcome James and thanks for the intro! I was wondering who you were :)
On Tue, Mar 12, 2013 at 2:36 PM, Gord Tanner wrote:
> Welcome!
>
> Sent from my iPhone
>
> On 2013-03-12, at 5:26 PM, Lorin Beer wrote:
>
> > Hi James, thanks for the intro!
> >
> >
> > On Tue, Mar 12, 2013 at 2:18 PM, Anis
Welcome Shravan. That's a pretty rad intern role. We have a similar intern,
Benn Mapes, at Adobe Vancouver who we unleash on whatever peaks his
interest.
On Wed, Mar 13, 2013 at 3:04 PM, Brian LeRoux wrote:
> /me highfives all around
>
> On Wed, Mar 13, 2013 at 2:33 PM, James Jong wrote:
> > We
+1 for switching the deprecation window from time to release. Michal summed
it up perfectly.
It's worth reflecting on Tommy and Simon's input. The deprecation window is
there to give users adequate warning that breakage is impending. However,
it's just make-work for us, if our user's don't care or
Reads very well, nice work Braden!
I was going to mention adding the creation of a topic branch for
completeness, but Ian, Max, and you have already hashed that out.
I would vote to create a "Contributor" section under "Guides." If Marcel
feels there's importance in defining roles, then that's wh
I actually think the work would be with it if it actually meant that things
didn't break at ALL until something's window closed.. but the reality is that
this is a fast moving target and things like plugins are still breaking fairly
frequently (which is worse than core api's changing since core
Benn got the cordova-cli working on Windows 8 today and has made progress
on adding support for project-level cli tooling in the windows phone
implementations!
Go interns!
On 3/14/13 7:56 PM, "Michael Brooks" wrote:
>Welcome Shravan. That's a pretty rad intern role. We have a similar
>inte
33 matches
Mail list logo
