On a Chromebook, the keyboard may be present but hidden (not available for
use) because the device is flipped around in Tablet mode. In this case we want
the soft keyboard to be available. This change also hides the soft keyboard
button if the hardware keyboard is available, since it doesn't do anything.
Fixes#13138.
This is a placeholder implementation that preserves the current
behaviour (asusmes a scaling of 2). But since the Android API
provides a way to get an accurare device-dependent scaling, this
should probably be used.
In CustomKeyboardView for mKeysDownCodesSet ArraySet
Also enable the option -Xlint:unchecked (within build.gradle) to show the unchecked conversion warnings on compile
For testing purposes and feedback mostly
Also set the level for debug to 3, to get messages related to native resolution and scaling from the new hidpi gui scale code
If the user keeps one finger down they can still generate new right click events
Previously in multitouch events, we supported only one right click event starting from one finger down.
The user subsequently had to restart the multitouch mode for another right click; hence lift all fingers
from the surface and start again.
New behavior allows user to generate a new right click while holding one finger down and putting down and lifting a second finger.
I think this is more intuitive and user friendly, although it might require some getting used to, if one was accustomed to the old behavior
Also added various comments to document behavior.
Minor JE_MULTI event (Fix concerned bad brackets code in the events.cpp for JE_MULTI (multiple fingers held down)
) fix and comments for mouse behavior
Allow onHover to catch the mouse events instead of OnTrackBallEvent()
Also the "system back" button is ignored for the Trackball too because we treat it as mouse in isMouse(e) check
Add multitouch handler class. Handling and early filtering of multitouch events is moved in the new class.
Crash reports mentioning this exception came from Play Store
stacktrace looked like the following:
java.lang.RuntimeException:
at org.scummvm.scummvm.ScummVM.run (ScummVM.java:144)
at java.lang.Thread.run (Thread.java:919)
Caused by: java.lang.IllegalArgumentException:
at com.google.android.gles_jni.EGLImpl.eglGetConfigAttrib (Native Method)
at org.scummvm.scummvm.ScummVM$EglAttribs.<init> (ScummVM.java:339)
at org.scummvm.scummvm.ScummVM.chooseEglConfig (ScummVM.java:440)
at org.scummvm.scummvm.ScummVM.initEGL (ScummVM.java:180)
at org.scummvm.scummvm.ScummVM.run (ScummVM.java:133)
Different platforms have different levels of support of encodings and
often have slight variations. We already have tables for most encoding
with only CJK missing. Full transcoding inclusion allows us to get reliable
encoding results independently of platform. The biggest con is the need for
external tables encoding.dat.
It removes a duplicate table for korean in graphics/korfont.cpp
Location is directly inside the app's internal storage folder
I am not sure if I did this by mistake, because I think it would be better for it
to be under the subpath ".config/scummvm" which we do create earlier.
However, this *mistake* makes the file easier accessible via the "LAN" feature,
since otherwise the user has to also enable the "show hidden files" option
and navigate specifically to the ".config/scummvm" subpath
to set it as root for the LAN server, in order to see the scummvm.ini.
In the current way, the user simply has to set the internal app folder
as root for the LAN server.
This can happen during development - shouldn't happen for any official release,
but even if it does let's just assume versions are different and default to
upgrading the config.
There were issues with manually aligning apks possibly due to upgrading gradle
The manual zipalign even though running with no fail message, would NOT align the apk properly anymore.
Command to manual verify alignment of an apk is:
Android/Sdk/tools/bin/zipalign -c -v 4 release/ScummVM-release-unsigned.apk
And also add some code to load and use the keyCharacterMap of the source device for the event
It is unclear if getUnicodeChar() already does this (loads the keyCharacterMap of the source device.
If it does, then the extra code is redundant.
