theom

Members
  • Content count

    19
  • Joined

  • Last visited

About theom

  • Rank
    Member

Profile Information

  • Gender
    Male
  • Location
    Iceland
  1. Come to think of it, no they shouldn't because some, like text labels, can be used in the scene itself and need to ignore the mouse. Forget that I asked
  2. Shouldn't all GUI controls set isPointerBlocker = true in order to not interfere with the scene behind?
  3. theom

    Disabling GUI controls

    I took a quick look at the Control class and it uses the same method as option 2, but for other purposes. Probably not a problem though. I'll begin with the Button and see how disabling it meshes with the current code.
  4. theom

    InputText dead key support

    Thanks DK Documentation is done and pushed as a PR.
  5. What is your take on implementing a control disable feature? Some thoughts (child overrides a parent handler): Set a flag in the Control class and it and all children need to know about the flag and honor it. Set a flag in the Control class and return false from the parent handler. The child only needs to act on the return value from the parent but call order matters, i.e the child needs to check with the parent method before doing anything else. I have mainly used option 2 in the past but 1 as well and they both work well. My current needs are to be able to disable buttons, which is easy to implement specifically for the button, but I think it's worth the effort to make this available to all the controls.
  6. theom

    InputText dead key support

    Yes, it's true that making the virtual keyboard more configurable is a bit more work, but it doesn't look that bad. We just need to create different layouts for each country (new Create.. methods) and it's probably best to get the keyPressObserver to behave like a desktop keyboard regarding the special keys. That way the InputText can stay the same and do its thing.
  7. theom

    InputText dead key support

    I have a working version that uses an observable. I'll have to do some more testing and once I'm satisfied with it I'll send you a PR.
  8. theom

    InputText dead key support

    1. Exactly. I'll see how I can deliver the feedback that way. And thanks for the example. 2. I'm focusing on the desktop at the moment, but the virtual keyboard is something we need to look into eventually.
  9. theom

    InputText dead key support

    1. I first looked into using an observable but dismissed it because I wanted to return a value to the InputText key processing code at the point of the call to the modifier. I couldn't see how to do that using an observable. But let me mull it over a bit. 2. Yes. Are there more than one virtual keyboard?
  10. theom

    InputText dead key support

    I can put up a PR for you to review.
  11. theom

    InputText dead key support

    @brianzinn @Deltakosh It seems to me that we are talking about the same thing, i.e. re-use of the key modifiers. The way I have done this in InputText is very similar to what @brianzinn suggests, except I check for the presence of the callback: class InputText ... private _onBeforeKeyAdd: (target: InputText, key: string) => { add: boolean, key: string }; ... /** Sets the callback that's called before the entered key is added to the input text */ public set onBeforeKeyAdd(cb: (target: InputText, key: string) => { add: boolean, key: string }) { this._onBeforeKeyAdd = cb; } ... public processKey(keyCode: number, key?: string) { // Specific cases switch (keyCode) { ... case 222: // Dead this.deadKey = true; return; } // Printable characters if ( (keyCode === -1) || // Direct access (keyCode === 32) || // Space (keyCode > 47 && keyCode < 58) || // Numbers (keyCode > 64 && keyCode < 91) || // Letters (keyCode > 185 && keyCode < 193) || // Special characters (keyCode > 218 && keyCode < 223) || // Special characters (keyCode > 95 && keyCode < 112)) { // Numpad let add = true; if (this._onBeforeKeyAdd) { if (key) { ({ add, key } = this._onBeforeKeyAdd(this, key)); } if (!key) { add = false; } } if (add) { if (this._cursorOffset === 0) { this.text += key; } else { let insertPosition = this._text.length - this._cursorOffset; this.text = this._text.slice(0, insertPosition) + key + this._text.slice(insertPosition); } } } } What confuses me is how the virtual keyboard comes into this? Is all keyboard input, desktop and mobile, routed through the virtual keyboard?
  12. theom

    InputText dead key support

    Just to make sure we are talking about the same thing: I'm wondering where it's best to keep the various callback definitions the InputText can be configured to use. For example, for those who might want to use the Icelandic version of the dead key callback they can pick it up from this place and plug it into their instances of InputText; if they want to limit the input to only numbers they can pick up the number input mask and plug it in, etc. Sorry if this was obvious to you. Given this 'plugin' nature, does it make sense to keep the callback definitions in the InputText class (I assume you meant that class when you say textbox)? I was more seeing this as something maintained externally to the InputText which then could be built up over time to include several different keyboard "mappings" and input masks. Maybe have some directory structure like this in the controls directory: InputTextModifiers KeyboardMapping InputMasks Maybe I'm taking this too far here but to me it doesn't feel right to keep the callbacks within the InputText class. Or I misunderstood you
  13. theom

    InputText dead key support

    Any thoughts on where to put the modifiers/callbacks?
  14. theom

    InputText dead key support

    A dead key is a key that does not output anything when hit, but is used to modify the next key. For example, Icelandic has several characters that have a diacritic above them (á, í, é ...) and we use a dead key to enter those characters (dead key (diacritic) + a = á). What I did in the InputText was to keep the state of the dead key to enable the key modifier to act on it if it likes.
  15. theom

    InputText dead key support

    Here's what I've got so far. What I'm trying to achieve is to be able to very easily configure different custom key mappings outside of Babylon and to be able to switch between them at runtime. This is all done in a callback I give to InputText. I can modify the entered character and event prevent it from being added to the input. This enables me, for example, to easily add dead key support or to just allow numbers to be entered. I think this also solves the "input mask" case we talked about here: Here's an incomplete dead key handler: let input = new gui.InputText(); input.onBeforeKeyAdd = (target, key) => { if (target.deadKey) { switch (key) { case "a": key = "á"; break; case "A": key = "Á"; break; } target.deadKey = false; } return { add: true, key: key }; }; And here's a handler that only allows numbers to be entered: let input = new gui.InputText(); input.onBeforeKeyAdd = (target, key) => { let add = false; if (key >= "0" && key <= "9") { add = true; } return { add: add, key: key }; }; What I'd also like to do is to bundle a set of these key modifiers along with Babylon so user's can pick the ones they need but I'm unsure of the best way to do that (where to put them). Any ideas?