List of open Widget 2.0 bugs & promised features...

Solar2D Widgets
#361

I am looking forward !

#362

I changed the code so I don’t have any way to check anymore but I am almost certain it wasn’t as I needed it to be on top of everything else in the app, but I’m almost 100% sure it wasn’t put in a group.

#363

Hey guys,

2014.2183 fixes:

#26439: widget.setTheme widget_theme_ios7 issue with tableView
#28359: tableView row.height and row.contentHeight is reported wrongly in ORR
#29678: tableView structure is misaligned
#29905: Tableview with row width inconsistent
#27439: tableview with params & iscategory
#29142: widget.newStepper:setValue does not update newStepper.value (the stepper now has a getValue() method)
#30229: widget.newPickerView not releasing all memory.
#25855: ButtonWidget causes texture memory leak

More on the way.

Thanks,

alex

#364

Awesome thanks a lot Alex!

#365

Guys,

I just looked at the list of open Widget 2 bugs and did not see one describing the “size” prob I’m having with newSegmentedControl.

My config.lua is currently set for a content area of 640 x 960 (although I’m anxious to change it on my next app to 1200 x 1800 as suggested by Rob in his ultimate config.lua tutorial)

In any case, my segmentedControl does not scale properly…it renders in a size that would be appropriate (I think) for a 320 x 640 screen. I’m having a similar problem with tableViews but will leave that to a separate post.

Are Widgets 2.0 not dynamic to match the config.lua in use or is this something I’m doing wrong?

If this is a bug, I’ll add it to the document…if not, please advise as to how to fix it

All feedback welcome.

Thanks

Dewey

#366

Hi Dewey, 

I did not notice this before but I wouldn’t be surprised if its a new thing. In my SplitView demo, I use a 768x1024 setting in config.lua (zoomStretch) to make it match the native iPad screen resolution. When I build and run it on iPhone (landscape) I see the widgets scale nicely and maintain the proportions I see on the larger iPad screen. Suggest starting a new thread specific to this issue you are observing so we can dive deep into it. 

Best regards,

Kerem

#367

Kerem…would you take a look this and tell me if you’ve seen this before…

#368

Hadn’t seen that before but it looks nasty. There row lines are very unpredictable of late. Thanks for sharing.

#369

Several of the widgets don’t scale.  If your app is going to make heavy use of widgets, you might want to consider continuing to use the 320x480 content area size. 

Rob

#370

Alex , the list is awesome! Thanks for putting in the effort in fixing the bugs and open communications here. 

Corona Labs leadership , David, Walter, thanks for hearing our calls and allowing this to happen. One more day to the anniversary and I do think we have gained significant momentum. I hope this becomes the norm rather than the exception. Thank you very much!!!

Bug owners in the spreadsheet… Please verify your bugs and move them to the fixed tab if all looks ok. Thanks much!!!

#371

Rob…I don’t usually b**ch, but don’t you think that should be FRONT AND CENTER on the Widget documentation???   On a few widgets, the docs say that xScale and yScale are not supported, but that (seems to me) is a far cry from saying these components simply don’t support CL’s recommended best practices for config.lua.   I’m quite far into a lot of nuanced object positioning based on the recommended (and more flexible) larger config.lua sizes, and I’ve not seen that very serious limitation expressed anywhere where it is clear and un-ambiguous…that sort of thing can engender a lot of ill-will if it’s known and not clearly stated as a serious warning.

What do you suggest I do at this point…is proper scaling on the widget roadmap or do I have to make a cost-benefit analysis whether it’s easier to patch W2.0, or go redo all of my complex screens

#372

Most widgets have issues using xScale and yScale, but that’s not what I’m referring to.  Any widget that you can control the width and height on and fontsize on you should be able to make work with any content area.

Rob

#373

I agree with dgaedcke…The documentation could be a little more clear about base HxW supported for widgets.  

I started re-writing a lot of my code to work with G2.  At that time I figured it would also be best to apply the modernized config.lua suggestions.  I wasn’t able to get the wheelpicker working. After reading comments I found a suggestion to stick with 320x480:

http://coronalabs.com/blog/2013/09/10/modernizing-the-config-lua/#comment-46318

So I scrapped the work I did and changed the base dimensions back.  I thought there might be a way to get it to work, but didn’t want to invest the time.  

Is the wheelpicker the only widget that doesn’t work? I think it is one the widget that’s holding me back from moving to a new base. Anyone have any hacks to move forward?

#374

Thanks for the update, but there are still some major issues which are not easy to describe as a bug report, so I made a little video again.

http://www.youtube.com/watch?v=KJjo_0hSoSA&feature=youtu.be

  1. Tableview doesn’t scroll back if finger moved more in x direction as in y, which I posted already.

  2. Rows don’t move correct back, what produces a gap between the rows

  3. Tableview position not correct by switching back from outside the screen after deleting a row

Before the update I could avoid the issues by reload the tableview after deletions, but there is now a incorrect row position anyway. 

I also reported a bug with samplecode. The number is 30735.

Thanks!

edit:

  1. a tableView:reloadData() call after a deletion causes that the row above and under the deleted row are too close together. The line of the last pixel of the upper row is covered from the lower row then. I have a shadow line as the last line of my row background, so this is very annoying.  
#375

Skatan - I had the same problems as you… it was driving me nuts.  I think I traced it down to the default anchor’s.  I set the default anchorX/Y=0.    If I set the default anchor to 

      display.setDefault( “anchorX”, .5 )

      display.setDefault( “anchorY”, .5 )

before creating my newPickerWheel and then setting back to 0 after it is created the problem appears to be fixed.

Looks like the newWheelpicker only plays nice with the default anchor point set to 0.5.

#376

I have the same bug like @Sunmils.

I need quick fixing please.

#377

In the works.

alex

#378

2159 seems to include some bug fixes but not sure which ones. 

Alex, can you kindly post the list of fixed bugs here? Thank you very much for your hard work.

#379

Since the new daily build setting up a defaultFile with the newButton function brings an error.

#380

@sunmills: noticed that too. Investigating.

@ksan: i will, but first i have to check, it might be that we pulled in a commit that was not supposed to go in.

alex