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 >>>>>>> > >>>>>>> >>>>> >>> >