Widget 2.0 Graphic Assets Not Following Convention

Solar2D Widgets
#1

As i understand it the Corona convention lets me pick how i want to handle multiple resolution naming conventions.  It appears to me that the new widgets have graphics that are now embedded in the Core of Corona but they are not respecting the choices i made in config.lua as to how i want different resolutions named.

 

If you use:

 

 

imageSuffix = { ["@2x"] = 2, }

 

you get the first image with the 2.0 widget demo.  I’ve only included a small portion of the screen due to the wacky small upload restrictions on this interface.  

 

In my config.lua i take a different naming convention that meets my needs better:

 

imageSuffix = { ["-x20"] = 2, }

 

But this apparently comes at a new cost which is that i only get the Low Res widget images. See second image.  I would bet that the Widget 2.0 code is assuming that we are all using the @2x as our naming convention but that would be a mistake given that the spec allows us to choose a convention of our liking.

 

Please fix this oversight.

 

I might also mention that there is no example in the new Widget code of using widget.setTheme() to create our own theme yet the docs say go look in the example code for how to do this.
 

 

 

 

 

#2

As i understand it the Corona convention lets me pick how i want to handle multiple resolution naming conventions.  It appears to me that the new widgets have graphics that are now embedded in the Core of Corona but they are not respecting the choices i made in config.lua as to how i want different resolutions named.

If you use:

imageSuffix = { ["@2x"] = 2, }

you get the first image with the 2.0 widget demo.  I’ve only included a small portion of the screen due to the wacky small upload restrictions on this interface.  

In my config.lua i take a different naming convention that meets my needs better:

imageSuffix = { ["-x20"] = 2, }

But this apparently comes at a new cost which is that i only get the Low Res widget images. See second image.  I would bet that the Widget 2.0 code is assuming that we are all using the @2x as our naming convention but that would be a mistake given that the spec allows us to choose a convention of our liking.

Please fix this oversight.

I might also mention that there is no example in the new Widget code of using widget.setTheme() to create our own theme yet the docs say go look in the example code for how to do this.
 

Good catch. I know I keep asking you this but please [buglink] and this will get added to my list of things to fix.

I know the theming guide has been promised for a while and has not yet come out. I apologize wholeheartedly for that.

Bug fixes have had to take priority this week.

#3

As i understand it the Corona convention lets me pick how i want to handle multiple resolution naming conventions.  It appears to me that the new widgets have graphics that are now embedded in the Core of Corona but they are not respecting the choices i made in config.lua as to how i want different resolutions named.

If you use:

imageSuffix = { ["@2x"] = 2, }

you get the first image with the 2.0 widget demo.  I’ve only included a small portion of the screen due to the wacky small upload restrictions on this interface.  

In my config.lua i take a different naming convention that meets my needs better:

imageSuffix = { ["-x20"] = 2, }

But this apparently comes at a new cost which is that i only get the Low Res widget images. See second image.  I would bet that the Widget 2.0 code is assuming that we are all using the @2x as our naming convention but that would be a mistake given that the spec allows us to choose a convention of our liking.

Please fix this oversight.

I might also mention that there is no example in the new Widget code of using widget.setTheme() to create our own theme yet the docs say go look in the example code for how to do this.
 

Good catch. I know I keep asking you this but please [buglink] and this will get added to my list of things to fix.

I know the theming guide has been promised for a while and has not yet come out. I apologize wholeheartedly for that.

Bug fixes have had to take priority this week.

#4

Any update on getting this bug fixed?  I submitted a bug report on it back on March 21st.

Thanks!

#5

Any update on getting this bug fixed?  I submitted a bug report on it back on March 21st.

Thanks!

#6

Poke for status update

#7

Poke for status update

#8

Another poke for status on this.  It is important that you pick up the imageSuffix and use that as per the documentation.  Bug report was submitted long ago.

#9

Hi.

There is nothing we can do about this at the present time. Your only option would be to grab the widget image files from github: https://github.com/coronalabs/framework-widgets/tree/master/widget_assets/graphics

And export them to match your naming convention.

#10

thanks for the hint … can you please tell me exactly where in my directory structure they should go so that your widget picks them up?

#11

Sure. If you want to keep the image sheet/lua files the same name as their defaults, you also need to add this to your main.lua file:

[lua]

package.preload.widget_theme_ios = nil

package.preload.widget_theme_ios_sheet = nil

package.preload.widget_theme_android = nil

package.preload.widget_theme_android_sheet = nil

[/lua]

They can reside wherever you like. You set the path to them in widget_theme_ios.lua > lines 9 & 10 (and again in widget_theme_android.lua if your using that) 

#12

thanks for the info … seems to work so far! 

Cheers,

m

#13

Another poke for status on this.  It is important that you pick up the imageSuffix and use that as per the documentation.  Bug report was submitted long ago.

#14

Hi.

There is nothing we can do about this at the present time. Your only option would be to grab the widget image files from github: https://github.com/coronalabs/framework-widgets/tree/master/widget_assets/graphics

And export them to match your naming convention.

#15

thanks for the hint … can you please tell me exactly where in my directory structure they should go so that your widget picks them up?

#16

Sure. If you want to keep the image sheet/lua files the same name as their defaults, you also need to add this to your main.lua file:

[lua]

package.preload.widget_theme_ios = nil

package.preload.widget_theme_ios_sheet = nil

package.preload.widget_theme_android = nil

package.preload.widget_theme_android_sheet = nil

[/lua]

They can reside wherever you like. You set the path to them in widget_theme_ios.lua > lines 9 & 10 (and again in widget_theme_android.lua if your using that) 

#17

thanks for the info … seems to work so far! 

Cheers,

m

#18

So … i have to raise this one again.  With the new ios 7 the fix for the issue of this thread no longer works. 

I guess i need to know where i get the new image sheets for the 7.0 theme?

Would it not be easier for this issue to be fixed once and for all properly?

Baring that … can you tell me what a work-around might be for this … i followed your documentation and chose a naming convention for my images that followed the guidelines but is not the same as most examples.  Changing all my filenames is not a simple matter or i would have done so already … but as i point out … it is what your documentation says.

To recap the Widget 2.0 image sheets do not pick up my resolution naming convention (see above).

#19

So … i have to raise this one again.  With the new ios 7 the fix for the issue of this thread no longer works. 

I guess i need to know where i get the new image sheets for the 7.0 theme?

Would it not be easier for this issue to be fixed once and for all properly?

Baring that … can you tell me what a work-around might be for this … i followed your documentation and chose a naming convention for my images that followed the guidelines but is not the same as most examples.  Changing all my filenames is not a simple matter or i would have done so already … but as i point out … it is what your documentation says.

To recap the Widget 2.0 image sheets do not pick up my resolution naming convention (see above).

#20

Bump … please