Anis/Fil:
I've got a plugin that contains the following in the ios platform section:
The content tag is being copied fine, but the access tag is not (!). I was
under the impression that config-file would do a raw copy over to platform
config? Are we whitelisting/blackli
CB-3188
On Thu, Apr 18, 2013 at 6:52 PM, Anis KADRI wrote:
> the access tag should be top-level (as a common practice) but it should
> work anywayweird...
>
>
> On Thu, Apr 18, 2013 at 12:22 PM, Filip Maj wrote:
>
> > Bug, file that shizzle yo
> >
> >
Seems access tag does not work in top-level either.
On Fri, Apr 19, 2013 at 10:00 AM, Michal Mocny wrote:
> CB-3188
>
>
> On Thu, Apr 18, 2013 at 6:52 PM, Anis KADRI wrote:
>
>> the access tag should be top-level (as a common practice) but it should
>> work anyway.
The intention is that all debugging time is theoretically invalidated once
you land big new features. If we haven't done a lot of testing yet, then a
few feature cherry-picks this early on are fine by me, assuming no one has
already gone through all the testing motions.
-MIchal
On Fri, Apr 19,
in, it did however install my access tags that were in the top-level:
>
> https://github.com/phonegap/phonegap-facebook-plugin/blob/plugman-FB-SDK-3.2.1/plugin.xml#L12-L16
>
>
> On Fri, Apr 19, 2013 at 7:23 AM, Michal Mocny wrote:
>
>> Seems access tag does not work in top
I like it.
On Fri, Apr 19, 2013 at 1:56 PM, Filip Maj wrote:
> Cool, nice job brooks
>
> On 4/19/13 10:53 AM, "Michael Brooks" wrote:
>
> >Hey all,
> >
> >We've been having conflicts with referencing the next version in the edge
> >documentation.
> >
> >From now on, the edge documentation shou
gt;
> On Fri, Apr 19, 2013 at 11:29 AM, Michal Mocny
> wrote:
>
> > Very odd, I just tried using the exact same syntax and even moved the tag
> > to the same relative file location. Not working.
> >
> > Shaz, are you using the future branch?
> >
> >
>
I thought we decided to leave the VERSION in master branch as a constant
EDGE or something like that?
On Fri, Apr 19, 2013 at 9:01 PM, Jesse wrote:
> continuous instigation?
>
> @purplecabbage
> risingj.com
>
>
> On Fri, Apr 19, 2013 at 5:57 PM, Joe Bowser wrote:
>
> > I've re-tagged Android w
Hey,
Just found out that git now does support cloning a subdirectory of a
project using sparse-checkout mode (added in git 1.7, so super fresh).
Quick guide:
http://jasonkarns.com/blog/subdirectory-checkouts-with-git-sparse-checkout/
I know this was indirectly possible using a temporary director
;> If they do, I don't see any reason to have 16 repositories.
> >>
> >>
> >> On Mon, Apr 22, 2013 at 7:35 AM, Michal Mocny
> wrote:
> >>
> >>> Hey,
> >>>
> >>> Just found out that git now does support cloning a subdirec
found it. CB-3188 updated.
I think its another argument for moving more stuff out to prepare step.
Essentially the plugman install time work is being overwritten on prepare.
On Fri, Apr 19, 2013 at 2:51 PM, Michal Mocny wrote:
> I am, sorry, I should have said so.
>
>
> On Fri,
It we want to play with this with some useful benefit, what should we wait
for completion? The zip script and re-download button?
On Mon, Apr 22, 2013 at 4:29 PM, Andrew Grieve wrote:
> Better late than never. I've imported Shravan's work-in-progress
> cordova-app-harness work into the Apache
is an interesting one. What if two plugins want to change
> the content entry point into an app? Heh.
>
> On 4/22/13 11:42 AM, "Michal Mocny" wrote:
>
> >found it. CB-3188 updated.
> >
> >I think its another argument for moving more stuff out to prepare st
+1 move to prepare, however, why does this only apply to access tags?
On Tue, Apr 23, 2013 at 7:16 PM, Filip Maj wrote:
> that¹s what I was thinking too
>
> On 4/23/13 4:13 PM, "Anis KADRI" wrote:
>
> >On Tue, Apr 23, 2013 at 4:03 PM, Filip Maj wrote:
> >
> >> One thing that I intentionally r
target attrib)?
>
> On 4/23/13 7:28 PM, "Anis KADRI" wrote:
>
> >It doesn't. All configuration edits should happen in prepare
> >(adding/removing xml fragments etc..).
> >
> >
> >On Tue, Apr 23, 2013 at 7:05 PM, Michal Mocny
> wrote:
> >
e could just assume that whatever top
> level config-file with no target specified has to be config.xml but
> explicit is better than implicit in my opinion.
>
>
> On Wed, Apr 24, 2013 at 9:29 AM, Andrew Grieve
> wrote:
>
> > Yeah, for things like whitelist and preferen
I thought we switched to 3 release policy -- and planned to start in 2.7 to
be done by 3.0?
Or is that not official yet?
On Fri, Apr 26, 2013 at 12:48 PM, Joe Bowser wrote:
> I haven't added the tickets yet. Do we want to deprecate by 3.0 or
> follow the six month deprecation policy?
>
> On F
official, we should announce it in a blog or something. Are
> people cool with me writing a blog post about this and getting it on
> PhoneGap.com?
>
> On Fri, Apr 26, 2013 at 10:06 AM, Michal Mocny
> wrote:
> > I thought we switched to 3 release policy -- and planned to start i
No plans for vacations yet, though I will likely take some in July.
No conferences until PGDay.
-Michal
On Thu, May 2, 2013 at 10:22 AM, Andrew Grieve wrote:
> Away Tues->Friday next week.
> Gone most of July for paternity :)
>
>
> On Thu, May 2, 2013 at 10:18 AM, James Jong wrote:
>
> > I'm
If you are using cordova-cli, there is already a merges/ folder for exactly
this.
>From the README:
Platform-specific web assets (HTML, CSS and JavaScript files) are contained
within appropriate subfolders in this directory. These are deployed during
a prepare to the appropriate native directory.
> > reasons,
> > >> in fact, most people were favorable for the change to app/.
> > >>
> > >> So, with plugman stabilizing and my focus moving to cli work, I feel I
> > >> have a good grasp of both projects and the direction they are going,
>
>> of
> >> > the structure are now contained in a single directory, and easier to
> >> > version control.
> >> >
> >> > This change gets more expensive every day. If we're ever going to do
> it,
> >> it
> >> > should be
a promoted flow (matter of fact,
why was it released? Are we supporting current users of that, is that it?)
-Michal
On Thu, May 23, 2013 at 12:22 PM, Michal Mocny wrote:
> Brian,
> I do not really understand your previous point, but I'll take a stab.
>
> First some clarificatio
and it in full and remove
> deprecation messages about it in 3.0.
>
> On 5/23/13 9:27 AM, "Michal Mocny" wrote:
>
> >Clarification of typing mistake, below..
> >
> >Also, curious why this breaks things in the first place? I thought this
> >is
> &g
ing
> > C) continue with this discussion to try to get to a resolution.
> Worst-case
> > we call a vote next week?
> >
> > On 5/23/13 10:56 AM, "Michal Mocny" wrote:
> >
> >>Fil, that sounds extremely sensible.
> >>
> >>
> >
[private reply]
Didn't want to sidetrack the discussion, but im curious about your
chromebook workflow.. are you doing full local dev using crouton, using a
remote connection, or something like phonegap build using local environment
just for text editing?
And which machine are you using?
Thanks.
Well I just suck. Please ignore me and dont sidetrack the original
question!
On Sun, May 26, 2013 at 10:06 PM, Michal Mocny wrote:
> [private reply]
>
> Didn't want to sidetrack the discussion, but im curious about your
> chromebook workflow.. are you doing full local dev usi
Thats pretty interesting, Alessio. It is very similar in concept to the
app-harness[1][2] project we are working on, except we were not planning to
integrate directly with dropbox, instead use a web server hosted solution.
We would love to hear your feedback on the project, and any
advice/request
Can we go with (1) and still keep master2 around (perhaps rename it to
something sensible) so that we can still get full history but with one
level of indirection:
- The mega commit could have a commit message such as "THIS WAS A HACKY
MERGE, FOR REAL HISTORY LOOK IN THE OLD_FUTURE BRANCH"
- When y
; We can avoid all of that
> nonsense with three lines.
>
> Braden
>
>
> On Wed, May 29, 2013 at 11:38 AM, Michal Mocny
> wrote:
>
> > Can we go with (1) and still keep master2 around (perhaps rename it to
> > something sensible) so that we can still get full histor
I would love to be able to split the JIRA updates for RC/Release management
out into a separate email folder. What do you think?
-Michal
Adding to Bradens answer, here are some things I remember discussing:
- Chrome/Android teams have significantly harder constraints than cordova
would have in terms of backwards compatibility, stability, and API
consistency. Cordova could probably do interesting things if we didn't
need to support
+1.
However, do we want to support 2.x for some extended time during the
tooling transition to 3.x for everyone? One way to do this is just land a
constant stream of point releases on the 2.9.x branch. Another way could
be to branch a 2.x long-lived feature branch before merging in 3.0.0 and
con
100 yard summary: our intern Shravan from last term was adding this as part
of his app-harness work. This specific change landed a too hastily as
there were some issues in corner cases (perhaps over-eagerness due to time
pressure as he approach term end), but all actual uses of DataResource
should
Glad to see movement on this.
Few suggestions:
- use $HOME/.cordova-config/libs <-- this gives us a folder to put other
stuff into later, without littering $HOME with .cordova-this and
.cordova-that
- I would love to have the ability to use different cordova-lib versions
within any project easily
tests are currently
> disabled
> > > (and not passing), so I am in favor of closing the serve-related issues
> > as
> > > won't fix and suggesting people employ `cordova ripple` instead.
> > >
> > > On 3/23/13 7:15 AM, "Andrew Grieve"
We hope to get a fixed up DataResource on android in for 2.9, Braden is
working on that.
+1 to lazy loading libraries in 2.9 and release timing.
On Mon, Jun 10, 2013 at 4:23 PM, Filip Maj wrote:
> Hey all,
>
> What do we want to ship in 2.9 other than the usual batch of fixes? Does
> anyone ha
onsolidated and fixed. DEFINITELY want to have good integration with the
> app harness. I have yet to play around with it, actually, to my shame.
> Michal are there any specific things necessary for the app-harness other
> than a local server?
>
> On 6/10/13 1:23 PM, "Michal
x wrote:
> There is an interesting nugget here. Maybe there should be things like
> ./platforms/ripple (and ./platforms/chrome-packaged-app
>
> ???
>
> makes sense to me.
>
>
> On Mon, Jun 10, 2013 at 1:42 PM, Michal Mocny wrote:
> > - App-harness is 99%
Hello! Welcome :)
On Mon, Jun 10, 2013 at 5:11 PM, Ken Wallis wrote:
> Welcome to the group Lisa!
>
> I do have to ask, have you looked at the new BlackBerry's?
>
> Sent from my BlackBerry 10 smartphone.
> From: Tommy Williams
> Sent: Monday, June 10, 2013 2:04 PM
> To: dev@cordova.apache.org
>
encouraging CLI usage instead of the traditional path.
> > >
> > >
> > >
> > > On Mon, Jun 10, 2013 at 1:30 PM, Michal Mocny
> > wrote:
> > >> We hope to get a fixed up DataResource on android in for 2.9, Braden
> is
> > >> work
Witam, Piotr!
On Tue, Jun 11, 2013 at 11:15 AM, Filip Maj wrote:
> Welcome man!
>
> I would totally link you to all the repos and which ones are important and
> how to get started, but the apache git servers we rely on are currently
> down :(
>
> On 6/11/13 6:47 AM, "James Jong" wrote:
>
> >Gr
le of how to download cordova-android 2.8.0 [1]. I
> >>think
> >> >this is better than downloading the entire release, because
> >>lazy-loading
> >> >is
> >> >meant to only grab what's needed. It's also a better choice than
> >>Gi
Before we go changing process, is this really a systemic issue? Bugs
happen, and people sometimes land code, I'de rather be nimble in fixing
those issues than rigid in preventing them. Personal opinion.
-Michal
On Wed, Jun 12, 2013 at 9:54 AM, Ian Clelland wrote:
> That's not an issue of "we
gt;conflicts
> >> > >>> > >and try to push the result. No one is likely to do that, and
> >>they
> >> > >>>still
> >> > >>> > >can't cause lasting damage unless it's a committer. All the
> >> > >>>commit
oks great, Fil!
> >
> >Braden
> >
> >
> >On Tue, Jun 11, 2013 at 9:30 PM, Michal Mocny
> wrote:
> >
> >> That sounds awesome, sweet work Fil!
> >>
> >> Question: your cordova-android lib example has the uri
> >> &
2.10 would mean new features, 2.9.x would mean just bugfixes. With that
definition, we can make the release number decision as we evaluate the
reason for a release. I'm hoping to not need a 2.10, since it would imply
people are not using 3.x yet.
On Mon, Jun 17, 2013 at 10:54 AM, Andrew Grieve
Great idea to expand the output.
I do prefer the explicit `ls` and would rather have the default be --help.
Given that, `ls` is harmless, so I don't much mind.
On Tue, Jun 18, 2013 at 1:36 PM, Michael Brooks wrote:
> I think [1] is up to the command patterns that cordova-cli uses. As far as
>
would be possible for an app that
uses the bridge heavily to remain using the UI thread indefinitely, right? Can
we assume that this is unlikely to happen, ie, the exec queue will drain to 0
relatively quickly?
- Michal Mocny
On June 21, 2013, 5:21 p.m., Jeffrey Willms wrote
Are we behind/ahead of schedule? Seems important to be organized about the
work left to do here. Also, "3.0 is already behind" has come up as an
argument a few times on the lists, so lets quantify that.
JIRA 3.0.0 fix version tracker [1] seems like it must be an incomplete list
of tasks, right?
Yeah, rebase private (local) commits liberally, never rebase public commits.
Also, merge commits do come with a cost. Aside from the extra commits
adding noise, it becomes more difficult to track branch history for
anything complicated.
** Aside ** RE: git rebase origin/master after an accidenta
To answer the question of why we may want to leave it out:
- If you are using remote debugging on ios6+ you don't need it
- Our log wrapper has been repeatedly less functional than the system
implementation (though we do fix these issues as they are found)
But that does not mean I am arguing agai
; > On Jul 2, 2013, at 3:22 PM, Brian LeRoux wrote:
> >
> > > Its a good point about ios6+. I can't imagine anyone is developing for
> > > anything less (other than corodva@<=2.9 legacy support).
> > >
> > >
> > > On Tue, Jul 2, 2013 at 11:44 A
Andrew and I had that conversation as few days ago, and he convinced me
that shipping code to end users should mean shipping with node_modules
(this sentiment is repeated from the creators of npm it seems). That way,
any given users' node setup/platform version issues don't affect your code.
Thus
build phase or additional steps that are not supported by the
> plugman specs out of the box. Besides npm supports it [1] so why not
> plugman ?
>
> [1] https://npmjs.org/doc/scripts.html
>
>
> On Wed, Jul 3, 2013 at 10:42 AM, Michal Mocny wrote:
>
> > Andrew and I h
On Wed, Jul 3, 2013 at 1:13 PM, Tyler Wilson wrote:
> Good day,
>
> Just wanted to publicise that I have had success with the cli, a custom
> plugin and an iOS build. I must say once everything is set up it is pretty
> nice being able to add/remove components and it appears to handle things
> just
If master is in use, then I think that is a mistake.
As far as I'm aware, master branch should be "dead" right? We had a 'next'
branch that was for 3.0 work which diverged from master and the merge back
was not clean (for various reasons), hence we "temporarily" went with a
master2 until we could
(small correction, next was actually called future).
Also, I don't see any work being done on master.
On Thu, Jul 4, 2013 at 1:18 PM, Michal Mocny wrote:
> If master is in use, then I think that is a mistake.
>
> As far as I'm aware, master branch should be "dead&q
> for the `fetch` command. All it does is copy the plugin code from location or URL> to a plugins directory. With --link, instead it will
> symlink. It does not actually create symlinks for native or web plugin
> code.
>
> Would that even work, I wonder? For compiling, etc.
>
iOS seems to have an undocumented "feature" to call into javascript before
every device orientation change (pasted below for your viewing pleasure).
I can't find any such similar functionality on other platforms, should it
be removed? Likely we will want to write a screen orientation (
http://www
ntly.[1]
> >
> > Agreed that supporting the screen-orientation spec is probably the way to
> > go in the future, on any platforms that can support it.
> >
> > [1]
> >
> >
> http://developer.apple.com/library/ios/#documentation/uikit/reference/UIViewC
ng (video?) in landscape thus "overriding" the app
> default.s
>
>
> On Fri, Jul 5, 2013 at 9:11 AM, Michal Mocny wrote:
>
> > Yeah, sorry, I meant the JS method: window.shouldRotateToOrientation is
> > undocumented and not supported on other platforms.
> &g
I think the use case is valid. Patch seems simple enough.
-Michal
On Fri, Jul 5, 2013 at 1:25 PM, Filip Maj wrote:
> Someone sent a pull request:
>
> https://github.com/apache/cordova-cli/pull/16
>
>
> Thoughts?
>
>
Not sure I understand how it is that this cannot be supported..
Couldn't we allow native plugins to register synchronous "observers" for
the CDVWhitelist URLIsAllowed method, and move the current implementation
out to a core plugin? Then if your app wants something more complicated,
you can just
Ian, that sounds great, but as a small nit could we rename alpha to dev?
alpha sounds like a release tag, and we've been using dev for upstream
work on master. I do like adding the next version information to it.
-Michal
On Mon, Jul 8, 2013 at 10:57 PM, Ian Clelland wrote:
> On Mon, Jul 8, 20
reviews.apache.org is just a place to submit patches for review, manage
comments on lines of code etc.
Some of us have started using it to organize reviews of patches. Its not
the most beautiful interface, but it serves its purpose.
I just tried it and submitting a new review I see many more tha
he problem is that folks are not setting the "Group" field to
> "cordova" when they do a new Request?
> Could this be a required field when the repository starts with "cordova*" ?
>
> --Carlos
>
>
>
> On Tue, Jul 9, 2013 at 9:38 AM, Michal Mocny wro
ache.org/groups/cordova/
>> >
>> > I got to "My Account" seetings and I can only add one group "cordova"
>> > Which groups do you belong to or wish to watch?
>> > [] cordova
>> >
>> > Maybe the problem is that folks are not set
t;> > > Thanks Andrew!
> >> >> > >
> >> >> > > Ian, will do.
> >> >> > >
> >> >> > > On 7/5/13 8:14 AM, "Ian Clelland" wrote:
> >> >> > >
> >> >> > > &
; > > >> > > Thanks Andrew!
> > > > >> > >
> > > > >> > > Ian, will do.
> > > > >> > >
> > > > >> > > On 7/5/13 8:14 AM, &quo
I'de have to disagree with that argument, Joe. I think Andrew did the work
for core plugins, and there should be no published external plugins using
the new 3.0 plugin structure yet, right?
Are we intending to not break compatibility with some hypothetical external
plugin dev who used a pre-relea
If we did that, wouldn't they both effectively just end up the same, anyway?
(See what I did there?)
Seriously though, if the schema is changing isn't that all the more reason
to support validation so devs can get early confirmation?
-Michal
On Tue, Jul 9, 2013 at 7:45 PM, Brian LeRoux wrote:
Yeah, thats true, willingness to support plugins by original devs changes
with time. Its just inevitable.
I wonder if the solution here doesn't just end up being the plugin
universe? As maintenance is dropped, other willing devs have to take over
ownership via forks, and we update the references
Fil, as an alternative to could you use a with
instead of clobbers/merges? (not a proposal, just curious)
-Michal
On Wed, Jul 10, 2013 at 7:52 PM, Filip Maj wrote:
> I think you may have to use a combination of both to get it right
>
> On 7/10/13 4:46 PM, "Jesse" wrote:
>
> >Thanks Fil,
>
Tue, Jul 2, 2013 at 11:54 PM, Steven Gill
> > > wrote:
> > >
> > > > +1 to making it a platform dependency and keeping it as a plugin.
> > > > On Tue, Jul 2, 2013 at 2:37 PM, Brian LeRoux wrote:
> > > >> I love that idea. Makes transiti
Fil, I kinda like that proposal, but Andrew previously brought up some
valid concerns: That would work great if there was only one object to
clobber, but if there is a set of them, you likely want to clobber
all-or-none. Not sure if this should be handled at the plugin manifest
level.
Also, perha
Fil has mentioned that we will eventually add a way to specify the starting
app template (ie, the "hello world" app) at cordova create time.
In mobile-chrome-apps land we do this via an optional --source=... flag,
and it accepts a few "magic" values such as --source=spec to automatically
create a
)
>
>
> On Thu, Jul 11, 2013 at 11:31 AM, Michal Mocny
> wrote:
>
> > Fil has mentioned that we will eventually add a way to specify the
> starting
> > app template (ie, the "hello world" app) at cordova create time.
> >
> > In mobile-chrome-apps lan
ing the template.
> Adding this for iOS is easy in the create script (just parameterize the
> template folder location)
>
>
> > On Thu, Jul 11, 2013 at 11:31 AM, Michal Mocny
> wrote:
> >
> > Fil has mentioned that we will eventually add a way to specify the
> start
t; On Thu, Jul 11, 2013 at 2:45 PM, Michal Mocny (JIRA) >wrote:
>
> > Michal Mocny created CB-4153:
> >
> >
> > Summary: Add ability to select default app template at
> > "cordova create" time
> >
Agree with Shaz, most of these thoughts already addressed in that bug.
Please add further opinions about specifics there.
On Fri, Jul 12, 2013 at 10:48 AM, Shazron wrote:
> Might be worth chiming in on the CB-4153 thread on this ML ("app" folder
> concept)
>
>
> On Fri, Jul 12, 2013 at 7:39 AM
gree we'd like a path for project generation.
> >>
> >>
> >> On Fri, Jul 12, 2013 at 8:03 AM, Michal Mocny
> wrote:
> >> > Agree with Shaz, most of these thoughts already addressed in that bug.
> >> > Please add further opinions about spec
Anis, if it was just a matter of blank-or-default-only that would be fine,
but I think we do want a way to start with arbitrary app, and so "blank" is
just one extra option (Can even be implemented not as a cli special case,
but just as an app template referenced by the already planned generic
impl
Does that mean 4.0 will ship for PGDay EU 2014? I think thats got good
symmetry.
On Wed, Jul 17, 2013 at 3:41 PM, Shazron wrote:
> +1 I like the fall idea
>
> For Cordova 3.11 I propose we call it "Cordova for Workgroups" :P
> http://www.zdnet.com/linux-3-11-linux-for-workgroups-718091/
>
This reminds me of a recent experiment Google+ team did for performance,
and they replaced all CSS loads from XHR with tags and god a big
perf boost to load times. Seems its best to let the browser do what it
does best.
-Michal
On Mon, Jul 15, 2013 at 2:57 PM, Shazron wrote:
> On a related n
Well, we should obviously not go purging the source, but I think that if it
isn't actively being maintained or tested, then it should be included in
releases and given new version numbers.
Unless there is anyone interested in maintaining it, I think the best we
can do for users is signal the last
One thing you could do today, Ray, is create a plugin which lists all the
plugin dependencies you want, then only add that one whenever you create a
new project.
If you would like, you could even publish that plugin as a
"cordova-core-useful-plugins" plugin or under some such name.
Otherwise, I do
le for general use though
> (pathing):
>
> https://github.com/apache/cordova-mobile-spec/blob/master/dependencies-plugin/plugin.xml
>
>
> On Tue, Jul 23, 2013 at 11:37 AM, Michal Mocny
> wrote:
>
> > One thing you could do today, Ray, is create a plugin which lists all
I haven't actually played with this yet. I think this would make an
awesome blog post. Found an old note that says "record a video to show off
the app-harness". I still think thats a good idea.
On Tue, Jul 23, 2013 at 2:54 PM, Brian LeRoux wrote:
> I'll ping the legal list to see what the pr
addressed by anis's work
>
> On Tue, Jul 23, 2013 at 3:17 PM, Ray Camden wrote:
> > I'd rather not see PG rely on another tool like yeoman. Just my 2 cents.
> > If I'm using the phonegap CLI to build it out and do stuff I'd rather
> stay
> > in th
I am not sure what form the chromecast SDK will have for browser (this was
not leaked internally). I suspect it is very likely to use some
chrome-specific extensions hence it was listed as a Chome-Api and no Web/Js
Api. Net/net, unlikely that you will see a PG plugin for this any time
soon -- we
I take that back, possibly we can build a plugin with the ios/android sdk.
I'm not sure what it would mean to stream media using this API and am not
all too hopeful that it will support web content from ios/android webview :(
On Wed, Jul 24, 2013 at 3:46 PM, Michal Mocny wrote:
>
/questions/13616449/screen-sharing-with-webrtc
On Wed, Jul 24, 2013 at 3:49 PM, Michal Mocny wrote:
> I take that back, possibly we can build a plugin with the ios/android sdk.
> I'm not sure what it would mean to stream media using this API and am not
> all too hopeful that it will suppo
Tommy-Carlos: Just so I understand, are you saying that it is necessary to
run a script to move your icons around correctly? Isn't that defeating the
point of the merges folder? Are you using merges/ specifically for its
merging ability, or just as a place to hold resources -- and isn't the
www/.
My understand was that: events fire faster than UI paints, and general good
design is to coalesce and update UI once on RAF. In this case, the events
came from native and were sent across the bridge, which meant the while the
app js could do the coalescing, doing it on the native side meant huge p
While I like that idea, what happens when creating the plugin result is
"heavy", perhaps needing to synchronize with background threads etc?
Waiting on the callbacks may not be a great plan.
Could an alternative be to just support a "clobber" boolean flag, to
replace old PluginResult (instead of
Just to be clear, thats 58% of *total* exec round trip time (580ms) , or
58% of only the native bits?
If its over half of the total, thats ridiculous.
-Michal
On Mon, Jul 29, 2013 at 11:36 AM, David Kemp wrote:
> I have been doing some testing on the bridge to see how the current
> implementa
obbers, how do you know what the JS side has already been sent?
>
> We could probably do similar timing + logging to detect slow plugins in
> this case.
>
>
> On Mon, Jul 29, 2013 at 2:08 PM, Michal Mocny wrote:
>
> > While I like that idea, what happens when creating t
Are you moving to Singapore?!
On Mon, Jul 29, 2013 at 5:10 PM, Shazron wrote:
> Hi guys,
> I'll be away from Aug 1st and back on Aug 26th, where my work hours will be
> UTC+08:00 (Singapore time) based.
>
> Not sure when 3.1.0 is slated to be released, but it's likely I will miss
> the window f
Just did a few quick tests: while shelljs exec may be slow, seems we are
not using it in a nested way (which seems quite obvious).
I wrote a quick benchmark to:
cordova plugin ls
cordova platform ls
cordova prepare
in a loop a bunch of times and see almost zero time difference replacing
shelljs
1 - 100 of 1338 matches
Mail list logo
