brianzinn Posted August 31, 2018 Share Posted August 31, 2018 Hi,. I'm trying to have a virtual keyboard on one plane and input text on another: http://playground.babylonjs.com/#WIACBP I can see that the keyboard.connect(input) is operating on the focus() and blur() of the inputText and hiding the keyboard, which is occurring when another plane is selected (clicking on the keyboard). Just wondering if I am missing something obvious or if somebody has tackled this before and maybe we could add it to framework. In other words, in the playground I would like to click more than one key in a row Thanks. Quote Link to comment Share on other sites More sharing options...
Guest Posted August 31, 2018 Share Posted August 31, 2018 That is DEFINITELY a problem Do you want to tackle this problem? (pretty please? :D) Quote Link to comment Share on other sites More sharing options...
brianzinn Posted August 31, 2018 Author Share Posted August 31, 2018 OK, I didn't miss anything obvious! ? I think I can work backwards from the input used on connect for a solution - should be fun to fix! Quote Link to comment Share on other sites More sharing options...
brianzinn Posted August 31, 2018 Author Share Posted August 31, 2018 @Deltakosh looks like the keyboard is meant to work with only one input. I was thinking that it would work for multiple, but with one is maybe easier: https://www.babylonjs-playground.com/#S7L7FE#12 I thought it could be connected to a group of inputs and would show when one is selected. That PG can actually send virtual keyboard keys to the wrong input. Did you want it working with multiple inputs, or is that not desired behaviour? Quote Link to comment Share on other sites More sharing options...
brianzinn Posted September 1, 2018 Author Share Posted September 1, 2018 actually, multi-input same keyboard looks easy enough with this monkey patch ? (needs at least disconnect(...) cleanup) https://www.babylonjs-playground.com/#S7L7FE#13 Will try look at the original issue of different planes next week. Quote Link to comment Share on other sites More sharing options...
brianzinn Posted September 2, 2018 Author Share Posted September 2, 2018 I did a PR for the multiple input. Now, for having a keyboard and input on different AdvancedDynamicTextures, how about a PR something like this? http://playground.babylonjs.com/#WIACBP#2 Feels kinda hacky, but it's the most surgical code in one if branch. Can have the InputText also track the keyboard it is attached to for scenarios with multiple keyboards and different textures, but I feel that is not an issue based on this not coming up before with a single keyboard (and can be added after). This feels hacky because: 1. .parent.parent depends on how rows are added (keyboard.addKeysRow) 2. emissiveTexture depends on CreateForMesh implementation details So, those make this change brittle, but at the same time at least CreateForMesh brittleness is encapsulated in the same class. It still feels like an improvement and can address the other issues separately. What do you think? Quote Link to comment Share on other sites More sharing options...
Guest Posted September 4, 2018 Share Posted September 4, 2018 Well done (as always) and merged! Thanks a ton! Quote Link to comment Share on other sites More sharing options...
brianzinn Posted September 4, 2018 Author Share Posted September 4, 2018 Great. I still see it as an open PR? Let me know about the PG above what you think of it as a way to have a keyboard on a different texture. - it doesn't feel right, but I didn't see any cleaner way to do it. Essentially, focus is maintained if an InputText currently has focus and a keyboard button was clicked on another plane. So, I think we still want to make sure that key pressed on the keyboard is the same connected keyboard, but just making sure that is a good method (even though it's brittle) and then I can make a new PR. I don't want two PRs at the same time as I think github will attach commits to other PR automatically. I'll update What's New with both PRs at the same time. Thanks. Quote Link to comment Share on other sites More sharing options...
Guest Posted September 4, 2018 Share Posted September 4, 2018 I agree. I will work on this one as it seems a bit deep into the system I'll send a fix asap! Quote Link to comment Share on other sites More sharing options...
Guest Posted September 4, 2018 Share Posted September 4, 2018 Well..Asap was probably a bit optimistic :)D This is a complex problem. It is not obvious how to fix that easily...Need to give it more thoughts..Any idea on your side? Quote Link to comment Share on other sites More sharing options...
Guest Posted September 4, 2018 Share Posted September 4, 2018 Ok I think I have a fix: https://github.com/BabylonJS/Babylon.js/commit/7ab7cfdd45898f9ceb118906f3a16a006c0ff111 Thoughts? brianzinn 1 Quote Link to comment Share on other sites More sharing options...
brianzinn Posted September 5, 2018 Author Share Posted September 5, 2018 Yes, Great way to do it! That will survive changes to everywhere that I had mentioned. The only thing I would change is to not have a keepFocus(...) method, but instead return an array of controls that a FocusableControl would like to maintain focus with. let keepFocusControls : Control[] = inputText.keepsFocusWith() It acts like a property, but I have it as a method because it's return value will change as it is connected/disconnected. My mind always wants to go the other way, probably from too much TDD. So, for InputText when not connected keepFocusControls would be []. When connected it would be: [this._connectedVirtualKeyboard] Then all code in keepFocus moves to the AdvancedDynamicTexture and InputText doesn't need to know about pointerId, _host, _lastControlOver, etc. I think all the private accessors is a sign that the responsibility is on the wrong side. Don't worry, I'm not planning on having multiple keyboards attached to same InputText, but it would be more possible like that and easier to add other FocusableControls without internal knowledge of AdvancedDynamicTexture. Quote Link to comment Share on other sites More sharing options...
brianzinn Posted September 5, 2018 Author Share Posted September 5, 2018 The opposite would be givesFocusTo(). So, there could like an HTML "for" attribute on labels (TextBlock)... Would be a useful addition to the new Selector, but auto-select is interesting as you may need some context...! https://www.w3schools.com/tags/tryit.asp?filename=tryhtml_label Quote Link to comment Share on other sites More sharing options...
Guest Posted September 5, 2018 Share Posted September 5, 2018 Good point! I'll fix that Quote Link to comment Share on other sites More sharing options...
Guest Posted September 5, 2018 Share Posted September 5, 2018 Done: https://github.com/BabylonJS/Babylon.js/commit/12e7d75b89785ba63e87de4eacc4820485ac6ff4 brianzinn 1 Quote Link to comment Share on other sites More sharing options...
brianzinn Posted September 6, 2018 Author Share Posted September 6, 2018 You are a magician! Quote Link to comment Share on other sites More sharing options...
Guest Posted September 6, 2018 Share Posted September 6, 2018 good team work I would say! Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.