Re: Pull request for [CB-2280] and [CB-2281]
Great thanks ! On 10/02/13 20:02, "Andrew Grieve" wrote: >Done and done. > > >On Fri, Feb 8, 2013 at 10:34 AM, Yaniv De Ridder >wrote: > >> Thanks, >> >> You can check the comments in jira and in the pull request. Let me know >>if >> you need something from me :) >> >> /yaniv >> >> On 08/02/13 15:46, "Andrew Grieve" wrote: >> >> >Yep, I can certainly take this on :) >> > >> > >> >On Fri, Feb 8, 2013 at 9:38 AM, Yaniv De Ridder >> >wrote: >> > >> >> I'm looking for a committer to have a look at my pull requests to get >> >>them >> >> integrated. I was until now working with Shazron Abdullah but he >>asked >> >>me >> >> if I can eventually look for someone else as he is really busy right >> >>now. >> >> >> >> @Andrew Grieve You maybe ? >> >> >> >> /yaniv >> >> >> >>
Re: Changing config.xml settings at runtime
Hmm. Tricky: can an app modify the whitelist at runtime then?
(Probably not a good idea.)
On Sun, Feb 10, 2013 at 7:01 PM, Andrew Grieve wrote:
> First - I'd like to add yet another setting for iOS:
>
> KeyboardShrinksView (boolean).
>
> It applies to apps that position their elements relative to the bottom of
> the webview. When the keyboard comes up, I'd like to shrink the webview
> rather than shrink the viewport and have the page scrollable. This is the
> default behaviour on Android, and makes a lot of sense when building apps
> as opposed to webpages.
>
>
> But... Reason for this email, is I think it'd be useful to have a
> x-platform API for changing the settings within config.xml at runtime.
> Something like:
>
> cordova.setConfigValue(key, value)
>
> An example of the keyboard case:
> app.onPageChange = function(pageName) {
> cordova.setConfigValue('KeyboardShrinksView', pageName != 'help');
> };
>
> And I suppose adding a getter makes sense:
> cordova.getConfigValues(successCallback)
>
> I'm thinking that setting these at runtime will *not* persist across app
> restarts to avoid the issue of what should happen when devs push updates to
> their apps that change settings around.
>
> If everyone's okay with this, I'll file a bug & sub-bugs per-platform.
Re: http://issues.cordova.io is broken
uuu, thought I had fixed that. should be working now. (its all dave's fault!) On Sun, Feb 10, 2013 at 11:04 PM, Tommy-Carlos Williams wrote: > http://brianleroux.damn-u-dave.jit.su/ > > Best ever failure message in a URL though ;)
Re: http://issues.cordova.io is broken
I gathered it was his fault from the domain name. On 11/02/2013, at 8:48 PM, Brian LeRoux wrote: > uuu, thought I had fixed that. should be working now. (its all > dave's fault!) > > On Sun, Feb 10, 2013 at 11:04 PM, Tommy-Carlos Williams > wrote: >> http://brianleroux.damn-u-dave.jit.su/ >> >> Best ever failure message in a URL though ;)
Re: Changing config.xml settings at runtime
The only case (as Brian mentions) is not allowing the whitelist to be set
at runtime.
Also - does the app have to "reset" if a setting that was read at runtime
was changed? ie we probably need a "configchanged" event/notification or
something. For example, BackupWebStorage in iOS, etc.
On Sun, Feb 10, 2013 at 11:01 AM, Andrew Grieve wrote:
> First - I'd like to add yet another setting for iOS:
>
> KeyboardShrinksView (boolean).
>
> It applies to apps that position their elements relative to the bottom of
> the webview. When the keyboard comes up, I'd like to shrink the webview
> rather than shrink the viewport and have the page scrollable. This is the
> default behaviour on Android, and makes a lot of sense when building apps
> as opposed to webpages.
>
>
> But... Reason for this email, is I think it'd be useful to have a
> x-platform API for changing the settings within config.xml at runtime.
> Something like:
>
> cordova.setConfigValue(key, value)
>
> An example of the keyboard case:
> app.onPageChange = function(pageName) {
> cordova.setConfigValue('KeyboardShrinksView', pageName != 'help');
> };
>
> And I suppose adding a getter makes sense:
> cordova.getConfigValues(successCallback)
>
> I'm thinking that setting these at runtime will *not* persist across app
> restarts to avoid the issue of what should happen when devs push updates to
> their apps that change settings around.
>
> If everyone's okay with this, I'll file a bug & sub-bugs per-platform.
>
Re: Changing config.xml settings at runtime
Hmm, yeah, definitely doesn't make sense for the whitelist. Not really for
BackupWebStorage either... If we're not saving across restarts, then
BackupWebStorage won't use the updated settings anyways.
Looking through the documentation, I think that most settings wouldn't have
a reason to change... Only ones are maybe:
UIWebViewBounce
EnableViewportScale
And also the KeyboardShrinksView one I wanted to add.
Perhaps another avenue here is to put this in an "App" plugin. Android
currently has an navigator.app with methods like "clearCache",
"overrideBackButton".
We could explicitly have methods such as:
navigator.app.setKeyboardShrinksView(true),
navigator.app.setUIWebViewBounce(false)
I'm not really sure if this would make more sense, or if it even matter
which approach we go with :P.
On Mon, Feb 11, 2013 at 11:59 AM, Shazron wrote:
> The only case (as Brian mentions) is not allowing the whitelist to be set
> at runtime.
> Also - does the app have to "reset" if a setting that was read at runtime
> was changed? ie we probably need a "configchanged" event/notification or
> something. For example, BackupWebStorage in iOS, etc.
>
>
> On Sun, Feb 10, 2013 at 11:01 AM, Andrew Grieve >wrote:
>
> > First - I'd like to add yet another setting for iOS:
> >
> > KeyboardShrinksView (boolean).
> >
> > It applies to apps that position their elements relative to the bottom of
> > the webview. When the keyboard comes up, I'd like to shrink the webview
> > rather than shrink the viewport and have the page scrollable. This is the
> > default behaviour on Android, and makes a lot of sense when building apps
> > as opposed to webpages.
> >
> >
> > But... Reason for this email, is I think it'd be useful to have a
> > x-platform API for changing the settings within config.xml at runtime.
> > Something like:
> >
> > cordova.setConfigValue(key, value)
> >
> > An example of the keyboard case:
> > app.onPageChange = function(pageName) {
> > cordova.setConfigValue('KeyboardShrinksView', pageName != 'help');
> > };
> >
> > And I suppose adding a getter makes sense:
> > cordova.getConfigValues(successCallback)
> >
> > I'm thinking that setting these at runtime will *not* persist across app
> > restarts to avoid the issue of what should happen when devs push updates
> to
> > their apps that change settings around.
> >
> > If everyone's okay with this, I'll file a bug & sub-bugs per-platform.
> >
>
Re: Android file chooser
I'm not familiar with Chrome's API, but I believe that there is a FileUtils API as well as the File Picker that Simon added a release ago that fires an intent to pick a file if you have a file picker installed. (Note: I don't use one, so it brings up the Gallery, Audio Player and other things associated with the intent, which is technically the correct behaviour). To use the file picker, you just have . Joe On Mon, Feb 11, 2013 at 11:21 AM, Max Woghiren wrote: > Hi everyone, > > I'm implementing Chrome's file system API using Cordova. On iOS, this uses > the Camera API. However, on Android, Camera isn't sufficient since we can > access more than just images and videos, so I need a more general file > chooser. It would be very similar to what exists in > CameraLauncher.getImage, but with a broader intent type (ie. MIME type). > > Does something like this already exist? If not, is something like this > valuable in core cordova or as a plugin? Is there an alternative/superior > approach? > > Thanks! > -Max
Re: Changing config.xml settings at runtime
Not sure about explicit methods since we will have more docs (and separate
ones for the diff platforms). I personally would go with a generic API, and
the setting to use would already be documented in the Project Settings doc.
e.g.
navigator.app.setConfigSetting('KeyboardShrinksView', false, win, fail)
or something to that effect. I reckon if the setting is "read-only", it
would call the fail callback.
On Mon, Feb 11, 2013 at 11:07 AM, Andrew Grieve wrote:
> Hmm, yeah, definitely doesn't make sense for the whitelist. Not really for
> BackupWebStorage either... If we're not saving across restarts, then
> BackupWebStorage won't use the updated settings anyways.
>
> Looking through the documentation, I think that most settings wouldn't have
> a reason to change... Only ones are maybe:
> UIWebViewBounce
> EnableViewportScale
>
> And also the KeyboardShrinksView one I wanted to add.
>
> Perhaps another avenue here is to put this in an "App" plugin. Android
> currently has an navigator.app with methods like "clearCache",
> "overrideBackButton".
>
> We could explicitly have methods such as:
> navigator.app.setKeyboardShrinksView(true),
> navigator.app.setUIWebViewBounce(false)
>
> I'm not really sure if this would make more sense, or if it even matter
> which approach we go with :P.
>
>
>
>
> On Mon, Feb 11, 2013 at 11:59 AM, Shazron wrote:
>
> > The only case (as Brian mentions) is not allowing the whitelist to be set
> > at runtime.
> > Also - does the app have to "reset" if a setting that was read at runtime
> > was changed? ie we probably need a "configchanged" event/notification or
> > something. For example, BackupWebStorage in iOS, etc.
> >
> >
> > On Sun, Feb 10, 2013 at 11:01 AM, Andrew Grieve > >wrote:
> >
> > > First - I'd like to add yet another setting for iOS:
> > >
> > > KeyboardShrinksView (boolean).
> > >
> > > It applies to apps that position their elements relative to the bottom
> of
> > > the webview. When the keyboard comes up, I'd like to shrink the webview
> > > rather than shrink the viewport and have the page scrollable. This is
> the
> > > default behaviour on Android, and makes a lot of sense when building
> apps
> > > as opposed to webpages.
> > >
> > >
> > > But... Reason for this email, is I think it'd be useful to have a
> > > x-platform API for changing the settings within config.xml at runtime.
> > > Something like:
> > >
> > > cordova.setConfigValue(key, value)
> > >
> > > An example of the keyboard case:
> > > app.onPageChange = function(pageName) {
> > > cordova.setConfigValue('KeyboardShrinksView', pageName != 'help');
> > > };
> > >
> > > And I suppose adding a getter makes sense:
> > > cordova.getConfigValues(successCallback)
> > >
> > > I'm thinking that setting these at runtime will *not* persist across
> app
> > > restarts to avoid the issue of what should happen when devs push
> updates
> > to
> > > their apps that change settings around.
> > >
> > > If everyone's okay with this, I'll file a bug & sub-bugs per-platform.
> > >
> >
>
Re: Changing config.xml settings at runtime
I'm not sure why a single generic api would mean less docs? We would still
need to document each valid key, wouldn't we? Anyway, I like the plugin
approach suggested, especially since there will likely be very few
configurations that need adjusting at runtime.
(btw, another adjustable setting might be "set supported orientations")
-Michal
On Mon, Feb 11, 2013 at 2:31 PM, Shazron wrote:
> Not sure about explicit methods since we will have more docs (and separate
> ones for the diff platforms). I personally would go with a generic API, and
> the setting to use would already be documented in the Project Settings doc.
>
> e.g.
>
> navigator.app.setConfigSetting('KeyboardShrinksView', false, win, fail)
>
> or something to that effect. I reckon if the setting is "read-only", it
> would call the fail callback.
>
>
> On Mon, Feb 11, 2013 at 11:07 AM, Andrew Grieve >wrote:
>
> > Hmm, yeah, definitely doesn't make sense for the whitelist. Not really
> for
> > BackupWebStorage either... If we're not saving across restarts, then
> > BackupWebStorage won't use the updated settings anyways.
> >
> > Looking through the documentation, I think that most settings wouldn't
> have
> > a reason to change... Only ones are maybe:
> > UIWebViewBounce
> > EnableViewportScale
> >
> > And also the KeyboardShrinksView one I wanted to add.
> >
> > Perhaps another avenue here is to put this in an "App" plugin. Android
> > currently has an navigator.app with methods like "clearCache",
> > "overrideBackButton".
> >
> > We could explicitly have methods such as:
> > navigator.app.setKeyboardShrinksView(true),
> > navigator.app.setUIWebViewBounce(false)
> >
> > I'm not really sure if this would make more sense, or if it even matter
> > which approach we go with :P.
> >
> >
> >
> >
> > On Mon, Feb 11, 2013 at 11:59 AM, Shazron wrote:
> >
> > > The only case (as Brian mentions) is not allowing the whitelist to be
> set
> > > at runtime.
> > > Also - does the app have to "reset" if a setting that was read at
> runtime
> > > was changed? ie we probably need a "configchanged" event/notification
> or
> > > something. For example, BackupWebStorage in iOS, etc.
> > >
> > >
> > > On Sun, Feb 10, 2013 at 11:01 AM, Andrew Grieve > > >wrote:
> > >
> > > > First - I'd like to add yet another setting for iOS:
> > > >
> > > > KeyboardShrinksView (boolean).
> > > >
> > > > It applies to apps that position their elements relative to the
> bottom
> > of
> > > > the webview. When the keyboard comes up, I'd like to shrink the
> webview
> > > > rather than shrink the viewport and have the page scrollable. This is
> > the
> > > > default behaviour on Android, and makes a lot of sense when building
> > apps
> > > > as opposed to webpages.
> > > >
> > > >
> > > > But... Reason for this email, is I think it'd be useful to have a
> > > > x-platform API for changing the settings within config.xml at
> runtime.
> > > > Something like:
> > > >
> > > > cordova.setConfigValue(key, value)
> > > >
> > > > An example of the keyboard case:
> > > > app.onPageChange = function(pageName) {
> > > > cordova.setConfigValue('KeyboardShrinksView', pageName != 'help');
> > > > };
> > > >
> > > > And I suppose adding a getter makes sense:
> > > > cordova.getConfigValues(successCallback)
> > > >
> > > > I'm thinking that setting these at runtime will *not* persist across
> > app
> > > > restarts to avoid the issue of what should happen when devs push
> > updates
> > > to
> > > > their apps that change settings around.
> > > >
> > > > If everyone's okay with this, I'll file a bug & sub-bugs
> per-platform.
> > > >
> > >
> >
>
Re: Changing config.xml settings at runtime
Regarding less docs: okay I see now Shaz, we use the same key names as we
have in configurations, and so we defer to the documentation there. Makes
sense. Should we then have a separate section/attribute for run-time
adjustable config values?
On Mon, Feb 11, 2013 at 2:38 PM, Michal Mocny wrote:
> I'm not sure why a single generic api would mean less docs? We would
> still need to document each valid key, wouldn't we? Anyway, I like the
> plugin approach suggested, especially since there will likely be very few
> configurations that need adjusting at runtime.
>
> (btw, another adjustable setting might be "set supported orientations")
>
> -Michal
>
>
> On Mon, Feb 11, 2013 at 2:31 PM, Shazron wrote:
>
>> Not sure about explicit methods since we will have more docs (and separate
>> ones for the diff platforms). I personally would go with a generic API,
>> and
>> the setting to use would already be documented in the Project Settings
>> doc.
>>
>> e.g.
>>
>> navigator.app.setConfigSetting('KeyboardShrinksView', false, win, fail)
>>
>> or something to that effect. I reckon if the setting is "read-only", it
>> would call the fail callback.
>>
>>
>> On Mon, Feb 11, 2013 at 11:07 AM, Andrew Grieve > >wrote:
>>
>> > Hmm, yeah, definitely doesn't make sense for the whitelist. Not really
>> for
>> > BackupWebStorage either... If we're not saving across restarts, then
>> > BackupWebStorage won't use the updated settings anyways.
>> >
>> > Looking through the documentation, I think that most settings wouldn't
>> have
>> > a reason to change... Only ones are maybe:
>> > UIWebViewBounce
>> > EnableViewportScale
>> >
>> > And also the KeyboardShrinksView one I wanted to add.
>> >
>> > Perhaps another avenue here is to put this in an "App" plugin. Android
>> > currently has an navigator.app with methods like "clearCache",
>> > "overrideBackButton".
>> >
>> > We could explicitly have methods such as:
>> > navigator.app.setKeyboardShrinksView(true),
>> > navigator.app.setUIWebViewBounce(false)
>> >
>> > I'm not really sure if this would make more sense, or if it even matter
>> > which approach we go with :P.
>> >
>> >
>> >
>> >
>> > On Mon, Feb 11, 2013 at 11:59 AM, Shazron wrote:
>> >
>> > > The only case (as Brian mentions) is not allowing the whitelist to be
>> set
>> > > at runtime.
>> > > Also - does the app have to "reset" if a setting that was read at
>> runtime
>> > > was changed? ie we probably need a "configchanged" event/notification
>> or
>> > > something. For example, BackupWebStorage in iOS, etc.
>> > >
>> > >
>> > > On Sun, Feb 10, 2013 at 11:01 AM, Andrew Grieve > > > >wrote:
>> > >
>> > > > First - I'd like to add yet another setting for iOS:
>> > > >
>> > > > KeyboardShrinksView (boolean).
>> > > >
>> > > > It applies to apps that position their elements relative to the
>> bottom
>> > of
>> > > > the webview. When the keyboard comes up, I'd like to shrink the
>> webview
>> > > > rather than shrink the viewport and have the page scrollable. This
>> is
>> > the
>> > > > default behaviour on Android, and makes a lot of sense when building
>> > apps
>> > > > as opposed to webpages.
>> > > >
>> > > >
>> > > > But... Reason for this email, is I think it'd be useful to have a
>> > > > x-platform API for changing the settings within config.xml at
>> runtime.
>> > > > Something like:
>> > > >
>> > > > cordova.setConfigValue(key, value)
>> > > >
>> > > > An example of the keyboard case:
>> > > > app.onPageChange = function(pageName) {
>> > > > cordova.setConfigValue('KeyboardShrinksView', pageName != 'help');
>> > > > };
>> > > >
>> > > > And I suppose adding a getter makes sense:
>> > > > cordova.getConfigValues(successCallback)
>> > > >
>> > > > I'm thinking that setting these at runtime will *not* persist across
>> > app
>> > > > restarts to avoid the issue of what should happen when devs push
>> > updates
>> > > to
>> > > > their apps that change settings around.
>> > > >
>> > > > If everyone's okay with this, I'll file a bug & sub-bugs
>> per-platform.
>> > > >
>> > >
>> >
>>
>
>
Re: Android file chooser
You're right about the FileUtils API, but I need a Cordova File object to access those methods. yields a native File object, so, for instance, I can't use FileWriter with it. Native File objects also don't have full paths, which are useful (eg. for FileTransfer.upload, which requires a full path). A file chooser would provide the full path, with which a Cordova FileEntry can be created. On Mon, Feb 11, 2013 at 2:25 PM, Joe Bowser wrote: > I'm not familiar with Chrome's API, but I believe that there is a > FileUtils API as well as the File Picker that Simon added a release > ago that fires an intent to pick a file if you have a file picker > installed. (Note: I don't use one, so it brings up the Gallery, Audio > Player and other things associated with the intent, which is > technically the correct behaviour). > > To use the file picker, you just have . > > Joe > > On Mon, Feb 11, 2013 at 11:21 AM, Max Woghiren wrote: > > Hi everyone, > > > > I'm implementing Chrome's file system API using Cordova. On iOS, this > uses > > the Camera API. However, on Android, Camera isn't sufficient since we > can > > access more than just images and videos, so I need a more general file > > chooser. It would be very similar to what exists in > > CameraLauncher.getImage, but with a broader intent type (ie. MIME type). > > > > Does something like this already exist? If not, is something like this > > valuable in core cordova or as a plugin? Is there an > alternative/superior > > approach? > > > > Thanks! > > -Max >
Re: Android file chooser
Check out some code I wrote in a side project that can do it. https://github.com/macdonst/corinthian Simon Mac Donald http://hi.im/simonmacdonald On Mon, Feb 11, 2013 at 3:05 PM, Max Woghiren wrote: > You're right about the FileUtils API, but I need a Cordova File object to > access those methods. yields a native File object, so, > for instance, I can't use FileWriter with it. Native File objects also > don't have full paths, which are useful (eg. for FileTransfer.upload, which > requires a full path). > > A file chooser would provide the full path, with which a Cordova FileEntry > can be created. > > On Mon, Feb 11, 2013 at 2:25 PM, Joe Bowser wrote: > >> I'm not familiar with Chrome's API, but I believe that there is a >> FileUtils API as well as the File Picker that Simon added a release >> ago that fires an intent to pick a file if you have a file picker >> installed. (Note: I don't use one, so it brings up the Gallery, Audio >> Player and other things associated with the intent, which is >> technically the correct behaviour). >> >> To use the file picker, you just have . >> >> Joe >> >> On Mon, Feb 11, 2013 at 11:21 AM, Max Woghiren wrote: >> > Hi everyone, >> > >> > I'm implementing Chrome's file system API using Cordova. On iOS, this >> uses >> > the Camera API. However, on Android, Camera isn't sufficient since we >> can >> > access more than just images and videos, so I need a more general file >> > chooser. It would be very similar to what exists in >> > CameraLauncher.getImage, but with a broader intent type (ie. MIME type). >> > >> > Does something like this already exist? If not, is something like this >> > valuable in core cordova or as a plugin? Is there an >> alternative/superior >> > approach? >> > >> > Thanks! >> > -Max >>
BlackBerry 2.4.0 Release
Hey gang, So it appears I forgot to push out a commit to update the version number in the BlackBerry repo, but accidently tagged 2.4.0 anyways. Should I force re-tag the repo? Also, the download on phonegap.com for the BlackBerry repo was kinda messed up anyways. In that the robson tool didn't copy over the www/ folder and just the bin/ folder (changed from using ant dist to ./bin/create). Sorry for the mix ups! I was at a conference and was kinda jet lagged when I was attempting to update the repo. -- Timothy Kim
Re: BlackBerry 2.4.0 Release
Since it's a low risk change (version number only), I say re-tag, and re-package - who is in charge of the robson tool? File a bug against it Or is the version number not worth it? On Mon, Feb 11, 2013 at 1:16 PM, Tim Kim wrote: > Hey gang, > > So it appears I forgot to push out a commit to update the version number > in the BlackBerry repo, but accidently tagged 2.4.0 anyways. Should I force > re-tag the repo? > > Also, the download on phonegap.com for the BlackBerry repo was kinda > messed > up anyways. In that the robson tool didn't copy over the www/ folder and > just the bin/ folder (changed from using ant dist to ./bin/create). > > Sorry for the mix ups! I was at a conference and was kinda jet lagged when > I was attempting to update the repo. > > -- > Timothy Kim >
RE: Tagging 2.3.0rc2?
both requests have been merged. > From: markus.leutwy...@hp.com > To: dev@cordova.apache.org > Subject: RE: Tagging 2.3.0rc2? > Date: Fri, 8 Feb 2013 10:35:12 + > > Hi Herm, > > I have 2 pull requests to put into Cordova webOS 2.5.0rc1 > > https://github.com/apache/cordova-js/pull/7 > https://github.com/apache/cordova-js/pull/8 > > Thanks for merging them in > > Markus > > -Original Message- > From: Herm Wong [mailto:kingoftheo...@hotmail.com] > Sent: Dienstag, 15. Januar 2013 00:17 > To: dev@cordova.apache.org > Subject: RE: Tagging 2.3.0rc2? > > I'm merging this change in now; it'll be in the 2.4.0rc1 release. > > > From: markus.leutwy...@hp.com > > To: dev@cordova.apache.org > > Subject: RE: Tagging 2.3.0rc2? > > Date: Fri, 4 Jan 2013 07:29:00 + > > > > Hi Herm, > > > > Here we go > > > > https://github.com/apache/cordova-js/pull/2 > > > > Thanks > > > > Markus > > > > -Original Message- > > From: Herm Wong [mailto:kingoftheo...@hotmail.com] > > Sent: Donnerstag, 3. Januar 2013 21:51 > > To: dev@cordova.apache.org > > Subject: RE: Tagging 2.3.0rc2? > > > > send me the url for your git repo and I'll merge in the changes from there. > > > > > From: markus.leutwy...@hp.com > > > To: dev@cordova.apache.org > > > Subject: RE: Tagging 2.3.0rc2? > > > Date: Fri, 14 Dec 2012 00:59:21 + > > > > > > When will we cut 2.3.0rc2? > > > > > > Herm: I have added functionality to support for the menubutton in > > > cordova-js for webOS ... how can I get that into rc2? > > > > > > Markus > > > > > > -Original Message- > > > From: Shazron [mailto:shaz...@gmail.com] > > > Sent: Dienstag, 11. Dezember 2012 22:19 > > > To: dev@cordova.apache.org > > > Subject: Re: Tagging 2.3.0rc2? > > > > > > iOS is almost ready to tag pending testing. Unfortunately most of us are > > > off-site Wednesday so I can only test this Thursday and tag. > > > > > > > > > On Mon, Dec 10, 2012 at 2:25 PM, Anis KADRI wrote: > > > > > > > Double the usual spam. Thanks Joe :-) ! > > > > > > > > > > > > On Mon, Dec 10, 2012 at 2:20 PM, Joe Bowser wrote: > > > > > > > > > OK, I'm deleting the duplicates so we don't get confused. Sorry > > > > > about getting inpatient! > > > > > > > > > > On Mon, Dec 10, 2012 at 2:17 PM, Joe Bowser wrote: > > > > > > OH crap, I created a duplicate in our tracker. :( > > > > > > > > > > > > On Mon, Dec 10, 2012 at 2:16 PM, Michael Brooks > > > > > > wrote: > > > > > >> @Jesse I agree with you timeline. > > > > > >> > > > > > >> @Joe Yep, let's get the ball rolling. > > > > > >> > > > > > >> I've created JIRA issue CB-1982 to track our progress: > > > > > >> > > > > > >> https://issues.apache.org/jira/browse/CB-1982 > > > > > >> > > > > > >> Go Go Go! > > > > > >> > > > > > >> Michael > > > > > >> > > > > > >> On Mon, Dec 10, 2012 at 12:32 PM, Joe Bowser > > > > > >> > > > > wrote: > > > > > >> > > > > > >>> So, are we getting this ball rolling? > > > > > >>> > > > > > >>> On Fri, Dec 7, 2012 at 4:48 PM, Jesse > > > > > >>> > > > > wrote: > > > > > >>> > +me > > > > > >>> > > > > > > >>> > Also, 2.3.0 final will be the last release of the year > > > > > >>> > with > > > > everyone > > > > > >>> > hopefully enjoying some time off. > > > > > >>> > Many of the Adobe+Cordova committers will be otherwise > > > > > >>> > occupied > > > > much > > > > > >>> > of next week, so it may be best to push the release of > > > > > >>> > 2.3.0 to the middle of the following week, on like the > > > > > >>> > 18th or 19th > > > > > >>> > > > > > > >>> > > > > > > >>> > > > > > > >>> > > > > > > >>> > > > > > > >>> > On Fri, Dec 7, 2012 at 4:37 PM, Anis KADRI > > > > > >>> > > > > > > wrote: > > > > > >>> >> I approve this message > > > > > >>> >> > > > > > >>> >> > > > > > >>> >> On Fri, Dec 7, 2012 at 3:28 PM, Brian LeRoux > > > > > >>> >> wrote: > > > > > >>> >> > > > > > >>> >>> agree > > > > > >>> >>> > > > > > >>> >>> On Fri, Dec 7, 2012 at 1:38 PM, Simon MacDonald > > > > > >>> >>> wrote: > > > > > >>> >>> > We doing that or going straight to 2.3.0 release? > > > > > >>> >>> > Personally > > > > I'd > > > > > >>> like to > > > > > >>> >>> > see a 2.3.0rc2 on Monday then if no fixes are checked > > > > > >>> >>> > in cut > > > > > 2.3.0 > > > > > >>> the > > > > > >>> >>> > following week. > > > > > >>> >>> > > > > > > >>> >>> > Simon Mac Donald > > > > > >>> >>> > http://hi.im/simonmacdonald > > > > > >>> >>> > > > > > >>> > > > > > > >>> > > > > > > >>> > > > > > > >>> > -- > > > > > >>> > @purplecabbage > > > > > >>> > risingj.com > > > > > >>> > > > > > > > > > > > >
Re: BlackBerry 2.4.0 Release
Tim, has anyone reported this or are you the only one who has noticed? (if the latter, I say we re-package, if the former we should probably do a retag =( On Mon, Feb 11, 2013 at 10:16 PM, Shazron wrote: > Since it's a low risk change (version number only), I say re-tag, and > re-package - who is in charge of the robson tool? File a bug against it > > Or is the version number not worth it? > > On Mon, Feb 11, 2013 at 1:16 PM, Tim Kim wrote: > >> Hey gang, >> >> So it appears I forgot to push out a commit to update the version number >> in the BlackBerry repo, but accidently tagged 2.4.0 anyways. Should I force >> re-tag the repo? >> >> Also, the download on phonegap.com for the BlackBerry repo was kinda >> messed >> up anyways. In that the robson tool didn't copy over the www/ folder and >> just the bin/ folder (changed from using ant dist to ./bin/create). >> >> Sorry for the mix ups! I was at a conference and was kinda jet lagged when >> I was attempting to update the repo. >> >> -- >> Timothy Kim >>
Re: BlackBerry 2.4.0 Release
Someone had brought it up through the google groups: https://groups.google.com/forum/#!topic/phonegap/wnICEdCs-Qk/discussion On 11 February 2013 15:24, Brian LeRoux wrote: > Tim, has anyone reported this or are you the only one who has noticed? > (if the latter, I say we re-package, if the former we should probably > do a retag =( > > On Mon, Feb 11, 2013 at 10:16 PM, Shazron wrote: > > Since it's a low risk change (version number only), I say re-tag, and > > re-package - who is in charge of the robson tool? File a bug against it > > > > Or is the version number not worth it? > > > > On Mon, Feb 11, 2013 at 1:16 PM, Tim Kim wrote: > > > >> Hey gang, > >> > >> So it appears I forgot to push out a commit to update the version number > >> in the BlackBerry repo, but accidently tagged 2.4.0 anyways. Should I > force > >> re-tag the repo? > >> > >> Also, the download on phonegap.com for the BlackBerry repo was kinda > >> messed > >> up anyways. In that the robson tool didn't copy over the www/ folder and > >> just the bin/ folder (changed from using ant dist to ./bin/create). > >> > >> Sorry for the mix ups! I was at a conference and was kinda jet lagged > when > >> I was attempting to update the repo. > >> > >> -- > >> Timothy Kim > >> > -- Timothy Kim
cordova command cli and merges concept pull request
Hey all:
I submitted a pull request for an enhancement of the addition of a merges
folder/concept into the cli build process.
https://github.com/apache/cordova-cli/pull/3
The concept of merges is pretty simple, to support a common core web base
across platforms, but allow for deploying platform specific www content to
specific platforms. The addition to the CLI tool adds a new folder "merges" to
the root level. Upon running "cordova platforms add|remove platform" a new
folder is created under the "merges" folder (ie: merges/ios , merges/android
etc). Upon running "cordova buid" any content added to this folder will be
deployed to the associated www folder in the platforms. This carries for
either new content being added, or more importantly overrides existing content
from the www folder. For a very simple example imagine you have a css file
named css/chrome.css in the www folder, where you could have .backButton {
display:block;} , but then under merges/android/css/chrome.css you could have
.backButton{display:none;}, this is a very simplistic use but it illustrates
the concept. This additional workflow to the build system in the cli enables
some great processes for building a nice clean cordova app for example.
* Allows for keeping code clean and limits the need for platform specific js
logic per platform
* Enables a process of mocking in custom plugins for in browser dev (mocks
under www real implementations under merges) , and not risking this code
filtering into production/device code
* Allows for creating platform specific assets such as css / font / images/
videos etc that only gets merged into the specific desired platform
* Allows for accepting that each platform is unique and sometimes need
specific logic and or shims, and always deserves the platform specific love,
and the build process should support doing this cleanly
Anywho….. Would love to see this integrated in.
Thanks
mw
