Updated 2013-01-06 15:49:17 by RLE

Official homepage: http://www.evolane.com/software/etcl/index.html

For comments or bugs reporting on a specific release, or notes in chronological order, see eTcl bugs and comments.

Voir aussi, en Français: http://wfr.tcl.tk/eTcl
What: eTcl
Where: http://www.evolane.com/software/etcl/
Description: A single file executable of Tcl, with a variety of add on extensions statically linked. Versions exist for Linux (x86, arm, mips and powerpc), Microsoft Windows, Windows Mobile (2003, 2003SE, 5.x and 6.x), and MacOSX.
Currently at version 1.0.0 (8.5.5 core).
Updated: 12/2008
Contact: See web site

RS, 2009-09-11: The whole site http://www.evolane.com/ is login only. 2009-09-16: back to normal again, looks like eTcl can be downloaded as before.

From http://www.evolane.com/software/etcl/index.html :

"ETcl is a Tcl/Tk distribution as a single standalone executable, with support for many different architectures (Linux, Microsoft Windows, Windows Mobile 2003, MacOSX universal binary, ...). Distribution for each supported platform consists in a standalone single executable, which includes not only a complete Tcl/Tk system, but also several popular extensions (Pixane image handling, Thread, ZIP virtual filesystem, evodio for simple audio playback, ...). " For PocketPC, the wce extension provides specific capabilities.

The license is said to be ActiveState-like (use free, don't redistribute). Tcl and Tk are up to date (8.5.0). sqlite 3.5.4 is also included.

RS copied the PocketPC exe onto his HTC Magician. Startup brings a full-screen light-blue console: bad if the keyboard covers the lower third of the screen. However, there's an easy solution: to leave out the keyboard screenspace, just type (or put in etclrc.tcl), using unambiguous abbrevs, to reconfigure the console:
 cons e {wm ge . 240x188}

For purists who don't have to tap with a stylus, that's
 console eval {wm geometry . 240x188}

Note: since the 2006-01-16 version, the console auto-adapts itself to available space, this hack is no longer necessary. To get this behavior for your own windows, just do
    bind $w <ConfigureRequest> {::etcl::autofit %W}

Different from the Keuchel port, toplevels have no title bar and decoration. Note that the position of a window that's right under CE's top menu is +0+26 (not +0+0 as I did on older ports, to hide the window title under CE's).

Other nice features: eTcl is a closed world inside a VFS just like Tclkit, but in contrast to that, eTcl has at least two manholes to the outside world:

  • auto_path contains [info na]/../../lib. If you e.g. have the 3MB executable in /StorageCard/Programs/eTcl.exe, /StorageCard/lib is also in auto_path, so one can e.g. copy BWidget there to have it implicitly in reach.
  • On startup, the file ~/.etclrc (set in the variable tcl_rcFileName: from 2006-01,16, it is changed to [info na]/../etclrc.tcl) is sourced. env(HOME) is just / on my phone. In this file you can set preferences, extend auto_path, etc. More soon.

A first for Tcl on PocketPC, an (X) button at top right which sends the window to the background. (It is said to be also configurable to close the app, but without docu, I'll wait with tests.)

MB 2008-11-20 Just a small clarification about the configuration script which is loaded at startup. Starting from etcl 1.0-rc2 the configuration script for all platforms (including Win32/Linux/macOSX/WinCE) is not ~/.etclrc file. Instead the configuration file is [info na]/../etclrc.tcl. On my PocketPC with etcl rc30, the value of the variable tcl_rcFileName is the following
   12% puts $tcl_rcFileName
   /Program Files/eTcl/bin/etclrc.tcl

while "info na" gives the following result
   13% info na
   /Program Files/eTcl/bin/etcl-normal.exe

LV The X button puts a window into background? Weird - most windows systems use X to mean "terminate this process". Sure would have been nice if it would have been a & ... - RS: That would be intuitive for Unix shell users, but most PocketPC users ain't. The semantics of (X) in Windows/CE rather seems to be "push in background, and close when space gets scarce". You can bring a window back up from the task list (in Memory), or sometimes from Start menu. But eTcl will start up a fresh instance if you do that.

Another first: socket works! (Tested with telnet over my corporate intranet). My problems here are that my mobile provider only allows me to use wsp: protocol (port 9201) which the http package does not accept, although it's pretty much identical in these days.

Note: Tk apps should contain the command
 wm deiconify .

because at startup, the "payload" window is iconified, instead of sitting over the console.

menu is better supported than in Keuchel's port or [TKM]: you can put multiple headings on the bottom. (In Keuchel, you'd get a single item "Menu" which has the headings in a first sub-menu). But you still can't set images for menu items as in native apps: they get replaced by the string "(image)" which is less helpful.

And exec seems not to work - I tried it with various executables, including eTcl itself: all lead to sudden death without error message. EH: exec should work again from version 8.4.12-pl4. Applications must however be started in background, or in pipe (e.g. exec pword & to start PocketWord)

More nagging: when displaying Chinese characters, some like \u5927 (/da4/ "big") were unexplainably not found and rendered with the empty box (while Keuchel's port finds them). EH 2006-01-22: eTcl/Mobile set default font for all widget classes to "Tahoma 8", because it is by far the best readable font for small font sizes. Do you force font in your test? If not, maybe problem comes only from Tahoma having less symbols defined than other fonts?

But still, RS is pretty happy with this port - more soon! See Sepp for the upcoming little IDE... newer additions will be listed only there.

2006-01-16: The version currently for download at evolane now has all encoding tables, and an optional toolbar at the bottom of the console, for "electric" brackets, braces, and switching windows. Also, the console resizes automatically depending on whether SIP is there or not. And, the optional startup file $tcl_rcFileName now is called [info na]/../etclrc.tcl, more in touch with the naming style on Windows.

This works in eTcl too (see screenshot above) - inline console imaging:
 proc see name {
    console eval [string map [list @ $name] {.console image create end -image [image create photo -file @]}]

PWE Very nice distribution indeed. However
 set f [open com2:]

fails here just as on all other pocketpc versions except Keuchel's.

2006-01-17: EH has fixed serial port issue in version 8.4.12-pl3. Supports for com1: to com9: serial ports (including bluetooth communication ports) should be fully functional now. PWE This version does indeed support com port, however I still have a problem. When trying the following:
 proc ReadGPSData { } {
   global f
   gets $f line
   puts $line 
 set f [open com2:]
 fconfigure $f  -mode 4800,n,8,1
 fileevent $f readable ReadGPSData 

I get a few lines of GPS data, after which eTcl quits without any error messages. It appears as if eTcl quits when there is real data (more than 3 sattelites). I also get a quit without error message when trying to run the pocket pc version of sudoku http://wiki.tcl.tk/_repo/wiki_images/sudoku.tcl Sudoku start without problems, but when selecting Game->Generate it quits.

2006-01-17: EH reports this is a stack-overflow problem, which is raised because of strongly recursive structure of the above sudoku implementation. Works again when explicitely increasing stack size at link time. Starting with release 8.4.12-pl4 (which will be made available 2006-01-18), stack size will now be set to 0x80000, instead of 0x10000 in previous releases. PWE I think that the above ReadGPSData problem might also be stack related. If I remove the update, it keeps working. EH I confirm this one was also stack related, everything fine again with increased stack size. I guess many code may have problem with low stack size, so I urge anyone having eTcl dying suddenly to update to eTcl-8.4.12-pl4 or better.

RS: I'm very amazed. ETcl must be the best-supported Tcl distribution ever :) "bug today, fix tomorrow". Thank you so much for your ongoing support, EH!

WK: I only wish it also included Itcl and Itk. Well, at least Itcl, Itk is way beyond my wildest dreams.

Zarutian: Symbian/S60 port on its way, yes? (I am hopefull)

2006-01-18: VK Could you please shed a light on eTcl in general? My questions basically are:

  • is it another application packaging system (in addition to already existing many), which happens to be PocketPC-compatible? (or it is a new port to PocketPC, which is able to be easily packageable) - RS: It says to be a {read|write}able zip-based vfs, available for Linux, big W., and PocketPC. Having proven installs on the first two, I'm only interested in the latter :)
  • How does the unpacking works? Some vfs, I beleive, but what namely happens on execution? Is there source to look at? - RS: No unpacking needed, mount a vfs, get to use the files. Source code is announced to be released soon. Binaries are updated every day or so.
  • Does this anyhow have something with existing port of Tcl described at Windows/CE? eTcl doesn't use CELIB? Besides, there is Tclkit Mobile, any relations to this? - RS: eTcl seems to use some celib (env(CELIBVERSION) is 4.0), but to be closer to platform-specific habits. It's a young alternative port, somehow comparable to TKM as pointed out above, but more open for an end-user like me, and amazes me the longer I use it.

EH eTcl uses a romified ZIP image, mounted at startup using VFS. Same packaging applies to all platforms. Now nearly all major bugs have been solved, and eTcl-8.4.12-pl4 is made available, I will get time to write some documentation, maybe release most or all sources, and hopefully answer your questions in details very soon.

RS 2006-01-19: The pl4 build can do some exec, especially on itself, so the restart idiom
 exec [info na] &; exit

works; but Windows executables still are a problem - "pword.exe" and "calc.exe" (the latter used to work in Keuchel's port) are refused: "couldn't execute ...: no such file or directory", while file size etc. clearly find the exe file.

EH Bad news :-( since all those one works for me here (etcl-8.4.12-pl4)
  exec pword &
  exec calc &
  exec pword.exe &
  exec calc.exe &
  exec /windows/pword.exe &
  exec /windows/calc.exe &

Maybe something in "your" env(PATH) I don't deal with correctly? Any idea/help welcome, since without being able to reproduce this, it will be difficult to fix it. - RS: original setting is plausible: "\;\Windows". I tried many combinations - with slashes instead of backslashes; with only a single \Windows, all to no avail. Will continue to research - must be a privileges problem. EH "exec" is an important feature, and I would like to make it as stable as possible. Right now, I have now idea on what could make it fail on Richard's device while working fine one all of those I can test on. If someone can give those "exec" commands a try, and let me know if they work or now, together with some information on OS version, language and eTcl version, it may help in getting somle valuable indication on what can be wrong.

PWE exec doesn't work for me either. I have a Mitac Mio 168, OS version 4.20.0, English (american?) eTcl-8.4.12-pl4. Another thing I noticed with the exec, is that all the programs that fail seem to be located in ROM. These files also seem to have some special status, since I cannot copy them to RAM. The file explorer throws an error with "Executable and resource files in ROM cannot be copied". Other explorer like programs are also unable to copy these files. I also noticed a problem with the scan command, something like
 scan "12.1 61.1 0.1" "%g %g %g" l1 l2 l3

exits eTcl without any error.

EH Oupss... "Nice" bug, thanks for reporting! Our internal strtod() stub is wrongly initialized, so any scan with %f, %g, etc... as argument, ending up to a call to strtod(buf, NULL) in tclScan.c, raises a segfault. It requires only a small fix, so will have a pl5 built available ASAP with this issue solved.

PWE I also tried using the BWidget combobox and saw some strange behaviour. With the following little program and bwidget in the "/storage card/lib" directory:
 package require BWidget
 text .t -height 10 -width 30
 ComboBox .e -textvariable sel -values "a b c d"
 pack .t .e

If I now click on the little triangle of the combobox, the whole window disappears, showing only the selection listbox of the combobox (which is at a lower position than the combobox). After selecting from the listbox, the window reappears.

EH This weird behavior was related to difference between Win32 and WinCE in the way WM_OVERRIDE_STYLE (that is when calling wm overrideredirect for Tcl) is managed. I believe I could find a workaround (at least, Bwidget's combo works fine), so pl5 release (coming very soon) should fix this. BTW, since BWidget seems to be very popular among Tcl on PocketPC users, and since it is pretty small (about 100k), I will consider embedding it in VFS.

2006-01-22: EH Version 8.4.12-pl5 has been made available for download. Starting with eTcl 8.4.12-pl5, making your favorite Pure-Tcl packages available from eTcl is made very easy: Any ZIP file found in [file dirname [info nameofexecutable]]/lib will be automatically mounted as a virtual directory, and this directory will be automatically added to auto_path. That is, if you installed eTcl executable as "/Storage Card/etcl/etcl.exe", copy e.g. BWidget-1.7.0.zip into "/Storage Card/etcl/lib" and "package require BWidget" will now work out of the box. Release 8.4.12-pl5 also fixes a bad bug in native menu support (menu use to grow every time a menubar entry was modified, detaching/reattaching it was a dirty workaround), the "scan %g" segFault, and the focus problem for transient windows (e.g. BWidget's combo). The only reported bug which remains not fixed yet is the exec problem. A few sample applications (from 3rd parties) have been added, available for those installing from ZIP, CAB or Windows Installer.

2006-01-27: Andres I would like to install eTcl on a Orange SPV 500 Smartphone running Windows Mobile 2003 2nd Ed. I tried the installer and copying the cab-file manually. However, I get an error message saying, that the installation file is not intended for this plattform. Does anybody know if there is compatible distribution for this device? Or is eTcl planned to be ditributed for this device? - RS I have downloaded eTcl several times now on HTC Magician, mostly by directly copying the .exe file. This always worked. You don't need an installer. - Andres Ok, so far. However, on starting the executable something happens, leaving me with a "Btn1" on the left an "Monmenu" containing "MItem1" and "MItem2" on the right soft button of the phone. I do not see any tcl shell. I also tried using etcrl.tcl to source a simple hello world script. Same result. - RS: The resource file should be called etclrc.tcl and sit in the same directory as the executable. If you start the executable, a light blue text window with a % prompt should come up. - EH: Native menus behave quite differently on PocketPC and Smartphone (I mean, Windows Mobile Smartphone Edition that is for devices without touchscreen. Richard's HTC Magician, similar to my Qtek S100, while phones, run with WM2003 PocketPC edition), OS management of focus too. I must admit eTcl was up to now more targetted and tested on PDA than smartphones (using the embedded console without a touchscreen isi probably impossible). I'm out of office for a couple of days, but will have a look at it, at least on MS smartphone emulator, ASAP. Since PDA version comes closer to stable (Note to RS: playing wave ready, will be available in next release ;-)), your feedback on smartphone, either here or contacting me by email, will be welcome and will get all my attention to get fast fixes.

2006-01-30: EH I have made some significant progress on making eTcl run on Smartphone devices. Console now displays fine (screen geometry was badly guessed, because SIP size was meaningless, thus console was actually displayed, but was 1x1 pixel large), with no toolbar since Smartphone devices have no pointing device to use it. Still have to fix support for native menus (Smartphone only support 2 menu headers, so may fallback to a single "Menu" button, displaying the whole Tcl menu tree when pressed). I will make Smartphone specific CABs available together with PocketPC ones in next release (today or tomorrow ), since, while executable is the same, I couldn't figure out how to generate a single CAB supported by both platforms.

2006-01-30: EH eTcl 8.4.12-pl6 is available for download. Last two weeks, since previous release, have been dedicated to fix all reported bugs, and to make eTcl fully compatible with all Windows Mobile devices (that is both PocketPC and Smartphone devices, for all OS versions from Windows Mobile 2003 to Windows Mobile 5). Native menu support has been rewritten and works fine on smartphones now. List of changes is pretty large, but I may mention exec works now for executables in ROM too, image display problem fixed, clock format (%c) fixed, full support for smartphones and VGA devices (that is, not in emulated QVGA mode), and sqlite upgraded to stable 3.3.3. I believe that from this release, Tcl port to Windows Mobile platforms can be considered as completed. As usual, all comments, bug reporting and feedbacks, here or by email (see Eric Hassold) are much appreciated. 2006-01-30: EH Etcl 8.4.12-pl7 has been made available for download, only a few hours after 8.4.12-pl6 release. Static dependencies to aygshell.dll and commdlg.dll has leaked in, whereas they are not available on WM 5.0 Smartphone Edition devices. Symbols are now resolved dynamically at runtime if possible. All WM 5.0 users will have to upgrade to have eTcl work again on their device.

2006-02-02: Where can one download the sources? I am interested in some of the packages from eTcl (quite an impressive list!). Is there a chance some of them at least will make it to tcllib? EH Are you referring to eTcl or EvoTcl? eTcl is a binary distribution, which doesn't contain much Pure-Tcl code which could fit into tcllib. EvoTcl is a collection of Pure Tcl packages, just like tcllib, so some convergence is more an option. I have been so busy with eTcl for Windows Mobile port last weeks that EvoTcl release has been postponed, but it will very very soon. will make source for a gunzip Pure-Tcl implementation, together with Pure-Tcl unzip and PNG reader, available during week-end.

2006-02-08: EH eTcl 8.4.12-pl8 is available for download. It introduces native support for PocketPC TapAndHold and for input mode selection (spell, text, numbers, ambiguous aka T9 or off). Both can be set on a per widget basis, through the wce tapandhold and inputmode subcommands. Input mode for console on Smartphone devices is set to spell at startup. Also new in this release, if an instance of eTcl is already running, it is now displayed again instead of starting another one, when users select again eTcl shortcut. This applies only to eTcl console, that is eTcl with no argument, so one can still have several eTcl instances running at the same time, as long as their toplevel window uses a different title. HE I tried to start two different scripts pad.tcl and edit.tcl directly from the filebrowser. Only the first one was opened. (I use eTcl 8.4.12-pl8 on windows mobile 5.0) pad.tcl must be closed before edit.tcl could be started. In the taskbar both scripts has different names. Is this the correct behavior?

ramsan: Would it be possible to have a mechanism to implement this uniqueness also in applications that are not the console? Fo example based on calling etcl with a title option or something similar.

EH I'm not sure what is the best default behavior one may expect. Set up some extension, inside wce, to let user decide his prefered behavior from Tcl code is quite feasible, but an early stage mechanism should probably be prefered. The quick hack in pl8 sounds not correct, you are right. I will update it, to have eTcl search for another eTcl console instance if eTcl is started with no argument, but use argv[1] (the script root name) as instance name if one is provided (that is, when main script is selected from filebrowser, once file association has been set up).

WK I agree that file name should be used for uniqueness. Also, a nice way would be to make dde work (if that's possible?) and allow Tcl scripts to send dde events to raise & focus and exit the other process. This would be the most elegant solution.

Also, is it possible to bind keycode events somehow? I have an MDA with 8 hardware buttons and red/green buttons for phone functionality. I can get their keycodes using AEKMap and it would be great to bind those. 2006-02-14 EH support for hotkeys is ready, and will be included in next (pl9) release, together with fixed handling of the "Back" button on smartphones (which can be binded to backspace). Something like "wce hotkey <keyalias|keycode> on" will allow eTcl to report hotkeys as normal KeyPress/KeyRelease events. WK Great. Another thing is that 219 is the "Sym" key for PDAs with qwerty keyboard. Could you add that as some keysym to that one? I'm writing some scripts to make eTcl more developer friendly and this is one of them :-)

eTcl blog (just started): http://doping.sics.se/prof/2006/01/27/running-etcl/

[MK] I wondered if there were any plans to incorporate XOTCL (http://media.wu-wien.ac.at/) into eTcl? I use XOTCL it in personal build based on celib, but would love to move to the benefits on eTcl.

2006-02-19 EH While eTcl was in a consolidation period, there was no immediate plan for incorporating other native extensions in the default distribution. Since it is getting more robust now, I will consider enumerating which native extensions are most popular and might end up into executable, and which others should propably be delivered as loadable packages (that is, as DLL). Current executable is about 3MB large, while eTcl with no extensions is about 1.5MB, so it seems to me extensions linked statically into eTcl executable will have to be carefully selected to prevent eTcl for Mobile to grow out of some reasonnable bounds. But I plan to provide, together with future releases, a developer package which will include everything needed (tclstub.lib, tkstub.lib and some headers) to let anyone compile its own loadable native package to extend eTcl core (and hopefully make them publicly available). While it runs on WM5, eTcl is compiled with EVC4, which is freely available from Microsoft. This is planned for next week.

Artur Trzewik I am also interested in having XOTcl in eTcl. I have noticed that eTcl is not shipped with source code (project files, patches) for embedded Visual C++ (EVC). Is it possible to have somethink like eTcl-SDK with Tcl.lib, header files or another files needed to build a extnesion-dll for eTcl? Perhaps also SampleExtension EVC project adapted for eTcl (a part of TEA) It will be similar to ActiveTcl distribution, which also not include all sources, but there is a possibility to write binary extension for it.

EH See paragraph above. Yes, indeed, a public release of an eTcl-devel package, including headers and tclstub84.lib/tkstub84.lib (maybe also our emulation layer evowce.lib) will be release soon. I'm little late about it, because of some bad compiler issues which made me had to track some weird bugs lately, but this is on top of the agenda. Note however that eTcl does not use an EVC project to build, but instead a cross-compilation framework (written in Tcl/Tk), which ease our support for a large set of target architectures. And extracting a subset of this framework for public release is actually what is taking some time. Last (but not least), it is still possible (and not that difficult) for anyone to compile just a tclstub84.lib/tkstub84.lib, using tcl.h and tk.h public API, to generate loadable extensions, without actually needing an eTcl SDK. I'm not saying I won't release the SDK, but only suggest the most impatient ones, who enjoy EVC project mechanism, can already compile their own extension for eTcl ;-)

Ruffy Got myself a 2003 PocketPC running eTcl - but I can't get the unicodes to appear - I tried Hebrew "\u5d0". Anybody?

EH I believe this is not an eTcl issue. Default font used by eTcl for all widgets is Tahoma, since it is best viewable font in small size, and available on all WM devices, and usually already loaded into system, so implies no startup delay. However, whereas Tahoma on desktop has full UNICODE support, the Windows Mobile version usually doesn't support full unicode range (may vary from manufacturer and/or localization). use "font families" to get list of all fonts families installed on your system. If none seems to include a full unicode support, you may copy one .ttf font file (e.g. times.tff) from your desktop into /Windows/Fonts (or whatever local name it as, e.g. /Windows/Polices under a French iPAQ 4150 / WM2003). Restart eTcl, check if new font is available with "font families", then configure the widget you want to display Hebrew characters to use this font. This works for me:
  set fn [font create -family {Times New Roman} -size 12]
  set w [label .l -font $fn -text "Unicode: \u5d0"]
  pack $w

Note that an unicode-compliant TTF font (bitstream-vera) is embedded into eTcl executable, but it is used by Pixane package, and unfortunatly right now not exported as a valid system font usable by Tk.

RS replied on the chat: "I have verified the problem here too. Quick solution: configure your widget to a font that has the wanted characters. Problem seems to be that Tk's font search gives up too early in eTcl. (In regular Tk since 8.1, all available fonts are searched). After a char was found, the console etc. will show it from the right font. I tried with {Bitstream Cyberbit} here; make sure your font has Hebrew (e.g. in the char selector in Pocket Excel). Example for interactive testing:
 pack [[label .1 -font {{Bitstream Cyberbit}} -text \u5d0\u5d1]]

PWE 20060420 With the new eTcl 1.0-rc0 release the console doesn't seem to work. A program like
 pack [button .b -text console -command {console show}]

raises an error if the button is pushed. If etcl is started without program, and the program is sourced from the console, it works OK.

EH This was supposed to be some kind of new "feature" to save memory, but actually, you are right, this is a bad one, so I will restore previous behavior. This is related to macOSX and Unix new heuristic to decide whereas console should be initialized or not. Under WinCE, console is no more initialized at startup if not running in interactive mode. As I said, I will follow your recommendation and change it back 1.0-rc1. In the mean time, you may still get the console by sourcing the console.tcl script.

2006-04-20 HE eTcl 1.0-rc0 for pocketPC (WM 2003 and CE5.0): 1. I associate etcl to .tcl, but I can't start them directly from the filebrowser. Only source them into an open etcl console works. 2. tk_chooseDirectory raises the following error:
 coudn't read file "/My Documents/tcl/tcl/etcl-1.0-rc0.exe/.etcl/tk8.4/tkfbox.tcl": no such file or directory

@EH if you like to include the Alternative dialogs for pocketPC/etcl, feel free to do so.

2006-04-20 EH Thanks for this bug report. Per mistake, VFS image for WinCE add same name than VFS image for Win32, so when automatically building for all architecture, Win32 VFS ended up into WinCE build. And since Win32 doesn't need tkfbox.tcl (nor clrpick.tcl), those two files are missing in 1.0-rc0. Another eTcl release canditate (1.0-rc1) is already available for download to fix this problem. File association should work too. If unsure, please uncheck all checkbox in the fila association dialog (in console), press Ok, then return to same dialog and check expected associations again, and press Ok again,to be sure no broken registry entry remain in your device.

EH would appreciate anyone to comment on what extensions should be part of eTcl on Windows Mobile. I'm planning to provide three different build now (compact, normal and sumo). While "compact" will probably contain only Tcl and Tk, what should end up in "normal" and "sumo" builds seems to vary a lot from one user to another, according to mails I got. So your feedback would be greatly appreciated, to try to find acceptable configuration(s) to fill everyone's needs.

2006-04-22 HE I use the following packages and it would nice to use them on pocketPC, too. But I prefer the posibility to load them from extern like in standard tcl oder to load them from a collection like the kitten.kit for tclkit. And it would be nice to build such a collection myself. The extern extension makes it possible to build packages with GPL-Lizenz for use with etcl The packages I use/need/want:

  • itcl
  • snack
  • tcludp
  • img or pixane (if it is possible to use pixane like img::window?)
  • tktable
  • tkhtml
  • BWidget
  • tcllib
  • tklib
  • 2006-05-05 I forget oratcl. But I believe it exists no oci-api for pocketPC. So it comes on the wishlist for sumo (I think normal should be the same for all platforms, and sumo becomes the rest)

By the way. I'm missing the functionality of package wce on w32 (and other platforms). I don't find a way to get the free screenplace (width, height, startpoint) without the taskbar or other bars on the borders of the screen. Placing a toplevel near the border contains the risk that important parts are covered from the bar.

2006-04-23 ramsan: I think that the packages with more priority should be the ones that contain C code, as the TCL only packages can be very easily installed. Among the most widely used (at least by me) are:

  • tdom (XML)
  • treectrl (both a tree widget and columns list widget)
  • sqlite3 (it is already there and I appreciate it)

2006-04-24 PWE: Also limiting myself to C code:

  • For deployment it would be nice to be able to source starkits, or something similar. This would also give a writable VFS, which would also be nice.
  • pixane
  • tktable
  • BLT (mainly for its graphs)
  • an XML parser (I've now been using the tcl only version of tcldom, which works OK, but is a bit slow).
  • wce (I would like that also in compact)

2006-04-30 HE Some experiences with etcl 1.0-rc1 on pocketPC:

  • Disabled menubar items and menubar items without existing menu terminates etcl/script without errormessage (looks like an error) (HE Fixed in 1.0-rc3.)

Sample (menu a2 and a3 terminates etcl):
 menu .menu -type menubar -tearoff 0
 .menu add cascade -label a1 -menu .menu.a1
 .menu add cascade -label a2 -menu .menu.a2 -state disabled
 .menu add cascade -label a3 -menu .menu.a3
 menu .menu.a1 -type normal -tearoff 0
 .menu.a1 add command -label a1-1
 .menu.a1 add command -label a1-2 -state disabled
 menu .menu.a2 -type normal -tearoff 0
 .menu.a2 add command -label a2-1
 .menu.a2 add command -label a2-2 -state disabled
 . configure -menu .menu

  • Tap and Hold must be activated for every widget separately. For NoteBook widget this means we must activate it for <notebookname>.c

 console show
 package require wce
 package require BWidget

 NoteBook .nb
 .nb bindtabs <ButtonPress-1> {de {Button Press 1a}}
 .nb bindtabs <ButtonPress-2> {de {Button Press 2a}} ;# Gibt es aktuell nicht auf pocketPC
 .nb bindtabs <ButtonPress-3> {de {Button Press 3a}}
 .nb insert end a1 -text a1
 .nb insert end a2 -text a2

 pack .nb -expand 1 -fill both

 proc de {msg args} {
        puts "$msg $args"
 etcl::autofit .
 wce tapandhold .nb.c on

  • Sometimes the console menu is displayed even when the application covers the console. In this situation it would be nice to raise the console from the console menu. Extending the eTcl console:
 console eval {.menubar.file insert 3 command -label {Show console} -command {consoleinterp eval {console show}}}

  • 2006-05-01 HE It looks like etcl 1.0-rc1/w32 doesn't load the file ./etclrc.tcl. The version for pocketPC does. EH See value of $tcl_rcFileName. Under WinCE, it is set explicitely to etclrc.tcl in the same directory as executable. However, on Win32/Linux/macOSX, it is set to ~/.etclrc. HE Thanks. Poorly I have some problems with it: 1. Files beginning with a i period are not easy to handle (native) on w32. Ok, I know how to create them, but what is with the normal user?:-) 2. In this way it isn't possible to use different enviroments in different directories. So I prefer the pocketPC way. (Also the behavior of etcl is more platform independent) EH I agree with your suggestion. If nobody argues against this, I will make etclrc.tcl in same directory than executable the default startup file on all architectures, starting from 1.0-rc2 HE You are to quick for me:-) In the meantime I helped myself patching the binary file of etcl and exchange the string ~/.etclrc with ./tcl.tcl
        set quellfid [open etcl.exe r]
        fconfigure $quellfid -translation binary -encoding binary
        while {![eof $quellfid]} {
                set tmp1 [read $quellfid 1]
                binary scan $tmp1 h a
                if {$a eq 0} {
                        append tmp @
                } else {
                        append tmp $tmp1
                set tmp [string range $tmp end-8 end]
                if {$tmp eq {~/.etclrc}} {
                        puts [set pos [tell $quellfid]]
        close $quellfid
        close $quellfid
        set quellfid [open etcl.exe r]
        fconfigure $quellfid -translation binary -encoding binary
        set zielfid [open etcl1.exe w]
        fconfigure $zielfid -translation binary -encoding binary

        puts -nonewline $zielfid [read $quellfid [expr $pos - 9]]
        puts -nonewline $zielfid {./tcl.tcl}
        read $quellfid 9
        puts -nonewline $zielfid [read -nonewline $quellfid]
        puts -nonewline $zielfid [read -nonewline $quellfid]
        close $zielfid
        close $quellfid

        set tmp [read $quellfid]
        regsub -all -- {\~/\.etclrc} $tmp {./etcl.tcl} tmp1
        close $quellfid
        set zielfid [open etcl1.exe w]
        fconfigure $zielfid -translation binary -encoding binary
        puts -nonewline $zielfid $tmp1
        close $zielfid
        close $zielfid

By the way: It would be nice if etcl use ./etclrc.tcl (or ~/etclrc) even if not interactive started. Perhaps in an alternative file for different behavior.

2006-05-01 [czp] I am very excited ! eTcl is a small wish-to-come-true. I even started learnig TCL :-) It turns the PocketPC into my personal digital assistant. My big dream is somthing along the lines of HyperCard sometime with tcl replacing HyperTalk. I am missing sound support. I have read RS's wish and EH allusion it's been done already - only I haven't found it yet.

2006-05-01 EH It is part of a pre-alpha package called evodio. Pretty basic for now, no async playing (whereas it may already be emulated using threads), no resampling, etc.., but to give it a try:
 package require evodio
 evodio play -file somefile.wav
 # or, to play in-memory data
 evodio play -data $somewavdata

2006-05-01 [czp] Currently I am trying to talk to my cell phone handset over Bluetooth using AT commands. It's not as straight forward as from the Win32 Hyperterminal. Some remarks:

  • I do not care about win32 & Mac support (it distracts, why yet another tcl interpreter there ?)
  • set f [open com6:] works only in the root directory and failes with 'no such file ...' after cd'ing to a different directory
  • console: path name completion failes on paths with directory names containing white space - it escapes the white space fine but does not follow the next nodes 2006-05-01 EH This Appears to be a Tk bug in console.tcl, not specific to eTcl. Same bug on ActiveTcl/Win32. I might consider fixing it in eTcl, but you should also consider file a bug on core Tcl/Tk bugs tracker.
  • wouldn't it be nice to add support for Tillanosoft's tGetFile.dll ( http://tillanosoft.com/ce/tgetfile.html )file choser dialog in etcl ?

EH I fixed the comX: bugs, which happen for com ports greater than 4 only (fix will be part of 1.0-rc2). I don't really understand your observation about the Win32/MacOS ports. Those port aim to provide a fully portable engine across a very wide range of platforms (together with some other platform, not publicly released, e.g. arm-linux). About the tGetFile.dll, HE made some nice contributions to provide better alternative to default native open/save dialogs (together with some others dialogs). I didn't have time yet to validate them, test them on smartphones, and embed them into eTcl, but this is on the agenda. I believe this may provide something very similar to tGetFile, without introducing a dependency to an external, closed binary DLL.

2006-05-04 EH 1.0-rc2 is available. It fixes comX: and empty menu bugs reported above. Also, etclrc.tcl is now the default rc file on all platforms. It also introduces support for TclXML (I tested and added support for both TclXML and tDOM, but had to make a choice, so...) and tktreectrl. However, thanks to some improvements in the packaging system, 1.0-rc2 executable, while having support for TclXML and tktreectrl, is smaller than previous 1.0-rc1 release. This will be the new "normal" distribution. The future "compact" one should be less than 2MB large.

@HE: All Tcl scripts embedded into the VFS are now made smaller by preprocessing them to remove comments and some spaces. If this breaks your alternative dialog package, or raise some unpredicted problems, please let me know. 2006-05-04 HE As long as the package isn't included in etcl it works. Reason: The way described in Alternative dialogs for pocketPC/etcl works with his own files to patch, and needs the comments inside the hot patched procs. On my own maschines I test a prepatched version of the files. This version should run even if all comments are deleted. Only the wrapping is done by the main script. If this works correcly I will look for a way to provide it.

2006-05-04 PWE Looks like the com ports don't work with rc2 (pocketpc). An open on com2: now gives "no such file or directory". This works in rc1. EH Just found your report. A patch hasn't been commited on the production platform :-( I re-sync and start a new build/release process right now, and fixed releases (for the serial issue) will be available today. Sorry for that. PWE Also on the pocketpc, when using the alt theme from tile, the checkbutton does not show its checkbutton, just the text. As far as I can see, the previous versions had the same problem with the checkbuttons. EH several problems have been reported with the alt and step themes, not only with checkbuttons, but also radiobuttons and other image-based elements. One may prefer either clam or default themes for now, which seem to work fine. BTW, to keep eTcl on Windows mobile smaller, I'm not convinced it should include the full range of themes tile support per default. 2006-07-13 EH I finally found idea and time to write an effective emulation of GetDIBits() on WinCE, used by XGetImage. In Tk core, this is required only to display images with "complex" alpha channel (true alpha blending). But surprise, this is also used by Tile to display some widgets (e.g. checkbutton, radiobutton, ...) with some pixmap-based themes (blue, step). So new GetDIBits() emulation also got rid of this last longstanding bug. Now, thanks to a fully functional Tile implementation, eTcl on PocketPC is fully themable, and 1.0 final release should come soon.

2006-05-04 HE Is it possible on etcl/pocketPC to change the appearance of disabled menubar items like it is done on other platforms (etcl/w32)? EH Fixed in 1.0-rc3

2006-05-05 ramsan: Is there a strong reason to choose TclXML over tDOM? they are different enough so as not to be able to port an application using tdom to etcl. And tdom works so well... The opposite option should be less problematic, as TclXML has a TCL only version, easier to load externally in a variety of platforms. EH No, there is no 'strong reason'. As I said, I added build config for both, and they both have their pros and cons. As said PWE in a previous comment, the Pure Tcl package is often too slow on embedded devices to make it a real option. But providing both tDOM and TclXML is neither an option on such platform. So I just made a choice, with no claim one is better than the other. One could even consider this was a random choice (if I had to give one reason to explain this choice, I would say TclXML object is few hundreds kbytes smaller than tDOM, which may matter on embedded devices). I plan to provide both as loadable packages in a (near) future eTcl compact distrib, where most extensions will be available as DLL. If a large majority of persons comment here to say they prefer tDOM over TclXML (but please, without starting a flame!), I won't care switching from one to the other. But I have the feeling that only falling back to loadable modules may satisfy everybody (just like choosing one of the many OOP extensions available for (e)Tcl).

2006-05-16 jcw - Are there changes in the eTcl distribution as far as Tcl/Tk are concerned? If so, have these changes been submitted back to the Tcl/Tk source code base? EH Desktop versions (Linux, Win32 and MacOSX) are just vanilla Tcl/Tk distributions, together with some extensions specific to eTcl (e.g. Pixane). The WinCE port requires small patches to the Tcl and Tk core (diff files are 17kB and 45kB respectively), everything else being managed by a posix and win32 emulation layer. Those patches have been send to Jeffrey Hobbs under his request. Until evolane.net developper site is ready, with an anonymous access to our svn repository, I will try to find some place to make them available for download.

2006-05-25 HEI want to try etcl on an G4 iMAC with OSX10.3. But copy anywhere and run doesn't work :-( I tried the dmg und zip archive. The etcl in the last one gives an errormessage:
 dyId: /Users/holger/Desktop/etcl/etcl undefined reference to ___stderrp expected to be defined in   /usr/lib/lib/System.B.dylib
 /Users/holger/Desktop/etcl/etcl undefined reference to ___stdinnp expected to be defined in /usr/lib/lib/System.B.dylib
 Trace/BPT trap

Doesn't etcl run on OSX10.3 or what I'm making wrong? 2006-05-26 EH PPC executable, part of the universal binary, has been built using 10.3.9 SDK, which requires OS 10.3.9 or later for deployment. I just hoped this would be fine for most users, but your report shows I was wrong. I will generate next PPC build using 10.2 SDK. However, since we have only 10.3.9 /PPC and 10.4.x/Intel hardware available for testing, I would be graceful if you could contact me directly, and accept to try on your 10.3/PPC system a pre-release I could send to you, before making it publicly available for download.

2006-06-08 EH Binary for arm-linux is now available for download. Like on all other platform, this is a fully static single executable, with no external dependencies, so it should run on any arm-linux system (kernel>=2.6). Tested on iPaq hardwares running linux. Feedback on trying to run it on Nokia 770 would be much appreciated. 2006-06-10 HE A short test on my zaurus SL-6000L (original qtopia with installed xqt and kernel 2.4.18) shows: it works.

2006-07-13 EH has been very impressed by revitablized tkhtml3 announced this week, so decided to add it to normal and full versions of eTcl, starting from 1.0-rc11. It's so exiting to be able to write and customize a decent competitor to Pocket IE in just a few hundreds lines of Tcl. A small (yet fully functional and fast) browser derived from HV3, and adapted to PocketPC, will be available for download once rc11 is released.

DK77 I'm not 100% sure, but a tkhtml3 based browser on pocket-pc could be the first mobile browser to pass the acid2 test (cvs only, released alpha version has a few problems with acid2). Gimmickry, to be sure, but a nice attention grabber. EH Opera 9 already claims passing ACID2 test (lot of buzz those days around this). Anyway, being one (if not the first) browser passing ACID2 test on PocketPC is already a great announce to promote your impressive work, and the power of Tcl, for those who still wonder why (e)Tcl on mobile would be useful. Release 1.0-rc11 is based alpha6, but since you committed my patch for declarations not at begining of blocks in CVS (required for compiling with EVC4), I will drop my patch and get synced with CVS for future releases (and releases are frequent). So rc12 will be the one enjoying Tkhtml, and its derived browsers, passing ACID2 test.

2006-07-25 EMJ I see that if the main menu (on Windows Mobile) has only one item, you get a native-look menu:

but as soon as you add a second item, you get the menu with SIPButton at the extreme right. Is there any way to get the "native"
    Left      SIPButton      Right

effect? (Happily building on e: a tiny editor plugin for eTcl + htext as eTcl plugin + SQLite and various bits from other places to produce a cousin of Notebook App on a Dell Axim X51v : 20 Jun 2007 - no longer trying to do this)

2006-07-25 HE On Windows Mobile 2003 the SIPButton is allways at the extreme right. The SIPButton in the middle is the behaviour on Windows Mobile 5.0. Personally I like the Windows Mobile 2003 way. The handling is more platform independent and if we have more then two main menuitems, we save opening one menulevel (On Window Mobile 5.0 the application menu is on the right side. To see the main menuitem we have to open it). Also I like that my application works in the same way on Windows Mobile 5.0 and Windows Mobile 2003. If there is a way to realize EMJ's wish, I hope there is also a way to change the menubehaviour per configuration. EH eTcl creates menubar calling SHCreateMenubar(), then fill it with menu entries, but does nothing special to force the way OS decides to display this menubar. With WM2003 and WM2003SE, OS always renders it as a grey bar, with menu headers on the left, and SIP button on right (SIP button can be hidden using embedded wce package). On WM5.0, it behaves the way you describe. But it seems to me this is the normal native way Microsoft wanted it to be. am I wrong? Also, note you may program the left and right softkeys the way you want, using wce extension. But maybe I am missing something. Please, don't hesitate to give me an example of an application having the "native behavior" you expect, and I will look at a way to add support for this, if not as defaut menubar behavior, at least as an option in wce package. EH About HE comments: I din't give it a try, but maybe you can add a disabled, blank menu entry in your menubar, which will force WM5.0 to display it the way you like, since it would then contain more than one menu header. EMJ I don't understand anything about the softkeys - I should do some research I suppose. Most of the built-in applications - Today, Calendar ... - have the two-item menu, left and right of the SIP button, which is why I though of having that look for the simple screens in the application. It is often menu on the right, most common operation on the left. Actually, I agree with HE that the extra layer may be bad unless the menu is just a few items. And I don't care enough for anyone to spend days on the problem.

2006-8-1 [MT] Please advise: I type in 'gets stdin name' console will not wait for keyboard input but always return '-1' immediately, is this a bug?

MG gets the same behaviour using a 'regular' ActiveTcl install on Win XP. I think it's caused by the fact that non-Unix systems don't have access to the real stdin, but have a 'fake' stdin/stdout/stderr set up using a pure-Tcl console. - RS: But see gets workaround.

***2006-08-11*** M1T I'm having trouble getting data from GPS ID (documented at [1] ) in WM5 using eTCL. If I use the hardware port (COM1: on my system), it works; but that is monopolizing the port. If I use the program port (COM7 on my system), I don't get any data. The program port works with other legacy GPS apps, using CreateFile, ReadFile, and CloseHandle. EH Will try to look at this. Most development/testings are made on WM2003/WM2003SE devices, and unfortunately, I currently have no such WM5 device with such an intermediate driver for testing. I may need to provide you with a debug-enabled version of eTcl to get more log about this for fixing. M1T: Sure, no problem; just let me know how you want to handle that.

***2006-08-11*** M1T removing the issue about seeing my USB port disconnect occasionally after running a tcl script, since I have now seen it happen without eTCL even being installed. Sorry for the distraction.

Other than that, I think eTcl on a PPC is looking very promising. Getting started was a little rough for me. This page, being chronologically organized AFAICT, was a little hard to follow. Any interest in a "Getting Started", or "Tips and Hints" page? I could add a few things while they are fresh on my mind. EH It was (and still is) on the agenda to add FAQ, tutorial, and more documentation on Evolane site, so this wiki page was more used for all kind of user feedbacks, bug reports, feature requests, annoucements, etc... But if you start such a page, It will be quite precious and I will do my best to contribute and help maintaining it as a better entry for newcomers to get started with eTcl. Some clean up on this page should probably be done, but I don't really feel confortable in editing/reorganizing what others have contributed. M1T: I will try to do that. Should I start a new page (if so, what should I call it), or just put it at the top of this page? Some of the things that I document will probably be obvious to the more experienced Tclers, but they weren't obvious to me (at least not until I figured them out).

***2006-08-17*** [tvtk] I'm also having trouble with BT serial comm and GPS. While issuing just this:
 set Gps [ open {com5:} {RDONLY} ]

the BT Manager dialog opens twice, and after the eTcl reports error /couldn't reopen serial "com5:": no such device/. At the same time other sample GPS app opens the connection smoothly (BT manager dialog opens just once). I've also tried standard Tcl/Tk distribution v8.4.4 and there my following simple code seems to work just perfectly:
 set Gps [ open {com5:} {RDONLY} ]
 while { 1 } {
   if { [ gets ${Gps} GpsSentence ] > 0 } {
      puts ${GpsSentence}

My HW/SW config is: iPAQ H3970, Win Pocket PC v4.20.1081, GPS Nokia LD-3W Any idea? EH Thanks to your report, it sounds like problem is not with WM5.x intermediate driver, but with any kind of serial I/O on virtual driver in eTcl. We have similar hardware available for testing, so will be able to focus on this and provide fix ASAP. 2006-08-18 EH made some changes on the way serial device is opened on WinCE, which may fix at least the "open twice" issue, maybe all issues with serial I/O. Patched executable is available as http://www.evolane.com/download/mirror/etcl-wince-dev20060819.zip for testing. Your feedback would be appreciated, before making another release candidate available. 2006-08-23 M1T I tried the patched version, and it opened the port, but seem to hang even before I executed the fconfig. Previously (with rc-12), the fconfig would fail, and I wouldn't get data, but with the 8-18 version, I don't seem to even get that far. This was with WM5 and the GPS ID. Just to verify: I copied the patched executable into the /program files/eTcl directory and execute it from there, correct? EH Bad news :-( Actually, I believe problem with WM5 and GPS intermediate driver is different from problem with WM2003 and bluetooth GPS device reported by [tvtk]. Later should be fixed now (works for me with iPaq 4150+TomTom BT GPS). For the GPS ID issue, we will try to physically get access to such a WM5.x device with GPS Intermediate Driver for testing, since debugging something we can't reproduce isn't that obvious unfortunately. 2006-11-06 [tvtk] Oops! As you can see, it took me a while to notice, that EH made the fix, to test it and to respond, but it's working fine for me since the end of September ;-) Great support, many thanks!

***2006-08-28*** [bsaunder] First of all loving eTcl...What a way to breath functionality into a "no longer supported" fully functional device. Way to save the landfills...

Some benchmarks: These are from my 400mhz PXA255 NEC Mobilepro 900 running HPC 2000(CE 3.0). (Rumor is that this version of CE is NOT optimized for the PXA and therefore kinda equivalent to a 206mhz SA1110)

Time to load: eTcl RC12 and application

Applications were hello_world.tcl (button .b -text "hello world" -command {exit}; pack .) and GemGame from the wiki(32kb).


All times in seconds, and approximate, very approximate

RAM,Internal Disk,Compact Flash





Some ideas: - Suprised that there isn't much difference between compact/std/full versions which are ~ 1.5 mb/3mb/4mb

- So I guess "load" time isnt that much of a factor...it must all be in etcl(or tcl) initialization time

- So size is the only reason to choose between the different versions(both in RAM and disk space)

- Would it be possible to add a flag to eTcl to load a splash screen before running the Tcl code? Ie something like:
     etcl -splash myintro.bmp -delay 5 hello_world.tcl

  Which would display the myintro.bmp file as soon as possible(immediately) and show it for at least 5 seconds.
  I think this would add some "polish" to eTcl and reassure the user that the application is coming.

2006-08-30 EH WinCE, just like most modern O.S., supports on-demand paging, so it loads only the memory page containing the portion of the application that is currently executing. Running full version without calling an extension is just equivalent to running compact version. Only available storage matters when choosing from compact, standard or full version, not speed or RAM usage (except of course ramdisk usage, if you don't store executable on flash memory, sdcard, ...). Your benchmarks are pretty bad, but not that surprising on WinCE 3.0 device. While eTcl for WM2003/5.x is optimized for XSCALE CPU, generic (and unsupported) WinCE3 version is compiled for generic ARM CPU. Those CPU are missing instructions to quickly load non word-aligned data, so it is quite possible Tcl bytecode is pretty unefficient on those architectures. On an iPaq 4150 (PXA400Mhz), load time for console is less than 2s.

2006-08-30 [bsaunder] Any chance of getting a PXA255 optimized version of the WinCE3 version of eTcl? Is eTcl for sale yet? 2006-09-07 EH Custom eTcl builds, sources, commercial-grade support and/or licenses to distribute are available (send a mail to me or to support at evolane.com). By the way, got three mails from you about those questions, and replied all of them, but never got an answer from you to my replies. Any chance my replies all got lost?

2006-08-30 [RL] I have added BWidget and tcllib to the lib directory under my etcl installation directory. Only BWidget is found on a package require statements. Any ideas on why this might be? I removed BWidget and tcllib was still not found. EH When a .etk (i.e. a .zip) archive is found in lib directory, it is automatically mounted and its mount dir is appended to auto_path. For BWidget, pkgIndex.tcl is just one level below this mount dir, so it is found by Tcl. in tcllib directory tree, pkgIndex.tcl files are two level below (e.g. modules/aes/pkgIndex.tcl, etc...). You may add the 'modules' subdirectory to auto_path. But it is simpler, and more compact, to create a ZIP archive containing only the modules directory, and copy it as lib/tcllib.etk on your device. Hope this help. [RL] Thank you. I extracted only the libraries I needed to use and placed them in the Lib directory. It works perfectly.

2006-09-19 [RK] I'm a bit confused about the licensing terms. One part says "1. You may use this Package for commercial or non-commercial purposes without charge". Another part says "You may not distribute copies of this Package, or copies of packages derived from this Package, to others outside your organization". Would not developing a commercial application with ETcl require distributing the Package as well as the application code and thus cause a conflict? EH We didn't want to spend much time worrying about license, and found terms in ActiveTcl very well adequate for a Tcl/Tk binary distrib, so eTcl license is just similar to ActiveTcl one. I believe there is no conflict in license. First part says anyone can download it for free, and run any Tcl code (including commercial one) with it, while second part aims to let the final user know where the runtime comes from, and let him update it for free, independantly from the application code. Being allowed to create a new distribution which contains both the eTcl Package and your application is something different, no matter your application is commercial or not. IMHO, this is something very common for a runtime engine (e.g. Java runtime, Flash player, .NET runtime can all be downloaded for free and run commercial applications, but developpers can't put them on a CDROM or redistribute it without permission and/or getting a license). If the generic terms raise problem, don't hesitate to let me know by contacting me directly (see EH).

2007-02-27 M1T Can someone give me an example of how to use the "wce fullscreen" function? I have tried it with the name of a frame widget and a toplevel widget, but I get "Window is not mapped" messages.

Also, when first launched, my windows have the name "Etcl console" rather than the name from "wm title . name". The contents of the window is OK, but how do I get the title from my window to show up in front of the console title? When I tap in the window, it updates to the correct title, but not initially.

A code snippet is below, if you would like to shoot holes in it directly ;-). Uncomment out the "wce fullscreen" line to see the 1st problem. Thanks in advance.
    wm title . test
    wm minsize . 20 40

    frame .top -background gray -width 10 -height 10
    if {[catch {package require wce} result]} {
        set sinfo [list 10 10 240 320]
    } else {
        #wce fullscreen .top
        set sinfo [wce sipinfo]         ;# 0 26 240 214

    wm geometry . "[lindex $sinfo 2]x[lindex $sinfo 3]+[lindex $sinfo 0]+[lindex $sinfo 1]"

HE The manpage of wce says, 'wce fullscreen toplevel'. So try to use . instead .top.

I tried the following from the etcl console:
  frame .top -background gray -width 10 -height 10
  pack .top
  package require wce
  after 3000 {wce fullscreen .;wm geometry . 240x360+0+0}

In the 3000 ms of the after command, I used the button in the etcl-toolbar to change to the application window.

2007-02-28 M1T Thanks. The trick seems to be to use "after 200 { wce fullscreen .} "; I had previous tried " wce fullscreen ." by itself and it didn't work. Is it typical to have to wait after install a package before using it, or is that a bug?

Also, I realize that I can tap a window to update the title, I was wondering if there was a way to force it to update without user intervention. EH Windows Mobile displays in titlebar title for the toplevel window which has focus. If your application has several toplevels, or a visible console, raise (or give focus to) main toplevel , with correct title set, to have this title displayed in title bar.

EH Are you sure "wce fullscreen ." is what you need? This is useful to switch application into kiosk mode, that is when title bar and SIP/menu bar should both be inivisible (e.g. media player, games,...). This is a wrapper around SHFullScreen() API, which requires window to be mapped. So you probably want to call "wce fullscreen ." either after an "update", or as a callback for Map event. If what you want is actually to have your application fill normal application zone, while leaving title bar and menu/SIP bar intact, what you are looking for is probably "::etcl::autofit .", or even "::etcl::automanage .". Later can be called on not yet mapped window, and will register all calbacks so that your toplevel window will get resized when required (screen rotation, SIP status modification, etc...).

2007-03-02 M1T Thanks. The "update idletasks" before the "wce fullscreen." works great. And yes, for this particular app (an LCD checker, where I want to turn every sub-pixel of a certain color on), fullscreen is what I want. However, for most other apps, "::etcl::autofit ." will be more appropriate, and I appreciate the pointer.

With both "wce fullscreen." and "::etcl::autofit .", the window seems to be bigger than the display, but I will further investigate the values returned from "wce sipinfo". I have already revised my geometry command to:
        wm geometry . "[lindex $sinfo 2]x[expr {[lindex $sinfo 3]+[lindex $sinfo 1]}]+0+0"

but, I may still not have it correct. But, I didn't issue a geometry command after "::etcl::autofit ." (should I have?).

"::etcl::automanage ." and giving focus isn't yet working for me (but thanks for the pointer). The "::etcl::automanage ." locked up my handheld. But, I'll keep trying. Very likely, I am still doing something wrong. I am still struggling with the concept of scheduling screen updates.

[DW] Hi, eTcl on the Pocket PC looks really cool so far, but I'm trying to build a minimalist web browser (as part of a larger project) on my phone edition device. So far, I'm running into the problem that I have to go to another application, like Pocket IE to establish a connection, before I can use http::geturl to get a web page. Is there any way to get eTcl to use the Connection Manager Establish/Release functions to dial up to the GPRS/CDMA network? Or do I need to write a tiny app and start it in the background to open or close my connection? 2007-03-03 EH There is currently (1.0-rc17) no way to access connection manager API from eTcl. However sounds pretty easy to add a wce subcommand to access the ConnMgr API and make it possible to establish programmaticaly a connection synchronously. Thanks for suggestion, you may expect to have it added in next release. In the meantime, if you have some suggestions about additional options such a subcommand should support (while keeping it simple for now), please let me know. Now eTcl core is pretty stabilized, more work will be done on wce extension, to support accessing a larger set of WinCE API.

SSch You can [exec] a MortScript [2] for this task. See the Connect command.

PWE Is it also possible to include bluetooth in wce? At present I manually switch bluetooth on if I want to receive the data from a gps receiver.

2007-05-15 M1T

Here is a little buglet in the smartphone version: if you do menu/file/source and immediately cursor down to the tcl script, it will create the path as "\/\My Documents" and reply "no such file".

However, if you do menu/file/source/menu, and then select the "My Documents" option, it will create the path correctly and execute the file.

2007-06-01 [easypeasy]

I use a beam proc to send files using PPC (Bluetooth/IR) which does an :-
  exec /Windows/beam.exe path &

Note path must be normalised and converted to a PPC path first (simple regsub proc elsewhere).

rc18 has font problems under win32 where you cannot change console font size anymore :-( Hope this is fixed in rc19.

EH In rc18, few problems have leaked into console code (e.g. file association broken), and were fixed as soon as they were reported to us (and before rc19 was out). Please do not hesitate to report bugs as soon as you detect them, either here or by email (see Eric Hassold). Starting with rc19, file nativename has been fixed to return normalized PPC names (using backslashes), so regsub trick you mention should now be useless.

2007-07-17 HE rc20:
 console eval {.console configure -font {{MS Sans Serif} 8}}

doesn't work anymore ('unknown option "-font"'). This works in the past (rc17). I think this is the same problem [easypeasy] described above. 2007-07-19 EH Changed the console widget tree, to prepare conde for multiple interp ala tkcon, and other cosmetic changes (better handling of scrollbars, sliding frames, etc...). As a consequence, the text widget is now called .console.frame.content.text. I didn't find any reference in documentation saying console text widget is called .console, so I thought this changes was acceptable. But maybe I'm wrong?

2007-06-26 Add a eTcl bugs and comments page on Wiki to separate chronological or per-release comments from general documentation.

escargo 28 Jun 2007 - I'm thinking of getting a new Windows Mobile 5 phone. It's not clear to me how you actually install eTcl on such a phone, and how to later add Tcl files to run with it. Is there a clear explanation somewhere? EH Once you have one of those nice little engine, you will find eTcl installs quite easily, in the same way any other applications you will wish to install on it. The most common way is connect your device to your PC using ActiveSync (or WMDC on Vista), a free application made by Microsoft (and usually delivered with your device). Then, you run eTcl installer directly from your desktop, and application will be pushed on phone automatically, together with a shortcut in your Programs menu. Since eTcl is distributed as a single file binary, without any dependencies, and not requiring any entries in registry, you can also simply extract executable from ZIP distribution, and copy it anywhere on your device, either via Activesync (which mounts phone just like a mass-storage disk) or by copying it on a flash memory (e.g. SD card) and plug that memory into your device. Of course, for the latter, no shortcuts is automatically created. That's not a problem with PocketPC Phone Edition (which has a file explorer to launch executables anywhere), but can makes things a little bit unconfortable with Smartphone (i.e. very small devices without touchscreen and file explorer). Last, eTcl has a console menu which allow you to easily associate some extensions (.tcl, .tk and .etk) to executable. Once association is set, you can copy .tcl files (or .etk kits) on your device and "click" on them to starts them. eTcl runs on both Smarpthone and PocketPC Phone Edition, but you will find eTcl much more easy to use on the latter (QVGA or VGA screen, touchscreen as pointing device, file explorer, etc...).

2007-09-28 eTcl 1.0-rc23 is available, based on Tcl/Tk 8.4.16. Support for Odyce embedded C compiler has been added.

MHo 2007-10-10: The url for Html Viewer 3 (2007-08-01) kit on http://www.evolane.com/software/etcl/ is invalid. Ok, Workaround is easy: navigate to http://www.evolane.com/download/etcl/noarch/ and rightklick the right file... EH Thanks for reporting. I enjoyed this opportunity to upgrade kit with up to date sources of hv3 , and fixed content-type for .etk files on our server to allow direct downloading.

[sailco] 8 Mar 2008 - The grammar::peg package (http://tcllib.sourceforge.net/doc/peg.html) of Dr. Andreas Kupries ([email protected]) is available to etcl users. If you would like to try it, perhaps the notes at the "grammar_peg" wiki http://wiki.tcl.tk/15512 will be of some use. Here are some general references on peg grammars: http://en.wikipedia.org/wiki/Parsing_expression_grammar http://home.swipnet.se/redz/roman/papers/FI2008.pdf

JMN 2008-04-03 I'm just trying out eTcl 1.0-rc27 with some of my existing code. Do you know a reason why thread::transfer would be failing? I haven't dug deeply - but I believe it happens when trying to transfer one end of a Memchan fifo2 channel to another thread.
 the error is 'transfer failed: target thread died'

The error doesn't occur in my usual tclsh shell (8.5.2b1) - but I notice that I use Memchan 2.2.1 whereas eTcl uses 2.3.0 - so perhaps it's just a Memchan issue.. 2008-04-03 EH Could you report platform, and eventually small code to reproduce error? I tried this with eTcl 1.0-rc28 on linux, and didn't get any error:
  package require Thread
  package require Memchan
  foreach {f1 f2} [::memchan::fifo2] {break}
  set t [thread::create]
  thread::transfer $t $f1
  thread::transfer $t $f2

Also, I will consider moving this report into eTcl bugs and comments later.

jmn It turns out it was a silly error on my part - the thread was attempting to write to stderr, when stderr isn't available under eTcl. I guess it returned a 'transfer failed' because the thread was already in the process of dying due to the stderr issue at the time the transfer occurred. Sorry for the noise and time wasted - I'll leave it to you to delete this noise from the page. cheers.

HE 20080429 Is there a way to call eTcl like the tclsh without gui (on w32)? The idea ist to run a tclscript with etcl in 'scheduled tasks' on windows.

[serg] 2008-06-16 Is there a way to access WinCE databases, PIM from eTcl ?

SB Is there a way to write into a *.etk-file at runtime? I first tried it with a starkit and it worked:
  set myFile [open [file join $::starkit::topdir myfile.txt] w]
  puts $myFile "some text"
  close $myFile

But after converting the *.kit-file into a *.etk-file it always raises an error saying:
  channel "channel-ID" wasn't opened for writing

mz i try to get the package ftp within etcl and i keep getting the error cant find package ftp. what am I doing wrong? mz Ok. I should know better as our main program is written half in TCL, but on linux. I created a lib directory under the eTcl directory on my wm6 machine(a tilt) in program files, and copied the tcllib-???.etk package there. Now the ftp package comes up. Thanks HE. HE 2008-11-16: On XP with etcl-1.0-rc29-win32.zip I got following dirs and files:

and some other. if you start etcl.exe you get the console. you can start ftp with
 package require ftp

because the ftp package is in tcllib. you can drop every package which runs under win32 in the directory ./lib or ./bin/lib.

SRIV It's a shame the Tcl community can't help anyone regarding eTcl, as its proprietary and closed source. Users beware. HE 2008-11-16: Why beware? If you want to run tcl on windows mobile, there is no alternative. And for most uses it is simply another distribution like activeTcl or tclkit. And only tclkit is completly free, non proprietary and nonclosed source (as far as I know). SRIV 2008-11-16: For "most uses", perhaps. But ActiveTcl source is available. For businesses that choose tcl to avoid proprietary vendor lock-in , eTcl is not a viable choice at the moment. Although I have read eTcl source would be released, but that was around 2 years ago. EH How are ActiveTcl sources more available than eTcl ones ? Are you able to generate your own ActiveTcl binary from scratch ? All binary distributions share same Tcl/Tk sources. Binaries are provided both for convenience (for those final users who don't want to handle the (hard) job of compiling, validating build process, etc...) and for helping business users to get professional support. AFAIK, ActiveState works strictly on the same model, providing both ActiveTcl distribution for free (with a strictly similar license than eTcl's one), and OEM license for redistribution, high-quality support, ... eTcl includes some (optional) closed sources extensions (e.g. pixane), just like ActiveTcl has some (tbcload, ...). You may, as an industry user, decide to generate and manage your own and custom Tcl binary from sources. What you'll get is neither an ActiveTcl binary, nor an eTcl distribution, but your own. tclkit and dqkit are efficient ways to get your own binaries from plain Tcl/Tk sources. But on the other side, you may believe you might reduce your costs and time to market by relying on a partner to handle this task, and this is where ActiveState or Evolane (or ...) may help. By the way, all our licenses get full sources, including those of our custom extensions (e.g. pixane). I'm really interested in discussions to receive arguments explaining how eTcl is supposed to be more "proprietary and closed" than other distributions. SRIV Thats very interesting. I haven't been able to find the availability or cost of a license that includes source on your web site, nor the text of that license. I would concede that eTcl is not proprietary if what you say is true. Can I request a quotation and a copy of the license? EH Not claiming eTcl is or isn't proprietary, since eTcl is, like other Tcl distributions (including ActiveTcl), a binary build of open-source components. Individuals finding it useful may use it for free, while professionals expecting more support, expertise, customisation, permissions to redistribute (especially on embedded systems) may contact us. This is the way ActiveTcl OEM licensing works (and neither are licensing details and costs available online, AFAIK, since they may be discussed on a per-partner basis). This is also the way hundreds of companies provide support and binary distributions for open-source components (toolchains, apache, postgreSQL, linux and embedded linux distributions, ...), while those components remain opened. Once again, eTcl core is plain Tcl/Tk, hence sources are available. Added value is in reducing costs and time to market, and supporting different OSes and architectures (Windows Mobile, SymbianOS, Embedded Linux), for partners who cares. If you (or anyone) is interested in those services, feel free to contact Evolane to request information and discuss partnership opportunities and get quotation.

CMcC interjects "tebc is not closed source." EH Is it ? Then sorry, I probably missed where those sources are available from. In tbcload, one can read that last open source version of tbcload does not work on current versions of 8.5 because of the expand syntax changes. The version included in ActiveTcl does work, but the source is not freely available, so this statement has to be updated/fixed, and a link to those sources will be welcome.

makr 2008-11-27: After that last comment - is there a low chance that you actually have eTcl for SymbianOS/S60 available anywhere? Because it really is no fun to develop on that platform, as I tried to describe in Nokia E90 Communicator / Symbian 60 Tcl/Tk Support ?.

2008-11-27 EH We used to maintain a SymbianOS port (S60 3rd) of eTcl (Tk working on top of an X11 emulation layer, so no native SymbianOS look&feel), but not enough time and resources to support efficiently a public release. For little story, same emulation layer is used in some of our Tcl/Tk ports on different STB (direct rendering on framebuffer without X11) or even Nintendo DS. I can't say if it will ever find its way for a public release.

HJG 2009-09-01 - The link to http://www.evolane.com/software/etcl/ now leads to a login-page for "Evolane Premium Support". Does that mean that etcl is no longer freely available ? Also, http://www.larochelle-innovation.com/tcltk/eTcl gives an error 404.

SRIV 2009-09-01 - Like all things related to eTcl, only EH can answer the questions.

jesperj - 2009-11-05 10:15:00

EH: Regarding the license:

I need a way to get my tcl/tk application ported to windows mobile 6.X devices. First eTcl seemed great, then the license made it unacceptable :-( I need to be able to pack my whole application as an easy to install package for the users. Pointing them to download from a website and installing with instructions from there is not going to work. I guess maybe the installer program could fetch the eTcl package directly from your website or something if that would be ok with the license, but I still don't like it as either a license says one can redistribute the application or you can not. Something vague that can be interpreted differently just makes things confusing and can stir up conflicts out of misunderstandings. So, since your license says I can not redistribute eTcl, I will probably look for another solution.


Kroc - 2009-11-05

According Evolane Community Licence, you can distribute copies if you got a written permission. You just have to ask before.

EH - 2009-11-08

You question me directly, but I don't have email to answer you, so I put a note here to reply, which will be deleted later.

I'm reading your comment, and can't figure out what is your question or request. You don't mention anything about your "application", if it's commercial or not, free or not, open-source (and which license, BSD, GPL, Apache, ...) or not, etc. If it's free and opened application, and have good arguments to explain why having users to download two cabs (one from your site, one from our) is unacceptable in your case, then you have probably already sent a request by mail to Evolane support (can't find one in our mail database so far), with detailed description of your project and your specific contraints, to get a written permission (mentionned in Licence, as Kroc noted) to distribute a copy of eTcl binary with your work with custom conditions (get sure we'll offer such permission with great pleasure if you're working for OLPC or some humanitarian care project).

But if it's a commercial one, and you want neither to ask your users to download a copy (for free) of eTcl binary from our site, nor to pay a license to be allowed to distribute our work with yours, fine, that's you're opinion, but then we can't help. Last, if you were just posting a note to report you won't use eTcl because you dislike our licence (and probably dislike licenses from other Tcl distributions, since e.g. ActiveTcl one is strictly similar), that's your freedom, no problem either (but not sure wiki is right place for this).

[PH] - 2009-02-23

I'm using eTcl on an IGEPv2 (http://igep-platform.com) board using the arm EABI v1.0.1. Although Tcl/Tk works fine the scene widget doesn't seem to be present, when I "package require scene" it states that it can't be found. On the evolane page it states that only WinCE misses scene so it this an oversight in the build or the documentation? One further note: the evolane side also indicates a separate download of scene, but it isn't present anymore.

[Komenor] - 2010-05-03 14:41:10


I try to run eTcl on a Windows Mobile 6.5 smartphone with a real keyboard and no touch screen (Samsung Omnia Pro B7330). I can run "calc.tcl", It appear on the screen, but the keyboard does not responding !

I tried to run a very simple program like this :

package require Tk set VarText "" proc InitGui {} {
  wm geometry . "250x250"
  entry .ent -width 20 -textvariable VarText
  button .btn -text "Quit" -command {exit}
  pack .ent .btn -side top
  pack .ent -fill both -expand yes

} InitGui

The widgets appear, but nothing append when I try to type some text.

Does eTcl works with Windows Mobile 6.5 and no touch screen smartphone ? Thank you for your help.

GS 2011-01-19 If you have a non touch screen smartphone, you can use Virtuamouse [3] to emulate a mouse cursor.

yahalom - 2012-07-19

eTcl is also running nicely on kindle touch after it was jail broken. Details can be found in https://groups.google.com/forum/?fromgroups#!topic/comp.lang.tcl/_dOrXBQs7Ps

RS 2013-01-06 eTcl runs quite nicely on a Sony Ericsson Xperia X2 (Win Mobile 6.5, physical slide-out keyboard). Since that has an 800x480 pixel screen, window and canvas geometries may have to be tuned. Sudoku and Collapse are already up and running. I'll keep you informed here.