cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Axel Nennker <ignisvul...@gmail.com>
Subject Re: Icons and Splash Screens (bug?)
Date Mon, 14 Apr 2014 19:54:00 GMT
There is a pull request related to cb-2606 for cordoava-docs. Sorry can't
find the link to it on my phone. Sergey knows more I think.

Axel
https://github.com/apache/cordova-cli/pull/126
 Am 14.04.2014 20:35 schrieb "Brian LeRoux" <b@brian.io>:

> Hey Jeremy: ah now I get you! I've cc'd the Cordova list to see if this is
> known (and we'll add a bug either way to fix).
>
> Thanks mang!
>
>
> On Mon, Apr 14, 2014 at 9:58 AM, Jeremy Battle <battlejj@gmail.com> wrote:
>
> > Brian,
> >
> > This is @complexcarb from Twitter, sorry for moving to e-mail but 140
> > characters is difficult to manage sometimes.
> >
> > The issue I am having is that in the 3.4 docs (
> >
> http://cordova.apache.org/docs/en/3.4.0/config_ref_images.md.html#Icons%20and%20Splash%20Screens
> )
> > they state that when a new project is created the folder www/res/icons
> and
> > www/res/screens will be created for icons and splash screen images
> > respectively. However, when I create a new project using Cordova 3.4 that
> > structure is not created. Which is fine, I created them myself based on
> how
> > Phonegap 3.4 creates the folder structure. But even in doing so neither
> the
> > assets in www/res/icons or www/res/screens are used in any way during a
> run
> > or build of the application.
> >
> > Now I can just create a grunt/gulp task to go ahead and move my icons
> into
> > the appropriate platforms/android/res/drawable* folder (which I've done
> and
> > works), that's not really a big issue, but the docs make this extremely
> > confusing referring to folder structure that isn't created, and then
> doing
> > nothing with the contents when that structure is used.
> >
> > So this is probably just incorrect documentation and not a bug in
> Cordova.
> > I should have originally tweeted that the Cordova CLI does not do what
> I'd
> > expect based on the documentation.
> >
> > Does this make a bit more sense?
> >
> > -Jeremy
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message