komodoopenlab / tecla-framework Goto Github PK

To minimize obstruction of the UI, the DPad should be removed from the center of the screen and arranged more discretely around the perifery of the screen.

Other suggested effects include fading out all HUD "buttons" with the exception of the one currently highlighted.

After this is done, the LatinIME class inside TeclaAccessJB should be made to extend the TeclaIMEService created as part of the tecla-as framework library as specified in https://github.com/idrc/TeclaAccessJB/issues/6.

The end result should be the possibility to install both TeclaAccessJB and tecla-as as a single app.

Will facilitate https://github.com/idrc/TeclaAccessJB/issues/9

The current highlighting approach - which focuses on detecting the UI element that will take keyboard input so it can be emphasized - presents too many inconsistencies to be useful for switch-based navigation. This is due to the fact that it is subject to the implementation of the full set of accessibility properties on every active element. Unfortunately, not even the most common built-in applications (e.g., Gmail) provide a complete implementation (e.g., it is not actually possible to use the keyboard to activate the email drop-down that appears on each email view).

Thus, it will be necessary to programmatically drive the highlighting, focus targeting and navigation of every node so switch users can interact with the device in a way that makes sense to them (e.g., active views with the same Y coordinate can be grouped for sequential scanning). Instead of tracking views, this will require tracking screen changes so that the user interface can be analyzed and the Accessibility Service prepared for navigating the new content as a whole.

This should be considered a blocker!

When home screen /launcher icons are grouped, clicking on the group explodes a small pop-up that does not trigger the event required to refresh the highlight.

Solving this bug likely involves finding the right kind of event that can be used to trigger a refresh. Alternatively, it may be possible that the pop-up is simply triggered by a visibility change rather than a screen change.

The file needs to be moved back to root.

This should provide additional control over, and easier access to, the functionality that is to be added to the built-in or any other IME.

The HashSet variable always holds either zero or one accessibility node, so there is no need to use HashSet.

The already running service crashes when disabled.

logcat (without any filters):
https://docs.google.com/file/d/0BzcVygR4_tDGM0xVTkt4bWxMWlU/edit?usp=sharing

This is needed to store the commonly used classes for the Tecla JB version.

Debugging interface was disconnected as part of the process of moving the touch interface out of the accessibility service

The circular dpad background currently renders as a gradient, which makes it distracting. A flat semi-transparent background should be used instead.

This will normalize the user experience for selecting and clicking across the entire device.

The description should contain the following:

"The Tecla Highlighter service emphasizes the screen elements that are selected to receive input from external devices. This makes your Android device easier to use with remote controls, keyboards and external switches."

Remember that this string should be added to the strings XML resource instead of being hard-coded.

One way to trigger the creation of the IME is to show a transparent overlay with a transparent edit box, which should force open the IME and create its service if it hasnt yet been created. Then we can track the IME onCreate method in the framework to show the HUD if the a11y service is running (is enabled).

Pending completion of the IME scanning code

Refer to the following screenshots posted in #60 .

The first screen shot is from Xperia Miro custom JB 4.1.2
the Second is from Galaxy SII generic 4.2

Logcat can be found here:
https://docs.google.com/folder/d/0BzcVygR4_tDGTERtWXNUYUY2M2M/edit?usp=sharing

A long-press is perhaps the best way to achieve this. It will facilitate testing and debugging by removing the need to navigate all the way to the accessibility service options to turn the HUD off.

During scanning, fade in only the highlighted button and fade out all other buttons.

Problem displaying the full overlay on smaller screens

An early version of the Tecla HUD is shown below. Should each control be simply an outline to follow more closely the typical HUD aircraft design?

This is the name that appears under accessibility settings. Remember that this string should be added to the strings XML resource instead of being hard-coded.

Name the folder "highlighter".

This instance of SimpleOverlay should only handle highlighting. Touch handling and debugging feedback can be implemented in separate instances of SimpleOverlay.

This relates to the top notification bar which currently can only be dragged down from the top. Implementation of this feature will occur until after the first release of the Tecla Access app for Jelly Bean devices.

From: KomodoOpenLab/TeclaAccess#178

Move all else to a separate thread where possible.

There should be a preferences screen associated with the Tecla Accessibility Service. For the purpose of this issue, it will be sufficient to add an "About" preference showing a screen that acknowledges contributions to the project once it is selected.

''input" is probably an appropriate name.

This should be done through a Tecla IME Service class inside the framework library. Eventually, the target IME will extend this custom class instead of the standard IME Service.

trace:

02-12 12:36:00.286: E/AndroidRuntime(17047): FATAL EXCEPTION: main
02-12 12:36:00.286: E/AndroidRuntime(17047): java.lang.ArrayIndexOutOfBoundsException: length=0; index=-1
02-12 12:36:00.286: E/AndroidRuntime(17047):    at java.util.ArrayList.get(ArrayList.java:306)
02-12 12:36:00.286: E/AndroidRuntime(17047):    at ca.idrc.tecla.TeclaAccessibilityService.onAccessibilityEvent(TeclaAccessibilityService.java:61)
02-12 12:36:00.286: E/AndroidRuntime(17047):    at android.accessibilityservice.AccessibilityService$1.onAccessibilityEvent(AccessibilityService.java:523)
02-12 12:36:00.286: E/AndroidRuntime(17047):    at android.accessibilityservice.AccessibilityService$IAccessibilityServiceClientWrapper.executeMessage(AccessibilityService.java:589)
02-12 12:36:00.286: E/AndroidRuntime(17047):    at com.android.internal.os.HandlerCaller$MyHandler.handleMessage(HandlerCaller.java:40)
02-12 12:36:00.286: E/AndroidRuntime(17047):    at android.os.Handler.dispatchMessage(Handler.java:99)
02-12 12:36:00.286: E/AndroidRuntime(17047):    at android.os.Looper.loop(Looper.java:137)
02-12 12:36:00.286: E/AndroidRuntime(17047):    at android.app.ActivityThread.main(ActivityThread.java:5039)
02-12 12:36:00.286: E/AndroidRuntime(17047):    at java.lang.reflect.Method.invokeNative(Native Method)
02-12 12:36:00.286: E/AndroidRuntime(17047):    at java.lang.reflect.Method.invoke(Method.java:511)
02-12 12:36:00.286: E/AndroidRuntime(17047):    at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:793)
02-12 12:36:00.286: E/AndroidRuntime(17047):    at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:560)
02-12 12:36:00.286: E/AndroidRuntime(17047):    at dalvik.system.NativeStart.main(Native Method)

The easiest to implement would be a long-press

is it intended?

The UI navigation and on-screen keyboard highlights should allow for custom colours to be used.

This bug is not currently a priority and should not be attempted until after the first release of the Tecla Access app for Jelly Bean. It has been transferred from its equivalent originally reported on the TeclaAccess project here: KomodoOpenLab/TeclaAccess#171

This is an example of how the Tecla highlight does not match the focused element. Perhaps the highlight is following the accessibilit and not the keyboard focus?

This issue is similar to #53

If highlights are not cleared when keyboard and/or accessibility focus is lost, then these highlights will be outdated and thus confuse or intrude on the user experience. Like in the following case:

The code for HUD scanning has been broken by the rework of HUD. The scan handler and HUD button activation need disabled. It will be rewritten after #80 is resolved.

The debugging, touch-based navigation gestures should be implemented in a separate instance of simple overlay so that the DEBUG=flag can switch it off completely.

This will also help make the code more modular preventing the touch methods from interfering with the highlighting methods.