Return-Path: X-Original-To: apmail-cordova-dev-archive@www.apache.org Delivered-To: apmail-cordova-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id D6288DFEF for ; Tue, 5 Mar 2013 17:59:57 +0000 (UTC) Received: (qmail 79394 invoked by uid 500); 5 Mar 2013 17:59:57 -0000 Delivered-To: apmail-cordova-dev-archive@cordova.apache.org Received: (qmail 79366 invoked by uid 500); 5 Mar 2013 17:59:57 -0000 Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cordova.apache.org Delivered-To: mailing list dev@cordova.apache.org Received: (qmail 79352 invoked by uid 99); 5 Mar 2013 17:59:57 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 05 Mar 2013 17:59:57 +0000 X-ASF-Spam-Status: No, hits=0.3 required=5.0 tests=FRT_ADOBE2,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of brian.leroux@gmail.com designates 209.85.223.176 as permitted sender) Received: from [209.85.223.176] (HELO mail-ie0-f176.google.com) (209.85.223.176) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 05 Mar 2013 17:59:53 +0000 Received: by mail-ie0-f176.google.com with SMTP id k13so7981856iea.7 for ; Tue, 05 Mar 2013 09:59:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=x5bUC2mvBdiWgHD3c32nQclHra5nN1504y8MZRpiKzI=; b=niYXHxQ3yepQLz3VqNWCEBzAx7wJFU2PsaLaNcoEcG7OiKUd8w1NL5aR8PgS/pDpc9 ht+jY94iCqX+TFpj1OqCF93Vr4Iaa2zWsPJ+dRrxjSBWz5CsN2+S49dm6cbY88xp2IdR EP+JyvVxu9UpjKXSINxVzmYw2JbK39r6d7UYeNBxg8zsTBliHf0rWzjGgbBAPyYEwWzk 7OFzid1Th/FuAPpwCf8NTIsz9SBuBXijMuZCaZ5c4lZxhOa7n7ruftEb8viblhsE6ZCq J+nWAdCaP/8pFh+e2YJBLpdsEzQN9nI95TD59rrY+zRaZdLEsn9SgcVVLLcYkekmh3ou fx1A== MIME-Version: 1.0 X-Received: by 10.42.95.147 with SMTP id f19mr27971091icn.24.1362506372740; Tue, 05 Mar 2013 09:59:32 -0800 (PST) Sender: brian.leroux@gmail.com Received: by 10.50.72.12 with HTTP; Tue, 5 Mar 2013 09:59:32 -0800 (PST) In-Reply-To: References: Date: Tue, 5 Mar 2013 09:59:32 -0800 X-Google-Sender-Auth: ksDzAX0K92_v0wojUWF5XuxQpao Message-ID: Subject: Re: [ALL PLATFORMS] element support in config.xml From: Brian LeRoux To: dev@cordova.apache.org Content-Type: text/plain; charset=ISO-8859-1 X-Virus-Checked: Checked by ClamAV on apache.org The cli tool should pretend that the ./platforms folders are build artifacts. I know we're not there yet but in an ideal world assets like these clobber, and in the future the ./platforms folder is not in revision control. Obviously we're going to need to document this behavior closely for each platform so its not too magical while we get down this road. On Tue, Mar 5, 2013 at 9:49 AM, Filip Maj 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: > > > > > 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" 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 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" 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 tag, and just update >>>>the asset in the native spots manually. >>>> >>>> >>>>On Mon, Mar 4, 2013 at 1:18 PM, Joe Bowser 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 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 >>>>> > >>>>> >>> >