My app config file is something like this:
application = { content = { width = 768, height = 1024, scale = "letterBox", xAlign = "center", yAlign = "center", audioPlayFrequency = 22050, imageSuffix = { ["@2x"] = 1.5, ["@4x"] = 3.0, }, }, notification = { iphone = { types = { "badge", "sound", "alert" } } } }
I try to use PickerWheel widget, but it will never scale to fit screen width. Any ideas would be appreciated.
Please note this passage in the documentation: http://docs.coronalabs.com/api/library/widget/newPickerWheel.html
This widget does not support scaling.
There are no size parameters to pass to the widget.newPickerWheel() to control the size of it. You can use visual customization if you provide your own custom imageSheet’s to provide a wheel of different sizes, but for the stock one, you get roughly a 320 wide wheel.
So, from your point, in order to make it full screen width, i must set 320 width and 480 Height in my config.lua to use the default picker wheel, right?
Somehow, we may want to set different width and height. Why can’t we change the pickerWheel size?
So will this will look ‘clunky’ on an iPad retina as there’s no scaling?
I hesitate to use the term scale… So let me use “rez-up” to talk about the images themselves. Because they are either solid or linear gradients when the retina display doubles the pixel count, it’s going to pretty much look the same. In this case, scale is meaning that it’s a 320px wide asset. You can’t set it’s width. So if you make your config.lua to be a 640px wide vs. 320px wide scale, the pickerWheel will still be 320px. But that 320px version on a config.lua that is 320px even if the device is 640px wide will look fine.
Please note this passage in the documentation: http://docs.coronalabs.com/api/library/widget/newPickerWheel.html
This widget does not support scaling.
There are no size parameters to pass to the widget.newPickerWheel() to control the size of it. You can use visual customization if you provide your own custom imageSheet’s to provide a wheel of different sizes, but for the stock one, you get roughly a 320 wide wheel.
So, from your point, in order to make it full screen width, i must set 320 width and 480 Height in my config.lua to use the default picker wheel, right?
Somehow, we may want to set different width and height. Why can’t we change the pickerWheel size?
So will this will look ‘clunky’ on an iPad retina as there’s no scaling?
I hesitate to use the term scale… So let me use “rez-up” to talk about the images themselves. Because they are either solid or linear gradients when the retina display doubles the pixel count, it’s going to pretty much look the same. In this case, scale is meaning that it’s a 320px wide asset. You can’t set it’s width. So if you make your config.lua to be a 640px wide vs. 320px wide scale, the pickerWheel will still be 320px. But that 320px version on a config.lua that is 320px even if the device is 640px wide will look fine.
Just to jump on the end of this…
I’m using a picker wheel with a config setting of 640px width. The picker wheel displays at 320 still, so it’s only half the screen width. Is there any way (other than setting my config to 320 width) that I can get the picker wheel to double up so it’s 640 width and fits the whole screen width?
Otherwise it’s very small and fiddly to use…
I’ve tried the suggestions in this thread - http://forums.coronalabs.com/topic/30110-how-to-set-the-pickerwheel-for-640x960-resolution/ - but changing the overlay width simply makes the visual width bigger but doesn’t affect the column widths. If I change those manually then things go all weird. It doesn’t want to let my total column widths add up to more than 280, regardless of the setting for overlayFrameWidth…
If anyone has any ideas that would be great. If not I’ll have to build my own picker wheel which I’d rather avoid having to do from a time point of view.
Thanks,
Ian
Widgets are designed to work with a 320px based content area. Apple uses 320 content points as it’s base (even today when they don’t have a 320px phone). Android is based on a 160 pixel per inch screen an most phones are around 2 inches wide in the content area which is 320 pixels.
As much as I would love to get away from 320px, the device vendors still think in 320px and therefore we have to.
Rob
Thanks Rob. Thought that would be the case.
Ok so I would like to use widget.newPickerWheel but it’s turning out to be a bit of a headache.
I’m using the ‘Modernized Ultimate config.lua’ described in this article because I thought it was the new best practice in corona projects :
https://coronalabs.com/blog/2013/09/10/modernizing-the-config-lua/
I just want a simple picker for a simple job and want to minimise the file size of my app so I don’t want to alter or add image sheets.
How can I do this?
Modernizing the config.lua post was about two separate things. One was getting a config.lua that uses letterbox scaling to fill the screen without a complex if-then-elseif-else statement. That concept works regardless of file size.
The second part was a suggestion about moving away from 320x480 for various reasons. However, there are some very strong reasons to stay with 320x480, such as “Apple says to”. They use content points to measure things which are based off of 320x… Android’s dpi based system is 160ppi which on an 2 inch device like many phones (2 inch wide), is 320px.
But the other big reason is our widgets are designed for 320x and we don’t have any immediate plans to change that. If you want to use the pickerWheel you have two choices. Move to 320x480 as your base screen size or download the widget library from out github repository and build a pickerWheel that works for you.
Rob
Thanks Rob. I won’t be changing my config settings now though, it’s too much hassle at this point.
What would be nice is if there was a vector based - resolution independent solution like with widget.newButton(). I’ve used the shape construction method for creating widget buttons and that works well.
Well, anyway… has anyone made a widget image sheet or adaptation for the following config settings then?
local aspectRatio = display.pixelHeight / display.pixelWidth application = { content = { width = aspectRatio \> 1.5 and 800 or math.ceil( 1200 / aspectRatio ), height = aspectRatio \< 1.5 and 1200 or math.ceil( 800 \* aspectRatio ), scale = "letterBox", fps = 30, imageSuffix = { ["@2x"] = 1.3, }, } }
I think the psd is here :
https://github.com/coronalabs/framework-widget/blob/master/widget_assets/graphics/widget_theme_ios7%402x.psd
I’m just not sure what size to make the assets for texturePacker or how to rebuild the widget library appropriately. I guess the problem is that the width and height aren’t set values in the config.lua.
Just to jump on the end of this…
I’m using a picker wheel with a config setting of 640px width. The picker wheel displays at 320 still, so it’s only half the screen width. Is there any way (other than setting my config to 320 width) that I can get the picker wheel to double up so it’s 640 width and fits the whole screen width?
Otherwise it’s very small and fiddly to use…
I’ve tried the suggestions in this thread - http://forums.coronalabs.com/topic/30110-how-to-set-the-pickerwheel-for-640x960-resolution/ - but changing the overlay width simply makes the visual width bigger but doesn’t affect the column widths. If I change those manually then things go all weird. It doesn’t want to let my total column widths add up to more than 280, regardless of the setting for overlayFrameWidth…
If anyone has any ideas that would be great. If not I’ll have to build my own picker wheel which I’d rather avoid having to do from a time point of view.
Thanks,
Ian
Widgets are designed to work with a 320px based content area. Apple uses 320 content points as it’s base (even today when they don’t have a 320px phone). Android is based on a 160 pixel per inch screen an most phones are around 2 inches wide in the content area which is 320 pixels.
As much as I would love to get away from 320px, the device vendors still think in 320px and therefore we have to.
Rob
Thanks Rob. Thought that would be the case.
Ok so I would like to use widget.newPickerWheel but it’s turning out to be a bit of a headache.
I’m using the ‘Modernized Ultimate config.lua’ described in this article because I thought it was the new best practice in corona projects :
https://coronalabs.com/blog/2013/09/10/modernizing-the-config-lua/
I just want a simple picker for a simple job and want to minimise the file size of my app so I don’t want to alter or add image sheets.
How can I do this?
Modernizing the config.lua post was about two separate things. One was getting a config.lua that uses letterbox scaling to fill the screen without a complex if-then-elseif-else statement. That concept works regardless of file size.
The second part was a suggestion about moving away from 320x480 for various reasons. However, there are some very strong reasons to stay with 320x480, such as “Apple says to”. They use content points to measure things which are based off of 320x… Android’s dpi based system is 160ppi which on an 2 inch device like many phones (2 inch wide), is 320px.
But the other big reason is our widgets are designed for 320x and we don’t have any immediate plans to change that. If you want to use the pickerWheel you have two choices. Move to 320x480 as your base screen size or download the widget library from out github repository and build a pickerWheel that works for you.
Rob