PIXI Input Elements

[Sebi]

Edit:

 

I have just pushed my plugin to github.

There are still many things to do as you can see in the contribution part of the read me.

 

However, you can just grab the plugin now, start working with it and then just grab the new version as soon as it's ready.

 

https://github.com/SebastianNette/PIXI.Input

 

 

I think this fits better here than in the other topic.
 
I'm currently working on input sprites for pixi and made quite some progress. The idea is to render input elements on the stage instead of fiddling around with real HTML tags. That means all those elements are completely rendered using pixi.
 


Demo: http://mokgames.com/playground/pixi.dom/

Feel free to tell me if you find any bugs and to post your suggestions.

I want to allow styling the inputs with CSS (optional) as well as supporting Bitmap Fonts for all the inputs.
After completing the select box I will also add checkboxes/radio buttons.

After that I would need to take a look at textareas. I do have a working script for scrollable containers, but applying it to a textarea might be more difficult.

[praneybehl]

Looks pretty good!

[sergkub]

It's useful, thanks.

[hubert]

Exactly what I need!

 

How do you instantiate the plugin? Is it going to be done the same way?!

[Sebi]

It's still not ready for public use. First I have to fix some bugs and other stuff.

All you will have to do is to load the js file. It will just attach to PIXI and is then ready to use via PIXI.Input, PIXI.Button and PIXI.Select.

e.g.:

 

var select = new PIXI.Select({   options: {    test1: "I'm a select box!",    test2: "Test 2",    test3: "Test 3",    test4: "Test 4",    test5: "Test 5"  },  text: {    font: "bold 12px Arial",    fill: "#000"  }});                    select.x = 50;select.y = 50;stage.addChild(select);

It will probably take a few days until I publish it on GitHub.

[hubert]

great. I started to implement my own Pixi plugin but your seems more smooth! Publish it on git hub! It could gain some traction! +1 for json configuration. i did it the same with my plugin! How are you planning to implement select method and inserting caret between the letters of the word?

 

Additionally I added a value property to the input element. Is it the same in your plugin?

[Sebi]

I'm not sure what you are talking about. Text selection and caret already work in my plugin.

[chg]

Tested your demo in IE11. Noted the following:

• Caret too small/short - should be at be as least as high as the font's ascenders and as low as the descenders
• Pressing backspace after highlighting text does not remove the highlighted text, a further issue is that the highlight is lost and the caret moved to the start of the visible text
• If the text is bigger than the control placing the caret before the left/right most letter visible letter and pressing the left/right key should scroll the text, it does not
• If the text is bigger than the control placing the caret before the left most visible letter and pressing backspace should delete the non-visible preceding letter, it does not
• Ctrl+X and Ctrl+C not working as expected (also be sure that on a Mac it's Command+[X/C/V] rather than Ctrl)
• With a drop down menu expanded, mouse of an option other than the current choice, now right click. Expected: rightclick should be ignored, or better should cancel the change (de-expanding the control, and making no change to the chosen option); instead the observed behaviour is the option under the mouse becomes the newly selected option displayed
• With a drop down expanded, pressing escape will move the highlighting from the option under the mouse cursor and the last value highlighted using the up/down keys while still expanded, or the current value if the up/down keys haven't been used since expansion. Expected: Control should be de-expanded and no change made
• Tabbing to a drop down control shows no visible indication that the control has focus. Furthermore pressing Enter does not expand the control
• Pasting text in an empty password field. Highlight some of the asterisks shown. Observed issue: the highlight asterisks disappeared spontaneous
• Double click or triple click on text in a text field. Expected behaviour: the current word or entire text should be highlighted, observed behaviour: no different than single click - the cursor was positioned at the location
• With more text in a field than can be shown all at once clicking to place the caret displays the flashing caret at the far right of the control until the mouse button is released, despite this being neither the previous location nor the current position of the mouse
• Clicking in the browser's address bar (or find search box) takes focus from the controls as expected, however clicking on the controls does not restore their focus, despite what is indicated by the flashing caret that appears on the clicked control if it is a text field
• If the text is bigger than the text field, attempting to move the caret with the keyboard outside of the visible area, or delete/backspace non-shown characters may cause the caret to show at a different location than typing will apply to
• Holding Alt and entering a character value on the numeric keyboard does not produce any characters
• If the default text to show when there is no text entered, is entered in the control, it is handled as if it were in that default state - eg. in the demo type "placeholder" and note that the text is cleared when clicked unlike say "Placeholder" or "placeholder "

[Sebi]

Thanks for your post, chg. Those bugs should be pretty easy to fix. Most of them seem to be selection/keydown related.

I already had some of those bugs fixed but I'm shortening the code atm and probably forgot to call a method.

edit:

Most of the issues above are fixed now.

[Sebi]

Can anyone test my inputs on mobile?

I haven't tested them yet and I can only test on android (kindle fire).

So I'm curious if those work across all devices.

[powerfear]

Can anyone test my inputs on mobile?

I haven't tested them yet and I can only test on android (kindle fire).

So I'm curious if those work across all devices.

 

Can't get them to work on ios8 safari, it just zoom around when i try to click something.

[Sebi]

Can't get them to work on ios8 safari, it just zoom around when i try to click something.

Hm, that's weird.

It shouldn't zoom around at all. Maybe that's because I didn't set that zoom meta tag.

I guess I have to take another look into event order for mobile devices. I guess there's something firing for mouse and touch events at the same time removing the focus on the selected element.

 

I will check this out on my android tablet.

Thanks for the report.

 

edit:

 

Apparently there are some keyboard issues where the focus event can't raise the keyboard.

I'm debating on 3 possible solutions.

 

1. Use a prompt if the keyboard doesn't show up. This works but it is blocking the code execution until the prompt is resolved.

2. Create a fallback keyboard with canvas. This would be drawn once, if no keyboard shows up, then saved in a renderTexture. This probably works too, but it has the disadvantage, that we can only support a fixed set of characters (qwertz/qwerty)

3. Place an invisible input field on top of the canvas. When clicked on the sprite, the input field will gain focus and trigger the keyboard. This is probably the worst of all 3 possibilites.

 

I'm not sure yet which way to go but I think it's possible to get this fixed somehow.

[Mat Groves]

This is looking really great Sebastian! So many peeps are gonna find this super handy

[Sebi]

Thank you, Mat

 

It still has some issues raising the keyboard on mobile devices. Apparently it's not enough to just call focus on an input element. 

I read that there are some webview settings to enable keyboard on focus, but that only applies to packed apps.

 

It might take a few more days until I push this plugin on Github, because I'm currently sick and can't work much.

[Daevid66]

Really nice! I fear that fully implementing the input components can be very time consuming (especially on all different devices) but you got a very nice start.

 

I tested on an iPhone 5, with ios 8.1 and noticed:

- tapping on the inputs doesn't bring up the keyboard

- tapping on the dropdown *does* bring up the keyboard

- possiby it would be nice to be able to use the default ios scroller for pickers (date/time/selects), but in that case you're probably better of with your DOM-Sprite

 

I would probably try to solve most of these things by creating hidden DOM-controls, and pipe focus/blur etc to enable the keyboard (But that may not work for cocoon developers).

 

Very nice work!

 

/David

[Sebi]

Thanks Daevid.

 

I guess I forgot to prevent the default behaviour on the dropdown. Or maybe I mixed it up with the Input element.

Makes me feel more confident to know that it is possible to raise the keyboard on ios.

 

Should be easy to fix.

 

About the layout for the dropdown and other elements:

It's not the intention to copy the look and feel of all devices. It's about creating the design yourself and have it look the same on all devices.

Since it's all drawn on the canvas you are able to design everything the way you want to.

[Daevid66]

Design of inputs: Yes, I appreciate this approach where you can get more control over the look of the components.

 

My suggestion to use a hidden input would have a lot of side effects. For example: when you focus on an date picker input you wont be able to see the stage anymore, since you will automatically be shown a full-screen spinner interface. On ipad you get a native spinner controller pointing at the input, which might be a bit funky if the input is hidden.

 

So if you are able to open the keyboard without a hidden input, that's probably a better solution.

 

/David

[Sebi]

I haven't used a date picker yet, maybe this could be solved by placing the input behind the canvas instead of offscreen.

To avoid the native date picker, you could always code one for canvas. It's basically just a box (like for all other inputs), with a mask and a text object inside it.

[hubert]

Please do not use any hidden inputs! It is a rabbit hole!!!

 

You wont be able to to use native wrappers like ejecta, completely misses the point of creating this plugin - no DOM elements inside pixi game. Hidden inputs sometimes trigger themselves in mobile browsers! FOR THE LOVE OF GOD DO NOT USE THE HIDDEN INPUTS!!! I BEG YOU!!!

[Sebi]

I don't use ejecta and don't know anyone who does. There is no point avoiding the DOM for me.

If you want to completely avoid the DOM for inputs, you could just create an image for your input fields and add a prompt dialog on click/tap.

 

It's not hard to prevent the default/to blur an input if it accidentally gained focus.

So I don't see an issue there.

 

If you pass me some variables to test against, then I sure could make prompt the default behaviour for those wrappers and allow the hidden input on non wrapped versions.

[Sebi]

Update:

 

I found out how to raise the keyboard on mobile. 

This plugin will be available on GitHub this weekend.

 

Can someone pass me a list of wrappers that don't support HTML elements + the variables to check against?

I've never used a wrapper before, so my knowledge about those is quite limited.

 

Afaik Crosswalk runs a stripped chromium which should allow HTML elements, right?

Cocoon doesn't support HTML elements?

 

I already know that there is "navigator.isCocoonJS" to check for cocoon. What about cocoon prompts? I heard that they have their own prompts? Are those blocking?

 

What about other wrappers? phonegap/ejecta/others?

[Daevid66]

Sounds great!

 

I' don't use any wrapper except phonegap and thats a normal webview so no problem there. If you make the sourcecode available i don't see why not the people using custom rendering engines could add their needed functionality themselves, as long as you make it somewhat easy to see what events needs to be handled (focus/blur/change/keyup/keydown?).

 

/David

[trueicecold]

ejecta and cocoonjs don't support DOM at all (cocoonjs supports "canvas" only). cocoonjs DOES support elements, but only when not in "canvas+" compilation mode.

Phonegap and crosswalk are fully fledged browsers (Phonegap uses the default device browser, while crosswalk uses chromium).

[Sebi]

Yea, I hope that some people will help me to improve the plugin when it's on GitHub.

Currently adding support for PIXI v.2

 

It's still far from being optimized but it does work to some degree already - at least works fine for desktop and half done for mobile.

 

Tomorrow night, I will push it to GitHub, so that you guys can start using it. Don't worry too much if not everything is working 100%, the plugin will be worked on and the bugs will sooner or later be fixed.

[Sebi]

I have just pushed my plugin to github.

There are still many things to do as you can see in the contribution part of the read me.

 

However, you can just grab the plugin now, start working with it and then just grab the new version as soon as it's ready.

 

https://github.com/SebastianNette/PIXI.Input