Excalibur
Excalibur copied to clipboard
Add an ex.Button class for easier player interaction
Context
It would be helpful to have a built-in Button class that allowed functionality to happen when a user clicks/taps it.
Proposal
Something similar to this would be a nice start:
class Button extends ex.UIActor {
// resize and attach the buttonText, and call the function passed in when a user clicks/taps the button
constructor(x: number, y: number, width: number, height: number, color: ex.Color, buttonText: string, func: () => void) {
...
}
(see also https://gist.github.com/jedeen/a1c7ec5a4ebac29fce0d9a251475b67e)
Currently working on this.
Should keyboard support be enabled for it? Such as using the arrow keys to select a button then using enter to activate the button which is currently selected. To implement this we could have the user pass an array (or an object that groups buttons, sounds better to me), and could easily set a boolean value in the Button class to change it's appearance to show it is selected.
To make it a bit clearer, that the user passes the array or class group of buttons to the engine, these will be the in focus buttons.
I'll let Josh chime in but I'd say for initial implementation that probably isn't needed (i.e. what if the arrow keys are already bound during the gameplay? Requires some more thought on the API/behavior)
On Mon, Mar 27, 2017 at 10:44 AM Robert [email protected] wrote:
Currently working on this.
Should keyboard support be enabled for it? Such as using the arrow keys to select a button then using enter to activate the button which is currently selected. To implement this we could have the user pass an array (or an object that groups buttons, sounds better to me), and could easily set a boolean value in the Button class to change it's appearance to show it is selected.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/excaliburjs/Excalibur/issues/749#issuecomment-289494368, or mute the thread https://github.com/notifications/unsubscribe-auth/AAiaa7ta3N8VSUNyLh6CHy6sEaPpw1Mxks5rp9lQgaJpZM4LrzUL .
Was just making suggestions, just seeing what sticks
It's a good idea, maybe we'll pull it into a separate issue once this is implemented.
Addressing keyboard input is a good idea. However, I think an initial implementation that takes care of mouse/touch input should work for now, since that form of input is the minimum necessary for a platform to use Excalibur (e.g. mobile devices).
I agree with @kamranayub. We can open an enhancement issue to add keyboard support to buttons.
Excellent, just so I'm putting it out there, I think it might be best to make UI generic. Currently I have two new files UIElement.ts
and Button.ts
. UIElement implements basically a Blank UI element that reacts to pointermove
, pointerdown
and pointerup
wrapped in an EventHandler class. Button then is a specialisation of UIElement, adding text, font, font size and font color. It will rely on UIElement to draw the base structure, the Button adds the text itself. When I have the code neater and working I'll post it to my fork so you can see it for yourselves
Sorry, was reading Actor wrong, might be able to rely on that for the drawing of the base element
This is the latest commit for the button addition. UIElement
is the thing being drawn in the visual test as Button
isn't finished yet. Button
is a specialisation of UIElement
which is itself a specialisation of UIActor
One point of feedback is that UIActor should already be propagating pointer events (except move, which is opt-in) and you can subscribe using button.on('pointerup', handler)
.
If that's the most common case (it probably is) then maybe just passing that handler could work in the constructor, rather than a collection/wrapper of handlers. Keep in mind due to #410 this will eventually look like:
new ex.Button({ x: 10, y: 10, onPointerUp: handler })
So it'll be cleaner anyway--and easier to pass in other pointer handlers that will shortcut to subscribing using on
.
@kamranayub @jedeen Check this branch out, using the ui visual test I am drawing a button that I've implemented taking into account #410 so let me know what needs changing, it's not finished yet, need to add some data manipulation for the Button
class and the UIElement
class.
@kamranayub @jedeen Any thoughts?
Haven't had time to look but I will when I get a chance
On Thu, Apr 6, 2017 at 9:45 AM Erik Onarheim [email protected] wrote:
@kamranayub https://github.com/kamranayub @jedeen https://github.com/jedeen Any thoughts?
— You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/excaliburjs/Excalibur/issues/749#issuecomment-292197191, or mute the thread https://github.com/notifications/unsubscribe-auth/AAiaa4vlKyXzIAPi42t0i0FglkG0WpBMks5rtPqLgaJpZM4LrzUL .
@PurityLake Please go ahead and issue a pull request for these changes. It will make it easier to track the differences and provide feedback. It's perfectly all right if a PR is a work in progress. Thanks for working on this feature!
Have to apologise for the absence, health issues but I'm back again. Gimme a day to reaquaint myself with the code I wrote and I'll make a pull request.
Any news on this issue? Implemented my own version but not happy at all with my own mess...
@jedeen Any updates?
It appears that there hasn't been any activity on this for a few months now. We'll prioritize this issue for the 0.14.0 Release.
Until then, if you're using TypeScript, you should be able to drop in the gist listed in the issue description above.
I'll get back to this after I finish both reacquainting myself with the code and finish that "good first issue"
This issue hasn't had any recent activity lately and is being marked as stale automatically.
Closing for now, we are moving towards an html first strategy for UI. More to come in the v0.30.0 release on first party HTML UI management in Excalibur