Brian Theado 20Jan2005 - Inspired by the wealth of Tcl/Tk games available at sdarchive and elsewhere, I wrote some code that can be used to browse and execute a bunch of applications all bundled together into a single starkit.
I bundled together over 60 games in a just over 2MB starkit that can be downloaded from http://tkoutline.sourceforge.net/tkgamepack.kit . Run the program and see a hierarchical list of Tcl/Tk games. Click on the game title to launch it. Click on the game's url to find more information. Add the title of a game to the command line and that game will be run directly.
Way cool! I've wondered for a long time when someone would take the initiative on this ;) -jcw
LV As of Feb 23, 2005, the game pack contains over 60 games or toys.
LV So, if people come up with additional script only games, how would they go about requesting the code be added?
LV So each time I select a game, a new starkit will end up in the real world flat directory where the starkit resides? Is there no way to run the starkits from where they are in the bundle?
Brian Theado - I guess I didn't explain the implementation well enough. It is a single file and stays a single file. All the games run from within the starkit.
[Removed information about package require Tk error that has been fixed]
UKo 2005-02-23: What are these fixed errors about? There still is an error can't find package Tk every time a game is launched -- if wishkit (8.4.9) is used on Mac OSX. The problem is in the initial auto_path of a slave interpreter. This doesn't contain an entry for the path where the Tk-shared-library can be found (it's not the same place as for the Tcl-shared-library). A workaround is to set the complete path after cloning a new interp in function runSlaveKit:
+ $s eval [list set auto_path $::auto_path] $s eval [list set argv $args]
Brian Theado - 2005-02-24: Thanks for this report. I made the change to runSlaveKit as you suggested. Let me know if it works for you.
It seems to me that this may be a bug in wishkit. I would expect a brand new slave interpreter to look identical to the main interpreter upon startup. If the main interpreter has a certain auto_path at startup, then why wouldn't a slave interpreter have the same? The variables argc, argv, and argv0 don't get set in a slave interpreter, but I think those are different from auto_path and it is reasonable to not set them. I guess there could be an argument either way for auto_path, but IMO the overriding argument should be consistency. Since tclsh and tclkit set auto_path in the slave, then why not wishkit.
BTW, the other package require Tk error [L1 ] was due to a missing package require Tk, not an error when package require Tk executes.
Discussion about keysym error (which has been fixed) moved to Cross platform keysyms.
If you get an error like "couldn't open setup.tcl, no such..." when launching a game like Felipe Voloch reported, then try getting the latest version of tclkit. Any tclkits built in 2004 or later (and probably some in 2003) contain the fix for launching starkits in slave interpreters.
JSI 25feb05 Concerning further updates: I'd propose to keep a current copy of tkgamepack.kit on sdarchive, so SDX.KIT update could keep my local starkit current, updating only changed content. Having it on sourceforge may provide more visibility, but why not use fantastic work already done in the distributed deployment arena? (insert applause!) :-)
Brian Theado - I plan to make future versions available to sdx update. I just initially put it somewhere where I could have quick turnaround time for making new versions as I worked out the initial bugs.
Update 23Mar05 - I haven't uploaded to sdarchive yet, but I did add starsync capability to the download. The following will work to update your starkit:
sdx update -from http://tkoutline.sourceforge.net/cgi-bin/sync.cgi tkgamepack.kit