Windows Mobile 2003 Smartphone
TP Jan 22, 2005. I recently bought a new phone for my mobile service, an Audiovox SMT5600 [L1 ]. This is the same device sold in Europe by Orange as the SPV C500. Other phones with the same O/S include the Motorola MPx 220.
This device runs Microsoft Windows Mobile 2003 Second Edition software for Smartphone [L2 ], which is a newer name for Windows/CE, running on a 200 mHz ARM processor [L3 ]. The device is not quite like a PocketPC, in that it has a smaller screen (176x220), and is not touch sensitive. Instead, a 5-way rocker switch is used to navigate, along with two soft menu keys, Home and Back keys. The soft menu keys are application dependent, Home normally returns to the Home screen, Back is used as a backspace in character entry mode, and to return to the previous application otherwise. The SMT5600 also employs T9 [L4 ] for smart text input (dictionary lookup based on the keys, e.g., 2-2-8 will offer "act", "cat", "bat", etc.) In 'multiple keypress' mode, several taps on the same key selects various letters (2-2-2 is 'C'), numbers, and special characters.
I have been experimenting with running Tcl/Tk on the phone. I installed the Tcl/Tk CE 8.4.6 package from http://sourceforge.net/projects/tcltkce . The good news is that Tcl/Tk does indeed run on the phone!!. The bad news is that the limited input is going to need some work to make the device a useful Tcl/Tk platform.
So far, I've been able to start TkCon (after a small bug fix), and run a few other hello world type programs. The 5-way rocker switch is currently interpreted as cursor motion (Up, Down, Right, Left) and Return (press down). The two soft keys and Home/Back keys do not currently pass any keypresses, and the keyboard is locked in numeric mode, so character input with T9 or multi-press is not available.
One of the primary differences is that most applications for the Smartphone run in 'fullscreen' mode. Tcl/Tk CE runs in windowing mode, complete with title bar and a close window 'X' button. I would guess that this will require some low level mechanics to make Tcl/Tk more like a Smartphone application.
I followed the install instructions from the tcltk846ce-arm.zip distribution file. Be sure to get the WinCE Desktop tools from [L5 ] , in order to get the Windows (x86) cereg program needed to make required registry entries. I installed in \Storage\Program Files\Tcl to get the software placed in the flash memory area. The distributed tkcon.tcl needed a small bug fix, at line 678:
# Place it so that the titlebar underlaps the CE titlebar set root $PRIV(root) ;# ADD THIS LINE wm geometry $root +0+0
Perhaps Jeff Hobbs has this fixed in later versions.
JC's WindowsCE build of Tclkit, Tclkit Mobile also runs, but exhibits the same display and input behavior (not quite a Smartphone app, and can't get multi-tap alpha or T9 input turned on.)
There is at least one Bluetooth keyboard that is known to work with the SMT5600, so perhaps I'll have to give it a try [L6 ].
I also have been able to use the SyncCE [L7 ] package to access this device from Linux, in order to do some basic file copying. Most other software you can get for the device requires a working Windows system to install; typically a Windows (x86) executable 'setup.exe' file extracts the actual ARM binary and installs it on the device. I've found a couple of small freebie text editors [L8 ] and [L9 ] that can be used for coding.
More to come as I have time to play..... More Information about smartphone visit : Fracent.com
(Spam deleted)
Coding on a cell phone can be lots of fun.
davidw Does this thing have j2me or java in any other form installed? TP Yes, it runs Java, supports MIDP 2.0.
If Tcl is so clearly superior to Java in so many aspects, how come no cell phone company ever uses Tcl as multi-purpose platform instead of heavy bloated Java? Has anyone here ever tried to sell the idea of embedding Tcl in a phone?
Why won't anyone answer the above question? - RS is not in a position of selling ideas to phone companies.. BTW, eTcl also has a dedicated build for Smartphones.
Silas S. Brown - 2010-06-13 05:01:03
I think Windows Mobile Smartphone does not support non-numeric input in apps like Tkinter that display their own text and handle their own events. It supports non-numeric input only in its native edit controls, where it does the text display and event handling by itself (which conflicts with Tkinter's event model; it might be possible to add a native edit control to Tkinter on the understanding that you can't bind callbacks to its events, but I'm not sure how to do it).
The restriction to numeric input makes sense because both multi-tap and T9 require the system to display candidate letters or words before the final letter or word is selected, and that would require either complex non-standard interaction with the app or else implementing a FEP (front-end processor) to sit on top of the app and display the candidate choices before they are sent to the app. Rather than do either of those things, MS decided to support multi-tap and T9 only in OS-native edit controls.
Unfortunately, this "don't have multi-tap or T9" seems to have been implemented as "switch on a NUM LOCK flag and don't allow it to be switched off". Result: even Smartphone devices that have a QWERTY keyboard are restricted. Any keys on the QWERTY keyboard that have numbers as well as letters are restricted to sending just numbers, and the Shift and Fn keys don't work. On the phone I tried, even the Backspace key doesn't send backspace when in this mode.
None of this affects PocketPC devices, which work just fine with Tkinter.
At least you can detect if you're running on a Smartphone rather than a PocketPC:
import ctypes def is_smartphone(): try: ctypes.cdll.commdlg except: return True
and then if you're on Smartphone you can fall back to raw_input() for data entry. raw_input() has its own native dialog on Python CE. I found you can even call raw_input() from within a Tkinter callback, but it leaves a spinning cursor in the middle of the screen when it's finished (obscuring your GUI) and calling app.config(cursor="") after the raw_input() doesn't help. It's better to tell another thread to do the raw_input and to notify the GUI thread when finished (by setting a variable etc).