I think we can assume the resources of CL are limited and we cant have it all, so for me two priorities seem obvious from all the feedback : - Fix the current issues in widgets 2. We as customers, are all wasting time working around or fixing issues in the current codebase of widgets. To a point where we are afraid of using any new widget or feature from widgets as it usually breaks at the first real world use case. Once the current batch of fixes are out, we will start using some more features and the next batch of bugs will become clear. - get a QA process in place and regression tests implemented. Maybe as a start have a test automation suite that runs through the demo projects so we dont have to manually test whats broken in our apps after each upgrade. In the meantime, we should not expect any enhancements. In fact, I rather NOT have enhancements like the new official screen management component formerly known as storyboard (not mentioning it by name as it gets threads locked) We can have a discussion on a roadmap, on what directions we would like to see widgets 3 take, as the current design is “sub-optimal”, but for now I would vote for CL to just focus on making the advertised features work as expected so we can ship our apps with more confidence and use a little more of the widgets. The option of using Corona Enterprise to access native widgets from the devices is simply not viable to me - there are competing solutions way ahead of Corona/Lua in this market.
Just submitted one more bug (#29905)
One thing I really like about the new Composer is that CL _ didn’t _ throw Storyboard out. So you don’t *have* to switch if you don’t want to. And even when they do decide to remove it from the codebase, they’ll make it available as a library. Which means you don’t have to move to Composer if you don’t want.
My existing apps will remain with Storyboard – the new stuff will be done with Composer. But I like that they didn’t just toss it out and say, “Use the new stuff only.”
Jay
I am looking forward !
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
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
Hadn’t seen that before but it looks nasty. There row lines are very unpredictable of late. Thanks for sharing.
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
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
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
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?
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.
Since the new daily build setting up a defaultFile with the newButton function brings an error.
@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
@sunmills: that happened in 2158. Is 2159 still exposing the same behavior for you?
alex
#29891 - Switch moves x-location when I scroll in the scroll view.
#29534 - widget.newSwitch missplacement on Android
#28960 - switch widget is displayed wrong in state = true and theme ~= ios7
#29419 - isBounceEnabled in scrollview is shared with all scrollviews.
#29399 - widget switch shifts upon scrolling in scrollView
#29144 - widgets.newSwitch in onOff style moves left & right on x axis when it is programmatically changed with obj:setState()
#30007 - scrollview problems in compatibility mode.
alex
fixed, thanks!
The code you posted in 29144 looks fine in 2159 here, in both compatibility and non-compatibility.
Anything in the config files? The code you posted does not contain any…
Alex
Can confirm the switch is solid as a rock now. No more wiggling. I had a code mixup earlier this morning and thought it was still moving. Thanks Alex. Great work.