The FE 'HandyTools' subsystem A Detailed DESCRIPTION ! DEPRECATED ! The FE 'HandyTools' subsystem is to be replaced by the FE 'tkGooies' subsystem. (FE = Freedom Environment)

The main toolchest of the 'feHandyTools' system --- an initial (2011) version.

FE Home page > FE Downloads page >

'feHandyTools' Download page

This
FE 'HandyTools' subsystem
DESCRIPTION page

! Note !
This 'feHandyTools' FE subsystem is DEPRECATED.
It is to be REPLACED by the FE 'tkGooies' subsystem.

This description page is provided for the historical notes
--- and it may be helpful to understand the 'tkGooies' system.

TABLE OF CONTENTS (links to sections of this page, below) INTRODUCTION to the 'FE HandyTools' subsystem (toolchests and app-categories) 'OPEN' CODE and RE-CONFIGURABLE TOOLCHESTS THE SEEMINGLY OBLIGATORY LICENSE DISCUSSION POP-FREE, rather than Pop-Connected, MENUS The TOOLCHEST BUTTONS, common to every feHandyTools toolchest : 'ChgFont' 'ChgColor' 'Help' '>>' 'EditChest' 'EditVars' THE FE HandyTools DIRECTORIES THE 'make_chest.tk' SCRIPT (the core of this FE subsystem) and embellishments : Anti-aliased fonts Icons Themes Skins SUPPORT and ENHANCEMENTS Help Yourself to the code APPENDIX A: Variations on the initials F.E.

Above is an 'feHandyTools' GUI ---
done with a Tcl-Tk script --- for
getting 'man' help on a topic/command.

That entry GUI popped up after a click on the
'LinuxHELP' toolchest, whose image is below.
See the fourth drawer from the top.

This is utility is similar to a 'LinuxHELP'
menu in the 'feNautilusScripts' system,
in which prompting done by a Zenity GUI,
instead of Tcl-Tk scripts.

Rather than spending time duplicating utilities
of 'feNautilusScripts' --- and spending time
using Tcl-Tk GUI's to replace Zenity GUI's ---
the 'tkGooies' system (that replaces 'feHandyTools')
concentrates on providing GUI utilities that are
NOT provided in 'feNautilusScripts'.

So a 'LinuxHELP' toolchest does not
appear in the 'tkGooies' system.

Page 2 INTRODUCTION to the 'FE HandyTools' subsystem : 'toolchests', 'drawers', and categories What the user sees on starting up the FE HandyTools system is a 'toolchest' composed of 'drawers' --- like the chest-of-drawers in the images above. The 'drawers' in the starting 'toolchest' of the 'FE HandyTools' system are categories of tools. See the list of categories, below. When the user clicks on any of those 'category' drawers, he/she calls up another toolchest, offering drawers of tools, in the selected category. In any of the 'category toolchests', most of the 'drawers' are 'tools' (utility scripts) which are triggered when you click on the drawer. However, if the toolchest is over-flowing with tools, some of the drawers may invoke 'subcategory toolchests'. The 'subcategory toolchests' then present utility 'tool drawers' --- or even more 'subcategories'. Usually, 2 or 3 levels of categories suffice. As delivered, the FE HandyTools system provides about 20 to 30 categories of toolchests (menus). About a dozen 'tool' categories are offered in the initial toolchest --- such as the following. (Sub-category toolchests are shown indented.) AUDIO-only tools CHANGEfiles tools EXAMINEfiles tools FILESlists tools FINDlists tools IMAGE-PHOTO tools MORE IMAGE tools LinuxHELPS PLOT tools PROCESS-MEM lists SPACE lists TERMINAL tools VIDEO tools MORE HandyTools (the top-level 'MORE' categories toolchest contains the following 'drawers') 3D tools EXE examine tools FONT tools HOSTCONFIG-FILES tools HOSTCONFIG-QUERY tools LOG file tools MAIL tools ANTISPAM tools NETWORK EXAMINATION tools NETWORK query tools PACKET examination tools OFFICE tools PDF tools PRINT-SCAN-FAX tools SCAN tools FAX tools PROGRAMMING tools USERS-and-GROUPS tools WEB/NET SECURITY tools Xinfo tools With the 'sub-chests' of tools, there are about 30 delivered toolchests in all. There are so many 'IMAGE-or-PHOTO tools' that there is at least one sub-chest with a name like 'OTHER IMAGE tools' to accomodate the overflow. feHandyTools vs. feNautilusScripts For consistency, the toolchests in the 'feHandyTools' subsystem, as delivered, follow the same categories and heirarchical structure used by the 'feNautilusScripts' system. Many of the tools in 'feHandyTools' were 'ported' from 'feNautilusScripts'. When a user can't find what he/she needs in one of these FE subsystems, he/she can try the other subsystem. A significant difference between the 'feHandyTools' subsystem and the 'feNautilusScripts' subsystem is that the 'feNautilusScripts' subsystem uses the 'zenity' tool (available on almost any Linux system) to prompt for user input whereas the 'feHandyTools' subsystem uses Tcl-Tk GUI scripts to prompt for user input. A Tcl-Tk GUI can be devised to almost any order of complexity required. A complex tool might require a *sequence* of 'zenity' prompts, but a single Tcl-Tk GUI could be created to get the user input via one GUI prompt. Altering the toolchests, via the 'chestdef' files --- like 'feAppMenus' The 'feHandyTools' toolchests are created from 'chestdef' files using a Tk GUI-making script called 'make_chest.tk'. This is the same method used to make the toolchests of the 'feAppMenus' subsystem. By simply editing the 'chestdef' files that are used by 'make_chest.tk', the user can modify ANY of the toolchests in just about any way, such as change the order of the drawers in any of the toolchests change the names (and longer descriptions) of the drawers add drawers (tools) to a toolchest remove drawers from a toolchest --- or 'gray out' drawers, that is, de-activate them create a new toolchest by creating a new 'chestdef' file and startup script --- and add the startup script as a drawer in an existing chestdef file reorganize the toolchest hierarchy by moving drawers from one 'chestdef' file into another collapse down two toolchests into one toolchest by moving all the drawers from one 'chestdef' file into another 'chestdef' file Numbers, Names, and Sizes of toolchests You can combine toolchest definition files to collapse the toolchests down into a lower number of categories. But the author of this system finds that he can find tools easier with about 25 to 30 categories. And to make it easier to find tools within a category, the author finds it helpful to keep the number of drawers in any toolchest to less than 20. In too many Linux menu systems, a wide variety of tools are put into vague categories such as 'Accessories' and 'Other', with a max of about 10 categories, total. More specific categories such as 'Internet' and 'Sound & Video' (or 'Media') end up having much more than 20 tools in them, of widely varying functionality. This makes it a chore to repeatedly have to scan an essentially randomly ordered list of tools to find the one tool that one is looking for. Example: In the 'Sound & Video' category of Ubuntu Linux, the list of tools varies among CD-DVD tools, Audio-only tools, Video tools, Webcam tools, and perhaps a few more sub-categories that one could add to this sub-category list. The essentially random order is usually due to the ordering of applications alphabetically by names, and the names are often no indication of the functionality of the tool. Examples: Firefox, Seamonkey, Thunderbird, Brasero, Totem After installing quite a few applications via a Linux package manager, the user can easily end up with 50 to 100 applications in a general category like 'Media' (or 'Sound & Video'). As a result, the author finds it very helpful to have a 'CD-DVD tools' category in 'feAppMenus', rather than having to wonder if a particular CD-DVD app is filed under 'Accessories' or 'Sound & Video' (or 'Media') or 'Other'. And the author finds it much less frustrating having audio-only tools, like the Audacity audio editor, the EasyTAG audio tags editor, and various audio players, in the 'AUDIO-only tools' chest --- rather than searching for them scattered among 30-plus tools, in a 'Sound & Video' category --- which includes many CD-DVD tools, as well as Video tools. Although I am using examples from the 'feAppMenus' FE subsystem, the same categorization considerations (appropriate numbers and names and sizes of categories) apply to the 'feHandyTools' FE subsystem.

Poke this image of the 'AUDIOtools' toolchest
--- to see the Directory-Selector GUI that
appears when you click on the 1st drawer
to use the 'gnome-player' program
to play some mp3 files.

The Directory-Selector GUI is shown in
a separate window or tab.

There is an 'AUDIOtools' toolchest in the
'tkGooies' system --- but that toolchest
has somewhat different options from this one.

Page 3 'OPEN' CODE and RE-CONFIGURABLE TOOLCHESTS : In terms of files, the FE HandyTools subsystem is, basically, a collection of a main Tcl-Tk SCRIPT, 'make_chest.tk' , that generates 'toolchest' GUIs, about 30 "CHEST DEFINITION" text-files, about 20 utility Tk-GUI-generating Tcl-Tk scripts, Linux/Unix SHELL SCRIPTS (more than 100) that are 'wrappers' for the Tk GUI scripts and various Linux/Unix commands an FE HandyTools HELP file (plain-text) and about 15 other plain-text help files and various other files such as 'include' script code snippets and icons. Herein lies the FREEDOM. All program code is in script text files --- either Linux/Unix shell scripts or Tcl-Tk scripts. Each script is easy to browse. There are no source files separate from the executable files --- which can lead to questions of whether the source matches the executables. The source files ARE the executables. Furthermore, to perform functions in shell and Tcl-Tk scripts generally requires many fewer lines of code than C++ or other compiled programs --- which become even more complicated because of their typical need to reference large libraries of utility routines --- especially graphical interface routines. So the scripts are relatively readable, compared to most source code that is intended for a compiler and linker. Furthermore, the scripts are open to direct modification and enhancement. Not so with compiled binary executables. (The author has put an unusual number of comments in the scripts --- mainly for his own benefit in maintenance and enhancement activities. But another benefit is that users have access to a lot of comments describing the general structure of the scripts, as well as comments on small sections and individual lines of the scripts.) Simple 'chestdef' files The 'chestdef' files that define the toolchests have a very simple format. This facilitates the freedom to modify the system. The 'chestdefs' are text files that can be easily edited. The format is described below, in an 'EditChest button' section. As delivered, the initial chestdef files contain some commented (or 'grayed out') example 'drawer'-definition lines, as well as activated lines. The activated lines can be commented or the commented example lines can be activated, after implementing the associated script. Changes via GUI buttons or via file operations The FE 'HandyTools' system is a *REALLY* 'OPEN SYSTEM'. If you do not like the way the 'toolchest' system is organized or its appearance, you can make changes. There are basically two ways you can make the changes : (1) via the 'EditChest' and 'EditVars' buttons on the toolchests or, to have access to EVERYTHING, (2) via more general manipulation of the files in the various installation directories --- like 'chestdefs', 'chestdef_scripts', 'scripts', 'tkGUIs', 'includes_tk'. The directories are outlined more fully in a section below. For example, I use Nautilus as a GUI file manager --- often with 3 or 4 directory windows open at directories 'tkGUIs', 'scripts', 'chestdefs', and, sometimes 'chestdef_scripts'. And I use 'TERMtools' of 'feNautilusScripts' to open a shell (command interpreter) window, positioned at one of the scripts directories --- to see error/debug/trace messages written to 'stdout' while doing script testing. Via the 'EditVars' button, you can change appearances, by changing values of parameters, which control toolchest and other Tk GUI fonts --- for buttons, labels, listboxes, etc. in Tk GUI widgets colors --- such as the 'palette' of Tk GUI's geometry --- such as padding in Tk GUI widgets apps --- such as those used for HTML browsing and image viewing/editing Via the 'EditChest' button, you can edit a 'chest definition' file to: change the order of apps in the 'toolchest' change the apps being presented add new ones comment-out or delete some let some app-lines show as 'grayed-out' --- as placeholders or reminders --- for future activation change the app name or description shown in the toolchest --- even translate to another language add separator lines or change the location of separator lines add or remove section heading lines, or change the wording in those section headings (or translate to another language) Some changes to the toolchests would have to be done via operations outside the functionality of the GUI buttons --- such as copying and renaming of 'chestdef' files --- and editing those new 'chestdef' files and the scripts that present the toolchests. For example, by using those kinds of operations: You could break a 'toolchest' up if it gets too large. If you want to break part of the 'drawers' off into a new sub-category, copy the 'chestdef' file into another 'chestdef' file, edit the two chestdef files, and provide a new 'toolchest' startup script for the new 'chestdef' file. You could go the other way: consolidate a couple of chestdef files into one chestdef file, and 'retire' one of the toolchest startup scripts. Also, you can edit a 'toolchest' startup script to change the top window-manager-bar title (or the icon title) for the toolchest --- or change where it pops up on the screen. The toolchests are in a Network, not a Hierarchy Note that the 'drawers' in the 'toolchests' do not have to have a hierarchical order --- any toolchest can call any other toolchest. A 'child' toolchest can call a 'parent' or 'grandparent' toolchest --- so that the concept of parent-child relationships can actually become almost meaningless. For example: A VIDEO-tools toolchest can call an AUDIO-tools toolchest and vice versa. In fact, an AUDIO-only-tools toolchest and a VIDEO-tools toolchest and a CD-DVD-tools toolchest can all call each other. About the only notion of a hierarchy that remains is that the 'feHandyTools' toolchest usually starts the menu chain off --- showing some of the most-frequently-used tool categories and a 'drawer-link' to an 'OTHER categories' toolchest, for a total of about 20 to 30 tools-categories drawers. So the 'feHandyTools' toolchest could be considered to be at the top of a hierarchy. But, actually, the user could start any of the other toolchests via its startup script and any of those toolchests could have a drawer that starts up the daddy or grand-daddy 'feHandyTools' toolchest. Some people would call this structure a 'network structure', rather than a 'heirarchy structure'. Any node (toolchest) can have a 'link' to any other node (toolchest). No frustrating rock-and-hard-places (no Catch-22's) You can re-organize the system in many ways --- and enhance it in many ways. You do not have to wait for a new release for a fix or enhancement. In fact, this author was motivated to create this flexible menu system after an unpleasant experience in using a KDE menu editor to edit a KDE tools menu. I made some menu changes using the menu editor, and got into a Catch-22 situation where an app that I added was not showing up, but when I tried to add it again, it would not let me because it said it was already there. I was stuck with no clear way out of that hole, other than re-installing KDE --- and then never touching the menu editor again. I will never encounter a dead-end like that with this FE HandyTools menu system.

Below is the 'PLOTtools' toolchest, expanded
to show the normally hidden right-hand side.

And below are images of the 3 plot GUI's that
appear when clicking on the 3 drawers shown.

NOTE:
These plots are SCALABLE (zoomable), when
the user clicks on the 'UpCan' button.

Page 4 THE SEEMINGLY OBLIGATORY LICENSE DISCUSSION : Partly because of the 'extreme open-ness' of the FE subsystems, the FE subsystems are provided in a freedom-to-copy-and-share and freedom-to-enhance mode (i.e. we are talking about the proverbial 'license' here). The other reason for 'freedom-to-copy-and-share and freedom-to-enhance' is that I am growing old and I would like to pass this useful software on to future generations, for free. NOTE: I do not use the word 'free' for two different concepts --- 'freedom' and 'no cost', like the GPL license does. To avoid confusion, I use the word 'freedom' for 'freedom' and the word 'free' for 'no cost'. So when I say "The 'Freedom Environment' is a free environment", I hope it is clear what I mean. (It means you do not have to pay for it --- to make that perfectly clear.) On obtaining this software, the only requirement is that, if you make enhancements, to one of my releases (or to enhanced versions of the FE system, made by others), those enhancements are available, upon request, at no cost, to me (the initiator of the system) --- and at no cost to anyone in the chain of people who created the version from which you started your enhancement --- and at no cost to anyone who wants to make an enhancement to their copy of an FE subsystem (any of the evolutionary offshoots of the original), even if the requestor never made an enhancement to a version of the FE subsystem themselves. (The only 'sharing' charge can be a reasonable charge for recording media and shipping --- both of which would be essentially zero if the code is delivered via download over the Internet. Since the code of any of the FE subsystems is much less than 20 Megabytes, the entire enhanced system could and should be delivered upon request. Even a heavily enhanced version of my releases of any the FE subsystems would occupy less than 3% of a CD, less than half of 1% of a DVD, and less than 8% of the smallest 'thumb drive' = 'USB stick' available nowadays. A copy could be transferred over a broadband Internet connection, even a slow connection, in much less than a minute --- within a few seconds, in most cases.) It is my hope and intent that the FE subsystems can evolve like the Linux kernel and Linux distros. That is, any of the FE subsystems is started as a free 'core' to which anyone can add --- and if they wish, enhancers can charge for support of their version --- bug fixing, question answering, further enhancements, training, and the like. But their enhanced code must be provided at no cost (as outlined above) upon request --- else stop any and all charging related to the enhancements and the original code. Like Linux distros and applications, I expect there to be many versions (evolutionary states) of any FE subsystem code --- available for free --- media and delivery costs excepted. And I expect that competition (and all code enhancements available to all requestors for free) will keep prices for 'support' (as outlined above) reasonable. I guess I need a name for the 'license' described in the above statements --- since it is not quite a GPL or BSD or any other kind of license --- although it is certainly in the spirit of those licenses. If I ever refer to this 'license' again, I will call it the 'FE license', for short. By the way, here is the usual disclaimer --- in the usual caps. THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHORS OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

Above are three feHandyTools 'toolchests'
that might typically be on a desktop.

The toolchests can be dragged down to
the bottom of the screen, leaving
only the title bars showing, so that
the chests are out of the way --- but
they are ready to be dragged into action
at any time, by those title bars.

Alternatively, on most desktops, click on
the minimize symbol at the upper right
of the title-bar to make a toolchest iconize
into a desktop tasks panel.

Note that you can close any one of the
toolchests in the usual way that you
close a window --- click on the upper right
(or left) of the window bar.

These windows are independent of each other,
so that you can 'kill' any one of them and
the others will remain --- even if you close
the one that started off the 'spawning'.

In other words, as soon as a window is spawned,
there is no parent-child relationship anymore
like there is among the processes you
usually track with the 'ps' command.

For each chest, you will see a
'make_chest.tk' process in a processes list.

Page 5 POP-FREE, rather than Pop-Connected, MENUS Each 'chest' pops up as a separate window --- rather than being attached to the chest from which it popped up. A nice property of the un-attached toolchests: You can close 'parent' (spawner) toolchests and 'child' (spawnee) toolchests are left open. One consequence of these features is that the toolchests are, quite naturally, a 'network' rather than a 'hierarchy'. There is no 'king' and no 'serfs'. Any toolchest can be closed --- and any toolchest can be left open (when its 'predecessors', NOT its 'overlords', are closed). There are predecessors, not overlords. A predecessor can be closed without resulting in the closing of its successors. There is an equality among all toolchests. For example, a 'Video-tools' toolchest can include a drawer that triggers a 'CD-DVD-tools' toolchest, and, at the same time, the 'CD-DVD-tools' toolchest can include a drawer that triggers the 'Video-tools' toolchest. You could say: 'Child' chests can trigger 'parent' chests. One toolchest does not become the 'master' toolchest just by facilitating the opening of another toolchest. In fact, any chest can trigger the 'top', usual-startup chest, the 'feHandyTools' chest. In other words, the 'main' 'feHandyTools' chest can be a 'drawer' in any other toolchest. You can close each chest in the way you usually close windows: click on the upper right (or upper left) of the window. If you need to keep a toolchest around for a while (to use various drawers within the toolchest), you can drag the window down to the bottom of the screen where just the title bar of the chest will show. Later, you can drag the chest up again, to use the drawers. Alternatively, you can click on the 'Minimize' indicator of the title bar of the chest, and the chest will be stored within the desktop taskbar, for later retreival. And, with some window managers (KDE), you can double-click on the titlebar of the chest and the chest will disappear leaving only the titlebar of the chest in place. This is the 'roll-up window shade' effect. Double-click again, on the titlebar of the chest, to restore the chest.

The 'SPACEtools' toolchest --- handy for
finding your biggest directories
(both in Megabytes and in numbers of files)
--- and the biggest files ---
when disk space is running out.

There is a 'SPACEtools' toolchest in the
'feNautilusScripts' FE subsystem.

Rather than have a similar 'SPACEtools' chest
in the 'tkGooies' system that is replacing this
'feHandyTools' system, the 'SPACEtools' of
'feNautilusScripts' can be used.

Page 6 The TOOLCHEST BUTTONS, common to every feHandyTools toolchest At the bottom of any of the toolchests are a few buttons --- labelled 'Help', 'Color', 'Font', and '>>'. The 'Help' button : Click on the 'Help' button and a plain-text help file, with content like the content of this web page, is shown. That plain-text help file and many of the other (plain-text) helps of the FE subsystems are shown with an FE system utility called 'xpg' --- which presents the text in a GUI, via a 'shofil.tk' Tk script. The FE 'xpg' utility is a scroll, search, extract-match-lines, and print utility for text files. Click on the 'Help' button of the 'xpg' GUI to see a description of those features of the FE 'xpg' utility. The 'extract-match-lines' feature is rather unique and can be a great help when browsing through huge text files in search of particular sections of information or data items. The 'Color' button : Click on the 'Color' button and a GUI with Red-Green-Blue slider bars appears, to allow you to change the background color of the (current) toolchest. This could be used to help you rapidly choose among several open FE toolchests via color. Or you can change the toolchest color to go better with your screen background. After some experimenting with the 'Color' button ... You can change the color 'palette' of ALL the toolchests and GUIs of the FE system by editing an FE system Tk script 'include' file to change the value of the three Tk variables --- r255, g255, b255 --- that are used to set the color 'palette' of the FE toolchests and Tk GUI's. There is more information on editing the Tk 'include' files, in the description of the 'EditVars' button, below. The 'Font' button : Click on 'Font' to change the font of the toolchest 'drawers' (which are actually Tk button widgets) and the font of the drawer-section-titles, if any, of the (current) toolchest. This could help those who need bigger/bolder print for readability. Or, try it just for grins. (Try a Greek letter font or a 'whimsical' font among those available on your computer. You can browse through the available fonts via the 'FE Font Selector' GUI that is presented when you click the 'Font' button on the toolchest.) After experimenting like this with font possiblities, the default font of ALL the toolchests can be 'permanently' changed by editing an FE system Tk 'include' code file. See more on editing the Tk 'include' files, in the 'EditVars' button section, below. The '>>' (and '<<') button : Click on the '>>' button and the toolchest expands to the right, showing some longer descriptions of the toolchest drawers. You can change these descriptions --- the short ones and the long ones --- on the left and right parts of the toolchest. For example, you can translate the descriptions to a different language --- by editing the 'chestdef' file of the corresponding toolchest. Simply click on the 'EditChest' button, as described below, to immediately make changes to the 'toolchest' you are looking at. After clicking on the '>>' button, its label changes to '<<'. Click on the button in that mode, and the GUI contracts back to its narrower size. The 'EditVars' and 'EditChest' buttons : When the user clicks on '>>' and the toolchest expands to the right, a couple of 'hidden' buttons are revealed --- 'EditChest' and 'EditVars'. There is a fundamental difference in these two buttons: When you click on the 'EditChest' button, the changes you make are only applicable to the toolchest on which you clicked. When you click on the 'EditVars' button, the changes you make apply to ALL the toolchests ---- and to ALL the Tk prompting GUI's of the 'feHandyTools' system --- the file-selector GUI's, the list-selector GUI's, the entry-field GUI's, the FE color-selector GUI, the FE font-selector GUI, etc.

The four buttons on the 'EditVars'
GUI that facilitate changing the
appearance of the 'feHandyTools' GUIs.

The 'EditVars' button The 'EditVars' button provides easy access to the several Tk 'include' files that allow you to 'more permanently' (than with the 'ChgColor' and 'ChgFont' buttons) change such toolchest GUI features as: widget fonts, in particular fonts for the Tk button widgets that are used to make the toolchest 'drawers' widget colors, like the default 'palette' of colors for all the toolchests widget geometry, like x and y internal padding in buttons. widget apps, like the web browser that you prefer to use in 'feHandyTools' utilities that show an HTML page NOTE that these Tk GUI parameters are used by ALL the 'feHandyTools' GUIs -- not just the common toolchest GUI. That is, ALL the prompting GUIs use the parameters in the fonts, colors, apps, and geometry parameter files. the listbox GUIs that provide for directory navigation and file selection the entry GUIs that accept user input via entry boxes and checkbuttons and radiobuttons and option lists the 'PlotQuik' GUIs the specialized GUIs, like the GUIs used for VIDEOtools So, if you want to change the appearance of a directory navigation GUI, you can do it via the 'EditVars' button in ANY of the toolchest GUIs. Close and re-open GUI's   (for changes to take effect) Clicking on the 'EditVars' button brings up the GUI seen above, with four Edit buttons --- corresponding to four Tk variables categories : 'fonts', 'colors', 'geometry', and 'apps'. After you edit one or more of those 4 files, according to the plentiful comments in those files, close out all FE 'HandyTools' GUIs. When you restart the GUIs, you will see the effects of your changes. There are backups of these '.tki' include files in the 'includes_tk' directory of the installation. Those '.tki_BKUP' files can be used to restore the files if you make an unrecoverable mistake in editing. The 'EditChest' button Similarly for the 'EditChest' button --- after editing, close the toolchest and re-open. After you have edited the '.chestdef' file for the current toolchest, close the toolchest and start it up again to see the changes in the GUI that result from your changes to the '.chestdef' file. Here is a description of the chestdef file format : Comment lines are indicated by '#' (hash symbol) in byte 1. Comment lines (and blank lines) are not processed when the toolchest is generated by the 'make_chest.tk' Tk script. 'Label' (title or section heading) lines are indicated by '^' (caret symbol) in byte 1, followed by the label text. 'Horizontal-Separator' lines can be added anywhere in the chest by specifying '!' (an exclamation mark) in byte 1. Any other text after the '!' in the line is ignored. 'Grayed-out program' lines are indicated by a '-' (minus sign) in byte 1. All other lines are considered 'executable app' lines. The separator for the several fields in the 'executable' (and the 'grayed-out') lines is back-slash (\). Field1 is the brief-text describing the executable. Field2 is the executable (with full path, if needed or wanted), with any parameters needed. Field3 is added description, for the sprout-out, right-hand-frame of the chest. Field4 (optional) may be used to specify an icon file. For 'grayed-out' lines ('-' in byte 1), Field2 (the executable field) is not trigger-able. So you can de-activate a 'live' line, yet have the description(s) still show, by putting '-' in col1. The program descriptions in field1 and field3 are shown, grayed out. This is a way of displaying a 'placeholder' or 'reminder' app line. If you don't want the program line to show, you can put '#' in byte 1, to make it a comment line. Or, if you are sure you don't need the line, you can delete it. One more (really heavy-duty) change --- the 'make_chest.tk' script : In summary, the appearance of the toolchests can be changed : temporarily via the 'ChgColor' or 'ChgFont' buttons, for that particular toolchest, or, change the widget appearances in ALL the toolchests, more permanently, by editing the Tk 'include' files via the 'EditVars' button or, change the content of the lines ('drawers') in any toolchest by editing its 'chestdef' file via its 'Edit Chest' button. BUT . . . You can also make a drastic change to the appearance of the toolchests by changing (or completely re-writing) the single 'make_chest.tk' script --- which makes all the toolchests. For example, you could make a 'make_chest.tk' script that uses a 'canvas' widget (and widgets within that canvas), rather than using the 'frame' and 'button' widgets in the delivered 'make_chest.tk' script. Here again you can see that --- the FE system is a *REALLY* open system. EVERYTHING is open to change. See the section below on the 'make_chest.tk' Tk script for a little more information on that Tcl-Tk script.

Above is an image of the
'File(s)-Selector' GUI that
provides the capability of running any
of the scripts of 'feNautilusScripts'
without using the Nautilus file manager.

In other words, if you use a non-Gnome-derived
desktop --- like KDE or LXDE or Xfce or Fluxbox
--- you can run the scripts of 'feNautilusScripts'.
Just install both 'feHandyTools' and 'feNautilusScripts'.

After the user selects one or more files via
this GUI, he/she clicks on the 'Apply-a-Script'
button to navigate to a Nautilus script and
select it to run with the selected files as input.

This function is being replaced by a
'tkScriptApplicator' in the 'tkGooies' system
--- in the 'FILEmanagers' toolchest.

Page 7 THE FE HandyTools DIRECTORIES : The install directories of the FE 'HandyTools' subsystem go under an 'feHandyTools_yyyymmmdd' directory --- full name $HOME/apps/feHandyTools_yyyymmmdd --- where yyyymmmdd is a release date like 2011sep17. It is a simple, 'almost-flat' directory structure --- only one or two levels of directories. The sub-directory names are chestdef_scripts chestdefs helps images (with a 'bullets' subdirectory) includes_sh includes_tk lists scripts (with about 20 to 30 tool-category subdirectories) tkGUIs (with 'tkGUIs_listbox', 'tkGUIs_entry', 'tkGUIs_DEMOS', and 'tkGUIs_PLOTtools' subdirectories) The 'chestdef_scripts' and 'chestdefs' directories contain the toolchest startup scripts and toolchest definitions, respectively, for about 20 to 30 categories of tools in the delivered installation. The 'feHandyTools.chestdef' file in the 'chestdefs' directory uses a 'bullet' icon that is used in all the drawers of all the delivered toolchests. That 'default' bullet icon can be changed by simply overlaying the 'bullet_default.gif' file in the 'images/bullets' sub-directory of the 'feHandyTools' installation. (To keep the height of the 'drawers' from being too big, it is best to use icons no bigger than about 20x20 pixels.) Making changes --- by directory : To give an idea of which directories to go to when trying to make changes to the 'feHandyTools' system via a file manager or the command line, rather than through the 'EditChest' or 'EditVars' buttons, here are the directories and the changes that can be made there: 'chestdefs' - edit the '.chestdef' files to change the toolchests : change the order of the tools in the drawers change/translate the names and descriptions given to the tools add, comment, delete, or gray-out 'drawers' add/move/remove separator lines re-word/translate/remove/add section titles 'chestdef_scripts' - change the title, icon-title, or opening window-position of any toolchest 'includes_tk' - edit the fonts, colors, geometry, or apps '.tki' include script code to change values in these types of variables used for all the 'feHandyTools' toolchests and Tk GUI's 'scripts' - edit any of the 'wrapper' scripts --- the 'general' scripts or the scripts in the 20-plus tool categories 'tkGUIs' - edit the general '.tk' scripts, like 'make_chest.tk', or the Tk scripts in several subdirectories: 'tkGUIs_listbox', 'tkGUIs_entry', 'tkGUIs_PLOTtools', 'tkGUIs_DEMOS' 'helps', 'lists' - edit the text files in these directories Backups when revising 'chestdefs' or scripts : If you intend to do revisions to chestdef files or scripts, I would suggest that you backup the individual files that you change. You could backup the original file by renaming it with an '_ORIG' suffix, for example. Then make a copy of it, to the original name, and start editing it. You can make a backup of your changes after saving your changes, by doing 'Save As' and saving the file with a suffix like '_2010sep08'. That way, if you make a series of changes, over a period of days or weeks or months, you will have an image for each of the several changes. If you do extensive revisions, I suggest that you back up the entire installation directory ... or have the original install file (the self-extracting '.sh' script) handy --- or download the self-extracting install script of the latest release. The install directory of this FE subsystem is relatively small (a few Megabytes), so it is no big space-eater if you back up the entire installation. (If you totally mess up the installation directory, you could rename it --- from $HOME/apps/ feHandyTools_yyyymmmdd to, say, $HOME/apps/ feHandyTools_yyyymmmdd_FOOBAR --- in case you want to be able to refer to some changes that you made. Then you can simply re-install to a $HOME/apps/feHandyTools_yyyymmmdd directory --- in a matter of seconds, from a self-extracting install script.)

Above is an image of a 'Line-Item-Selector'
GUI that is used whenever a handy-tool needs
to offer the user a list from which to select a line.

Page 8 THE 'make_chest.tk' SCRIPT : The 'chest definition' files are read, line by line, by the script $FEDIR/tkGUIs/make_chest.tk to make the 'toolchest' for each HandyTool category. The 'make_chest.tk' script executes a series of widget-making Tk commands and then goes into the Tk wait mode --- waiting for user actions --- mouse-clicks and keyboard entries on the widgets of the 'toolchest' GUI. NOTE: HERE is one of the VERY OPEN aspects of the FE system : The 'make_chest.tk' Tcl-Tk script could be radically altered to make the chests in a quite different way (say using Tk 'canvas' items rather than with Tk 'frame'-enclosed items like the Tk 'button' widgets). Not only can you change the widgets used, but you can also change the 'bindings' of procedures to specified actions (like <Button-Release>) on the widgets of the toolchest. You can invent new behaviors for the toolchest. Anti-aliased fonts : The initial implementation of this FE subsystem was developed using the Tcl-Tk 8.4 command interpreter --- the version that came with most Linux systems in the 2007-2010 time frame. Tcl-Tk developers incorporated the 'Xft' (X-free-type) anti-aliasing system into the Tcl-Tk 8.5 release of the 'wish' interpreter. Tcl-Tk 8.5 was released circa 2007 (see www.tcl.tk), but only around 2010 did that interpreter start to make an appearance in many Linux distros and package managers. The Xft anti-aliasing makes the fonts in Tk widgets appear without 'jaggies'. It is mostly those 'jaggies' that have made people wonder, in the timeframe from about 2001 to about 2010, what's wrong with Tcl-Tk --- why can't it make nice looking fonts like the Gnome and KDE desktops and file managers --- and like the GIMP and OpenOffice applications, and the Gnome and KDE font-viewer utilities? Well, Tcl-Tk 8.5 (with Xft) should put almost all of that belly-aching and complaining to rest. In mid-2011, I put Tcl-Tk 8.5 on my development machine. I am now able to generate screenshots of the toolchests in which the fonts look much smoother. I am now able to use italic and oblique fonts without having to be concerned about their having a too-jaggie look. Themes : In recent releases of Tcl-Tk (8.4, 8.5), the Tcl-Tk developers have come up with a 'theming' system that is intended to blend in with themes of various windowing systems --- Mac OS X, MS-Windows, and perhaps even various Linux windowing and desktop systems. To implement that Tk-handling of themes, a new set of Tk widgets (in a 'ttk::' Tk namespace) needs to be used. ( ttk = themed tk or tiled tk ) However, the 'ttk::' widgets do not have all the features of the original Tk widgets --- so it may be a few more years before I would want to try to convert the FE subsystems that are based on Tk scripts to use the new 'ttk::' widgets --- especially since there seem to be some questions as to how well this new Tk theming is implemented for Linux systems. When that 'mature' time comes, then the FE system chests and GUIs may blend in a little more seamlessly with the Linux desktop themes (Gnome, KDE, or whatever) in use by the Linux user --- if the 'ttk' system is used in all the Tk scripts of the FE subsystems. An enhancer of the FE Tk-based subsystems could make '.ttk' scripts based on copies of the '.tk' scripts --- leaving the '.tk' scripts available for users still running older versions of Tcl-Tk. After some suitable re-coding of the 'make_chest.tk' script (and various other scripts in the 'feHandyTools' subsystem), the user could be able to choose whether to use '.tk' or '.ttk' scripts by simply 'flipping a switch' --- such as setting a 'ttk-yes-no' Tk variable in an 'include' Tk script file of the FE subsystems --- say in the 'set_widget_apps.tki' Tk-include script-code file. Or, to avoid a lot of re-programming, simply backup the '.tk' scripts into a backup directory and copy the '.ttk' scripts into the appropriate 'tkGUIs' (sub)directory and rename the '.ttk' suffix to a '.tk' suffix. Or, a 3rd alternative: use symbolic links. For example, have the '.ttk' scripts in 'ttkGUIs' (sub)directories. Move the '.tk' scripts (of the 'tkGUIs' directory) to a backup directory and, in their place, make 'symbolic links' from '.ttk' scripts in the 'ttkGUIs' (sub)directories to '.tk' link files in the 'tkGUIs' (sub)directories. Icons on toolchest drawers : In a past Tcl-Tk release (8.3.x or 8.4.x) came an enhancement to allow an 'image' and a text string to both be used on a button or label Tk widget at the same time. Hence we can populate all the FE system chests with button-drawers that have a icon image next to the text. The current (2011) 'make_chest.tk' script of 'feHandyTools' looks for a fourth field in the 'executable' lines of the input '.chestdef' file. In that 4th field, a fully-qualified filename can be placed, that specifies an icon file --- gif, pgm, or ppm --- a format readable by plain-vanilla Tk. For example, on the main 'feHandyTools' toolchest, on the 'feNautilusScripts' drawer, I could put a Nautilus icon (about 20x20 pixels or smaller) to the left of the 'feNautilusScripts' text string. (See the 2nd 'drawer' from the bottom in the main toolchest below.) The current 'make_chest.tk' script relies on using image formats (like gif) with 'built-in' support by Tk, without having to install a Tk extension. Hopefully, some of the PNG-and-JPEG-reading extension called 'Img' will eventually be built-in to Tk. The 'Img' extension will probably not be delivered with most Linux distros. (PNG support is said to be coming in Tcl-Tk 8.6 --- to be released in 2012??) At this time (2011), I do not intend to spend much time on adding icons to the chests --- partly because icons (larger than the default, small bullet image being used now) will just add processing-load and startup-time whenever a chest starts up. To get a nice looking Nautilus icon, for example, I will probably have to use an icon about twice as large, in bytes, as the 20 pixels x 15 pixels bullet icon being used now. The bullet icon that is being used now is from a 1,007 byte file. The text string in most of the drawer titles is only about 20 bytes of character code --- although that might be rendered into quite a few more bytes of pixel image of the characters. In any case, in a 20-drawer toolchest, there are about 20,000 extra bytes being processed to show the bullet icons. One could probably make the toolchests startup a little faster by commenting out the code line of 'make_chest.tk' that creates the bullet icon in each toolchest drawer. However, since the toolchests startup in less than a second now, there may not be a noticeable speedup by eliminating the (default) icons. The main reason that I do not plan to spend much time on icons is because I need to spend time on creating some useful new 'feNautilusScripts' --- and in creating new 'tkGooies' in the system that is to replace this 'feHandyTools' system. Users can experiment with icons to their hearts' content --- in the FE 'feAppMenus' and 'tkGooies' systems. Skins : One man (Portuguese) has used Tcl-Tk to put a classy 'skin' on a player GUI. The player is/was called 'VebKlaso' and some pictures of it may still be at pragana.net. Rildo Pragana's player indicates that we can eventually make the chests as wild looking as the wild looks that one sees in the many skins for applications like 'winamp' or 'xmms'. We can create a common skin for all the chests by changing only the one script, 'make_chest.tk', and leaving the many chestdef files unchanged. Unfortunately, this 'skin' technique takes more than basic Tcl-Tk programming. It requires using an 'extension' of Tk, and the couple of extensions that exist so far, with this skinning type of capability, are not 'mainstream' --- and not 'blessed' by the maintainers and developers of the Tcl-Tk core. Reliability is more important than 'wild looks' anyday. At least that is so in the world of computing --- maybe not in the fashion world. So I leave skins to a future FE subsystem release --- and concentrate on getting functionality into the initial releases. In summary, there is much that can be done to 'prettify' the FE system chests (and GUIs) --- with icons, themes, and skins. But probably the best 'prettifying', in my mind, comes with using a Tcl-Tk 8.5 'wish' interpreter to gain the advantage of the anti-aliasing of fonts by the Linux 'Xft' system that has been implemented in the 8.5 release of the Tcl-Tk 'wish' interpreter (Linux version). I have no plans to address adding themes (ttk widgets) in 2011. Nor do I intend to spend a lot of time trying to implement skins, until the ability to have non-rectangular or transparency-capable windows is incorporated into the core of Tcl-Tk (so that I do not have to deal with installing extensions of Tcl-Tk). Furthermore, I would want the non-rectangular/transparency capability to be compatible with at least one of the window-managers available on Linux. For now (2011 Sep), I am occupied with continuing to add some scripts to the 'feNautilusScripts' subsystem --- and occupied with adding similar and additional scripts (and Tk GUIs) to the 'feHandyTools' subsystem. Because of my advanced age, I may end up leaving themes and skins to be added by others.

Above are images of two versions of
the old 15-tile puzzle/game ---
done by two different Tcl-Tk scripts.

You click on a tile next to the open spot
to make the tile move into the hole.

This is an example of 'binding' a procedure
(to move a tile-object on the 'canvas') to a
mouse-event (like 'Button-Release' on
the tile-objects on the canvas).

The demo on the left is a Tk script that
is delivered, along with about 30 others,
in a Tcl-Tk interpreter installation.

The demo on the right was done by Keith Vetter
who contributed a lot of Tk scripts to
the Tclers' Wiki (wiki.tck.tk).

Unfortunately many people who use
Tcl-Tk apps, and even those who program
Tcl-Tk scripts, do not know of the demos.
Their location in the Tcl-Tk interpreter
installation directories is not well-publicized.

Maybe that is a good thing, because even
a highly experienced Tcler like
Keith Vetter (KPV), who has been writing
Tcl-Tk scripts since 1993, had
the following exchange (in 2005)
on Vetter's web page 'The Classic 15 Puzzle' :

"DKF:
The puzzle has been part of the
standard Tk demos since before
I started using Tcl.

KPV:
duh! Well, in my defense, I can say
that at least I'm not the only
person to overlook the Tk demo version
since 'Ideas for Projects in Tcl/Tk'
[http://wiki.tcl.tk/15067] has it listed
as a project to be done."

As a result, Vetter made his own version
of the 15-tile puzzle --- with a 'Solve' button
--- a quite major addition to this 'Tk-app'.

That's quite an achievement. And he even
went on to make an NxM-tile puzzle
--- that is, the number of rows of tiles and
columns of tiles can be other than 4x4.

So maybe it is NOT a good thing that I am trying
to make the 'core' Tk demos, that come with
any Tcl-Tk interpreter installation, available
via a few mouse clicks on 'PROGRAMMING tools'
toolchest drawers in 'feHandyTools'.

Links to pertinent 'feHandyTools' chest images are here :

'PROGRAMMING tools' toolchest   >

Tcl-Tk Help Chest   >

Tk 'Core' Demos Chest

Page 9 SUPPORT and ENHANCEMENTS : Since the FE system is provided for free (thus no well-funded human resources office), and since there is only one person (me) developing the system for now (2011), and since I have long to-do lists (of my own and of my wife), I cannot provide much support --- like 'hand-holding'. I am willing to take bug reports and suggestions for enhancements and additions. But, since I hope to enjoy life in retirement, I cannot even promise to keep up with brief communications about those kinds of basic issues. Email has become a pain for me --- partly because of the daily receipt of spam that manages to make it through the filters of my ISP (Internet Service Provider). One of the things on my to-do list is to provide an easily implemented procmail(?)-based whitelist/blacklist-by-IP-address-range mail-filtering-system in an FE 'mail_tools' toolchest. I plan to block mail from China, Korea, Argentina, Brazil, Chile, Turkey, Romania, and most other non-U.S. countries. That should take care of about 50% of the spam getting through my ISP's filters. I will add blocking ISP ranges for the U.S. also, as I discover sources of spam from U.S. IP addresses. That should take care of another 49% of the spam.) (Time-out for a rant: It is really stupid that they did not parcel out IP addresses to countries in contiguous ranges, proportional to their populations. For example, Korea's address ranges are scattered all over the IP address map. It makes for really huge IP-range black-lists. It makes white-lists more appealing, but then one has to keep checking the Probable-Spam mail folder for addresses to add to the white-list.) If you send requests for enhancements or additions, please consider sending a modest donation (such as $5, $10, $20, ...) --- to help me pay my ISP (Internet Service Provider), to keep this web site up. An example of a kind of request that I can probably satisfy is a request for a (set of) Tk-GUI interface(s) to a Linux command or application --- replacing its many command-line options by GUI prompts, using check-buttons, radio-buttons, entry-fields, and the like. I intend to show some examples of this type of GUI development via a 'Featured tkGUIs' web page on this site. Some kinds of FE subsystem enhancements that I could implement are enhancements to (or re-write of) the 'make_chest.tk' tkGUI script of the FE HandyTools (and FE AppMenus) subsystem enhancements to the 'shofil.tk' tkGUI script of the FE 'xpg' subsystem --- also used in the 'feHandyTools', 'feAppMenus' and 'feNautilusScripts' subsystems more scripts added to the FE Nautilus Scripts subsystem more shell and Tk GUI scripts added to the FE Handy Tools subsystem. These kinds of enhancements involve editing FE text files --- mostly creating or enhancing shell and Tcl-Tk scripts --- which I have trained myself to do. I generally try to stay away from compiling languages such as C and C++. I generally try to 'glue' compiled programs together with shell and Tcl-Tk scripts. I generally try to steer away from 'monolithic' compiled program projects --- in my retirement. So please direct suggestions for enhancements to compiled programs to the appropriate developers. But let me know of options that should be added to FE subsystem Tk GUI 'front-end' scripts and Bourne/bash shell 'wrapper' scripts, when such compiled programs are called on within FE subsystems. If you have used the FE subsystems for a while and find that they are helpful to you, please consider making a donation --- to help pay the bills for keeping this web site hosted. See the 'FE Contact' web page for info on how to contact me to make a donation. [One type of programming request that could draw time away from the 'fun' projects is bug fixing. Hopefully there are not many bugs, since I use the FE subsystems myself.]

There are four Tk 'pack' command parameters
that control how a widget is placed in a window
--- 'side', 'anchor', 'fill', and 'expand'.

I decided to make a four-widget (four-frame)
GUI that allowed me to see how various
combinations of those four parameters (for each
widget) affected the placement of the widgets.

On the left you see my first version.
When the window first comes up, the
16 pack parameters are set randomly.
And each time you click the 'Refresh'
button, a new set of the 16 pack parameters
is generated (randomly) and
the window is redrawn.

That was educational, but I saw right away
that I needed the answer to questions
like 'What happens if I change the 'side'
parameter of the 3rd widget from 'left'
to 'top'? So I created the Tk script
that generates the GUI on the right.

Instead of just one 'Refresh' button, there
are also 16 Tk option-menu buttons that
allow you to change one to 16 of the pack
parameters before clicking on
the 'Refresh' button.

Poke the right-hand image to see a new image
in its place. That image shows the effect of
changing the 'side' parameter of Frame-1 from
'bottom' to 'top'. That one is easy to predict.

But I am still surprised sometimes at the
result of a given change. I cannot predict, yet,
with 100% accuracy what will happen, in all cases.

(4x9x4x2=288 to the 4th power? 6,879,707,136?
about 6.8 billion possible combinations?
Many of those combinations result in the
same GUI configuration. Anyone care to calculate
how many distinct combinations there are?).

This could make a betting game. For example,
two Tcler's could bet with each other on who
will have the right answer to what will happen for
a given change in one (or more) of the 16 'pack'
parameters. Put 'feHandyTools' on a netbook and
take it to a bar for a few beers and some
game-playing with friends.

Links to pertinent 'feHandyTools' chest images are here :

'PROGRAMMING tools' toolchest   >

Tcl-Tk Help Chest   >

Tk FE Demos Chest

Page 10 Helping Yourself (be my guest) Because most of the FE HandyTools system is composed of Linux/Unix shell scripts and Tcl-Tk scripts (and 'chestdef' files), you can enhance that system yourself. All of these scripts and chestdef's are simply text files --- not 'binaries'. And there is no compiling involved --- no 'configure', 'make', etc. The shell scripts simply invoke the 'sh' shell, which is a command interpreter. (On Ubuntu 9.10, 'sh' is a link to the 'dash' interpreter, which is like a subset of the 'bash' interpreter.) The Tcl-Tk scripts simply invoke the 'wish' (window shell) command interpreter. For example, if you do not like the way a GUI works, you can change the Tcl-Tk script that provides the GUI. And if you do not like the format of a report, you can change the Linux/Unix shell script that provides the report. Happy changing and enhancing!

Above is a screenshot of an animated
Rube Goldberg device that is rendered
on a Tk 'canvas' widget with various
objects drawn on the canvas --- some
are static and some move.

The user clicks on the ball at the
top right to set the ball in motion.
Then sit back and watch the devices function.

This Tk script is one of many donated
by Keith Vetter who has a
web page of links to his donated code
(Tk scripts source code on Wiki pages).

I have added an appropriate call to the
'wish' interpreter to the top of many
of his scripts, and, almost without fail,
they have run on Linux.

Some of his scripts are available to be
run with a few mouse clicks via the
'PROGRAMMING tools' toolchest, after
installing 'feHandyTools'.
(I am trying to make his good work more known
to the public --- well Linux users, anyway.)

Some of Vetter's scripts, and those of other
Tcler's, need to have some changes made
to fit the screen appropriately, especially
if one wants to demo them on a netbook with a
screen height of 600 pixels or thereabout.

Some of the donated scripts would need
much more drastic changes than others.
(Vetter's Rube Goldberg GUI, which appears
to be not readily scalable, exceeds even
the 1024x780 screen size of my desktop computer.)

Links to pertinent 'feHandyTools' chest images are here :

'PROGRAMMING tools' toolchest   >

Tcl-Tk Help Chest   >

Tk 'Wiki' Demos Chest

Page A.1 APPENDIX A. Variations on F.E. (variations on Freedom E. --- what the 'E' stands for) 'Have at it' ... 'it' being your copy of an FE subsystem. Enhancing (or simply tailoring) an FE subsystem is one way to get a taste of that. It's REAL freedom! ... Ain't freedom great? --- like the freedom to say "ain't" instead of "isn't". We all need some freedom in our lives. In fact, instead of "Freedom Environment", the FE could stand for Freedom Euphoria Freedom Ecstasy Freedom Envy (a short form of Freedom Environment) Freedom Enhancement Freedom Elysium Freedom Emancipation (a double positive?) Freedom Embodiment Freedom Enjoyment Freedom Enthusiasm Or ... Freedom Earth-mother Freedom Earth-shaker Freedom Easement Freedom Ease (= Freedom-ese) Freedom Eclecticism Freedom Effector Freedom Electricity Freedom Enchantment Freedom Encounter Freedom Encouragement Freedom Endeavor Freedom Endowment Freedom End-zone Freedom Enema Freedom Energy Freedom Energizer (bunny?) Freedom Enfranchising Freedom Engagement Freedom Eruption Freedom Essence Freedom Evermore Freedom Everybody Freedom Everywhere Freedom Evolution Freedom Exaltation Freedom Excitation Freedom Exclamation Freedom Exemplar Freedom Exemplifying Freedom Exhaustless Freedom Exhibition Freedom Exhilaration Freedom Expansion Freedom Expedition Freedom Experiment Freedom Explosion Freedom Exploration Freedom Exponentiation Freedom Exposition Freedom Expounded Freedom Expression Freedom Expressway Freedom Extension Freedom Extrapolation Freedom Extroversion Freedom Extrusion Freedom Eyeopener Freedom Eyepopper Or even Freedom E (= Freedom-y) (kind of like truth-y) Freedom Eagle Freedom Egg Freedom Embryo Freedom Enchilada Freedom Eyes (= Freedom-ize) The list is left as an exercise to finish. The keyword is Freedom. I'm sticking with that. Otherwise, with variations on both F and E, the list would go through the roof. END OF a GUIDE to the HandyTools subsystem of the FE family of systems

FE Software . . . . Some Kind of Wonderful.

Bottom of this FE 'HandyTools' subsystem DESCRIPTION page. FE = Freedom Environment To return to a previously visited web page, click on the Back button of your web browser a sufficient number of times. OR, use a History-list option of your web browser. OR ... < Go to Top of Page, above. > Page history: Page was created 2011 Sep 15. Page was changed 2011 Sep 25. Page was changed 2018 Aug 16. (Added css and javascript to try to handle text-size for smartphones, esp. in portrait orientation.) Page was changed 2019 Jul 22. (Specified image widths in percents to size the images according to width of the browser window.)

My thanks to Jeff Godfrey who wrote
this Asteroids program in 2005.
It looks almost identical to
the original arcade game.

John Ousterhout, the author of Tcl-Tk,
has said in the past that he expected
Tcl-Tk to be used as 'glue' to weld together
compiled programs that do a lot of processing.

He has said that he has been surprised
at the many kinds of Tcl-Tk scripts that
have been written that he would have expected
to be implemented only with compiled languages
like C and C++.

No doubt Ousterhout would classify this
Asteroids program as one of those surprises.

Watching the performance of this program
would certainly surprise many knowledgable
computer professionals who are of the opinion
that an INTERPRETED scripting language would be
INcapable of non-hesitant-response-to-user-actions
during
CONSTANT-MOTION-of-MULTIPLE-OBJECTS and
EXPLODING-OBJECTS graphics like this.

No hiccups (pauses).
No jumpiness (gaps) in motion.

Continuous displacements and piece-wise
continuous velocities (mathematically speaking).

List of Tk Wiki GAMES --- to run, show code, or both