Poke this image to see color change.
Poke off-image to change back.
Poke this image to see font change.
Poke off-image to change back.
! Note !
This description may be touched up or revised occasionally
--- for example, if there is ever a new release.
The old toolchest images here may be updated someday
to show images with nicer, anti-aliased fonts.
TABLE OF CONTENTS
(links to sections below, on this page)
Click on this image to see the expanded 'toolchest',
as if you had clicked on the '>>' button, at
the bottom of this FE chest of 'drawers'.
(The bigger image is shown in a
separate window or tab.)
INTRODUCTION to the 'FE AppMenus' subsystem :
What the user sees on starting up the FE AppMenus system is a 'toolchest' composed of 'drawers' --- like the chest-of-drawers in the images above.
When the user clicks on any of those drawers, he/she can start up the indicated application --- or call up another toolchest, offering a different category of applications.
As delivered, the FE AppMenus system provides about 20 categories of application menus (toolchests). The main toolchest offers
The application categories toolchest offers (initially) about 20 categories such as (in alpha-numeric order)
You can combine toolchest definition files to collapse these down into a lower number of categories. But the author of this system finds that he can find apps easier with about 20 to 30 categories.
In too many menu systems, a wide variety of apps are put in vague categories like 'Accessories' and 'Other', with a max of about 10 categories.
Even categories that are little more specific --- such as 'Internet' and 'Sound & Video' (or 'Media') --- end up having more than 20 apps in them, of widely varying functionality. This makes it a chore to repeatedly have to scan an effectively randomly (alphabetically) ordered list of apps to find the one app that one is looking for.
An alphabetic sort of apps in one of these monster categories is not of much help, because the wide variety of app names results in a quite random list of apps, going back and forth among several sub-categories, as you scan down the list.
Example: In the 'Sound & Video' category, the list of apps hops among CD-DVD apps, Audio-only apps, Video apps, Webcam apps, and perhaps a few more sub-categories one might wish to add to this sub-category list.
For example, the author finds it very helpful to have a 'CD-DVD apps' category, 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 apps, like the Audacity audio editor, the EasyTAG audio tags editor, and various audio players, in the 'AUDIO-only apps' chest --- rather than searching for them scattered among 30 apps, in a 'Sound & Video' category that includes many CD-DVD apps, as well as Video apps.
Click on this image to see the expanded
'AppCategories' toolchest, as if you had
clicked on the '>>' button, at the bottom of
this FE chest of 'drawers'.
(The bigger image is shown in
a separate window or tab.)
'OPEN' CODE --- AND RE-CONFIGURABLE
In terms of files, the FE AppMenus 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.
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 --- and open to modification and enhancement.
(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 a lot of information on the general structure of the scripts, as well as comments on small sections and individual lines of the scripts.)
In addition, the 'chestdef' files that define the toolchests have a very simple format. They are text files that can be easily edited.
They can be tailored so that they show and execute the favorite programs of the user.
As delivered, the initial chestdef files contain many example 'drawer'-definition lines.
Those example lines can be commented or de-commented --- or they can be edited to change the title and executable name.
Also new lines can be added, to add more applications to the 'toolchests'.
This 'AppMenus' FE subsystem is a *REALLY* 'OPEN SYSTEM' in the following sense.
If you do not like the way the 'toolchest' system is organized, you can make changes in many different ways:
Note that the 'toolchests' that call other 'toolchests', via the drawers, do not have to have a strict parent-child relationship to each other. 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.
In fact, the Audio-only toolchest and the Video toolchest and the CD-DVD toolchest can all call each other.
About the only notion of a hierarchy that remains is that the 'feAppsMenu' toolchest usually starts the menu chain off --- showing the user's favorite apps and a 'link' to the main 'apps categories' toolchest, which has about 20 to 30 categories drawers.
So the 'feAppsMenu' toolchest and the 'main App Categories' toolchest could be considered to be two toolchests at the top of a hierarchy.
But, actually, the user could start up any of the other toolchests and any of those toolchests could have drawers that startup the grand-daddy 'feAppsMenu' toolchest and/or the 'main App Categories' 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).
Note that you can re-organize the system and enhance it. 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 app-menu system after an unpleasant experience in using a KDE menu editor to edit a KDE apps 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 (or some tedious recovery action like that) --- and then never touching the menu editor again.
I will never encounter a dead-end like that with this FE AppMenu system.
THE SEEMINGLY OBLIGATORY LICENSE DISCUSSION :
Partly because of the 'extreme open-ness' of the FE system (all the executable code is in human-readable scripts), the FE system is provided in a freedom-to-copy-and-share and freedom-to-enhance mode (i.e. we are talking about the proverbial 'license' here).
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), your 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 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 [ususally less than 2 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 1/6-th of a CD, less than 1/40-th of a DVD, and much, much less than half 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 --- in 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, the system 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.
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.
(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'.)
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 is a 'chain' of three 'toolchests',
spawned from left to right.
Click on this image to see
how the toolchests can be dragged down
to the bottom of the screen so that
they are out of the way --- only
their title bars showing. But the
toolchests are ready to be dragged
into action at any time,
by their title bars.
Note that you can close any one of
the toolchests in the usual way
that you close a window --- click on
the 'Close' symbol at the upper
right (or left) of the window title bar.
These toolchest windows are independent of
each other, so you can close 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 an FE toolchest
is spawned, there is no child-to-parent
relationship anymore like there is among
the processes you can 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.
One consequence of this is that the toolchests are, quite naturally, a 'network' rather than a 'hierarchy'. For example, the 'Video-tools' toolchest can include a drawer that triggers the 'CD-DVD-tools' toolchest, and vice versa.
And 'child' chests can trigger 'parent' chests. In fact, any chest can trigger the 'top', usual-startup chest, the 'feAppMenus' chest.
Another consequence of un-attached toolchests:
*** You can close 'parent' (spawner) toolchests and leave *** 'child' (spawnee) toolchests open.
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. Double-click again on the titlebar of the chest to restore the chest.
Bottom buttons of the 'feAppMenus' toolchests.
The TOOLCHEST BUTTONS, common to every feAppMenus 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 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 one rapidly choose among several open FE toolchests via color. Or you can change the toolchest color to go better with your screen background. Or, you may find other uses.
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 toolchest.
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 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.)
The default font of ALL the toolchests can be 'permanently' changed by editing an FE system Tk 'include' code file. 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, translating 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'.
The 'EditVars' button provides easy access to the several Tk 'include' files that allow you to more 'permanently' change such toolchest GUI features as:
Clicking on the 'EditVars' button brings up a GUI with 4 Edit buttons --- corresponding to those 4 Tk variables categories : 'fonts', 'colors', 'apps', and 'geometry'.
The GUI presented by poking the 'EditVars' button.
After you edit one or more of those 4 files, according to the plentiful comments in those files, close out all FE 'AppMenus' 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 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 :
The appearance of the toolchests can be changed :
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 'Image Tools' toolchest, as
it was implemented in an early release of 'feAppMenus'.
Click on this image to see the 'expanded' chest.
THE FE AppMenus DIRECTORIES :
The install directories of the FE 'AppMenus' subsystem go under a 'feAppMenus_yyyymmmdd' directory --- fullname $HOME/apps/feXpg_yyyymmmdd --- where yyyymmmdd is a release date like 2010sep17.
It is a simple, 'flat' directory structure --- only one level of directories (except for two small 'bullets' and 'icons' subdirectories of the 'images' directory). The directory names are
There are less than 10 files in each of the 'helps', 'includes_sh', 'includes_tk', 'scripts', and 'tkGUIs' directories.
The large directories are the 'chestdef_scripts' and 'chestdefs' directories, because they contain the startup scripts and app-toolchest definitions for about 30 categories of apps in the delivered installation.
Bullets and Icons :
As mentioned above, the one exception to the flat directory structure is the 'images' directory, which contains 'bullets' and 'icons' subdirectories.
The 'icons' subdirectory is delivered with icons representing a lot of the popular applications, such as Firefox (web browser), Seamonkey (web browser), Thunderbird (email client), and Filezilla (FTP client).
The user can add icons to that directory and incorporate them in toolchest 'drawers' as seen in the 'feAppMenus.chestdef' file in the 'chestdefs' directory.
For now, there is only one bullet icon used on the drawers without a unique app icon. That 'default' bullet icon can be changed.
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 making a copy with an '_ORIG' suffix, for example. And, then 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, you will have an image for each of the several changes.
If you do extensive revisions, I suggest that you back up the entire directories ... or have the original install file (the self-extracting '.sh' script) handy --- or download the latest release. The install directory of this FE subsystem is quite small (less than 1 Megabyte), 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/feAppMenus_yyyymmmdd
Then you can simply re-install to a $HOME/apps/feAppMenus_yyyymmmdd directory --- in a matter of seconds.)
Here is an image of the 'Web Browsers' toolchest, as
it was implemented in an early release of 'feAppMenus'.
Click on this image to see the 'expanded' chest.
THE 'make_chest.tk' SCRIPT :
The 'chest definition' files are read, line by line, by the script
to make the 'toolchest' for each application 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 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).
The initial implementation of this FE subsystem was developed using Tcl-Tk 8.4 --- the version which comes with most Linux systems in the 2007-2010 time frame.
With Tcl-Tk 8.5 (released circa 2007 --- see www.tcl.tk --- and only in 2010 starting to make an appearance in many distros and package managers), the Tcl-Tk developers have incorporated the 'Xft' (X-free-type) anti-aliasing system into the Tcl-Tk system.
This makes the Tk widgets --- and especially the fonts in those widgets --- appear without 'jaggies'. It is mostly those 'jaggies' that have made people wonder, for the past 5 to 15 years, 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.
And when I put Tcl-Tk 8.5 on my development machine, I will be able to generate screenshots of the toolchests in which the fonts will look much smoother. I will be 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 ; ttk = themed tk) needs to be used.
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 may 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 themes 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.
The user could be able to choose whether to use '.tk' or '.ttk' scripts by simply 'flipping a switch' --- such as setting an environment variable in an 'include' shell script file of the startup script(s) of the FE subsystems.
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 text 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 buttons that have a icon image next to the text.
For example, on the main feAppMenus toolchest, if I have Thunderbird as the mail application and Firefox as the web browser applicaton, I could have a Thunderbird icon to the left of the 'Thunderbird' text string and a Firefox icon to the left of the 'Firefox' text string.
The current (2010) 'make_chest.tk' script looks for a fourth field in the 'executable application' lines of the input '.chestdef' file. In that field, a fully-qualified filename can be placed, that specifies an icon file --- gif, pgm, or ppm --- a format readable by plain-vanilla Tk.
That is, 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 JPEG-reading extension called 'Img' will eventually be built-in to Tk. The 'Img' extension will probably not be delivered with most Linux distros.
At this time (2010), I do not intend to spend much time on adding icons to the chests --- partly because icons will just add processing load and time whenever a chest starts up --- but mainly because I need to spend time on finalizing the many feAppMenus shell and Tk scripts and chestdef files and help files --- and I need to go on to the development of other FE subsystems.
One fellow (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.
This 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.
So I leave skins to a future FE subsystem release --- and concentrate on getting functionality into the initial releases. But I cannot help but keep thinking about how to skin this cat.
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, will come with using Tcl-Tk 8.5 to gain the advantage of the anti-aliasing of the Linux 'Xft' system, that is now connected into the 8.5 release of Tcl-Tk.
For now, I am occupied with going back to add some features to the FE 'xpg' subsystem --- and in developing 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 'cannot-proceed' messages (i.e. blocking by print system 'filters') which I encounter when I try to print using systems like the HPLIP printing system.
And there are some 'fun' Tk GUIs that I plan to code and show in these web pages --- in a 'Featured tkGUIs' category.
Because of my advancing age, I may end up leaving themes and skins to be added by others.
SUPPORT and ENHANCEMENTS :
Because there is only one person (me) developing the FE subsystems for now (2010 to 2018-plus), and because I have long to-do lists (of my own and of my wife), I cannot provide much support --- certainly no '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 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 a '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 80% of the spam getting through my ISP's filters.
(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 black-lists. Makes white-lists more appealing, but then one has to keep checking the Probable-Spam mail bucket for addresses to add to the white-list.)
I will add blocking ISP ranges for the U.S. also, as I discover sources of spam from U.S. IP addresses.
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 you can let me know of options that should be added to FE subsystem Tk GUI 'front-end' scripts and Bourne/bash shell 'wrapper' scripts, when 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 for the cost of maintaining this web site --- and to help motivate the continuation of additions and enhancements --- such as the IP-address mail filtering (at the user's mail client) mentioned above --- or, such as the Tk themes and skins, mentioned in a previous section.
[One type of programming that could draw time away from the 'fun' projects is bug fixing. Hopefully there are not many, since I use the FE subsystems myself.]
You can choose an oblique font for the toolchests.
Helping Yourself (be my guest)
Because most of the FE AppsMenu 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 (command 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!
Have fun with fonts --- for the FE 'AppMenus' toolchests!
You can use the 'ChgFont' button at the bottom
of each FE toolchest.
(These are relatively crude Tcl-Tk 8.4 images.
I plan to eventually add some Tcl-Tk 8.5 images here.
Tcl-Tk 8.5 uses Xft anti-aliasing to render fonts
in high-quality. We could compare and contrast 8.4
images versus 8.5 images --- jaggies versus anti-aliasing.
Some claim they prefer the jaggies to anti-aliasing.
I beg to differ. The image on the left would be
SOOO much better with anti-aliasing.)
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 AppMenus subsystem of the FE family of systems
FE Software . . . . Some Kind of Wonderful.
Bottom of this
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 2010 Sep 07.