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

Reply via email to