> > 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.
I whole heartily support this. I probably worded my original response in the wrong way. The point is that the Cordova CLI should not deal with platform-specifics. We know from past experiences that decoupling the platform responsibility will result in a large, difficult to maintain tool. On Tue, Mar 5, 2013 at 3:44 PM, Anis KADRI <anis.ka...@gmail.com> wrote: > 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 <bows...@gmail.com> 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 <mich...@michaelbrooks.ca > > > > 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 <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}