It's worth pointing out that the same problems will apply to the splash screens.
> Since this is a compile-time property, how would we go about supporting it > across all platforms? I'm thinking either a) need to add logic into each > platform's CLI scripts to parse the contents of config.xml, grab/verify > icon assets, copy them over into appropriate place or b) move that > responsibility into the CLI tool, but then we'd need extra documentation > on how to update the icon on a per-platform basis in case users are not > using the cli tools. I want to lean on b) having the CLI take on the responsibility. However, since each platform currently supports config.xml parsing (e.g. whitelist), then for consistency it should also support <icon />. This leads into a bigger topic. I'm starting to feel like each native project should be just that - a native project. No config.xml support or conformance to the generic Cordova app specification. The Cordova CLI is the tool that unionizes all of the platforms under a common app specification. It would translate config.xml properties to the native manifests. Now... if we look back at our previous CLI efforts, we know that this is a path full of maintenance hell (decoupling native logic from the native project). One way to ensure native project compatibility with the Cordova CLI is to create small bin/ scripts for each CLI task. For example, a bin/ script to "install" an icon or a bin/ script to "update" the app name. The CLI can then shell out to these native bin/ scripts in the same way that it does to create or build a project. This is an ugly topic... thoughts? One more question that came up on the issue thread is, does the src attrib > need to be relative to the www? The concern here being that you will have > several megabytes of icon images in your application package that gets > used only for specific platforms, and only at compile time. I'm not sure > if there is some sort of convention we can come up with here to alleviate > this problem (perhaps in the context of using the CLI tools?). I think the icon paths should be defined relative to the config.xml, so relative to the www/. Now, for those users using cordova-cli, I am trying to see if we can come > up with a reasonable convention that solves the problem of packaging icon > assets that are not relevant for specific platforms. Why not simply delete (or not copy) icons referenced by the config.xml when we generate the native project (the artifacts as Brian calls them)? The config.xml tells us exactly what we don't want to include, so we can leverage that and ensure the www/ folder built by the native project does not include large, unused resources. On Tue, Mar 5, 2013 at 11:11 AM, Brian LeRoux <b...@brian.io> wrote: > Smells a little weird to me but we could introduce an /icons folder > within the /merges/<PLATFORM> folders as appropriate. Otherwise I see > /icons just mirroring /merges except slightly differently. > > On Tue, Mar 5, 2013 at 10:50 AM, Filip Maj <f...@adobe.com> wrote: > > I'm never into creating make-work. > > > > Solving this problem using the CLI tools allows for defining application > > metadata, including icons, without having to know ANYTHING about the > > native platform structures. However, I brought this discussion up > > (actually Daniel Pogue did on the JIRA issue), that it would be good to > > define these icons without toiling around "extra" assets on a > per-platform > > basis. > > > > We already enable this kind of customization of application name, package > > id, whitelist access, and application entry point (html page) all via > > config.xml. Now I want to push the support a bit further to allow users > to > > do the same thing with icons. The way icons differ from previous > > properties is that they are tied to specific assets. Just like the other > > properties, they need to be "set up" before the app gets compiled. > Leaving > > them in the www/ folder, in a way, is wasteful, since each platform only > > needs to consume a few icon assets at most, but the requirements for each > > icon asset differ vastly across platforms, and as such you end up with a > > lot of different assets [1]. > > > > First thing's first, we definitely need to document which icon assets > > people need to change in the native project structures for each platform. > > I'll set up issues for those. > > > > Now, for those users using cordova-cli, I am trying to see if we can come > > up with a reasonable convention that solves the problem of packaging icon > > assets that are not relevant for specific platforms. I have a few ideas: > > > > - have an icons folder under the .cordova folder, containing icon assets, > > that the config.xml's <icon> elements inside the platform-agnostic www/ > > folder reference. > > - have an icons folder under the platform-agnostic www/ folder that gets > > removed before compilation. This one is a little more clear to users but > > starts imposing restrictions on what can and can't be in the > > platform-agnostic www/ folder. > > > > Comments welcome! > > > > [1] https://github.com/phonegap/phonegap/wiki/App-Icon-Sizes > > > > On 3/5/13 9:54 AM, "Joe Bowser" <bows...@gmail.com> wrote: > > > >>OK, so the icon could exist online as well: > >> > >><icon src="http://phonegap.com/foo/bar/res/hdpi/icon.png"; /> > >> > >>I have no idea what this problem is trying to solve, or why we need > >>the icon tag other than to conform to the spec for the sake of > >>conforming to the spec. I don't think the icon should change at > >>runtime, and I think it's fine if some of the paths don't exist on all > >>platforms, since you can have multiple icon tags, right? > >> > >>On Tue, Mar 5, 2013 at 9:49 AM, Filip Maj <f...@adobe.com> wrote: > >>> Right, the tool would certainly copy the icon into the right place. The > >>> issue here is that config.xml is platform-agnostic, but we may coding > >>> paths to icons that may or may not be platform-specific. Here's an > >>> example, assuming paths are relative to native project root: > >>> > >>> <icon src="res/hdpi/icon.png" /> > >>> <icon src="www/res/icon.png" /> > >>> > >>> The first one would be Android-specific, and the second one would NOT > >>>work > >>> on Android. This is the kind of issue I'm looking to resolve. > >>> > >>> On 3/5/13 9:44 AM, "Joe Bowser" <bows...@gmail.com> wrote: > >>> > >>>>Since it's compile time, the icon should be available anywhere. Why > >>>>would it need to be relative to the www directory? I'm assuming the > >>>>CLI would copy the appropriate files from wherever they are to where > >>>>they would be on each platform, since I don't understand how it could > >>>>work any other way. > >>>> > >>>>On Tue, Mar 5, 2013 at 9:41 AM, Filip Maj <f...@adobe.com> wrote: > >>>>> That seems reasonable, thanks for your input guys. > >>>>> > >>>>> One more question that came up on the issue thread is, does the src > >>>>>attrib > >>>>> need to be relative to the www? The concern here being that you will > >>>>>have > >>>>> several megabytes of icon images in your application package that > gets > >>>>> used only for specific platforms, and only at compile time. I'm not > >>>>>sure > >>>>> if there is some sort of convention we can come up with here to > >>>>>alleviate > >>>>> this problem (perhaps in the context of using the CLI tools?). > >>>>> > >>>>> On 3/4/13 10:19 PM, "Andrew Grieve" <agri...@chromium.org> wrote: > >>>>> > >>>>>>I think we should plan for having all users using CLI. It really is a > >>>>>>bit > >>>>>>step forward. So... option b) is what sounds good to me. If users > >>>>>>don't > >>>>>>want to use CLI, then they shouldn't use the <icon> tag, and just > >>>>>>update > >>>>>>the asset in the native spots manually. > >>>>>> > >>>>>> > >>>>>>On Mon, Mar 4, 2013 at 1:18 PM, Joe Bowser <bows...@gmail.com> > wrote: > >>>>>> > >>>>>>> This is compile-time, so I think that the CLI tool should take > >>>>>>> responsibility for compile-time attributes. Per-platform CLI is > >>>>>>> already virtually unmaintainable as it is. > >>>>>>> > >>>>>>> On Mon, Mar 4, 2013 at 10:13 AM, Filip Maj <f...@adobe.com> wrote: > >>>>>>> > I've set up a parent issue to track progress [1]. > >>>>>>> > > >>>>>>> > Since this is a compile-time property, how would we go about > >>>>>>>supporting > >>>>>>> it > >>>>>>> > across all platforms? I'm thinking either a) need to add logic > >>>>>>>into > >>>>>>>each > >>>>>>> > platform's CLI scripts to parse the contents of config.xml, > >>>>>>>grab/verify > >>>>>>> > icon assets, copy them over into appropriate place or b) move > that > >>>>>>> > responsibility into the CLI tool, but then we'd need extra > >>>>>>>documentation > >>>>>>> > on how to update the icon on a per-platform basis in case users > >>>>>>>are > >>>>>>>not > >>>>>>> > using the cli tools. > >>>>>>> > > >>>>>>> > Thoughts/questions/comments? > >>>>>>> > > >>>>>>> > [1] https://issues.apache.org/jira/browse/CB-2606 > >>>>>>> > > >>>>>>> > >>>>> > >>> > > >
![http://phonegap.com/foo/bar/res/hdpi/icon.png"](http://phonegap.com/foo/bar/res/hdpi/icon.png"){kind=link}