Poke this image to see another toolchest.
Poke title area to change back.
The FE 'HandyTools' subsystem
a detailed DESCRIPTION
(FE = Freedom Environment)
Poke this image to see another toolchest.
Poke title area to change back.
! 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
Here is an FE Tk entry GUI for getting 'man' help on a topic/command.
That entry GUI came from the 'LinuxHELP' toolchest. (image below)
See the fourth drawer from the top.
Click on this image to see a larger one
in a separate window. You can close that
window to return to this one.
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 :
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
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 hops 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.
Put your mouse over (or 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.
Move your mouse off this image (or poke outside it) to change back.
WIDE-OPEN CODE & RE-CONFIGURABLE TOOLCHESTS :
In terms of files, the FE HandyTools subsystem is, basically, a collection of
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 :
Via the 'EditVars' button, you can change appearances, by changing values of parameters, which control toolchest and other Tk GUI
Via the 'EditChest' button, you can edit a 'chest definition' file to:
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 those kinds of operations:
Network, not 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 dead-ends (no Catch-22's)
So 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.
Here is the 'PLOTtools' toolchest, expanded to show the normally hidden right-hand side.
And here are images of the 3 plot GUI's that appear when clicking
on the 3 drawers shown.
NOTE: These plots are SCALABLE. Just click on the 'UpCan' button.
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.)
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.
Here 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.
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
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 only predecessors, not overlords.
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 vice versa. And the predecessor can be closed without resulting in the closing of its successors. One toolchest does not become the 'master' toolchest just by facilitating the opening of another toolchest.
'Child' chests (I'm using the word 'child' here in the 'typically a successor' sense) can trigger 'parent' chests. In fact, any chest can trigger the 'top', usual-startup chest, the 'feHandyTools' chest.
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.
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:
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:
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.
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 :
The separator for the several fields in the 'executable' (and the 'grayed-out') lines is back-slash (\).
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 :
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.
Here is an image of the 'File(s)-Selector-and-Script-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 desktop --- like KDE or LXDE or Xfce or Fluxbox --- you can run
the '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.
THE FE HandyTools DIRECTORIES :
The install directories of the FE 'HandyTools' subsystem go under an 'feHandyTools_yyyymmmdd' directory --- full name $HOME/apps/feXpg_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 directory names are
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' 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:
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
--- 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.)
Here is an image of the Line-Item-Selector GUI that is used whenever
a handy-tool needs to offer the user a list from which to select a line.
THE 'make_chest.tk' SCRIPT :
The 'chest definition' files are read, line by line, by the script
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.
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 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, 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 loaded 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 toolchest 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 porting many 'feNautilusScripts' --- especially the many 'IMAGEtools' and 'VIDEOtools' scripts --- to be used in added 'feHandyTools' chestdef files, with associated help files --- and I need to go on to the development of other FE subsystems and Tk GUIs.
Users can experiment with icons to their hearts' content.
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.
Furthermore, I may develop another FE subsystem called 'xlphp', for printing text files. I want to be able to print any of my text files, like Tk scripts, without getting 'will-not-process' messages (i.e. blocking by print system 'filters') --- which I encounter when I try to print using systems like the CUPS and HPLIP printing system.
And there are some 'fun' Tk GUIs that I plan to code and add to the 'FE tkGUI DEMOS' section of the 'PROGRAMMING tools' category in the 'feHandyTools' system.
Because of my advanced age, I may end up leaving themes and skins to be added by others.
Here 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 contributes a lot of Tk scripts to
the Tcl-Tk 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 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 this exchange (in 2005) on his 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 do not have to be equal.
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
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
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 --- 'top', '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.
Run your mouse over the right-hand image to see a new image in its place.
That is 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
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!
Here 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 web 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
APPENDIX A. Variations on F.E. (variations on Freedom E.)
So ... 'have at it' ... 'it' being your copy of the FE system.
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.
Enhancing (or simply tailoring) the FE system is one way to get a taste of that.
In fact, instead of "Freedom Environment", the FE could stand for
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 the 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.
Page was created 2011 Sep 15.
My thanks to Jeff Godfrey who wrote this Asteroids program in 2005.
It looks almost identical to the original arcade game.
John Ousterhout (rhymes with Rooster-pout --- think of a pouting rooster),
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