AndroWish Bugs

List of AndroWish Bugs 11 Jan 2014

The "Metropolis" edition:

package require Thread

cannot find symbol "Tclthread_Init": Symbol not found: load_library[1109]: Library 'libtclthread.so' not found

Fixed starting with the "James Joyce" edition 2014-01-13.

jima 2014-01-13

According to a report from rmax in the Tcler's Chat:

wm overrideredirect . 1

kills AndroWish.

chw 2014-01-14 confirmed for all versions of AndroWish. "adb logcat" reports a SIGSEGV in the X11 emulation code for XDestroyWindow. This bug will be fixed soon, hopefully.

MG Not sure if it's a bug (my experience with Android devices is limited to 0, and so far I've only played in the SDK's emulator), but

  info nameofexecutable

returns an empty string - assuming it's possible to exec an APK to run it, it would be handy if it returned a path (or whatever is needed for said execing) instead.

chw 2014-01-14 wouldn't call this a bug. Process (application) startup on Android is quite different from traditional UN*Xen. It is not possible to start an APK by means of exec(2) or exec(n). However from within AndroWish it is of course possible to use exec(n) to spawn a normal UN*X process (e.g. "ps"). When you need information about AndroWish's execution environment there's hopefully everything available in the "env" array:

   env(EXTERNAL_FILES)    app specific directory on external storage

   env(EXTERNAL_STORAGE)  path name of external storage (could be internal SD card)

   env(EXTERNAL_STORAGE2) path name of external storage (real external SD card)

   env(HOME)              app's home directory (internal storage)

   env(INTERNAL_STORAGE)  app specific directory on internal storage (identical with $env(HOME))

   env(LANG)              system language

   env(LD_LIBRARY_PATH)   load path for shared libraries including app specific directory

   env(OBB_DIR)           on some Android versions extra stuff bundled with the app

   env(PACKAGE_CODE_PATH) path name of the app's APK

   env(PACKAGE_NAME)      package name where the app's main class comes from

   env(PATH)              path for exec(n) including app specific directory

   env(TMPDIR)            path name for temporary files

For the structure of an APK please see http://en.wikipedia.org/wiki/APK_(file_format )

The "assets" directory from the APK is "mounted" on application startup using the built-in virtual ZIP file system of the Tcl shared library. This is where all Tcl library code (and possibly your application Tcl code) has been bundled at build time (e.g. /assets/tcl8.6, /assets/tcllib1.5 etc.) The entire APK is mmap(2)'ed on application startup, thus the cost for accessing the files under "/assets" is decompression time only. Parts of the APKs "lib" directory (mostly architecture specific shared libraries) are copied to internal device storage at installation time of the APK. That is the reason, why all extension shared libraries are kept below "lib" and not "assets".

MG just noticed a couple of things:

1. tcl_platform(pathSeparator) is set to ":" not "/"
2. Running the latest AndroWish on the official Android SDK emulator, the cursor keys aren't working (no <KeyPress> binding fires for them at all). Not sure whether the problem lies with AndroWish or the emulator, though.

Other than that, everything seems to be working perfectly so far. Thanks for all your time and effort on it.

RS pathSeparator is correct on Unixes with ":". The question is how elements of $env(PATH) are separated,

 C:\bin;D:\bin

or

 /bin:/usr/bin:/usr/local/bin

MG D'oh, my mistake - confused it with file separator. Thanks, Richard.

ramsan: these two commands give me problems:

  package require img::png
  package require treectrl

mh2 26.01.2014, when I run a big tcl program (impress.tcl from [L1 ] sligtly modified for tk8.4), on my cheap tablet with 256MB RAM and android 2.3.3, than:

1. with androwish 8.4, impress.tcl works perfectly
2. with androwish 8.6, impress.tcl crash (android's oom killer kills it or something else?)

is androwish 8.6 much more memory hungry than 8.4 ??? if it is so, than may be 8.4 line of androwish should be continued ???

chw 2014-01-26 turned out to be a SIGSEGV in the Xlib emulation, please refetch the "Leningrad" edition, should work now.

ES - 2014-02-09 12:19:44

Wow, fantastic response - confirm that "Jules Verne" fixes the Bluetooth bug under Android 4.0.3. Thanks!

MG I just built the HelloTclTk example app on Windows using Eclipse from the Android SDK, but the resulting file fails to load, saying it can't find libSDL2.so - full log at http://pastebin.com/LRsWg3v0 . I haven't gotten around to firing up a Linux VM to try the other buildtools yet.

chw pretty sure your build environment is not the culprit. Where on your device is libSDL2.so located when you install the latest AndroWish-debug.apk? That's most likely the problem. Unfortunately, the HelloTclTk Java code has /data/data/lib/tk.tcl.wish/lib hard coded as the path where it expects the AndroWish native runtime. And this takes places in a static initializer where no full Android application context is established.

chw 2014-02-11 16:10+0000: please refetch the ZIP and the APK files. I hope it is fixed now.

GCS 2014-02-15 Galileo Galilei has a problem with the new SQLite3:

package require sqlite3
attempt to provide package sqlite3 3.8.3 failed: package sqlite3 3.8.3.1 provided instead

The trivial workaround in a script is to use catch, but thought this should be reported.

Eppur si muove! chw 2014-02-15 18:58+0000: thanks, should be fixed now.

GCS 2014-02-22 The Heinrich Hertz files do not seem to be on the server

chw 2014-02-22 15:39:47+0000: should be fixed now.

Uli 2014-03-02 13:57 Androwish containing Tk8.6 crashes when you type in lower . ! Androwish containing Tk8.4 is ok!

chw confirmed for all my devices. Bug must have been invented in the 8.6 port. Fixed in Pioneer 10 edition as of 2014-03-03.

NN 2014-03-07 (Pioneer 10): accelerator values seem to be wrong reported by virtual event <<Accelerometer>> %s is 1 or 2 or 3 (axis) -> ok, but values are e.g. 200, 32000, 212. I would expect e.g. 0.2, 9.8, 0.3

chw 2014-03-07: not a bug, see updated AndroWish: Documentation. In the SDL library the accelerometer is handled like a joystick with 3 axes. The values are reported as signed shorts {-32768...+32767}.

Superlinux - 2014-03-08 18:18:08

command checkbutton exits. command ttk::checkbutton does not exist. On the desktop, latest ActiveTcl this command exists.

JM - 2014-03-15

Looks like extension .tcl is always added to the file selection dialog from the console's menu File>>>Source.

For example, I was trying to source a script named "blt", and I am always getting the error message saying that "blt.tcl" does not exist, while the name is just "blt" without any extension. Of course, you can source it from the console but I should be able to source a file without extension with the dialog...

chw 2014-03-16: yes, that is a misfeature (or even bug?) of the file selection dialog on all UN*Xen including Android. I'll try to fix that in a later edition of AndroWish, however IMO you should file that bug report for Tk in general.

JM It was really a very minor thing, but now, with the "The Dark Side of the Moon" edition, I cannot see any file to source with the fileSelection dialog...I see the directories, and the file that I want to source is there of course, it is just that is not listed anymore...

I am very happy with the Icon though ;)

chw 2014-03-25: oooooops! I've messed the file selection up. Will fix it soon. And again JM thank you for the Icon.

Superlinux - 2014-04-01 09:09:54

I had a crash of AndroWish ("The Dark Side of the Moon" edition, 2014-03-24) when I installed it on Android-x86 4.4 RC1. get it here . Crash report here: open report here

PWE - 2014-05-12

I tried to run the tkgamepack.kit on android, and got errors. A closer look at the problem showed that a "package require Tk" in a slave interpreter causes an error in androwish. Other tclkit programs and wish do not give an error.

  set s slave
  interp create $s
  $s eval {
    package require Tk
  }

chw - 2014-05-12

There's a similar entry in AndroWish Questions. The reason is the missing pkgIndex.tcl file in the /assets/sdl2tk8.6 folder (grrrr, took months to find this out :-(. This will be fixed in the next edition of AndroWish.

escargo - Does this mean that the reporting of the error was not sufficiently specific enough for you to be able to tell what the true underlying error was? If so, does that constitute a bug in the error reporting? (I would think so. I really hate the loss of information that happens in some software where a specific error is encountered but only a vague error message results.)

chw - No problem with the reporting. My problem is that I've stumbled over this months ago but missed the missing pkgIndex file and had the wrong impression that it could be related to the VFS mount of the /assets folder of the Android APK.

OxFEEDBACC - 2014-05-18 10:46:51

On my Motorola Moto G (physical display size 1280x720), AndroWish's display (I think I've read it uses some sort of X server?) seems to think it is bigger than it actually is.

As far as I can evaluate, this is not a bug of AndroWish, however. borg displaymetrics properly reports 1186x720 or 720x1184 (plus soft buttons, each).

The point seems to be that the Moto G's display is classified as MDPI with only 526x320 pixels resolution; so obviously the X server examines the display size by the display's getRealMetrics() method, but later on only the classified display resolution as returned by getMetrics() is used (compare the screenshot).

The fix I finally found, after some days of fighting with this issue, was to acquire a bitmap with the real metrics, associate it to a custom view component, and draw the bitmap in this component's onDraw handler.

(full resolution image here )

chw - 2014-05-18 Trying to catch your findings (without a device with similar behavior) what is needed to get things proper? Would that help in AndroidManifest.xml:

  <!-- Disable screen compatibility modes -->
  <supports-screens
     android:smallScreens="true"
     android:normalScreens="true"
     android:largeScreens="true"
     android:xlargeScreens="true" />

And BTW did you succeed in rebuilding AndroWish from sources?

OxFEEDBACC - 2014-05-19 well no... i just downloaded the AndroWish sources, and read that the NDK is required --- I think I can do without those steps. Thanks anyway

BTW, since changing the AndroidManifest.xml would require recompilation, I don't know if that would help.

BTW 2, while trying out how to include screen shots (still didn't figure how to properly scale them (and yes, I've looked at pg. 14 )), i forgot those of AndroWish, as it shows up on the Moto G. (Maybe I just got the wrong figure and everything is as expected? But can't be... I can't even reach the scrollbar without moving the window)

(full resolution images here: startup , portrait , landscape , landscape after dismissing keyboard .

chw 2014-05-21: More and more am I convinced that everything works as expected. We have the console made up of a default text widget having 80 columns by 25 rows using the DejaVu Sans Mono font at 8 points (1 point = 1/72 inch). That makes for the console a real world estate of about 7 centimeters in height and (since the character width is smaller) about 13 centimeters in width. Sure that is more than the Moto G's display's area, so you cannot see the console in its entirety. But you can change either the console's font or the console's geometry in your ~/.wishrc. And no, I will not change the AndroWish behavior in this regard, since we already had some opposite complaints 3 month ago about requiring a microscope due to font sizes.

OxFEEDBACC 2014-05-21: Okay, then it was just about my expectation to see the window adapting to the screen size. > And no, I will not [...]

And no, I wasn't even considering to argue about preferences ;-) that's what *rc files are for... thanks for your time.

YS "encoding names" gives me only "utf-8 X11ControlChars ucs-4 ucs-2be identity unicode iso8859-1". Why don't you include other encodings? Hmm, I see all encoding files in encoding dirs, but observed behavior is quite strange: "source -encoding" works correctly, while using "fconfigure -encoding" produces garbage (but this depends on file extension?)

Create this file in cp1251 and save as a.ini and a.tcl:

set a "что-то по-русски"
set fd [open [info script]]
fconfigure $fd -encoding cp1251
gets $fd line
close $fd
set b [lindex $line 2]
button .b1 -text $a
button .b2 -text $b
grid .b1 .b2

Then this exposes the bug:

source -encoding cp1251 a.ini 

chw 2014-05-23: the problem with encoding names is most likely related to globbing in a virtual file system (the mounted APK file). I'll try to fix this. Regardless of the encoding names the encoding files are there and can be used.

YS 2014-05-23: Did you try the script? Are different texts displayed in buttons?

chw 2014-05-23: Tried it, both buttons show the same text. I've called that file a.tcl and source'd it with source -encoding cp1251 a.tcl. Where is the problem?

YS Nowhere. It was caused by interaction with tcllib's "inifile" package rewriting file in incorrect (non-system) encoding, I didn't recheck. Sorry to confuse you. :(

YS Also, trying to use usbserial I've discovered this bug:

set fd [usbserial [usbserial]]
fconfigure $fd -mode 

> 19200,n,8,1

fconfigure $fd -mode 19200,n,8,1

Gives error that 'data' value is invalid.

chw 2014-05-23: in fconfigure -mode you should specify baud,parity,data,stop (not baud,data,parity,stop).

YS That's what happens when copying from memory. :( Sorry about that, I've fixed the example. But my point is that I'm passing the value returned by fconfigure into fconfigure, It should work (and works on other platforms). This is more obvious:

fconfigure $fd -mode [fconfigure $fd -mode]

Gives this: "bad value for -mode date: should be 5, 6, 7 or 8"

chw 2014-05-23: confirmed, fix is WIP.

YS 2014-05-23: One more bug for you. ;) I can write to file in pwd using open, but:

file copy a.txt b.txt

complains that I'm not owner.

chw 2014-05-23: Please provide a more precise test case. What was the current directory?

YS 2014-05-23: I mean this:

set fd [open a.txt w] ; puts $fd a ; close $fd ; #Works ok
file copy a.txt b.txt

gives: error copying "a.txt" to "b.txt": not owner

chw: I see, that happens when run on the external or internal SD card (e.g. /storage/sdcard0). It is caused by Android's permission system and usage of supplementary group ids. The fix for Android will be to relax error reporting in the file command when errno is EPERM on the chmod() and/or utimes() system calls. For file copy the behavior will not be exactly as on normal UN*X platforms, i.e. the exact permission and modification/access time stamps of the destination file cannot always be copied.

YS 2014-06-02: Trying to use usbserial after your fixes I've found these bugs:

I can't read anything from usbserial (nothing returned from read, gets or fileevent readable).

Looks like there is output buffer length setting bug:

puts -nonewline $fd "12345678"
> "12345678" comes from the port to the other side.
puts -nonewline $fd "aaa"
> "aaa45678" comes from the port to the other side.

I wonder if you actually have any usbserial device to check these?

chw 2014-06-02: using a converter with a PL2303 chip I can confirm the output bug (will be fixed soon). However, with this setup I have no problems reading data.

YS 2014-06-03: I'll see what chip is in my converter... Do you use nonblocking mode? Does [fileevent readable] work for you? I see that there is no -timeout option in AndroWish's fconfigure, so it seems that using nonblocking mode becomes a must for real serial communication.

BTW, how your device (AndroWish) reacts if you disconnect converter when port is open? On my device, AndroWish usually just hangs.

chw 2014-06-04: Since usbserial is not quite a POSIX tty there's no way to support fconfigure -timeout. So when using fileevent it is required to use fconfigure -blocking 0. That is working in my setup when the read callback procedure uses eof and fblocked appropriately. Regarding disconnects I've observed similar problems. It seems that one of the two Java threads dealing with the USB transfers goes in an endless loop. I'll try to fix this soon.

YS 2014-06-03: One of converters I've got also has PL2303. I've retested reading on it, and it works. Also I've noticed that puts actually always outputs 256 bytes to port, sent data followed by 0x00's.

GCS 2014-06-18: [borg isspeaking] always returns 0

On my Galaxy Note 3, running Alan Turing under kitkat 4.4.2, both speaking and speech recognition work well, but I cannot set up a conversation because I can't tell when [borg speak ...] completes. As a workaround, I can put a human in the loop and require a keypress to indicate that the app should start listening for the next vocal input, but a hands-free mode would be nice.

chw 2014-06-18: not much I can do regarding detecting when TTS is over than calling some Java stuff on Android's side. But OTOH what do you understand exactly as "hands-free mode"? And what would be required to make Tcl/Tk (plus some AndroWish stuff) hands-free? It could possibly be helpful if you would provide a code snippet to illustrate your intention.

GCS 2014-06-19

Below is a snippet of the code, which I execute in namespace ::Eliza. I removed most of the GUI stuff, leaving only a bit to show how I use the <App> key to have the code ask for input. In the desired hands-free mode, Eliza would ask me to state my problem, I would reply, she would "give advice," I would comment,.... Having to press a button to indicate I want to talk is not terrible, but I think it would be geekier if it were pure conversation.

BTW, the rest of Eliza's code in in https://wiki.tcl-lang.org/36981

# Say something, check once a sec for end of speech and listening, then ask for vocal input
    variable islistening 0
    borg speak "Eliza will see you now. Please state your problem."
    while 1 {
        after 1000
        if {![borg isspeaking] && ! $islistening} {
            getinput
        }
    }
# In hands-free mode the following is never executed. Where [borg isspeaking] does not work, change [while 1] to [while 0] above
    focus .eliza.t
    bind .eliza.t <App> ::Eliza::getinput

# Start speech recognition and wait for callback
proc getinput {} {
    variable islistening 1
    borg speechrecognition {} processspeech
    return
}

# Use data from speech recognition to compute the next thing to say and say it
proc processspeech {retcode data} {
    variable islistening 0
    array set recog $data
    set input [lindex $recog(android.speech.extra.RESULTS) 0]
    set response [response $input]
    borg speak [string tolower $response]
}

chw 2014-06-20: thanks, I see. During review of the C code implementing borg isspeaking etc. I've found a bug which safely suppresses the proper return code. It will be fixed soon.

chw 2014-06-21: The "Manu Chao" edition (2014-06-21) should fix all speech issues now. Consequently, I couldn't resist to adapt the Eliza from this Wiki to the new speech recognition features and copy her as /assets/sdl2tk8.6/demos/android_eliza.tcl into the AndroWish package. Updated documentation on borg speechrecognition follows soon on AndroWish: Documentation.

GCS 2014-06-26: Thank you for the fast response. It took me a couple days to get back to the project, and then a while to get my code working, but I have now verified that Manu Chao works properly, allowing an AndroWish app to converse with the user. I will soon post some code on my Classic Eliza wiki page.

AM - 2014-07-04 12:54:26

Got my first app working on my Cubot GT99, but the Checkbuttons and Radio Buttons are both tiny, althogh the text is the expected size. The screen resolution on the phone is 1280x720.

AM - 2014-07-04 13:19:37

chw 2014-07-06: should be better now with the "A Hard Day's Night" edition (2014-07-06) at least for devices with 140..200 dpi screen resolution. Other option is to use e.g. ttk::radiobutton with the default theme.

AM 2014-07-08: yes, it is much better, may be not yet perfect. My device resolution is 320 dpi which may be the reason.

Superlinux - 2014-07-22 16:11:32

Using image of Android-x86.org 4.4 RC1 , AndroWish version 2014-06-21 Manu Chao does work.

After updating to AndroWish version 2014-07-06 A Hard Day's Night all I can see is a black blank screen.

adb Logcat gives this error: libEGL === called unimplemented OpenGL ES API

The reason I concentrate on this version of Android is because the emulators of the SDK , the AVD's that's, do NOT support Bluetooth. Android-x86.org distribution can be run on VirtualBox. So this can give full system support. Also not everyone there is going to buy another tablet or another phone just to program. let's make this Android distribution the standard test environment.

JM 8/9/2014, Whenever I install a new Androwish version, my .wishrc gets deleted from the config-startup path. It is not a big deal, but it would be better just leaving it there.

r0lZ - 2014-08-10 06:50:40

Great work! I'm very happy to see Tcl/Tk on Android. Thanks!

Some bugs I've discovered:

1. Launching a tcl script from the file manager doesn't work. I see only a toast message telling that "the app is not installed". Similarly, I see the same message when trying to launch a shortcut created with "borg shortcut add". Of course, AndroWish is installed and working.

2. When a toplevel is in full screen mode (with "wm attributes .win -fullscreen 1"), its size is correct in portrait mode (768x986 on my Medion tablet), but wrong in landscape: 1040x768 instead of 1024x730. Therefore, the right and bottom parts of the window are hidden. "winfo screenwidth ." and "winfo screenheight ." return the right screen dimensions in portrait and landscape modes.

3. Selecting text in the console doesn't work well. The selection is systematically cleared after 1 or 2 seconds, and before the user has had a chance to copy it to the clipboard.

4. Not sure it's a bug, but currently, there is no way to know that a script is running on Android with the tcl_platform() array. IMO, $tcl_platform(os) should return "Android" instead of "Linux". (Workaround: Currently, I use "info commands borg" to determine the OS, but it's not an elegant solution.)

If that matters, I'm using AndroWish v 2014-07-28 Alice In Wonderland, with my tablet Medion S7852 running KitKat 4.4.2.

Keep up the good work!

GCS - 2014-08-16

The Great Moon Hoax file is not working for me. I get an error "There was a problem parsing the package." This is on a Galaxy Note 3 running KitKat 4.4.2.

RZ - 2014-10-13

At first the good news: I could start my application shown at eurotcl on android. Only minor tweaks are necessary. I replaced rbc::* with blt::* calls. Only procedures from library/graph.tcl are missing. So I source´d the graph.tcl from blt and it was working. So it seems the files from the library dir are not available.

I found it also difficult to work with scrollbars and with toplevel borders. Scrollbars sometime work and sometime not. And resizing of toplevels is just pure luck. Is there a possibility for improvements in this area?

Thank you for the good work and let me know is you need more informations. I´m still in the lookout for problems mode.

Oh, the startup time is quite long. I have put my vfs source tree under /sdcard/Android/data/tk.tcl.wish/files Then I cd in my source tree and source main.tcl

HE - 2014-11-06 When I start AndroWish I get a small wish window and the console window.

In orientation portrait the console window is wider than the screen and the vertical scrollbar isn't visible. Can't find a way to move the screen around to get the other part of the console window visible.

In orientation landscape the console window is shown completely.

chw 2014-11-06: Did you try the menu entry in the console's edit menu labelled with "Fit To Screen Width"? This should decrease or increase the console font that it fits to the current (orientation dependent) screen width.

HE 2014-11-06: Yes, I did. But then the font becomes to small to read. Font selection/calculation should be based on the DPI of the screen. And width should based on the width of the screen of the current orientation. My display metrics (from borg displaymetrics):

rogerl - 2015-02-09 11:20:37

Having great success with my learning of tcl/tk by writing a small accounting package with the same code functional on both windows 7 and my galaxy tab 10.1. I struggled to find a decent date picker widget but eventually settled on widget::dateentry which works great on windows but on android seems to close the calendar dropdown as soon as you tap an arrow to change the month or year. Is this a bug? Fixable? I must say I am really impressed with how easy it has been so far to write a cross platform app with tcl/tk, sqlite and pdf4tcl - a breath of fresh air after struggling with alternative methods of developing on android!

chw 2015-02-09: the drop down blues is caused by a bug in XTranslateCoordinates() which yields "winfo containing ..." useless. It is fixed now in the fossil trunk on http://www.androwish.org (please use the fossil bug tracker when discovering new bugs).

rogerl - 2015-02-09 20:28:27

Many thanks for the quick response! In future I will report any suspected bugs in the correct place. I assume that the fossil trunk is source only, so as I am an 'end user' ie an application programmer, and not into compiling Androwish, I will need to wait for the next binary release for the fix. Any estimate of when this might be? Again many thanks for a fabulous android development environment!

chw 2015-02-10: Please expect the next release in early March. If you're adventurous follow the instructions to build AndroWish for yourself using the fossil source tree and Android NDK/SDK. I build on Linux but would be glad to hear that somebody succeeded building on Windows, too.

LostOne 2015-02-19 20:44 GMT+2

Hi, when running the HelloTclTk (from http://www.ch-werner.de/sdltk/AndroWish/HelloTclTk/ ) application after I've compiled it I get a dual "screen" and it seems way worse than if I just run the .tcl file from AndroWish (which runs perfectly and flawlessly both on the device

Compiled from a linux machine..

Target is android-21

I get this on all emulation devices (5.0/4.0) and also tested on a (borrowed) E-Boda Sunny V38 (Android 4.2) since my old Samsung has an android version of 2.1 and can't run it there.

Any ideas? Did I do anything wrong? is there a new HelloTclTk version out there? Does anyone have this too? Any workaround fix?

AndroWish seems very cool!

chw 2015-02-19: this question was asked and answered multiple times during the last 10 months on AndroWish Questions: just use the HelloTclTk template from the official source tree on www.androwish.org and it should work.

dzach 2016-1-18: This is not an AndroWish bug, but reporting it here may help people figure out what goes wrong with the appearance of apps written for AW on a desktop PC. I've found it to be difficult to match Tk widget and font sizes on Android AndroWish and plain Tk on a PC. Investigation has shown that, at least with my PC setup, Tk (on Linux) reports the wrong physical screen dimensions. This, in turn, results to calculating a wrong dpi for the screen. The bug can be verified by running:

    $ xrandr

on a Linux machine and then comparing the physical screen sizes reported in mm with the results given by Tk:

    % winfo screenmmwidth .
    % winfo screenmmheight .

A bug report has been filed: http://core.tcl.tk/tk/info/985607f2406d737a

MDD I'm not sure if the problem is in Androwish or in the device firmware, but I just recently tried Androwish out on the Planet Computers Gemini PDA, which is an amazing little device (https://www.planetcom.co.uk/ ), and the Fn-key is not recognized. It is required for accessing characters such as the semicolon or apostrophe. For example Fn-k should return the semicolon, but it just ignores the Fn press, and returns a "k." Once this problem is solved, the Gemini will be a great device for Androwish or NovaTcl projects!