So I've been making my way through the tutorials, and I noticed that there's not really a way to use the virtual keyboard on android right now? android/orxKeyboard provides Init/EventHandler/Exit routines, but there is no way to bring the keyboard up and down...
Since we're not using nativeactivity, we don't have ANativeActivity_showSoftInput. This means we'll need to call Java for this, probably from the main thread. Is there a code guideline on how to add Java functionality right now (in terms of structural flow)?
Comments
So again, I'm afraid you'll have to wait till next mid-week before getting an answer to that question.
When using a button as a toggle, several calls to InputUpdate/orxInput_IsActive manage to come through between the TouchDown and TouchUp events. Even if you try to click the button as fast as you can.
I've uploaded the keyboard-related changes into my orx fork. I tried to set up a new pull request for the keyboard files, but bitbucket seems to want to merge it with the one I made for the makefile, whereas I'd like to keep them separate. Is there a way to do that?
As for the orxInput_IsActive calls, I'm not entirely sure of what you mean.
Do you also check for orxInput_HasNewStatus() which allows you to know if the input's status just changed this frame?
The way it works, when using input, is that you can either test for continuous status (useful for long running actions such as moving) or for status switches (useful for toggles).
IsActive() == true -> the key/button/... is currently pressed (and could have been pressed for an unknown amount of time)
IsActive() == false -> the key/button/... is *not* currently pressed (and could have been in this state for an unknown amount of time)
IsActive() == true + HasNewStatus() == true -> the key/button/... has just been pressed this frame
IsActive() == false + HasNewStatus() == true -> the key/button/... has just been released this frame
After playing around further, I found that different keys on the soft keyboard behave differently (this is on an old HTC Thunderbolt, default keyboard in 2.3). For example:
- menu button: continuously sends KeyDown while being held, followed by a single KeyUp once let go. This behavior is well controlled by using IsActive/HasNewStatus combo.
- letters: instaneously sends Down followed by Up, even if the button is being held.
- arrows(dpad): waits until the button is let go then sends Down/Up back to back. (Opposite of what letters do)
The last two are very hard to catch, as the events are sent so close together. If you push the button enough times, eventually it is detected. I looked through orxInput for functions that may deal with this, but nothing caught my eye.
Some other observations about the Android keyboard:
Not all characters are available as a single Up/Down combination. Frequently, a button/character, such as " is represented by a nested Down, Down, Up, Up sequence where the outer button is shift, and the inner button is '. There are other scenarios that are possible along these lines as well.
As for the characters, the keyboard plugins are supposed to report them separately in unicode (UTF-8) format, via the orxKeyboard_ReadString() function. This function abstracts keys entirely as well as locale settings, allowing for text inputs.
All the separate key presses should be sequentially reported via the orxKeyboard_ReadKey() function, as well as the state query function: orxKeyboard_IsKeyPressed().
As for the Android specifics, once again I'm afraid we have to wait for lydesik.
I'm not sure we'll be able to implement orxKeyboard_ReadKey(), but ReadString() should be possible.
Just to make sure how it works...
The user code needs to call orxKeyboard_ReadString() in an Update() callback, and feed this string to an orxObject to display it.
When done I need to call orxKeyboard_ClearBuffer().
We'll probably need to add two orxAndroid_... functions to show and hide the virtual keyboard.
Any thoughts on this rom?
The ClearBuffer() should be called as soon as the user is ready to listen for text inputs, it shouldn't matter after being done as it's typically using a ring buffer internally and not expanding ad infinitum.
What is the best way to revert to parent or otherwise solve conficts in bitbucket?
Not sure in which state you are, but, after pulling, you might either chose to rebase your changes if possible, or simply strip them and start anew from the current version.
Any advice?
I looked at your bitbucket repo but that doesn't reflect your local one.
Do you use a GUI client for hg? I'd recommend TortoiseHg on Windows and there are a few alternative on other OSes, it usually makes the display of recent commits much more visual.
If hg status is blank, that means you don't have any local changes. If hg update doesn't do anything, it means you're already at a head revision. You can sync back to any revision with extra parameters to hg update (better look on the mercurial website, I don't know them by heart).
Worst case scenario, you can run a local hg server (hg serve) and I can sync it locally to see what's going on, after you give me the address.
Situation:
1. I fork orx in bitbucket, clone the fork locally
2. Make changes, push to fork
3. Issue pull request
4. Pull request denied
5. New changes are committed on top of pull-request code in orx
6. Now I cannot sync via bitbucket anymore
What I did to fix it:
1. locally, hg pull https://bitbucket/orx
2. hg merge (locally)
3. hg commit (locally)
4. hg push (to my fork)
What I would have like to have done:
1. Revert fork to main branch, in the process abandoning all of my changes (I have them saved elsewhere)
2. Update local copy to sync with orx tip
oh, how i hate source control...
Another option would be to pull orx into your local clone, update to that head (not yours), rebase your changes on top of this new head, then push to your fork.
Another one would be to enable the MQ extension which adds the strip command, strip your own local commits (before or after pulling from orx, doesn't matter), update to orx's head, re-add your changes.
As for the keyboard, I haven't followed the case closely those last couple of days, so I haven't much to say there.