cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anis KADRI <anis.ka...@gmail.com>
Subject Re: [ALL PLATFORMS] <icon> element support in config.xml
Date Tue, 05 Mar 2013 23:44:52 GMT
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 <bowserj@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 <michael@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 <fil@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" <bowserj@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 <fil@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" <bowserj@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 <fil@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" <agrieve@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 <bowserj@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 <fil@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
> >> >>>>>>> >
> >> >>>>>>>
> >> >>>>>
> >> >>>
> >> >
> >>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message