[jira] [Created] (CB-1933) Using comma in button labels
Ingo Bürk created CB-1933:
-
Summary: Using comma in button labels
Key: CB-1933
URL: https://issues.apache.org/jira/browse/CB-1933
Project: Apache Cordova
Issue Type: Improvement
Components: Android, CordovaJS
Reporter: Ingo Bürk
Assignee: Joe Bowser
Priority: Minor
It's currently not possible to use comma in button labels when creating confirm
dialogs. This would be useful for buttons like Yes, Delete.
Probably a good idea for implementation would be allowing an array as the
buttonLabels argument, e.g.
navigator.notification.confirm('Alert!', function(){}, function(){}, 'Title',
['Yes, Do It', 'No']);
For compatibility it shouldn't be a problem to detect whether a string or an
array has been passed and act accordingly.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CB-1933) Using comma in button labels
[
https://issues.apache.org/jira/browse/CB-1933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ingo Bürk updated CB-1933:
--
Description:
It's currently not possible to use comma in button labels when creating confirm
dialogs. This would be useful for buttons like Yes, Delete.
Probably a good idea for implementation would be allowing an array as the
buttonLabels argument, e.g.
{code}navigator.notification.confirm('Alert!', function(){}, function(){},
'Title', ['Yes, Do It', 'No']);{code}
For compatibility it shouldn't be a problem to detect whether a string or an
array has been passed and act accordingly.
was:
It's currently not possible to use comma in button labels when creating confirm
dialogs. This would be useful for buttons like Yes, Delete.
Probably a good idea for implementation would be allowing an array as the
buttonLabels argument, e.g.
navigator.notification.confirm('Alert!', function(){}, function(){}, 'Title',
['Yes, Do It', 'No']);
For compatibility it shouldn't be a problem to detect whether a string or an
array has been passed and act accordingly.
Using comma in button labels
Key: CB-1933
URL: https://issues.apache.org/jira/browse/CB-1933
Project: Apache Cordova
Issue Type: Improvement
Components: Android, CordovaJS
Reporter: Ingo Bürk
Assignee: Joe Bowser
Priority: Minor
It's currently not possible to use comma in button labels when creating
confirm dialogs. This would be useful for buttons like Yes, Delete.
Probably a good idea for implementation would be allowing an array as the
buttonLabels argument, e.g.
{code}navigator.notification.confirm('Alert!', function(){}, function(){},
'Title', ['Yes, Do It', 'No']);{code}
For compatibility it shouldn't be a problem to detect whether a string or an
array has been passed and act accordingly.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
writing to console output of XCode with cordova ()
Hi, For debugging, I want to write a log to console of XCode. For instance, I have an iphone that is connected to the XCode as a developing environment. At my index.js file I write a console.log(something); However, I cannot see the string something at the console output, after I run the code. With NSLog command at objective c, I can observe the output at the console. TLDR; Which command at javascript, writes to the console output of XCode? Regards. -- Yaprak
Re: writing to console output of XCode with cordova ()
Thanks Brian. On Fri, Nov 23, 2012 at 11:40 AM, Brian LeRoux b...@brian.io wrote: console.log will do the trick but ensure you've included cordova.js file and have your console.log calls occur after the deviceready event fires. (Have a look at the default generated project src from running ./bin/create and you'll see a console.log example in js/index.js at the bottom.) I'm certain no one here minds but this list is meant for the development of Cordova as opposed to the usage of Cordova---in the future we'd appreciate queries of this nature happen on the downstream phonegap distribution list. (Or feel free to email me personally and I'm happy to help.) On Fri, Nov 23, 2012 at 9:19 AM, Yaprak Ayazoglu yaprak.ayazo...@gmail.comwrote: Hi, For debugging, I want to write a log to console of XCode. For instance, I have an iphone that is connected to the XCode as a developing environment. At my index.js file I write a console.log(something); However, I cannot see the string something at the console output, after I run the code. With NSLog command at objective c, I can observe the output at the console. TLDR; Which command at javascript, writes to the console output of XCode? Regards. -- Yaprak -- Yaprak
Re: incubator repos no more - remove the prefix in your git urls
Hi, On Thu, Nov 22, 2012 at 8:33 PM, Simon MacDonald simon.macdon...@gmail.com wrote: Do we need to fix the mirrors at: https://github.com/apache I updated the mirrors at git.apache.org, and Github should pick up the changes shortly. Can we make sure pull requests to the new repo's on GitHub end up in our mailing list? I'll make sure the settings are correct once the mirrors show up on GitHub. BR, Jukka Zitting
Re: InAppBrowser api questions
Eh Simon, was just trying to kick the tires using the wiki test page [1]
but always only loads in the webview for me atm. I'm certain I missed
something simple---all I did was create a default project---anything
immediately occur that I might be missing?
[1] http://wiki.apache.org/cordova/InAppBrowserTest
On Thu, Nov 22, 2012 at 9:30 PM, Simon MacDonald
simon.macdon...@gmail.comwrote:
Well, I've got the code mostly implemented there are some things that
probably can be thrown away or cleaned up a bit (UI, events). I'll probably
push a version later tonight. All of the manual mobile spec tests are
working for me.
With regards to the back button, if clicked it closes the InAppBrowser. Why
you ask? Well the implementation of the ChildBrowser had a hide navigation
bar parameter and if it was hidden there was no way to dismiss the dialog.
That's why I'm asking some UI questions as things will need to change just
a bit.
Simon Mac Donald
http://hi.im/simonmacdonald
On Thu, Nov 22, 2012 at 2:50 PM, Joe Bowser bows...@gmail.com wrote:
Why do we have the Forward and Back buttons on the browser on Android
when Chrome and the Default Browser only have a refresh button? How
does this handle the hardware back button? I think we should do what
the platform does, except that we don't need multi-tab browsing.
On Thu, Nov 22, 2012 at 11:47 AM, Simon MacDonald
simon.macdon...@gmail.com wrote:
Should the implementation of the InAppBrowser on Android mimic the UI
of
the iOS app or should it go it's own way?
Currently the Android ChildBrowser has the buttons and location bar on
the
top of the screen. Is there any UI pattern we should be following for
this
type of in app browsing?
Simon Mac Donald
http://hi.im/simonmacdonald
On Mon, Nov 19, 2012 at 6:24 PM, Shazron shaz...@gmail.com wrote:
I have a pull request for the JavaScript changes, can someone please
review: https://github.com/apache/incubator-cordova-js/pull/43
I have committed my InAppBrowser changes to iOS:
https://git-wip-us.apache.org/repos/asf?p=incubator-cordova-ios.git;a=commit;h=26a6535c
To test this on iOS right now:
cordova.exec(null, null, InAppBrowser, open, [
http://google.com;,
_blank, location=yes]);
(don't forget to add InAppBrowser/CDVInAppBrowser to your
Cordova.plist).
Note that non-whitelisted URLs cannot be opened in the InAppBrowser
yet
because of http://issues.cordova.io/1695 which I am doing next.
Once the js changes are in (at least on ios), you can do:
var mywin = window.open(http://www.google.com;, _blank,
location=no);
mywin.close();
On Thu, Nov 15, 2012 at 3:58 PM, Shazron shaz...@gmail.com wrote:
I updated the spec: http://wiki.apache.org/cordova/InAppBrowser
However, I added the _blank option as well just to be explicit.
On Thu, Nov 15, 2012 at 1:58 AM, Shazron shaz...@gmail.com wrote:
I spent some time playing with how to do this.
1 - Use referer header - Too many situations result in no header,
so
this
is out!
2 - Use Cookies - if there were a way to have UIWebViews use
separate
cookie jars, this might be feasible. Don't think that's possible.
3 - Use User-Agent - this is already suggested in CB-1695. I also
found
this:
http://stackoverflow.com/questions/12180224/unique-tab-id-appended-to-user-agent-string-in-chrome-for-ios
,
which suggests that this is what Chrome for iOS uses to implement
incognito
mode. If they can make it work, then we should be able to as well!
So, this is looking like it's non-trivial but not impossible! As
long
as
it's possible, let's implement it :)
Looks like it may be possible in CB-1695 as you mentioned -- so we
can
finish InAppBrowser with this one failing case until it is
implemented.
I
can look into this further once I finish the InAppBrowser
integration.
I don't think the semantics of _parent and _blank really map well
to
what
we're doing. My vote is to create a new special value: _system,
and
only
this target kicks you out to the system browser.
Also: on the wiki we have:
[F] window.open('http://random-url.com', '_blank'); // native
browser
It seems weird to me that the effect of _blank changes based on
whether
the
URL is in the whitelist. I'd think this case would also open in
the
InAppBrowser.
Summary of what I think:
_self or no target -- open in cordova webview if it's in the
Whitelist,
InAppBrowser otherwise
_system -- open in system browser
anything else -- open in InAppBrowser
Also, I like Simon's idea of using the options in window.open to
specify
whether to show URL bar etc. :)
I agree, we need a new value _system as you suggested, as well as
the
other
Re: InAppBrowser api questions
Updated the JS in the Android repo with the lastest from the JS repo. InAppBrowser should just work with any project that is started with the create command. Simon Mac Donald http://hi.im/simonmacdonald On Fri, Nov 23, 2012 at 7:48 AM, Brian LeRoux b...@brian.io wrote: doh, should've noticed that in the commit---thx man On Fri, Nov 23, 2012 at 12:38 PM, Simon MacDonald simon.macdon...@gmail.com wrote: I bet it is because I did not pull the JS change into the Android repo. My dev env does that for me. I fix that in a couple of hours. Simon On Friday, November 23, 2012, Brian LeRoux wrote: Eh Simon, was just trying to kick the tires using the wiki test page [1] but always only loads in the webview for me atm. I'm certain I missed something simple---all I did was create a default project---anything immediately occur that I might be missing? [1] http://wiki.apache.org/cordova/InAppBrowserTest On Thu, Nov 22, 2012 at 9:30 PM, Simon MacDonald simon.macdon...@gmail.com javascript:;wrote: Well, I've got the code mostly implemented there are some things that probably can be thrown away or cleaned up a bit (UI, events). I'll probably push a version later tonight. All of the manual mobile spec tests are working for me. With regards to the back button, if clicked it closes the InAppBrowser. Why you ask? Well the implementation of the ChildBrowser had a hide navigation bar parameter and if it was hidden there was no way to dismiss the dialog. That's why I'm asking some UI questions as things will need to change just a bit. Simon Mac Donald http://hi.im/simonmacdonald On Thu, Nov 22, 2012 at 2:50 PM, Joe Bowser bows...@gmail.com wrote: Why do we have the Forward and Back buttons on the browser on Android when Chrome and the Default Browser only have a refresh button? How does this handle the hardware back button? I think we should do what the platform does, except that we don't need multi-tab browsing. On Thu, Nov 22, 2012 at 11:47 AM, Simon MacDonald simon.macdon...@gmail.com wrote: Should the implementation of the InAppBrowser on Android mimic the UI of the iOS app or should it go it's own way? Currently the Android ChildBrowser has the buttons and location bar on the top of the screen. Is there any UI pattern we should be following for this type of in app browsing? Simon Mac Donald http://hi.im/simonmacdonald On Mon, Nov 19, 2012 at 6:24 PM, Shazron shaz...@gmail.com wrote: I have a pull request for the JavaScript changes, can someone please review: https://github.com/apache/incubator-cordova-js/pull/43 I have committed my InAppBrowser changes to iOS: https://git-wip-us.apache.org/repos/asf?p=incubator-cordova-ios.git;a=commit;h=26a6535c To test this on iOS right now: cordova.exec(null, null, InAppBrowser, open, [ http://google.com;, _blank, location=yes]); (don't forget to add InAppBrowser/CDVInAppBrowser to your Cordova.plist). Note that non-whitelisted URLs cannot be opened in the InAppBrowser yet because of http://issues.cordova.io/1695 which I am doing next. Once the js changes are in (at least on ios), you can do: var mywin = window.open(http://www.google.com;, _blank, location=no); mywin.close(); On Thu, Nov 15, 2012 at 3:58 PM, Shazron shaz...@gmail.com wrote: I updated the spec: http://wiki.apache.org/cordova/InAppBrowser However, I added the _blank option as well just to be explicit. On Thu, Nov 15, 2012 at 1:58 AM, Shazron shaz...@gmail.com wrote: -- Simon Mac Donald http://hi.im/simonmacdonald
Re: InAppBrowser - events
The Cat-Signal that the Internet Defence League would be purr-fect.
http://internetdefenseleague.org/
Simon Mac Donald
http://hi.im/simonmacdonald
On Fri, Nov 23, 2012 at 7:53 AM, Brian LeRoux b...@brian.io wrote:
We need a MAX-signal. It'd be like the bat signal but with cats.
On Fri, Nov 23, 2012 at 12:43 AM, Tommy-Carlos Williams
to...@devgeeks.orgwrote:
At some point Gather used ChildBrowser for Oauth, but I think they might
not be anymore. Max left the list shortly after joining, so I could try
and
ping him on IRC if it would help?
On 23/11/2012, at 10:40 AM, Andrew Grieve agri...@chromium.org wrote:
The more events the better! :) Really though, it would be good if
someone
knew of an app that used ChildBrowser for the purposes of OAuth. That
seems
like one of the most important use-cases, so we should make sure to
have
all of the events that it requires.
On Thu, Nov 22, 2012 at 4:26 PM, Simon MacDonald
simon.macdon...@gmail.comwrote:
Just looking at this again and...
webview.addEventListener('exit', handleExit);
webview.addEventListener('loadstart', handleLoadStart);
would seem to map to our:
onClose
onLocationChanged
methods from the ChildBrowser. At least on Android I fire location
changed
event when the page starts to load not when it is finished.
Simon Mac Donald
http://hi.im/simonmacdonald
On Thu, Nov 22, 2012 at 1:53 PM, Simon MacDonald
simon.macdon...@gmail.comwrote:
Is this required for the 2.3.0 release?
Simon Mac Donald
http://hi.im/simonmacdonald
On Wed, Nov 21, 2012 at 11:30 PM, Shazron shaz...@gmail.com wrote:
Great! Let's stick with one API, since we have Chrome members on the
Cordova team the choice is obvious :)
On Wed, Nov 21, 2012 at 8:06 PM, Andrew Grieve
agri...@chromium.org
wrote:
Looks that way. Given how similar they are, I don't think it
matters
which
one we go with (or if we come up with our own event names), but
it'd
be
good to follow the same pattern of having events and an API like
canGoBack(), goForward(), etc. If they ever move to standardize,
then
we
can follow suit.
On Wed, Nov 21, 2012 at 7:18 PM, Shazron shaz...@gmail.com
wrote:
Mozilla's 'locationchange' is similar to what we have for
ChildBrowser,
but
I don't see the equivalent in the Chrome example - I suppose it is
'loadstop'?
I suppose if we were to adopt either, it would go something like
this:
var iab = window.open('http://apache.org', '_blank');
// Firefox
iab.addEventListener('locationchange', handleLocationChange);
// Chrome
iab.addEventListener('loadstop', handleLoadStop);
// Firefox
function handleLocationChange(e) {
console.log('location changed to: ' + e.detail);
}
// Chrome
function handleLoadStop(e) {
console.log('location changed to: ' + e.url);
}
On Wed, Nov 21, 2012 at 1:32 PM, Andrew Grieve
agri...@chromium.org
wrote:
https://github.com/GoogleChrome/chrome-app-samples/blob/master/browser/browser.js
[jira] [Commented] (CB-1928) Search field in Elements view
[ https://issues.apache.org/jira/browse/CB-1928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13503217#comment-13503217 ] Patrick Mueller commented on CB-1928: - Something similar was requested previously, and I made a few accommodations. Maybe one of these will help you: https://issues.apache.org/jira/browse/CB-540 Search field in Elements view --- Key: CB-1928 URL: https://issues.apache.org/jira/browse/CB-1928 Project: Apache Cordova Issue Type: Improvement Components: weinre Reporter: Metis Lab Assignee: Patrick Mueller A search field to find a DOM element would be really useful! Now the DOM exploration is manual and vry slow... To find a DOM element very well nested we have to click 20 or more times. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Attempting to add debug token support for building on PlayBook
I tried the path thing initially but it didn't work.. On 11/23/12 8:35 AM, Gord Tanner gtan...@gmail.com wrote: Ok, debug token support added to playbook: https://git-wip-us.apache.org/repos/asf?p=cordova-blackberry.git;a=commitd iff;h=ef16d935bf08e0baaa8c1d875edd5af76c856f1f Let us never speak of this again. This should make the CI stuff for Fil suck a whole lot less. On Fri, Nov 23, 2012 at 10:43 AM, Gord Tanner gtan...@gmail.com wrote: So I found out it doesn't suck as bad as we all thought ;) From: https://developer.blackberry.com/html5/documentation/runnning_unsigned_ap ps_using_a_debug_token_1866987_11.html It looks like all we need to do is provide the path to the debug token in the bbwp.properties file. I tested this on my playbook and was able to deploy to it. This is a lot easier to automate in the build script then the Rube Goldburg machine mentioned above. From the link: 1. In the BlackBerry WebWorks SDK for BlackBerry Tablet OS installation folder, navigate to the*bbwp\bin* folder. 2. Using a text editor, open the bbwp.properties file. 3. Add the path to the debug token file by using debug_token tags. debug_tokenpath to debug token file/debug_token On Thu, Nov 22, 2012 at 3:51 PM, Josh Soref jso...@rim.com wrote: Gord wrote: not the best way to do it now ;) I should be able to automate this in the playbook.xml so our users don't have to deal with it. The way I'm told is to just remove those items from the PlayBook.xml file entirely and just rely on the packager/debugtoken to magically set them or somehow make it work. (this was advice I got from non-RIM people, to me,...) - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
Re: Attempting to add debug token support for building on PlayBook
seems to work for me (just double checked to make sure my blackberry-tablet.xml wasn't updated) On Fri, Nov 23, 2012 at 12:03 PM, Filip Maj f...@adobe.com wrote: I tried the path thing initially but it didn't work.. On 11/23/12 8:35 AM, Gord Tanner gtan...@gmail.com wrote: Ok, debug token support added to playbook: https://git-wip-us.apache.org/repos/asf?p=cordova-blackberry.git;a=commitd iff;h=ef16d935bf08e0baaa8c1d875edd5af76c856f1f Let us never speak of this again. This should make the CI stuff for Fil suck a whole lot less. On Fri, Nov 23, 2012 at 10:43 AM, Gord Tanner gtan...@gmail.com wrote: So I found out it doesn't suck as bad as we all thought ;) From: https://developer.blackberry.com/html5/documentation/runnning_unsigned_ap ps_using_a_debug_token_1866987_11.html It looks like all we need to do is provide the path to the debug token in the bbwp.properties file. I tested this on my playbook and was able to deploy to it. This is a lot easier to automate in the build script then the Rube Goldburg machine mentioned above. From the link: 1. In the BlackBerry WebWorks SDK for BlackBerry Tablet OS installation folder, navigate to the*bbwp\bin* folder. 2. Using a text editor, open the bbwp.properties file. 3. Add the path to the debug token file by using debug_token tags. debug_tokenpath to debug token file/debug_token On Thu, Nov 22, 2012 at 3:51 PM, Josh Soref jso...@rim.com wrote: Gord wrote: not the best way to do it now ;) I should be able to automate this in the playbook.xml so our users don't have to deal with it. The way I'm told is to just remove those items from the PlayBook.xml file entirely and just rely on the packager/debugtoken to magically set them or somehow make it work. (this was advice I got from non-RIM people, to me,...) - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
Re: Fast edit-refresh cycles
Something else along these lines we should consider - is providing a grunt.js file in the default template when you run cordova create. It could have a watch task that copies files from the root www/ into platform www/ directories whenever a file changes. On Fri, Nov 23, 2012 at 10:29 AM, Gord Tanner gtan...@gmail.com wrote: I have always had a vision that the build step for cordova.js would make it into the app build step. Currently the packager has most of the functionality to bundle in plugins / platform specific code / core modules. With a little bit of work it could be made to be driven off of the plugin's folder for 3rd party code and the manifest for core modules. On Fri, Nov 23, 2012 at 10:20 AM, Brian LeRoux b...@brian.io wrote: just considering this, I suppose we could say that cordova.js is a build artifact, and the manifest is the 'truth' of the install (from the issue tracking perspective) On Fri, Nov 23, 2012 at 3:09 PM, Braden Shepherdson bra...@chromium.org wrote: I'm happy adding multiple script tags. We could require plugins to be wrapped up for AMD, instead, and just include them in the index page. I don't think a single file makes the reproducibility any worse: you still need to have the exact set and versions of plugins that anyone else has. And it's not strictly a build step, that's being deliberately avoided. It's a plugin-install-time step that comes at the end of every plugin add or rm. Braden On Fri, Nov 23, 2012 at 10:02 AM, Brian LeRoux b...@brian.io wrote: So, we have a build step no matter what. Currently we concat the whole go. When we have the many plugins world doing a fat concat is dangerous business for issue tracking. My cordova.js very likely won't be the same as yours. Moving this into a second file has the same problem. Script loaders are a touchy subject. General consensus is that browsers prefer AMD but I think most folks really just chuck in a bunch of script tags. This is not ideal, but I really feel we should not be dictating how ppl build their apps, and I do want to see a super slim cordova.js file---and leave the inclusion of plugins as an exercise for the developers. Now THAT said, we could encourage a sensible default in cordova-client. On Thu, Nov 22, 2012 at 9:18 PM, Andrew Grieve agri...@chromium.org wrote: On Thu, Nov 22, 2012 at 3:36 PM, Gord Tanner gtan...@gmail.com wrote: This also is feeding into some of the work we are doing with ripple. Ripple will serve up the app and host it kind of like how we do debug.phonegap.com for in browser testing. Sent from my iPhone On 2012-11-22, at 3:15 PM, Filip Maj f...@adobe.com wrote: Agree with Jesse. Automatically adding the plugin's .js to html pages inside a www dir can be done by the cordova-client tool anyways. Agree this should go to vote before we proceed. On 11/22/12 12:13 PM, Jesse purplecabb...@gmail.com wrote: I think all the refresh stuff is super cool, I will share how I work, so you can get another perspective. 90% of my code is written on localhost, either running directly in a browser to work out UI stuff. When I need access to actual device APIs, I simply put a redirect in my index.html. This gets me through 99% of my work, after which I can fine tune an individual device or functional piece in XCode, Eclipse, Visual Studio, et al Awesome! This is the workflow we want to encourage via cordova serve. When it comes to inclusion of multiple script tags, I do not see this as a barrier at all. This is the way the internet has always worked, and it ain't broke. I like the explicit declaration of having a script tag, plus you can have multiple pages, with different plugin requirements. Adding an extra build step, + reinventing the internet inside our framework is madness in my opinion. madness is maybe a bit of an exaggeration :) Our cordova plugin add tool already adds the necessary plugin line to your config.xml / cordova.plist *and* edits your xcode project file to add the native files. Why have the tool take care of these manual steps on the native side, but not the HTML side? It's a pain to have to make manual edits to your .html file every time you add or remove a plugin. I see this more as removing a step rather than adding a step. I'm not set on having a single plugins-concat.js file, but it *is* what we already do for our cordova.js file (we don't list each source file separately in this case). From
Re: Chrome Apps on Cordova
That's pretty cool! On Thu, Nov 22, 2012 at 2:33 AM, Brian LeRoux b...@brian.io wrote: this is killer! nice work guys On Thu, Nov 22, 2012 at 4:00 AM, Andrew Grieve agri...@chromium.org wrote: https://github.com/MobileChromeApps/chrome-cordova
[jira] [Commented] (CB-1893) Convert cordova.plist - config.xml
[ https://issues.apache.org/jira/browse/CB-1893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13503297#comment-13503297 ] Braden Shepherdson commented on CB-1893: This is done for the main iOS repo, but cordova-client and pluginstall are not ported yet. This eliminates special handling for iOS plugins from a few places, but I haven't fixed or tested everything yet. Convert cordova.plist - config.xml --- Key: CB-1893 URL: https://issues.apache.org/jira/browse/CB-1893 Project: Apache Cordova Issue Type: Improvement Components: iOS Reporter: Andrew Grieve Assignee: Braden Shepherdson Priority: Minor Fix For: 2.3.0 Relevant ML discussion: http://callback.markmail.org/thread/dulyzr4rcmudtibq Just like Android switched, iOS should also use a config.xml file that follows the same format. Bonus points for writing a script to convert a .plist - config.xml, but this is not strictly necessary. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CB-1893) Convert cordova.plist - config.xml
[ https://issues.apache.org/jira/browse/CB-1893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13503298#comment-13503298 ] Anis Kadri commented on CB-1893: I just created an issue for both. Convert cordova.plist - config.xml --- Key: CB-1893 URL: https://issues.apache.org/jira/browse/CB-1893 Project: Apache Cordova Issue Type: Improvement Components: iOS Reporter: Andrew Grieve Assignee: Braden Shepherdson Priority: Minor Fix For: 2.3.0 Relevant ML discussion: http://callback.markmail.org/thread/dulyzr4rcmudtibq Just like Android switched, iOS should also use a config.xml file that follows the same format. Bonus points for writing a script to convert a .plist - config.xml, but this is not strictly necessary. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
