When and who decided that Buttons defaultColor, overColor strokeColor strokeWidth cornerRadius were irrelevant? I have all my buttons as purely text buttons and this makes it a real pain. I would like to keep up with current builds but I would also like existing functions to be available.
When and who decided that Buttons defaultColor, overColor strokeColor strokeWidth cornerRadius were irrelevant? I have all my buttons as purely text buttons and this makes it a real pain. I would like to keep up with current builds but I would also like existing functions to be available.
We replaced defaultColor and such with 9 slice widget button creation. Adding to this that antialiasing is currently not supported, your rounded rect buttons would have looked very jagged.
Also this was a function in the old widget library, we re-wrote the widget library from scratch so in widget 2.0 it wasn’t an existing function.
Note; we are planning on adding support for text only widget buttons ( just text no background )
Pity, I guess I must write my own button function or look elsewhere.
You are missing the point. Even if you wrote your own function your button still wouldn’t look right ( with rounded edges ) due to the lack of antialiasing.
I think his point is, you took functionality he was using (and so was I) and threw it away because you (CL) didn’t like it.
Text-only buttons will help (me, at least), but it’s kind of the principle of the thing. 
Jay
I know what you are saying, but with the recent antialiasing changes you wouldn’t be able to use buttons created via rounded rects in a production app anyway due to the point I made above.
Danny, when you rewrite a library you should be enhancing it not reducing it’s functions. This indicates a less than mature product. I can program around it but I am disappointed and am looking at other development options.
Hi @PopsHugo,
Widgets 2.0 was designed as a “fits most cases” library, but we couldn’t add every potential use-case to the library, at least not immediately, as it’s impossible to determine how developers will use widgets in all cases and scenarios. This need for text-only buttons or vector-back buttons surfaced later, and we didn’t anticipate that so many users would request it. It wasn’t removed because we “didn’t like it” as Jay suggests; merely, it was not added as a core initial feature. This sort of functionality should be added upcoming, and I apologize for the inconvenience.
Remember that if you have a pressing, ready-for-market app that used Widgets 1.0, you can still use them via the open-sourced 1.0 library. You probably already know that, and I’m not suggesting it’s a great solution, only that you can go that route if necessary. In the meantime, we hear your “widget needs” and are rolling them in as quickly as we can.
Thanks for your understanding,
Brent Sorrentino
Brent,
I probably should have said, “didn’t see the need for it” rather than “didn’t like it.” To me, at the time, they meant the same thing.
And Pops, you’d give up everything else Corona SDK has to offer because widgets don’t (at this point) automatically make round rect buttons? You can create something similar pretty easily. I’ll stick some code below in case it might come in handy for you.
If not, Widgets 2.0 will keep getting better and better.
Jay
[lua]
–[[
Usage:
local function buttonTapped(event)
if event.target.param == “back” then
--do something
end
end
local doesNothingBtn = makeTextButton(“Look at me!”)
local backBtn = makeTextButton(“Back”, 20, 300, {param=“back”, listener=buttonTapped})
local otherBtn = makeTextButton(“Do Something”, 100, 400, {fontFace=“Courier”, fontColor={255,127,0}, fontSize=48, listener=buttonTapped, param=“other”})
–]]
–===================================================
– make text that acts like a button
– requires only text to display, others are optional
– passes back the display text object
function makeTextButton(txt, x, y, opts)
local options = opts or {}
local fontFace = options.fontFace or “Helvetica”
local fontSize = options.fontSize or 24
local fontColor = options.fontColor or {255,255,255}
local param = options.param
local tapOrTouch = options.tapOrTouch or “tap”
local listener = options.listener
local group = options.group
local btn = display.newText(txt, 0, 0, fontFace, fontSize)
btn:setTextColor(fontColor[1], fontColor[2], fontColor[3] )
btn.x = x or centerX
btn.y = y or centerY
if param then
btn.param = param
end
if listener then
btn:addEventListener(tapOrTouch, listener)
end
if group then
group:insert(btn)
end
return btn
end
[/lua]
When and who decided that Buttons defaultColor, overColor strokeColor strokeWidth cornerRadius were irrelevant? I have all my buttons as purely text buttons and this makes it a real pain. I would like to keep up with current builds but I would also like existing functions to be available.
We replaced defaultColor and such with 9 slice widget button creation. Adding to this that antialiasing is currently not supported, your rounded rect buttons would have looked very jagged.
Also this was a function in the old widget library, we re-wrote the widget library from scratch so in widget 2.0 it wasn’t an existing function.
Note; we are planning on adding support for text only widget buttons ( just text no background )
Pity, I guess I must write my own button function or look elsewhere.
You are missing the point. Even if you wrote your own function your button still wouldn’t look right ( with rounded edges ) due to the lack of antialiasing.
I think his point is, you took functionality he was using (and so was I) and threw it away because you (CL) didn’t like it.
Text-only buttons will help (me, at least), but it’s kind of the principle of the thing.
Jay
I know what you are saying, but with the recent antialiasing changes you wouldn’t be able to use buttons created via rounded rects in a production app anyway due to the point I made above.
The point is that when rewriting a library or whatever there shouldn’t be sudden dramatic changes that then have to be programmed round. Stability for development is very important. I would prefer a stable programming platform that I don’t have to keep make programming work arounds.
Yes, basically I agree with you. While a property name of defaultFile may make more sense than default , leaving the original in place as well would have meant no code changes would be needed (on our side). Docs and everything going forward could have just referenced the new names with a note of the deprecated old names.
Today is the first day in the last few weeks where I’ve had time to sit down and get into the widget 2.0 stuff and in general, I’m really unhappy. While W2 may be built on a better foundation, I’m not really seeing any benefits at this point. Just more work.
Jay
I hit the same problem when updating one of my old apps that used text only buttons.
Dead easy fix, download the widget-v1.lua from github and at the top of your files where you include widget, change it to widget-v1 and viola all your text buttons work.
You can even have both versions of the widget library included and use a mix of both (as I do).
Dave
I too was affected by this change, which initially left me a bit flustered.
However I do see the benefits of leaving the old API behind. Widget 2.0 has better performance, and apart from some “growing pains” has been easier to work with. Breaking changes are a part of any developer’s life. Every API has them from time-to-time and they’re about moving the API forward.
I still miss the text buttons though. Granted, rounded rect buttons may look jagged (if not handled properly), but square buttons don’t suffer from anti-aliasing issues, so I still believe that there’s a place for these “old” properties in Widget 2.0.
What I’ve done to deal with this situation is to use Widget 1.0 and Widget 2.0 side-by-side.
I use a modified Widget 1.0 for my text buttons and Widget 2.0 for everything else.
It works, and now I’m happy 
@thedavebaxter and @ingemar, that’s a good idea (about using both v1.0 and v2.0 side by side.) That’s a great way to transition into widget 2.0. I wish I thought of it when I first tried migrating to v2.0. Thanks for sharing this tip!
Naomi