Hi,
I was wondering if there has been any discussion about using Chrome
packaged apps as a platform. This seems like it would be much easier than
targeting windows, OS X, and possibly Linux separately since Chrome runs on
them all. I've seen chrome-cordova (
https://github.com/MobileChromeApps/chro
My answers in line, thanks for taking the time to run through the tool
Becky!
On 3/5/13 11:39 AM, "Becky Gibson" wrote:
> 1. Although I could easily figure it out from the note about changing
> ownership of the cordova directory, it would help to state up front the
> directory where cordov
Hi all,
I'm getting up to speed with Cordova but have encountered some confusing doc
issues:
1) When upgrading a project from 2.4.0 to 2.5.0, the upgrade instructions say
to make several changes to "your config.xml file", when in reality all changes
seem to indicate that it's a change to the t
>
> 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 t
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 believ
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
>
> For Android plugin developers if they want to keep their source hidden they
> could provide only the class that extends from CordovaPlugin in source form
> and have it call their code in a provided jar file. Just trying to think of
> a simple way for folks to provide "for pay" plugins.
Good t
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, gr
Yeah, it was just a proof of concept. All I need to do now is just add the
platform specific exec.js and we will have our own OS X cordova.js, it
won't work for all the APIs though, since we don't have all the core
plugins implemented.
On Tue, Mar 5, 2013 at 8:41 AM, David Lewis wrote:
> That a
For Android plugin developers if they want to keep their source hidden they
could provide only the class that extends from CordovaPlugin in source form
and have it call their code in a provided jar file. Just trying to think of
a simple way for folks to provide "for pay" plugins.
Simon Mac Donald
I played around a bit with cordova-cli and have a few comments and
questions. I think a bit more detail in the instructions would resolve
most of my issues. I think I am a fairly good test subject with respect
to Android since I am not familiar with the SDK and don't use it much. I
also haven'
Smells a little weird to me but we could introduce an /icons folder
within the /merges/ folders as appropriate. Otherwise I see
/icons just mirroring /merges except slightly differently.
On Tue, Mar 5, 2013 at 10:50 AM, Filip Maj wrote:
> I'm never into creating make-work.
>
> Solving this proble
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
I see no good reason for an online asset in a packaged app. I think we
can safely ignore that part of the spec. Slavish conformance will do
us no good. If somebody has an issue they can open an ... uhm ...
issue.
On Tue, Mar 5, 2013 at 9:54 AM, Joe Bowser wrote:
> OK, so the icon could exist onli
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 pla
OK, so the icon could exist online as well:
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
runtim
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 An
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.
O
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 plat
That answers my next question. I was just trying to find the cordova.osx.js
for 2.4. The build in 2.4 doesn't actually load Cordova.
Thanks.
On Tue, Mar 5, 2013 at 2:23 AM, Shazron wrote:
> FYI
> https://issues.apache.org/jira/browse/CB-2621
>
> The bridge works but it has no plugins to call y
20 matches
Mail list logo
