The FE 'AppMenus' subsystem

a detailed Description

(FE = Freedom Environment)

Javascript is disabled. Please enable Javascript
in order to see image changes on 'mouse-overs'.

FE Home page > FE Overview page > This FE 'AppMenus' subsystem Description page

! Preliminary ! This description may be touched up or revised occasionally.


Click on this image to see the expanded 'toolchest',
as if you had clicked on the '>>' button, at the bottom of
the chest of 'drawers'. To return to this page,
click on the 'Back' button of your browser.

Page 2

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

  • app 'drawers' for the user's favorite apps
  • a drawer that starts up an 'Application Categories' toolchest
    (image of the 'AppCat' toolchest is below)

The application categories toolchest offers (initially) about 20 categories such as (in alpha-numeric order)

  • 3D apps
  • AUDIO-only apps
  • CD-DVD apps
  • EDITORS-of-text apps
  • FTP apps
  • IMAGE-PHOTO apps
  • MAIL apps
  • OFFICE apps
  • PDF apps
  • VIDEO-AUDIO apps
  • TERMINAL apps

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
the chest of 'drawers'. To return to this page,
click on the 'Back' button of your browser.

Page 3


In terms of files, the FE AppMenus subsystem is, basically, a collection of

  • Linux/Unix SHELL SCRIPTS,
  • a main TCL-TK SCRIPT that generates 'toolchest' GUIs,
  • 'CHEST DEFINITION' text-files, and
  • this HELP file.

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'. If you do not like the way the 'toolchest' system is organized, you can make changes in many different ways:

  • edit a 'chest definition' file to change the apps being presented or to change their order in the 'toolchest' or to change the app name or description shown in the toolchest

  • edit a 'toolchest' startup script to change the top window-manager-bar title (or the icon title) for the toolchest

  • break a 'toolchest' up if it gets too large. Or, even if a toolchest is not overwhelmingly large, you might want to break part of the 'drawers' off into a new sub-category --- by splitting off part of the 'chestdef' file into another 'chestdef' file, and providing 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

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. For example: a Video-tools toolchest can call a CD-DVD-tools toolchest and vice versa. 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.

Page 4


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.


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 --- but they 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 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
'' 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.

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.

Page 6

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 '' 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:

  • widget fonts, in particular fonts for the Tk button widgets that are used to make the 'drawers'

  • widget colors, like the default 'palette' of colors for all the toolchests

  • widget apps, like the print command to be used for printing

  • widget geometry, like x and y internal padding in buttons.

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'.

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 :

  • Comment lines are indicated by '#' in byte 1. Comment lines (and blank lines) are not processed when the toolchest is generated by the '' Tk script.

  • 'Label' (title or section heading) lines are indicated by '^' in byte 1, followed by the label text.

  • 'Horizontal-Separator' lines can be added anywhere in the chest by specifying '!' 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 '' script :

The appearance of the toolchests can be changed :

  • temporarily via the 'Colors' or 'Font' buttons,

  • or changing the widget appearances in the GUI more permanently by editing the Tk 'include' files

  • or changing the content of the lines ('drawers') in the GUI by editing the 'chestdef' files.

You can also make a drastic change to the appearance of the toolchests by changing (or completely re-writing) the single '' script --- which makes all the toolchests.

For example, you could make a '' script that uses a 'canvas' widget (and widgets within that canvas), rather than using the 'frame' and 'button' widgets in the delivered '' 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 '' Tk script for a little more information on that Tcl-Tk script.

Here is an image of the 'Image Tools' toolchest, as it may be delivered.
Click on this image to see the 'expanded' chest.

page 7


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

  • chestdef_scripts
  • chestdefs
  • helps
  • images
  • includes_sh
  • includes_tk
  • scripts
  • tkGUIs

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
    to, say,
    $HOME/apps/feAppMenus_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/feAppMenus_yyyymmmdd directory --- in a matter of seconds.)

Here is an image of the 'Web Browsers' toolchest, as it may be delivered.
Click on this image to see the 'expanded' chest.

page 8


The 'chest definition' files are read, line by line, by the script


to make the 'toolchest' for each application category.

The '' 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 '' 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).

Anti-aliasing :

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 --- 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.

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 ; 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) '' 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 '' 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.

Skins :

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

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, '', 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.

page 9


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 (2010), 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 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

  • enhancements to (or re-write of) the '' tkGUI script of the FE AppMenus subsystem

  • enhancements to the '' tkGUI script of the FE 'xpg' subsystem

  • more scripts added to the FE Nautilus Scripts 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 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.]

I got rid of most of the jaggies in this oblique font by
running the image through the Gaussian Blur effect of the
'mtpaint' program, which is my work horse.

page 10

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!
(I plan to eventually add some Tcl-Tk 8.5 [with Xft anti-aliasing]
images here --- to compare and contrast --- 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.)

page A.1

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

  • 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 AppMenus subsystem of the FE family of systems

"FE Software . . . . Some Kind of Wonderful."

Bottom of the FE 'AppMenus' 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. >

OR ...

< Go to FE Home page >

Page created 2010 Sep 07. Changed 2011 Sep 17.