cordova-statusbar created, that was fast. I'm migrating the statusbar folder to that repo now.
On Thu, Mar 13, 2014 at 12:35 PM, Shazron <shaz...@gmail.com> wrote: > https://issues.apache.org/jira/browse/INFRA-7444 > > > On Thu, Mar 13, 2014 at 11:50 AM, Shazron <shaz...@gmail.com> wrote: > >> Alright, I'm going to start on this today: >> >> org.apache.cordova.keyboard stays in cordova-plugins but has a new >> namespace: org.apache.cordova.labs.keyboard >> org.apache.cordova.statusbar stays in cordova-plugins *for now* until we >> get a new repo, and keeps its existing namespace >> >> >> On Tue, Mar 11, 2014 at 11:55 AM, Jesse <purplecabb...@gmail.com> wrote: >> >>> oops, yeah Shaz. "statusbar namespace does *not* change" >>> >>> @purplecabbage >>> risingj.com >>> >>> >>> On Tue, Mar 11, 2014 at 11:50 AM, Shazron <shaz...@gmail.com> wrote: >>> >>> > The proposal looks good to me. Since the majority of the code for the >>> two >>> > plugins have been contributed by me, I will continue to help maintain >>> them. >>> > One thing though -- "statusbar namespace changes" -- I believe you >>> wanted >>> > to say "statusbar namespace does *not* change" >>> > >>> > >>> > >>> > >>> > On Tue, Mar 11, 2014 at 11:01 AM, Jesse <purplecabb...@gmail.com> >>> wrote: >>> > >>> > > Andrew, I agree with all of that, and never suggested that statusbar >>> not >>> > be >>> > > a plugin. >>> > > >>> > > Attempting to rescue this thread into something we can do? ... >>> > > >>> > > >>> > > >>> > > Plugins: >>> > > [PROPOSAL] >>> > > org.apache.cordova.labs.keyboard >>> > > - a iOS only keyboard plugin doing some very iOS specific stuff, >>> lives in >>> > > labs >>> > > - there is no change here, so proposal is that it stays the same >>> > > >>> > > [PROPOSAL] >>> > > org.apache.cordova.statusbar >>> > > - a status bar plugin for Android, iOS, and Windows Phone, lives in >>> core, >>> > > maintained by at least Jesse >>> > > - statusbar namespace changes, and it get's own repo possibly >>> > > >>> > > To discuss further ( in their own threads ) >>> > > - default plugins, really just one plugin with dependencies >>> > > - expected intrinsic functionality, console.log? >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > @purplecabbage >>> > > risingj.com >>> > > >>> > > >>> > > On Tue, Mar 11, 2014 at 10:05 AM, Brian LeRoux <b...@brian.io> wrote: >>> > > >>> > > > I like this idea. Achieves all concerns. (Separation thereof, and >>> > > > onboarding ease.) >>> > > > >>> > > > >>> > > > On Tue, Mar 11, 2014 at 9:04 AM, Carlos Santana < >>> csantan...@gmail.com >>> > > > >wrote: >>> > > > >>> > > > > +1 Keep it as a plugin not embed into platform repo >>> > > > > >>> > > > > default plugins ? >>> > > > > >>> > > > > what about binding a set of default plugins with our www >>> template app >>> > > > (the >>> > > > > template app specified what plugins are required) >>> > > > > >>> > > > > meaning associate a set of plugins with a template www app, and >>> not >>> > > > > associate with platform or cli >>> > > > > >>> > > > > >>> > > > > >>> > > > > >>> > > > > >>> > > > > On Tue, Mar 11, 2014 at 10:37 AM, Andrew Grieve < >>> > agri...@chromium.org >>> > > > > >wrote: >>> > > > > >>> > > > > > Plugins allow us to share JS. Rolling statusbar into platforms >>> > means >>> > > > > > different JS for all platforms, and make it easier for the >>> APIs to >>> > > > > diverge. >>> > > > > > >>> > > > > > Plugins allow us to share docs, and to have the docs live with >>> the >>> > > > code. >>> > > > > > APIs like Android's "app" plugin don't have very good docs (or >>> > maybe >>> > > > they >>> > > > > > are just undiscoverable, or maybe I've just missed where they >>> are). >>> > > But >>> > > > > > having consistency with docs is a big win I think, so having >>> > > statusbar >>> > > > > as a >>> > > > > > plugin means devs can go to its plugin page to find its docs. >>> > > > > > >>> > > > > > I think just having default plugins would achieve the "everyone >>> > will >>> > > > > > probably want it" concern. But having it show up in "cordova >>> plugin >>> > > ls" >>> > > > > > will help devs discover that it's there and that they should >>> > probably >>> > > > use >>> > > > > > it. >>> > > > > > >>> > > > > > >>> > > > > > On Tue, Mar 11, 2014 at 8:49 AM, Jonathan Bond-Caron < >>> > > > > > jbo...@gdesolutions.com> wrote: >>> > > > > > >>> > > > > > > On Mon Mar 10 04:07 PM, Jesse wrote: >>> > > > > > > > More on the concept of rolling into a platform ... >>> > > > > > > > My distinction is that there are some things that every >>> > platform >>> > > > > should >>> > > > > > > consider a >>> > > > > > > > baseline of browser functionality, and if the OS SDKs do >>> not >>> > > > provide >>> > > > > it >>> > > > > > > out of the >>> > > > > > > > box, then we should. Some examples of this : >>> > > > > > > > >>> > > > > > > > 1. Local XHR, Windows Phone does not support xhr when >>> trying to >>> > > > > access >>> > > > > > a >>> > > > > > > file:// >>> > > > > > > > url, I could have made this a plugin that would only be >>> used on >>> > > WP, >>> > > > > but >>> > > > > > > I think >>> > > > > > > > this functionality should be intrinsic, so now it is. >>> > > > > > > >>> > > > > > > +1 >>> > > > > > > >>> > > > > > > > 2. console.log: if you create a brand new iOS cordova >>> project, >>> > > the >>> > > > > > > hello-world app >>> > > > > > > > gives you some boilerplate code to get started. One thing >>> that >>> > > new >>> > > > > > > users may >>> > > > > > > > notice is the use of console.log in index.js, however, they >>> > will >>> > > > > never >>> > > > > > > see the >>> > > > > > > > output. Hooking conosle.log output to go to the >>> command-line >>> > > > output >>> > > > > of >>> > > > > > > a run >>> > > > > > > > command, or the output window of visual studio, or xcode >>> is the >>> > > > > minimum >>> > > > > > > > functionality, and I personally think it should be built >>> in. >>> > This >>> > > > is >>> > > > > > > probably best >>> > > > > > > > discussed in a new thread, as I know Michal has a different >>> > > > opinion, >>> > > > > > > because of >>> > > > > > > > some weinre edge case, but this is meant to serve more as >>> an >>> > > > example. >>> > > > > > > > >>> > > > > > > >>> > > > > > > Yep agree, distinction here is there's ~ "web dev" flow and >>> > "native >>> > > > > dev" >>> > > > > > > flow (using an IDE) >>> > > > > > > >>> > > > > > > Both of those should be core somehow >>> > > > > > > >>> > > > > > > >>> > > > > > >>> > > > > >>> > > > > >>> > > > > >>> > > > > -- >>> > > > > Carlos Santana >>> > > > > <csantan...@gmail.com> >>> > > > > >>> > > > >>> > > >>> > >>> >> >> >
