I also disagree with getting rid of the config.xml part. It doesn't solve the current problem (or any problem I can think of). I also disagree with having multiple scrips that do one single thing. All platforms have common tasks (build, clean, log, run). They're just executed differently.
I believe that we should update ./cordova/build to support copying icons over. It's simple, easy and straight-forward. cordova-cli already uses that script so it shouldn't do anything extra. *In general, I believe the cordova-cli should ONLY rely on each platforms scripts. It should not try to do anything fancy or anything that users who don't use it can't do otherwise.* * * my 0.02 On Tue, Mar 5, 2013 at 3:30 PM, Joe Bowser <[email protected]> wrote: > I disagree! We've already put too much work into making Cordova > support config.xml. I think that we're at the point where we can: > > 1. Have multiple tools read the same XML file > 2. Have certain tags ignored by cordova, but read by cordova-cli > 3. Have certain tags ignored by cordova-cli but read by cordova > 4. Document this so that it makes sense for each platform. > > I'm not looking forward to going back and re-deprecating config.xml > support just because it's impossible to specify an icon at runtime > without the help of half-baked shell/bash scripts. The fact is that > the widget spec is a really poor spec, and was never intended to be > used for apps that have both runtime and compile-time elements. If > we're going to keep cramming this square peg into the round hole, > we're going to have to make the hole bigger, and fill in the parts > after the fact. > > > On Tue, Mar 5, 2013 at 3:14 PM, Michael Brooks <[email protected]> > wrote: > > 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 <[email protected]> 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 <[email protected]> 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" <[email protected]> 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 <[email protected]> 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" <[email protected]> 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 <[email protected]> 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" <[email protected]> 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 <[email protected]> > >> 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 <[email protected]> > 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}