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> > > > > > > > > > >
