cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Brooks <mich...@michaelbrooks.ca>
Subject Re: [ALL PLATFORMS] <icon> element support in config.xml
Date Wed, 06 Mar 2013 00:11:52 GMT
>
> 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.kadri@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 <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