I read the API docs page couple times. It does not appear to be possible to change the color of a button unless I’m missing something painfully obvious.
I know I can achieve this by preparing a graphical button image in the color and shape I want and then provide it to the newButton() widget but I was wondering if I can make a simple button in any color and color gradient without resorting to image files.
Thanks,
Kerem
I think this was possible in widget 1.0 but is not possible still in widget 2.0. Can someone (cough, err, Danny?) please confirm this to be the case and if so whether widget 2.0 will ever get this feature back or not? Thank you very very much.
Hi @ksan,
I know that some people have requested this, but it’s not yet implemented. You’re free to implement it yourself (via the widget 2.0 open-source) or up-vote it in feedback.
In terms of changing the colors, you can apply a fill color to a 2-frame or 9-slice button, use a basic “greyscale” image set, and fill/tint each button to provide variety. I know that’s not the same as just using “newRoundedRect()” with a gradient, but at this time, it’s a potential workaround if you want to get some color variation without creating a new set of graphics for each color variety.
Regards,
Brent
Hi Brent,
Thanks for your kind response. Again, this was a feature present in widget 1.0 that was dropped for some reason in widget 2.0 yet it was used and valued by your developer community. We should not have to solicit votes for something like this. It is a bug or defect not a new feature requested.
Besides, I am getting a little confused by this whole ‘vote it up to see it get done’ response. Just this morning I was reading another thread where someone asked about flipping an object and you said the following…
Brent Sorrentino, on 20 May 2013 - 09:58, said:
It will flip the image, but the physics body will retain its core orientation. I have, however, asked the engineers to look into this and see if we can provide a “true” flip with physics… hopefully it can happen before too long.
It appears in this particular case, for one reason or another, the request ‘appealed’ to you so much that you bumped it up in the internal priority scheme… No votes requested. Not even sure if this ‘feature’ is even registered on the voting system yet.
My post above and a number others which got the ‘vote it up to see it get done’ response were features that existed in the product which people counted on. As far as I’m concerned, the fact that it was dropped just like that, without first depreciating it etc is a bug or defect. As with other bugs / defects, we should not have to vote, petition or lobby etc to get it resolved. It should get resolved in line with your prioritization scheme which should be fair and equitable.
No new feature (ie flip physics object) should be bumped up over a bug just like that because Brent asked for it. Does this make sense?
It is just frustrating for us to be waiting patiently for some issues to be resolved. We try to work with the system, vote up features for future implementation etc. Then something comes along and shows us that it is all a bubble of make-believe and whatever CL wants to do next will happen next and all of use can go ‘vote’ things up all we want…
I know CL is a business and it is a not a democracy per se but please at least have some sense of accountability and consistency towards how you respond to issues on this very public forum.
Thank you very much.
Kerem
Hello Kerem,
I understand your concern, but allow me to clarify. When I “suggest” something to the engineers, as in the case of physics body flipping, that doesn’t mean it gets done… I wish I had the authority to demand features, but it’s not the case. I have also suggested the addition of vector object buttons, but I didn’t announce it here publicly.
In regards to Widgets, yes, the use of vector object buttons from 1.0 to 2.0 was dropped. It was a decision made by the engineers. We felt that the majority of Corona developers would be satisfied with image-based 2-file, 2-frame, and 9-slice buttons. I don’t consider the lack of it in 2.0 as a bug… it was a simply a feature that was dropped by design.
Whether it’s a “bug” or a “lacking feature” isn’t really the core issue. Since the launch of Widgets, we’ve seen that many users require implementations that are not native to the framework. When it comes to widgets, it’s impossible to predict every use-case by every developer. We could spend months adding new features, and there would still be a list of requests, constantly growing/expanding/changing. This is why we decided to open-source Widgets 2.0 (and 1.0)… so developers can use the framework (either one) and hopefully accomplish their very specific, non-common widget-related needs. That doesn’t mean that we’re stopping all support and feature implementation on widgets, but rather, that we’re allowing developers to add their own custom features if they require them sooner than we can realistically add them.
I could have phrased it better in my first response to this thread, so I apologize for that. Still, when it comes to widgets, developers now have 3 choices (4 choices actually):
Use Widgets 2.0 within its supported framework.
Add in specific, non-common features using the open-sourced 2.0 library.
Use Widgets 1.0 (not recommended, but allowed).
Build your own “widgets” using standard Corona display objects, listeners, etc.
I will request the addition of vector-object buttons again, but I don’t know where it will land on the list. Proven, documented widget bugs (in terms of performance and functionality) will be fixed before new features and legacy features from 1.0 will be added back in. In the meantime, you have the 4 options above, and I hope one of them will suit your needs.
Thanks for your understanding,
Brent
Hi Brent,
Thanks for your thoughtful and kind response. No apology was needed but nevertheless I appreciate your willingness to own-up. I apologize for perhaps being somewhat brash!
Having said that… I don’t agree with your position on the features disappearing from one version to another but that’s just me.
I have seen CL use the ‘deprecated’ designation for certain API calls which is the right way to handle features that you wish to eradicate over time. It gives us time to switch over to whatever is replacing the feature being depreciated.
The fact that CL uses ‘depreciated’ for certain API calls, features and then simply drops others without warning is an anomaly. Due to this fact I feel it is fair for us to see ‘dropped without warning’ features as a bug or a defect. At least thats how I see it for what its worth. You don’t have to agree.
I will continue to use a mix of widget 1 and 2 in my project until all gets stabilized with widget 2. I think a lot is in the air still. A lot of progress is being made and time invested which is wonderful to see evidenced in the daily build logs. Thanks for all the hard work. Keep it up!
Regards,
Kerem
I think this was possible in widget 1.0 but is not possible still in widget 2.0. Can someone (cough, err, Danny?) please confirm this to be the case and if so whether widget 2.0 will ever get this feature back or not? Thank you very very much.
Hi @ksan,
I know that some people have requested this, but it’s not yet implemented. You’re free to implement it yourself (via the widget 2.0 open-source) or up-vote it in feedback.
In terms of changing the colors, you can apply a fill color to a 2-frame or 9-slice button, use a basic “greyscale” image set, and fill/tint each button to provide variety. I know that’s not the same as just using “newRoundedRect()” with a gradient, but at this time, it’s a potential workaround if you want to get some color variation without creating a new set of graphics for each color variety.
Regards,
Brent
Hi Brent,
Thanks for your kind response. Again, this was a feature present in widget 1.0 that was dropped for some reason in widget 2.0 yet it was used and valued by your developer community. We should not have to solicit votes for something like this. It is a bug or defect not a new feature requested.
Besides, I am getting a little confused by this whole ‘vote it up to see it get done’ response. Just this morning I was reading another thread where someone asked about flipping an object and you said the following…
Brent Sorrentino, on 20 May 2013 - 09:58, said:
It will flip the image, but the physics body will retain its core orientation. I have, however, asked the engineers to look into this and see if we can provide a “true” flip with physics… hopefully it can happen before too long.
It appears in this particular case, for one reason or another, the request ‘appealed’ to you so much that you bumped it up in the internal priority scheme… No votes requested. Not even sure if this ‘feature’ is even registered on the voting system yet.
My post above and a number others which got the ‘vote it up to see it get done’ response were features that existed in the product which people counted on. As far as I’m concerned, the fact that it was dropped just like that, without first depreciating it etc is a bug or defect. As with other bugs / defects, we should not have to vote, petition or lobby etc to get it resolved. It should get resolved in line with your prioritization scheme which should be fair and equitable.
No new feature (ie flip physics object) should be bumped up over a bug just like that because Brent asked for it. Does this make sense?
It is just frustrating for us to be waiting patiently for some issues to be resolved. We try to work with the system, vote up features for future implementation etc. Then something comes along and shows us that it is all a bubble of make-believe and whatever CL wants to do next will happen next and all of use can go ‘vote’ things up all we want…
I know CL is a business and it is a not a democracy per se but please at least have some sense of accountability and consistency towards how you respond to issues on this very public forum.
Thank you very much.
Kerem
Hello Kerem,
I understand your concern, but allow me to clarify. When I “suggest” something to the engineers, as in the case of physics body flipping, that doesn’t mean it gets done… I wish I had the authority to demand features, but it’s not the case. I have also suggested the addition of vector object buttons, but I didn’t announce it here publicly.
In regards to Widgets, yes, the use of vector object buttons from 1.0 to 2.0 was dropped. It was a decision made by the engineers. We felt that the majority of Corona developers would be satisfied with image-based 2-file, 2-frame, and 9-slice buttons. I don’t consider the lack of it in 2.0 as a bug… it was a simply a feature that was dropped by design.
Whether it’s a “bug” or a “lacking feature” isn’t really the core issue. Since the launch of Widgets, we’ve seen that many users require implementations that are not native to the framework. When it comes to widgets, it’s impossible to predict every use-case by every developer. We could spend months adding new features, and there would still be a list of requests, constantly growing/expanding/changing. This is why we decided to open-source Widgets 2.0 (and 1.0)… so developers can use the framework (either one) and hopefully accomplish their very specific, non-common widget-related needs. That doesn’t mean that we’re stopping all support and feature implementation on widgets, but rather, that we’re allowing developers to add their own custom features if they require them sooner than we can realistically add them.
I could have phrased it better in my first response to this thread, so I apologize for that. Still, when it comes to widgets, developers now have 3 choices (4 choices actually):
Use Widgets 2.0 within its supported framework.
Add in specific, non-common features using the open-sourced 2.0 library.
Use Widgets 1.0 (not recommended, but allowed).
Build your own “widgets” using standard Corona display objects, listeners, etc.
I will request the addition of vector-object buttons again, but I don’t know where it will land on the list. Proven, documented widget bugs (in terms of performance and functionality) will be fixed before new features and legacy features from 1.0 will be added back in. In the meantime, you have the 4 options above, and I hope one of them will suit your needs.
Thanks for your understanding,
Brent
Hi Brent,
Thanks for your thoughtful and kind response. No apology was needed but nevertheless I appreciate your willingness to own-up. I apologize for perhaps being somewhat brash!
Having said that… I don’t agree with your position on the features disappearing from one version to another but that’s just me.
I have seen CL use the ‘deprecated’ designation for certain API calls which is the right way to handle features that you wish to eradicate over time. It gives us time to switch over to whatever is replacing the feature being depreciated.
The fact that CL uses ‘depreciated’ for certain API calls, features and then simply drops others without warning is an anomaly. Due to this fact I feel it is fair for us to see ‘dropped without warning’ features as a bug or a defect. At least thats how I see it for what its worth. You don’t have to agree.
I will continue to use a mix of widget 1 and 2 in my project until all gets stabilized with widget 2. I think a lot is in the air still. A lot of progress is being made and time invested which is wonderful to see evidenced in the daily build logs. Thanks for all the hard work. Keep it up!
Regards,
Kerem
Brent,
Any updates on this one? Any commitment to bring it back?
Not sure where it lands on the list but seeing things like Green Throttle get on the list out of nowhere (ie not on Roadmap and not on voted feature requests list) make me wonder…
Let me re-iterate.
Widget 2.0 is on the Roadmap. It is a Priority 1 item. It says DONE next to it…
At question here is a feature that was available in Widget 1.0 that was dropped just like that without being depreciated first. Now some people want it back along with other dropped features (ie tab bar button ignoring taps while selected etc).
Until these features and other stability fixes are in Widget 2.0 we can’t really say DONE next to it on the Roadmap can we?
So in a nutshell… GT not on roadmap, Widget 2.0 on roadmap. Pretty obvious case isn’t it?
Sorry to start your week with a rant. Hope the rest of the week goes well for all of us!
Regards,
Kerem
Hi Kerem,
I don’t consider this a “rant”; it’s a legitimate opinion. 
I just put in another request with the engineers to make it (Widget vector buttons) happen this week. I can’t make any guarantees (it could slip a bit longer), but it’s back on my own radar and I’ll keep on top of it.
Brent
Hi Brent,
Thanks much for your kind reply. I wasn’t trying to push this to get done asap vs other more pressing bugs, issues etc. Was just trying to see if it is now confirmed that this feature will come back but your reply is even better! I appreciate all the hard work by the CL staff.
Thank you very much. Have a great week. Regards,
Kerem
Brent,
Any updates on this one? Any commitment to bring it back?
Not sure where it lands on the list but seeing things like Green Throttle get on the list out of nowhere (ie not on Roadmap and not on voted feature requests list) make me wonder…
Let me re-iterate.
Widget 2.0 is on the Roadmap. It is a Priority 1 item. It says DONE next to it…
At question here is a feature that was available in Widget 1.0 that was dropped just like that without being depreciated first. Now some people want it back along with other dropped features (ie tab bar button ignoring taps while selected etc).
Until these features and other stability fixes are in Widget 2.0 we can’t really say DONE next to it on the Roadmap can we?
So in a nutshell… GT not on roadmap, Widget 2.0 on roadmap. Pretty obvious case isn’t it?
Sorry to start your week with a rant. Hope the rest of the week goes well for all of us!
Regards,
Kerem
Hi Kerem,
I don’t consider this a “rant”; it’s a legitimate opinion. I just put in another request with the engineers to make it (Widget vector buttons) happen this week. I can’t make any guarantees (it could slip a bit longer), but it’s back on my own radar and I’ll keep on top of it.
Brent
Hi Brent,
Thanks much for your kind reply. I wasn’t trying to push this to get done asap vs other more pressing bugs, issues etc. Was just trying to see if it is now confirmed that this feature will come back but your reply is even better! I appreciate all the hard work by the CL staff.
Thank you very much. Have a great week. Regards,
Kerem
Hi Brent, Is this change still in queue? Thanks much for looking at the queue to confirm.
Hi Brent, Is this change still in queue? Thanks much for looking at the queue to confirm.
Was a bug report on this every filed or was it added to the feedback site? Can I get the bug number or the link from the feedback site?
Thanks
Rob