It won't have to special case dealing with some stupid .plist format. And the rest of your args have been clarified by Fil.
On Thu, Nov 8, 2012 at 10:35 AM, Jesse MacFadyen <[email protected]>wrote: > Pluginstall will always have to special case iOS(all of them really), > because it must modify the project(s) > > Also, are we planning on replacing feature names in a cross device way? How > do we resolve this:? > iOS: > <key>Notification</key> <string>CDVNotification</string> > Android: > <plugin name="Notification" value="org.apache.cordova.Notification"/> > > Also there are various other differences that are not cross platform, like > useBrowserHistory or > > AllowInlineMediaPlayback. > What is the plan for these items? > > Cheers, > Jesse > > Sent from my iPhone5 > > On 2012-11-08, at 10:08 AM, Shazron <[email protected]> wrote: > > Hi Becky - yes Cordova.plist will go away entirely and it is to be replaced > by config.xml that follows the w3c widget spec, and the format would be > common among all the platforms (all the major ones currently). A dev can > certainly update the .xml from Xcode but it will be plain text editing > instead of the nice .plist editor - that is the trade-off. Having a common > config.xml would allow a common tool across the platforms to modify this > format -- right now I believe the tool we have (pluginstall?) would need to > special case the iOS platform to read and write the .plist format. > > The iOS specific settings would be replaced by feature elements: > http://www.w3.org/TR/widgets/#the-feature-element-and-its-attributes > > > On Thu, Nov 8, 2012 at 6:42 AM, Becky Gibson <[email protected]> > wrote: > > Ok, I'm a bit confused. Are we suggesting to get rid of the cordova.plist > > entirely? Does that mean that if a dev wants to change one of those > > settings they have to leave Xcode and modify config.xml and update the > > project? That certainly doesn't seems a bit cumbersome and not taking > > advantage of the OS specific tools. I can see using config.xml for > > Cordova specific things like the whitelist and plug definitions but some of > > the Cordova.plist items are iOS specific. Am I missing something? > > > -becky > > > > On Thu, Nov 8, 2012 at 7:23 AM, Brian LeRoux <[email protected]> wrote: > > > any reason why we should not follow our deprec policy here? > > > > On Wed, Nov 7, 2012 at 12:20 PM, Filip Maj <[email protected]> wrote: > > > Yeah and it pissed off users, esp since the docs weren't updated :) > > > On 11/7/12 12:00 PM, "Anis KADRI" <[email protected]> wrote: > > > Didn't Android just switch from plugins.xml + cordova.xml -> > > config.xml > > without deprecating anything ? > > > > On Wed, Nov 7, 2012 at 11:53 AM, Filip Maj <[email protected]> wrote: > > > IMO we should support both for at least a point revision or two and > > deprecate appropriately.. > > > On 11/7/12 11:49 AM, "Anis KADRI" <[email protected]> wrote: > > > Because generation McDonald's wants everything yesterday! Users > > don't > > like > > to think too much [1] > > > [1] > > http://www.amazon.com/Dont-Make-Me-Think-Usability/dp/0321344758 > > > > On Wed, Nov 7, 2012 at 11:44 AM, Jesse <[email protected]> > > wrote: > > > I would go cold turkey. > > Not sure why you need to write a cli tool, just instruct users > > that > > in > > version 2.3 and beyond, they must use config.xml, and tell them > > if > > they are migrating, they will have to put their data in the new > > format. > > > Not sure why we keep insisting on doing everything for everyone. > > but > > meh, I'm grumpy and old ... > > > On Wed, Nov 7, 2012 at 11:25 AM, Shazron <[email protected]> > > wrote: > > Do we want to still support the .plist (thus deprecate) or go > > cold > > turkey > > and support config.xml only? > > > I'd rather go cold turkey and write a cli tool to convert a > > Cordova.plist > > -> config.xml, which shouldn't be hard. > > > > > -- > > @purplecabbage > > risingj.com >
