The FE 'HandyTools' subsystem
A Detailed DESCRIPTION
! DEPRECATED !
The FE 'HandyTools'
subsystem
is to be replaced
by the FE
'tkGooies' subsystem.
(FE = Freedom Environment)
|
The main toolchest of the
'feHandyTools' system ---
an initial (2011) version.
|
Javascript is disabled. Please enable Javascript
in order to see image changes on 'mouse-overs'
and see text at an appropriate size.
! Note !
This 'feHandyTools' FE subsystem is DEPRECATED.
It is to be REPLACED by the FE 'tkGooies' subsystem.
This description page is provided for the historical notes
--- and it may be helpful to understand the 'tkGooies' system.
TABLE OF CONTENTS
(links to sections of this page, below)
|
Above is an 'feHandyTools' GUI ---
done with a Tcl-Tk script --- for
getting 'man' help on a topic/command.
That entry GUI popped up after a click on the
'LinuxHELP' toolchest, whose image is below.
See the fourth drawer from the top.
This is utility is similar to a 'LinuxHELP'
menu in the 'feNautilusScripts' system,
in which prompting done by a
Zenity GUI,
instead of Tcl-Tk scripts.
Rather than spending time duplicating utilities
of 'feNautilusScripts' --- and spending time
using Tcl-Tk GUI's to replace Zenity GUI's ---
the 'tkGooies' system (that replaces 'feHandyTools')
concentrates on providing GUI utilities that are
NOT provided in 'feNautilusScripts'.
So a 'LinuxHELP' toolchest does not
appear in the 'tkGooies' system.
Page 2
INTRODUCTION to the 'FE HandyTools' subsystem :
'toolchests', 'drawers', and categories
What the user sees on starting up the FE HandyTools system is
a 'toolchest' composed of 'drawers' --- like the chest-of-drawers
in the images above.
The 'drawers' in the starting 'toolchest' of the 'FE HandyTools' system
are categories of tools.
See the list of categories, below.
When the user clicks on any of those 'category' drawers, he/she calls up
another toolchest, offering drawers of tools, in the selected category.
In any of the 'category toolchests', most of the 'drawers' are 'tools' (utility
scripts) which are triggered when you click on the drawer.
However, if the toolchest is over-flowing with tools, some of the drawers
may invoke 'subcategory toolchests'.
The 'subcategory toolchests' then present utility 'tool drawers' --- or even more
'subcategories'.
Usually, 2 or 3 levels of categories suffice.
As delivered, the FE HandyTools system provides about 20 to 30 categories of
toolchests (menus).
About a dozen 'tool' categories are offered in the initial toolchest ---
such as the following.
(Sub-category toolchests are shown indented.)
- AUDIO-only tools
- CHANGEfiles tools
- EXAMINEfiles tools
- FILESlists tools
- FINDlists tools
- IMAGE-PHOTO tools
- LinuxHELPS
- PLOT tools
- PROCESS-MEM lists
- SPACE lists
- TERMINAL tools
- VIDEO tools
- MORE HandyTools
(the top-level 'MORE' categories toolchest
contains the following 'drawers')
- 3D tools
- EXE examine tools
- FONT tools
- HOSTCONFIG-FILES tools
- HOSTCONFIG-QUERY tools
- LOG file tools
- MAIL tools
- NETWORK EXAMINATION tools
- NETWORK query tools
- PACKET examination tools
- OFFICE tools
- PDF tools
- PRINT-SCAN-FAX tools
- PROGRAMMING tools
- USERS-and-GROUPS tools
- WEB/NET SECURITY tools
- Xinfo tools
With the 'sub-chests' of tools, there are about 30 delivered toolchests
in all.
There are so many 'IMAGE-or-PHOTO tools' that there is at least one sub-chest
with a name like 'OTHER IMAGE tools' to accomodate the overflow.
feHandyTools vs. feNautilusScripts
For consistency, the toolchests in the 'feHandyTools' subsystem, as
delivered, follow the same categories and heirarchical structure used
by the 'feNautilusScripts' system.
Many of the tools in 'feHandyTools' were 'ported' from 'feNautilusScripts'.
When a user can't find what he/she needs in one of these FE subsystems, he/she
can try the other subsystem.
A significant difference between the 'feHandyTools' subsystem and the
'feNautilusScripts' subsystem is that the 'feNautilusScripts' subsystem
uses the 'zenity' tool (available on almost any Linux system) to prompt
for user input whereas the 'feHandyTools' subsystem uses Tcl-Tk GUI scripts
to prompt for user input.
A Tcl-Tk GUI can be devised to almost any order of complexity required.
A complex tool might require a *sequence* of 'zenity' prompts, but
a single Tcl-Tk GUI could be created to get the user
input via one GUI prompt.
Altering the toolchests, via
the 'chestdef' files --- like 'feAppMenus'
The 'feHandyTools' toolchests are created from 'chestdef' files using a
Tk GUI-making script called 'make_chest.tk'.
This is the same method used to make the toolchests of the 'feAppMenus' subsystem.
By simply editing the 'chestdef' files that are used by 'make_chest.tk',
the user can modify ANY of the toolchests in just about any way, such as
-
change the order of the drawers in any of the toolchests
-
change the names (and longer descriptions) of the drawers
-
add drawers (tools) to a toolchest
-
remove drawers from a toolchest --- or 'gray out' drawers, that is,
de-activate them
-
create a new toolchest by creating a new 'chestdef' file
and startup script --- and add the startup script as a drawer
in an existing chestdef file
-
reorganize the toolchest hierarchy by moving drawers from one 'chestdef'
file into another
-
collapse down two toolchests into one toolchest by moving all the
drawers from one 'chestdef' file into another 'chestdef' file
Numbers, Names, and Sizes of toolchests
You can combine toolchest definition files to collapse the toolchests down into
a lower number of categories.
But the author of this system finds that he can find tools easier with
about 25 to 30 categories.
And to make it easier to find tools within a category, the author finds it
helpful to keep the number of drawers in any toolchest to less than 20.
In too many Linux menu systems, a wide variety of tools are put into vague
categories such as 'Accessories' and 'Other', with a max of about 10 categories,
total.
More specific categories such as 'Internet' and 'Sound & Video' (or 'Media')
end up having much more than 20 tools in them, of widely varying functionality.
This makes it a chore to repeatedly have to scan an essentially randomly
ordered list of tools to find the one tool that one is looking for.
Example:
In the 'Sound & Video' category of Ubuntu Linux,
the list of tools varies among CD-DVD tools, Audio-only tools, Video tools,
Webcam tools, and perhaps a few more sub-categories that one could add
to this sub-category list.
The essentially random order is usually due to the ordering of
applications alphabetically by names, and the names are often no indication
of the functionality of the tool.
Examples: Firefox, Seamonkey, Thunderbird, Brasero, Totem
After installing quite a few applications via a Linux package manager, the user
can easily end up with 50 to 100 applications in a general category like
'Media' (or 'Sound & Video').
As a result, the author finds it very helpful to have a 'CD-DVD tools' category
in 'feAppMenus', rather than having to wonder if a particular CD-DVD app is
filed under 'Accessories' or 'Sound & Video' (or 'Media') or 'Other'.
And the author finds it much less frustrating having audio-only tools,
like the Audacity audio editor, the EasyTAG audio tags editor,
and various audio players, in the 'AUDIO-only tools' chest ---
rather than searching for them scattered among 30-plus tools, in
a 'Sound & Video' category --- which includes many CD-DVD tools, as well
as Video tools.
Although I am using examples from the 'feAppMenus' FE subsystem, the same
categorization considerations (appropriate numbers and names and sizes of
categories) apply to the 'feHandyTools' FE subsystem.
|
Poke this image of the 'AUDIOtools' toolchest
--- to see the Directory-Selector GUI that
appears when you click on the 1st drawer
to use the 'gnome-player' program
to play some mp3 files.
The Directory-Selector GUI is shown in
a separate window or tab.
There is an 'AUDIOtools' toolchest in the
'tkGooies' system --- but that toolchest
has somewhat different options from this one.
Page 3
'OPEN' CODE and
RE-CONFIGURABLE TOOLCHESTS :
In terms of files, the FE HandyTools subsystem is, basically,
a collection of
-
a main Tcl-Tk SCRIPT, 'make_chest.tk' , that generates
'toolchest' GUIs,
-
about 30 "CHEST DEFINITION" text-files,
-
about 20 utility Tk-GUI-generating Tcl-Tk scripts,
-
Linux/Unix SHELL SCRIPTS (more than 100) that are 'wrappers'
for the Tk GUI scripts and various Linux/Unix commands
-
an FE HandyTools HELP file (plain-text) and about 15 other
plain-text help files
-
and various other files such as 'include' script code snippets
and icons.
Herein lies the FREEDOM.
All program code is in script text files --- either
Linux/Unix shell scripts or Tcl-Tk scripts.
Each script is easy to browse.
There are no source files separate from the executable files --- which
can lead to questions of whether the source matches the executables.
The source files ARE the executables.
Furthermore, to perform functions in shell and Tcl-Tk scripts generally
requires many fewer lines of code than C++ or other compiled programs ---
which become even more complicated because of their typical need to reference
large libraries of utility routines --- especially graphical interface
routines.
So the scripts are relatively readable, compared to most source code that is
intended for a compiler and linker.
Furthermore, the scripts are open to direct modification and enhancement.
Not so with compiled binary executables.
(The author has put an unusual number of comments in the scripts
--- mainly for his own benefit in maintenance and enhancement activities.
But another benefit is that users have access to a lot of comments
describing the general structure of the scripts, as well as comments
on small sections and individual lines of the scripts.)
Simple 'chestdef' files
The 'chestdef' files that define the toolchests have a very simple format.
This facilitates the freedom to modify the system.
The 'chestdefs' are text files that can be easily edited.
The format is described below, in an 'EditChest button' section.
As delivered, the initial chestdef files contain some commented (or 'grayed out')
example 'drawer'-definition lines, as well as activated lines.
The activated lines can be commented or the commented example lines
can be activated, after implementing the associated script.
Changes via GUI buttons or via file operations
The FE 'HandyTools' system is a *REALLY* 'OPEN SYSTEM'.
If you do not like the way the 'toolchest' system is organized
or its appearance, you can make changes.
There are basically two ways you can make the changes :
or, to have access to EVERYTHING,
-
(2)
via more general manipulation of the files in the various
installation directories --- like 'chestdefs', 'chestdef_scripts',
'scripts', 'tkGUIs', 'includes_tk'.
The directories are outlined more fully in a section below.
For example, I use Nautilus as a GUI file manager --- often with
3 or 4 directory windows open at directories 'tkGUIs', 'scripts',
'chestdefs', and, sometimes 'chestdef_scripts'.
And I use 'TERMtools' of 'feNautilusScripts' to open a shell
(command interpreter) window, positioned at one of the scripts
directories --- to see error/debug/trace messages written to
'stdout' while doing script testing.
Via the 'EditVars' button, you can change appearances, by changing values of
parameters, which control toolchest and other Tk GUI
-
fonts --- for buttons, labels, listboxes, etc. in Tk GUI widgets
-
colors --- such as the 'palette' of Tk GUI's
-
geometry --- such as padding in Tk GUI widgets
-
apps --- such as those used for HTML browsing and image viewing/editing
Via the 'EditChest' button, you can edit a 'chest definition' file to:
-
change the order of apps in the 'toolchest'
-
change the apps being presented
-
change the app name or description shown in the toolchest
--- even translate to another language
-
add separator lines or change the location of separator lines
-
add or remove section heading lines, or change the wording
in those section headings (or translate to another language)
Some changes to the toolchests would have to be done via operations
outside the functionality of the GUI buttons ---
such as copying and renaming of 'chestdef' files --- and editing those new
'chestdef' files and the scripts that present the toolchests.
For example, by using those kinds of operations:
-
You could break a 'toolchest' up if it gets too large.
If you want to break part of the 'drawers' off into a new sub-category,
copy the 'chestdef' file into another 'chestdef' file, edit the two
chestdef files, and provide a new 'toolchest' startup script for the new
'chestdef' file.
-
You could go the other way: consolidate a couple of chestdef
files into one chestdef file, and 'retire' one of the toolchest
startup scripts.
-
Also, you can edit a 'toolchest' startup script to change
the top window-manager-bar title (or the icon title) for the
toolchest --- or change where it pops up on the screen.
The toolchests are in
a Network, not a Hierarchy
Note that the 'drawers' in the 'toolchests' do not have to
have a hierarchical order --- any toolchest can call any other
toolchest.
A 'child' toolchest can call a 'parent' or 'grandparent'
toolchest --- so that the concept of parent-child relationships
can actually become almost meaningless.
For example: A VIDEO-tools toolchest can call an AUDIO-tools toolchest
and vice versa.
In fact, an AUDIO-only-tools toolchest and
a VIDEO-tools toolchest and a CD-DVD-tools toolchest
can all call each other.
About the only notion of a hierarchy that remains is that
the 'feHandyTools' toolchest usually starts the menu chain off
--- showing some of the most-frequently-used tool categories
and a 'drawer-link' to an 'OTHER categories' toolchest, for a
total of about 20 to 30 tools-categories drawers.
So the 'feHandyTools' toolchest could be considered to be at
the top of a hierarchy.
But, actually, the user could start any of the other toolchests via
its startup script and any of those toolchests could have a drawer
that starts up the daddy or grand-daddy 'feHandyTools' toolchest.
Some people would call this structure a 'network structure',
rather than a 'heirarchy structure'.
Any node (toolchest) can have a 'link' to any other node (toolchest).
No frustrating rock-and-hard-places
(no Catch-22's)
You can re-organize the system in many ways --- and enhance it in
many ways.
You do not have to wait for a new release for a fix or
enhancement.
In fact, this author was motivated to create this flexible menu
system after an unpleasant experience in using a KDE menu editor
to edit a KDE tools menu.
I made some menu changes using the menu editor, and got
into a Catch-22 situation where an app that I added
was not showing up, but when I tried to add it again, it would not
let me because it said it was already there.
I was stuck with no clear way out of that hole, other than
re-installing KDE --- and then never touching the menu editor again.
I will never encounter a dead-end like that with this FE HandyTools
menu system.
|
Below is the 'PLOTtools' toolchest, expanded
to show the normally hidden right-hand side.
And below are images of the 3 plot GUI's that
appear when clicking on the 3 drawers shown.
NOTE:
These plots are SCALABLE (zoomable), when
the user clicks on the 'UpCan' button.
Page 4
THE SEEMINGLY OBLIGATORY LICENSE DISCUSSION :
Partly because of the 'extreme open-ness' of the FE subsystems, the FE subsystems
are provided in a freedom-to-copy-and-share and freedom-to-enhance mode
(i.e. we are talking about the proverbial 'license' here).
The other reason for 'freedom-to-copy-and-share and freedom-to-enhance'
is that I am growing old and I would like to pass this useful software
on to future generations, for free.
NOTE:
I do not use the word 'free' for two different concepts ---
'freedom' and 'no cost', like the GPL license does.
To avoid confusion, I use the word 'freedom' for 'freedom' and the word
'free' for 'no cost'.
So when I say "The 'Freedom Environment' is a
free environment", I hope it is clear what I mean.
(It means you do not have to pay for it --- to make
that perfectly clear.)
On obtaining this software, the only requirement is that,
if you make enhancements, to one of my releases
(or to enhanced versions of the FE system, made by others),
those enhancements are available, upon request, at no cost, to me
(the initiator of the system) --- and at no cost to anyone in the chain
of people who created the version from which you started your enhancement
--- and at no cost to anyone who wants to make an enhancement to their
copy of an FE subsystem (any of the evolutionary offshoots of the original),
even if the requestor never made an enhancement to a version of the
FE subsystem themselves.
(The only 'sharing' charge can be a reasonable charge for recording media
and shipping --- both of which would be essentially zero if the
code is delivered via download over the Internet.
Since the code of any of the FE subsystems is much less than 20 Megabytes,
the entire enhanced system could and should be delivered upon
request.
Even a heavily enhanced version of my releases of any
the FE subsystems would occupy less than 3% of a CD, less than
half of 1% of a DVD, and less than 8% of the smallest 'thumb drive'
= 'USB stick' available nowadays.
A copy could be transferred over a broadband Internet connection,
even a slow connection, in much less than a minute ---
within a few seconds, in most cases.)
It is my hope and intent that the FE subsystems can evolve like the Linux
kernel and Linux distros.
That is, any of the FE subsystems is started as a
free 'core' to which anyone can add --- and if they wish, enhancers can
charge for support of their version --- bug fixing, question answering,
further enhancements, training, and the like.
But their enhanced code must be provided at no cost (as outlined above)
upon request --- else stop any and all charging related to the
enhancements and the original code.
Like Linux distros and applications, I expect there to be many versions
(evolutionary states) of any FE subsystem code --- available for free ---
media and delivery costs excepted.
And I expect that competition (and all code enhancements available
to all requestors for free) will keep prices for 'support'
(as outlined above) reasonable.
I guess I need a name for the 'license' described in the above
statements --- since it is not quite a GPL or BSD or any other
kind of license --- although it is certainly in the spirit of
those licenses.
If I ever refer to this 'license' again, I will call it the
'FE license', for short.
By the way, here is the usual disclaimer --- in the usual caps.
THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS "AS IS" AND
ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHORS OR CONTRIBUTORS BE LIABLE
FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
SUCH DAMAGE.
|
Above are three feHandyTools 'toolchests'
that might typically be on a desktop.
The toolchests can be dragged down to
the bottom of the screen, leaving
only the title bars showing, so that
the chests are out of the way --- but
they are ready to be dragged into action
at any time, by those title bars.
Alternatively, on most desktops, click on
the minimize symbol at the upper right
of the title-bar to make a toolchest iconize
into a desktop tasks panel.
Note that you can close any one of the
toolchests in the usual way that you
close a window --- click on the upper right
(or left) of the window bar.
These windows are independent of each other,
so that you can 'kill' any one of them and
the others will remain --- even if you close
the one that started off the 'spawning'.
In other words, as soon as a window is spawned,
there is no parent-child relationship anymore
like there is among the processes you
usually track with the 'ps' command.
For each chest, you will see a
'make_chest.tk' process in a processes list.
Page 5
POP-FREE, rather than Pop-Connected, MENUS
Each 'chest' pops up as a separate window --- rather than
being attached to the chest from which it popped up.
A nice property of the un-attached toolchests:
One consequence of these features is that the toolchests are, quite
naturally, a 'network' rather than a 'hierarchy'.
There is no 'king' and no 'serfs'.
Any toolchest can be closed --- and any toolchest
can be left open (when its 'predecessors', NOT its 'overlords', are closed).
There are predecessors, not overlords.
A predecessor can be closed without resulting in the closing
of its successors.
There is an equality among all toolchests.
For example, a 'Video-tools' toolchest can include a drawer that
triggers a 'CD-DVD-tools' toolchest, and, at the same time,
the 'CD-DVD-tools' toolchest can include a drawer that triggers
the 'Video-tools' toolchest.
You could say: 'Child' chests can trigger 'parent' chests.
One toolchest does not become the 'master' toolchest
just by facilitating the opening of another toolchest.
In fact, any chest can trigger the 'top', usual-startup chest,
the 'feHandyTools' chest. In other words, the 'main' 'feHandyTools' chest
can be a 'drawer' in any other toolchest.
You can close each chest in the way you usually close
windows: click on the upper right (or upper left) of the
window.
If you need to keep a toolchest around for a while
(to use various drawers within the toolchest), you can
drag the window down to the bottom of the screen where
just the title bar of the chest will show.
Later, you can drag the chest up again, to use the drawers.
Alternatively, you can click on the 'Minimize' indicator
of the title bar of the chest, and the chest will be
stored within the desktop taskbar, for later retreival.
And, with some window managers (KDE), you can double-click
on the titlebar of the chest and the chest will disappear
leaving only the titlebar of the chest in place.
This is the 'roll-up window shade' effect.
Double-click again, on the titlebar of the chest, to
restore the chest.
|
The 'SPACEtools' toolchest --- handy for
finding your biggest directories
(both in Megabytes and in numbers of files)
--- and the biggest files ---
when disk space is running out.
There is a 'SPACEtools' toolchest in the
'feNautilusScripts' FE subsystem.
Rather than have a similar 'SPACEtools' chest
in the 'tkGooies' system that is replacing this
'feHandyTools' system, the 'SPACEtools' of
'feNautilusScripts' can be used.
Page 6
The TOOLCHEST BUTTONS,
common to every feHandyTools toolchest
At the bottom of any of the toolchests are a few buttons
--- labelled 'Help', 'Color', 'Font', and '>>'.
The 'Help' button :
Click on the 'Help' button and a plain-text help file, with content
like the content of this web page, is shown.
That plain-text help file and many of the other (plain-text) helps
of the FE subsystems are shown with an FE system utility called
'xpg' --- which presents the text in a GUI, via a 'shofil.tk' Tk script.
The FE 'xpg' utility is a scroll, search, extract-match-lines,
and print utility for text files.
Click on the 'Help' button of the 'xpg' GUI to see
a description of those features of the FE 'xpg' utility.
The 'extract-match-lines' feature is rather unique
and can be a great help when browsing through
huge text files in search of particular sections of
information or data items.
The 'Color' button :
Click on the 'Color' button and a GUI with Red-Green-Blue
slider bars appears, to allow you to change the background
color of the (current) toolchest.
This could be used to help you rapidly choose among
several open FE toolchests via color.
Or you can change the toolchest color to go better with your
screen background.
After some experimenting with the 'Color' button ...
You can change the color 'palette' of ALL the toolchests
and GUIs of the FE system by editing an FE system Tk script
'include' file to change the value of the three Tk variables
--- r255, g255, b255 --- that are used to set the
color 'palette' of the FE toolchests and Tk GUI's.
There is more information on editing the
Tk 'include' files, in the description of the 'EditVars'
button, below.
The 'Font' button :
Click on 'Font' to change the font of the toolchest 'drawers'
(which are actually Tk button widgets) and the font of the
drawer-section-titles, if any, of the (current) toolchest.
This could help those who need bigger/bolder print
for readability. Or, try it just for grins.
(Try a Greek letter font or a 'whimsical' font
among those available on your computer.
You can browse through the available fonts via the
'FE Font Selector' GUI that is presented when
you click the 'Font' button on the toolchest.)
After experimenting like this with font possiblities,
the default font of ALL the toolchests can be 'permanently'
changed by editing an FE system Tk 'include' code file.
See more on editing the Tk 'include' files, in the 'EditVars'
button section, below.
The '>>' (and '<<') button :
Click on the '>>' button and the toolchest expands to the right,
showing some longer descriptions of the toolchest drawers.
You can change these descriptions --- the short ones and the
long ones --- on the left and right parts of the toolchest.
For example, you can translate the descriptions
to a different language --- by editing the 'chestdef'
file of the corresponding toolchest.
Simply click on the 'EditChest' button, as described below,
to immediately make changes to the 'toolchest' you are looking at.
After clicking on the '>>' button, its label changes to '<<'.
Click on the button in that mode, and the GUI contracts back
to its narrower size.
The 'EditVars' and 'EditChest' buttons :
When the user clicks on '>>' and the toolchest expands to the right,
a couple of 'hidden' buttons are revealed --- 'EditChest' and
'EditVars'.
There is a fundamental difference in these two buttons:
-
When you click on the 'EditChest' button, the changes you make are
only applicable to the toolchest on which you clicked.
-
When you click on the 'EditVars' button, the changes you make apply
to ALL the toolchests ---- and to ALL the Tk prompting GUI's of the
'feHandyTools' system --- the file-selector GUI's, the list-selector
GUI's, the entry-field GUI's, the FE color-selector GUI, the
FE font-selector GUI, etc.
|
The four buttons on the 'EditVars'
GUI that facilitate changing the
appearance of the 'feHandyTools' GUIs.
The 'EditVars' button
The 'EditVars' button provides easy access to the several Tk 'include'
files that allow you to 'more permanently' (than with the 'ChgColor'
and 'ChgFont' buttons) change such toolchest GUI features as:
-
widget fonts, in particular fonts for the Tk button widgets
that are used to make the toolchest 'drawers'
-
widget colors, like the default 'palette' of colors for all
the toolchests
-
widget geometry, like x and y internal padding in buttons.
-
widget apps, like the web browser that you prefer to use in
'feHandyTools' utilities that show an HTML page
NOTE that these Tk GUI parameters are used by ALL the 'feHandyTools'
GUIs -- not just the common toolchest GUI.
That is, ALL the prompting GUIs use the parameters in the fonts,
colors, apps, and geometry parameter files.
-
the listbox GUIs that provide for directory navigation and
file selection
-
the entry GUIs that accept user input via entry boxes and
checkbuttons and radiobuttons and option lists
-
the 'PlotQuik' GUIs
-
the specialized GUIs, like the GUIs used for VIDEOtools
So, if you want to change the appearance of a directory
navigation GUI, you can do it via the 'EditVars' button
in ANY of the toolchest GUIs.
Close and re-open GUI's (for changes to take effect)
Clicking on the 'EditVars' button brings up the GUI seen above,
with four Edit buttons --- corresponding to four Tk variables
categories : 'fonts', 'colors', 'geometry', and 'apps'.
After you edit one or more of those 4 files, according to the plentiful
comments in those files, close out all FE 'HandyTools' GUIs.
When you restart the GUIs, you will see the effects of your changes.
There are backups of these '.tki' include files in the 'includes_tk'
directory of the installation.
Those '.tki_BKUP' files can be used to restore the files if you
make an unrecoverable mistake in editing.
The 'EditChest' button
Similarly for the 'EditChest' button --- after editing,
close the toolchest and re-open.
After you have edited the '.chestdef' file for the current toolchest,
close the toolchest and start it up
again to see the changes in the GUI that result from your changes to
the '.chestdef' file.
Here is a description of the chestdef file format :
-
Comment lines are indicated by '#' (hash symbol) in byte 1.
Comment lines (and blank lines) are not processed when the
toolchest is generated by the 'make_chest.tk' Tk script.
-
'Label' (title or section heading) lines are indicated by
'^' (caret symbol) in byte 1, followed by the label text.
-
'Horizontal-Separator' lines can be added anywhere in the chest by
specifying '!' (an exclamation mark) in byte 1.
Any other text after the '!' in the line is ignored.
-
'Grayed-out program' lines are indicated by a '-' (minus sign) in byte 1.
-
All other lines are considered 'executable app' lines.
The separator for the several fields in the
'executable' (and the 'grayed-out') lines is back-slash (\).
-
Field1 is the brief-text describing the executable.
-
Field2 is the executable (with full path, if needed or wanted),
with any parameters needed.
-
Field3 is added description, for the sprout-out,
right-hand-frame of the chest.
-
Field4 (optional) may be used to specify an icon file.
For 'grayed-out' lines ('-' in byte 1), Field2 (the executable field) is not
trigger-able.
So you can de-activate a 'live' line, yet have the description(s) still
show, by putting '-' in col1.
The program descriptions in field1 and field3
are shown, grayed out.
This is a way of displaying a 'placeholder' or 'reminder' app line.
If you don't want the program line to show, you can put '#' in byte 1,
to make it a comment line.
Or, if you are sure you don't need the line, you can delete it.
One more (really heavy-duty) change
--- the 'make_chest.tk' script :
In summary, the appearance of the toolchests can be changed :
-
temporarily via the 'ChgColor' or 'ChgFont' buttons, for that
particular toolchest,
-
or, change the widget appearances in ALL the toolchests,
more permanently, by editing the Tk 'include' files via
the 'EditVars' button
-
or, change the content of the lines ('drawers') in any toolchest by
editing its 'chestdef' file via its 'Edit Chest' button.
BUT . . . You can also make a drastic change to the appearance of the
toolchests by changing (or completely re-writing) the single
'make_chest.tk' script --- which makes all the toolchests.
For example, you could make a 'make_chest.tk' script that uses
a 'canvas' widget (and widgets within that canvas), rather than
using the 'frame' and 'button' widgets in the delivered
'make_chest.tk' script.
Here again you can see that --- the FE system is a *REALLY*
open system.
EVERYTHING is open to change.
See the section below on the 'make_chest.tk' Tk script for
a little more information on that Tcl-Tk script.
|
Above is an image of the
'File(s)-Selector' GUI that
provides the capability of running any
of the scripts of 'feNautilusScripts'
without using the Nautilus file manager.
In other words, if you use a non-Gnome-derived
desktop --- like KDE or LXDE or Xfce or Fluxbox
--- you can run the scripts of 'feNautilusScripts'.
Just install both 'feHandyTools' and 'feNautilusScripts'.
After the user selects one or more files via
this GUI, he/she clicks on the 'Apply-a-Script'
button to navigate to a Nautilus script and
select it to run with the selected files as input.
This function is being replaced by a
'tkScriptApplicator' in the 'tkGooies' system
--- in the 'FILEmanagers' toolchest.
Page 7
THE FE HandyTools DIRECTORIES :
The install directories of the FE 'HandyTools' subsystem go under an
'feHandyTools_yyyymmmdd' directory --- full name
$HOME/apps/feHandyTools_yyyymmmdd
--- where yyyymmmdd is a release date like 2011sep17.
It is a simple, 'almost-flat' directory structure --- only one or two levels
of directories.
The sub-directory names are
-
chestdef_scripts
-
chestdefs
-
helps
-
images
(with a 'bullets' subdirectory)
-
includes_sh
-
includes_tk
-
lists
-
scripts
(with about 20 to 30 tool-category subdirectories)
-
tkGUIs
(with 'tkGUIs_listbox', 'tkGUIs_entry', 'tkGUIs_DEMOS',
and 'tkGUIs_PLOTtools' subdirectories)
The 'chestdef_scripts' and 'chestdefs' directories
contain the toolchest startup scripts and toolchest definitions, respectively,
for about 20 to 30 categories of tools in the delivered installation.
The 'feHandyTools.chestdef' file in the 'chestdefs' directory uses a
'bullet' icon that is used in all the drawers of all the delivered toolchests.
That 'default' bullet icon can be changed by simply overlaying the
'bullet_default.gif' file in the 'images/bullets' sub-directory of the
'feHandyTools' installation.
(To keep the height of the 'drawers' from being too big,
it is best to use icons no bigger than about 20x20 pixels.)
Making changes --- by directory :
To give an idea of which directories to go to when trying to make
changes to the 'feHandyTools' system via a file manager or the
command line, rather than through the 'EditChest' or 'EditVars' buttons,
here are the directories and the changes that can be made there:
-
'chestdefs' - edit the '.chestdef' files to change the toolchests :
-
change the order of the tools in the drawers
-
change/translate the names and descriptions given to the tools
-
add, comment, delete, or gray-out 'drawers'
-
add/move/remove separator lines
-
re-word/translate/remove/add section titles
-
'chestdef_scripts' - change the title, icon-title, or
opening window-position of any toolchest
-
'includes_tk' - edit the fonts, colors, geometry, or apps '.tki'
include script code to change values in these types of variables
used for all the 'feHandyTools' toolchests and Tk GUI's
-
'scripts' - edit any of the 'wrapper' scripts --- the 'general'
scripts or the scripts in the 20-plus tool categories
-
'tkGUIs' - edit the general '.tk' scripts, like 'make_chest.tk',
or the Tk scripts in several subdirectories: 'tkGUIs_listbox',
'tkGUIs_entry', 'tkGUIs_PLOTtools', 'tkGUIs_DEMOS'
-
'helps', 'lists' - edit the text files in these directories
Backups when revising 'chestdefs' or scripts :
If you intend to do revisions to chestdef files or scripts, I would suggest
that you backup the individual files that you change.
You could backup the original file by renaming it with an '_ORIG' suffix,
for example.
Then make a copy of it, to the original name, and start editing it.
You can make a backup of your changes after saving your changes,
by doing 'Save As' and saving the file with a suffix like '_2010sep08'.
That way, if you make a series of changes, over a period of days or weeks
or months, you will have an image for each of the several changes.
If you do extensive revisions, I suggest that you back up the entire installation
directory ... or have the original install file (the self-extracting
'.sh' script) handy --- or download the self-extracting install script of
the latest release.
The install directory of this FE subsystem is relatively small (a few Megabytes),
so it is no big space-eater if you back up the entire installation.
(If you totally mess up the installation directory, you could rename it
--- from
$HOME/apps/ feHandyTools_yyyymmmdd
to, say,
$HOME/apps/ feHandyTools_yyyymmmdd_FOOBAR
--- in case you want to be able to refer to some changes that you made.
Then you can simply re-install to a
$HOME/apps/feHandyTools_yyyymmmdd
directory --- in a matter of seconds, from a self-extracting install
script.)
|
Above is an image of a 'Line-Item-Selector'
GUI that is used whenever a handy-tool needs
to offer the user a list from which to select a line.
Page 8
THE 'make_chest.tk' SCRIPT :
The 'chest definition' files are read, line by line, by the script
$FEDIR/tkGUIs/make_chest.tk
to make the 'toolchest' for each HandyTool category.
The 'make_chest.tk' script executes a series of widget-making
Tk commands and then goes into the Tk wait mode --- waiting
for user actions --- mouse-clicks and keyboard entries
on the widgets of the 'toolchest' GUI.
NOTE: HERE is one of the VERY OPEN aspects of the FE system :
The 'make_chest.tk' Tcl-Tk script could be radically altered to make the
chests in a quite different way (say using Tk 'canvas' items rather
than with Tk 'frame'-enclosed items like the Tk 'button' widgets).
Not only can you change the widgets used, but you can also change
the 'bindings' of procedures to specified actions (like <Button-Release>)
on the widgets of the toolchest.
You can invent new behaviors for the toolchest.
Anti-aliased fonts :
The initial implementation of this FE subsystem was developed using the Tcl-Tk 8.4
command interpreter --- the version that came with most Linux systems in the
2007-2010 time frame.
Tcl-Tk developers incorporated the
'Xft' (X-free-type) anti-aliasing system into the Tcl-Tk 8.5 release
of the 'wish' interpreter.
Tcl-Tk 8.5 was released circa 2007 (see
www.tcl.tk), but only around 2010 did that interpreter
start to make an appearance in many Linux distros and package managers.
The Xft anti-aliasing makes the fonts in Tk widgets appear without 'jaggies'.
It is mostly those 'jaggies' that have made people wonder,
in the timeframe from about 2001 to about 2010,
what's wrong with Tcl-Tk --- why can't it make nice looking
fonts like the Gnome and KDE desktops and file managers ---
and like the GIMP and OpenOffice applications, and the Gnome and KDE
font-viewer utilities?
Well, Tcl-Tk 8.5 (with Xft) should put almost all of that belly-aching
and complaining to rest.
In mid-2011, I put Tcl-Tk 8.5 on my development machine.
I am now able to generate screenshots of the toolchests in which the fonts look
much smoother.
I am now able to use italic and oblique fonts without having
to be concerned about their having a too-jaggie look.
Themes :
In recent releases of Tcl-Tk (8.4, 8.5), the Tcl-Tk developers
have come up with a 'theming' system that is intended to blend in
with themes of various windowing systems --- Mac OS X, MS-Windows, and
perhaps even various Linux windowing and desktop systems.
To implement that Tk-handling of themes, a new set of Tk widgets
(in a 'ttk::' Tk namespace) needs to be used. ( ttk = themed tk or tiled tk )
However, the 'ttk::' widgets do not have all the features of the
original Tk widgets --- so it may be a few more years before I
would want to try to convert the FE subsystems that are based on
Tk scripts to use the new 'ttk::' widgets --- especially since
there seem to be some questions as to how well this new Tk theming
is implemented for Linux systems.
When that 'mature' time comes, then the FE system chests and GUIs
may blend in a little more seamlessly with the Linux desktop themes
(Gnome, KDE, or whatever) in use by the Linux user --- if the 'ttk'
system is used in all the Tk scripts of the FE subsystems.
An enhancer of the FE Tk-based subsystems could make '.ttk' scripts
based on copies of the '.tk' scripts --- leaving the '.tk' scripts
available for users still running older versions of Tcl-Tk.
After some suitable re-coding of the 'make_chest.tk' script (and
various other scripts in the 'feHandyTools' subsystem),
the user could be able to choose whether to use '.tk' or '.ttk'
scripts by simply 'flipping a switch' --- such as setting a 'ttk-yes-no'
Tk variable in an 'include' Tk script file of the FE subsystems
--- say in the 'set_widget_apps.tki' Tk-include script-code file.
Or, to avoid a lot of re-programming, simply backup the '.tk' scripts
into a backup directory and copy the '.ttk' scripts into the appropriate
'tkGUIs' (sub)directory and rename the '.ttk' suffix to a '.tk' suffix.
Or, a 3rd alternative: use symbolic links.
For example, have the '.ttk' scripts in 'ttkGUIs' (sub)directories.
Move the '.tk' scripts (of the 'tkGUIs' directory) to a backup
directory and, in their place, make 'symbolic links' from '.ttk' scripts
in the 'ttkGUIs' (sub)directories to '.tk' link files in the 'tkGUIs'
(sub)directories.
Icons on toolchest drawers :
In a past Tcl-Tk release (8.3.x or 8.4.x) came an enhancement to
allow an 'image' and a text string to both be used on a button or label
Tk widget at the same time.
Hence we can populate all the FE system chests with button-drawers
that have a icon image next to the text.
The current (2011) 'make_chest.tk' script of 'feHandyTools'
looks for a fourth field in the 'executable' lines of the
input '.chestdef' file.
In that 4th field, a fully-qualified filename can be placed, that specifies
an icon file --- gif, pgm, or ppm --- a format readable by plain-vanilla Tk.
For example, on the main 'feHandyTools' toolchest, on the
'feNautilusScripts' drawer, I could put a Nautilus icon
(about 20x20 pixels or smaller) to the left of the
'feNautilusScripts' text string.
(See the 2nd 'drawer' from the bottom in the main toolchest below.)
The current 'make_chest.tk' script relies on using image
formats (like gif) with 'built-in' support by Tk, without having
to install a Tk extension.
Hopefully, some of the PNG-and-JPEG-reading extension
called 'Img' will eventually be built-in to Tk.
The 'Img' extension will probably not be delivered with most
Linux distros.
At this time (2011), I do not intend to spend much time on
adding icons to the chests --- partly because icons (larger than
the default, small bullet image being used now) will
just add processing-load and startup-time whenever a chest starts up.
To get a nice looking Nautilus icon, for example, I will probably
have to use an icon about twice as large, in bytes, as the
20 pixels x 15 pixels bullet icon being used now.
The bullet icon that is being used now is from a 1,007 byte file.
The text string in most of the drawer titles is only about 20 bytes of
character code --- although that might be rendered into quite a few more
bytes of pixel image of the characters.
In any case, in a 20-drawer toolchest, there are about 20,000 extra
bytes being processed to show the bullet icons.
One could probably make the toolchests startup a little faster by
commenting out the code line of 'make_chest.tk'
that creates the bullet icon in each toolchest drawer.
However, since the toolchests startup in less than a second now, there may
not be a noticeable speedup by eliminating the (default) icons.
The main reason that I do not plan to spend much time on icons is
because I need to spend time on creating some useful new 'feNautilusScripts'
--- and in creating new 'tkGooies' in the system that is to
replace this 'feHandyTools' system.
Users can experiment with icons to their hearts' content
--- in the FE 'feAppMenus' and 'tkGooies' systems.
Skins :
One man (Portuguese) has used Tcl-Tk to put a classy 'skin' on a
player GUI.
The player is/was called 'VebKlaso' and some pictures of
it may still be at
pragana.net.
Rildo Pragana's player indicates that we can eventually make the
chests as wild looking as the wild looks that one sees in the many
skins for applications like 'winamp' or 'xmms'.
We can create a common skin for all the chests by changing only
the one script, 'make_chest.tk', and leaving the many chestdef
files unchanged.
Unfortunately, this 'skin' technique takes more than basic
Tcl-Tk programming.
It requires using an 'extension' of Tk, and
the couple of extensions that exist so far, with this skinning
type of capability, are not 'mainstream' --- and not 'blessed' by
the maintainers and developers of the Tcl-Tk core.
Reliability is more important than 'wild looks' anyday.
At least that is so in the world of computing --- maybe not in the
fashion world.
So I leave skins to a future FE subsystem release ---
and concentrate on getting functionality into the initial releases.
In summary, there is much that can be done to 'prettify'
the FE system chests (and GUIs) --- with icons, themes, and skins.
But probably the best 'prettifying', in my mind, comes with
using a Tcl-Tk 8.5 'wish' interpreter to gain the advantage of the
anti-aliasing of fonts by the Linux 'Xft' system that has been
implemented in the 8.5 release of the Tcl-Tk 'wish' interpreter (Linux version).
I have no plans to address adding themes (ttk widgets) in 2011.
Nor do I intend to spend a lot of time trying to implement skins,
until the ability to have non-rectangular or transparency-capable
windows is incorporated into the core of Tcl-Tk (so that I do not
have to deal with installing extensions of Tcl-Tk).
Furthermore, I would want the non-rectangular/transparency capability to be
compatible with at least one of the window-managers available on Linux.
For now (2011 Sep), I am occupied with continuing to add some scripts to
the 'feNautilusScripts' subsystem --- and occupied with adding similar and
additional scripts (and Tk GUIs) to the 'feHandyTools' subsystem.
Because of my advanced age, I may end up leaving themes and
skins to be added by others.
|
Above are images of two versions of
the old 15-tile puzzle/game ---
done by two different Tcl-Tk scripts.
You click on a tile next to the open spot
to make the tile move into the hole.
This is an example of 'binding' a procedure
(to move a tile-object on the 'canvas') to a
mouse-event (like 'Button-Release' on
the tile-objects on the canvas).
The demo on the left is a Tk script that
is delivered, along with about 30 others,
in a Tcl-Tk interpreter installation.
The demo on the right was done by Keith Vetter
who contributed a lot of Tk scripts to
the Tclers' Wiki (wiki.tck.tk).
Unfortunately many people who use
Tcl-Tk apps, and even those who program
Tcl-Tk scripts, do not know of the demos.
Their location in the Tcl-Tk interpreter
installation directories is not well-publicized.
Maybe that is a good thing, because even
a highly experienced Tcler like
Keith Vetter (KPV), who has been writing
Tcl-Tk scripts since 1993, had
the following exchange (in 2005)
on Vetter's web page
'The Classic 15 Puzzle' :
"DKF:
The puzzle has been part of the
standard Tk demos since before
I started using Tcl.
KPV:
duh! Well, in my defense, I can say
that at least I'm not the only
person to overlook the Tk demo version
since 'Ideas for Projects in Tcl/Tk'
[http://wiki.tcl.tk/15067] has it listed
as a project to be done."
As a result, Vetter made his own version
of the 15-tile puzzle --- with a 'Solve' button
--- a quite major addition to this 'Tk-app'.
That's quite an achievement. And he even
went on to make an
NxM-tile puzzle
--- that is, the number of rows of tiles and
columns of tiles can be other than 4x4.
So maybe it is NOT a good thing that I am trying
to make the 'core' Tk demos, that come with
any Tcl-Tk interpreter installation, available
via a few mouse clicks on 'PROGRAMMING tools'
toolchest drawers in 'feHandyTools'.
Links to pertinent 'feHandyTools' chest images are here :
'PROGRAMMING tools' toolchest
>
Tcl-Tk Help Chest
>
Tk 'Core' Demos Chest
Page 9
SUPPORT and ENHANCEMENTS :
Since the FE system is provided for free (thus no well-funded
human resources office), and since there is only one person
(me) developing the system for now (2011), and since I have
long to-do lists (of my own and of my wife),
I cannot provide much support --- like 'hand-holding'.
I am willing to take bug reports and suggestions for
enhancements and additions.
But, since I hope to enjoy life in retirement, I cannot
even promise to keep up with brief communications
about those kinds of basic issues.
Email has become a pain for me --- partly because of the daily
receipt of spam that manages to make it through the filters of
my ISP (Internet Service Provider).
One of the things on my to-do list is to provide
an easily implemented procmail(?)-based
whitelist/blacklist-by-IP-address-range
mail-filtering-system in an FE 'mail_tools' toolchest.
I plan to block mail from China, Korea, Argentina,
Brazil, Chile, Turkey, Romania, and most other
non-U.S. countries.
That should take care of about 50% of
the spam getting through my ISP's filters.
I will add blocking ISP ranges for the U.S. also,
as I discover sources of spam from U.S. IP addresses.
That should take care of another 49% of the spam.)
(Time-out for a rant:
It is really stupid that they did not parcel out IP addresses
to countries in contiguous ranges, proportional to their
populations.
For example, Korea's address ranges are scattered all over
the IP address map.
It makes for really huge IP-range black-lists.
It makes white-lists more appealing, but then one has to keep
checking the Probable-Spam mail folder for addresses to
add to the white-list.)
If you send requests for enhancements or additions, please
consider sending a modest donation (such as $5, $10, $20, ...)
--- to help me pay my ISP (Internet Service Provider),
to keep this web site up.
An example of a kind of request that I can probably satisfy
is a request for a (set of) Tk-GUI interface(s) to a Linux command
or application --- replacing its many command-line options by
GUI prompts, using check-buttons, radio-buttons, entry-fields,
and the like.
I intend to show some examples of this type of GUI development
via a 'Featured tkGUIs' web page on this site.
Some kinds of FE subsystem enhancements that I could implement are
-
enhancements to (or re-write of) the 'make_chest.tk'
tkGUI script of the FE HandyTools (and FE AppMenus) subsystem
-
enhancements to the 'shofil.tk' tkGUI script of
the FE 'xpg' subsystem --- also used in the 'feHandyTools',
'feAppMenus' and 'feNautilusScripts' subsystems
-
more scripts added to the FE Nautilus Scripts subsystem
-
more shell and Tk GUI scripts added to the FE Handy Tools subsystem.
These kinds of enhancements involve editing FE text files ---
mostly creating or enhancing shell and Tcl-Tk scripts --- which I
have trained myself to do.
I generally try to stay away from compiling languages
such as C and C++.
I generally try to 'glue' compiled programs together with
shell and Tcl-Tk scripts.
I generally try to steer away from 'monolithic' compiled program
projects --- in my retirement.
So please direct suggestions for enhancements to compiled programs
to the appropriate developers.
But let me know of options that should be added to FE subsystem
Tk GUI 'front-end' scripts and Bourne/bash shell 'wrapper' scripts,
when such compiled programs are called on within FE subsystems.
If you have used the FE subsystems for a while and find that
they are helpful to you, please consider making a donation
--- to help pay the bills for keeping this web site hosted.
See the
'FE Contact' web page for info on how to contact me
to make a donation.
[One type of programming request that could draw time away
from the 'fun' projects is bug fixing.
Hopefully there are not many bugs, since I use the
FE subsystems myself.]
|
There are four Tk 'pack' command parameters
that control how a widget is placed in a window
--- 'side', 'anchor', 'fill', and 'expand'.
I decided to make a four-widget (four-frame)
GUI that allowed me to see how various
combinations of those four parameters (for each
widget) affected the placement of the widgets.
On the left you see my first version.
When the window first comes up, the
16 pack parameters are set randomly.
And each time you click the 'Refresh'
button, a new set of the 16 pack parameters
is generated (randomly) and
the window is redrawn.
That was educational, but I saw right away
that I needed the answer to questions
like 'What happens if I change the 'side'
parameter of the 3rd widget from 'left'
to 'top'? So I created the Tk script
that generates the GUI on the right.
Instead of just one 'Refresh' button, there
are also 16 Tk option-menu buttons that
allow you to change one to 16 of the pack
parameters before clicking on
the 'Refresh' button.
Poke the right-hand image to see a new image
in its place. That image shows the effect of
changing the 'side' parameter of Frame-1 from
'bottom' to 'top'. That one is easy to predict.
But I am still surprised sometimes at the
result of a given change. I cannot predict, yet,
with 100% accuracy what will happen, in all cases.
(4x9x4x2=288 to the 4th power? 6,879,707,136?
about 6.8 billion possible combinations?
Many of those combinations result in the
same GUI configuration. Anyone care to calculate
how many distinct combinations there are?).
This could make a betting game. For example,
two Tcler's could bet with each other on who
will have the right answer to what will happen for
a given change in one (or more) of the 16 'pack'
parameters. Put 'feHandyTools' on a netbook and
take it to a bar for a few beers and some
game-playing with friends.
Links to pertinent 'feHandyTools' chest images are here :
'PROGRAMMING tools' toolchest
>
Tcl-Tk Help Chest
>
Tk FE Demos Chest
Page 10
Helping Yourself (be my guest)
Because most of the FE HandyTools system is composed of Linux/Unix shell
scripts and Tcl-Tk scripts (and 'chestdef' files), you can enhance
that system yourself.
All of these scripts and chestdef's are simply text files --- not 'binaries'.
And there is no compiling involved --- no 'configure', 'make', etc.
The shell scripts simply invoke the 'sh' shell, which is a command interpreter.
(On Ubuntu 9.10, 'sh' is a link to the 'dash' interpreter, which is like a subset
of the 'bash' interpreter.)
The Tcl-Tk scripts simply invoke the 'wish' (window shell) command
interpreter.
For example, if you do not like the way a GUI works, you can change
the Tcl-Tk script that provides the GUI.
And if you do not like the format of a report, you can change the
Linux/Unix shell script that provides the report.
Happy changing and enhancing!
|
Above is a screenshot of an animated
Rube Goldberg device that is rendered
on a Tk 'canvas' widget with various
objects drawn on the canvas --- some
are static and some move.
The user clicks on the ball at the
top right to set the ball in motion.
Then sit back and watch the devices function.
This Tk script is one of many donated
by Keith Vetter who has a
web page of links to his donated code
(Tk scripts source code on Wiki pages).
I have added an appropriate call to the
'wish' interpreter to the top of many
of his scripts, and, almost without fail,
they have run on Linux.
Some of his scripts are available to be
run with a few mouse clicks via the
'PROGRAMMING tools' toolchest, after
installing 'feHandyTools'.
(I am trying to make his good work more known
to the public --- well Linux users, anyway.)
Some of Vetter's scripts, and those of other
Tcler's, need to have some changes made
to fit the screen appropriately, especially
if one wants to demo them on a netbook with a
screen height of 600 pixels or thereabout.
Some of the donated scripts would need
much more drastic changes than others.
(Vetter's Rube Goldberg GUI, which appears
to be not readily scalable, exceeds even
the 1024x780 screen size of my desktop computer.)
Links to pertinent 'feHandyTools' chest images are here :
'PROGRAMMING tools' toolchest >
Tcl-Tk Help Chest >
Tk 'Wiki' Demos Chest
Page A.1
APPENDIX A.
Variations on F.E.
(variations on Freedom E.
--- what the 'E' stands for)
'Have at it' ... 'it' being your copy of an FE subsystem.
Enhancing (or simply tailoring) an FE subsystem is one way
to get a taste of that.
It's REAL freedom! ... Ain't freedom great? --- like the freedom
to say "ain't" instead of "isn't".
We all need some freedom in our lives.
In fact, instead of "Freedom Environment", the FE could stand for
- Freedom Euphoria
- Freedom Ecstasy
- Freedom Envy
(a short form of Freedom Environment)
- Freedom Enhancement
- Freedom Elysium
- Freedom Emancipation
(a double positive?)
- Freedom Embodiment
- Freedom Enjoyment
- Freedom Enthusiasm
Or ...
- Freedom Earth-mother
- Freedom Earth-shaker
- Freedom Easement
- Freedom Ease (= Freedom-ese)
- Freedom Eclecticism
- Freedom Effector
- Freedom Electricity
- Freedom Enchantment
- Freedom Encounter
- Freedom Encouragement
- Freedom Endeavor
- Freedom Endowment
- Freedom End-zone
- Freedom Enema
- Freedom Energy
- Freedom Energizer (bunny?)
- Freedom Enfranchising
- Freedom Engagement
- Freedom Eruption
- Freedom Essence
- Freedom Evermore
- Freedom Everybody
- Freedom Everywhere
- Freedom Evolution
- Freedom Exaltation
- Freedom Excitation
- Freedom Exclamation
- Freedom Exemplar
- Freedom Exemplifying
- Freedom Exhaustless
- Freedom Exhibition
- Freedom Exhilaration
- Freedom Expansion
- Freedom Expedition
- Freedom Experiment
- Freedom Explosion
- Freedom Exploration
- Freedom Exponentiation
- Freedom Exposition
- Freedom Expounded
- Freedom Expression
- Freedom Expressway
- Freedom Extension
- Freedom Extrapolation
- Freedom Extroversion
- Freedom Extrusion
- Freedom Eyeopener
- Freedom Eyepopper
Or even
- Freedom E (= Freedom-y) (kind of like truth-y)
- Freedom Eagle
- Freedom Egg
- Freedom Embryo
- Freedom Enchilada
- Freedom Eyes (= Freedom-ize)
The list is left as an exercise to finish.
The keyword is Freedom. I'm sticking with that.
Otherwise, with variations on both F and E, the list
would go through the roof.
END OF a GUIDE to the HandyTools subsystem of the FE family of systems
|
FE Software . . . . Some Kind of Wonderful.
Bottom of this
FE 'HandyTools' subsystem DESCRIPTION page.
FE = Freedom Environment
To return to a previously visited web page, click on the
Back button of your web browser a sufficient number of times.
OR, use a History-list option of your web browser.
OR ...
Page history:
Page was created 2011 Sep 15.
Page was changed 2011 Sep 25.
Page was changed 2018 Aug 16.
(Added css and javascript to try to handle text-size
for smartphones, esp. in portrait orientation.)
Page was changed 2019 Jul 22.
(Specified image widths in percents to size the
images according to width of the browser window.)
|
My thanks to Jeff Godfrey who wrote
this Asteroids program in 2005.
It looks almost identical to
the original arcade game.
John Ousterhout, the author of Tcl-Tk,
has said in the past that he expected
Tcl-Tk to be used as 'glue' to weld together
compiled programs that do a lot of processing.
He has said that he has been surprised
at the many kinds of Tcl-Tk scripts that
have been written that he would have expected
to be implemented only with compiled languages
like C and C++.
No doubt Ousterhout would classify this
Asteroids program as one of those surprises.
Watching the performance of this program
would certainly surprise many knowledgable
computer professionals who are of the opinion
that an INTERPRETED scripting language would be
INcapable of non-hesitant-response-to-user-actions
during
CONSTANT-MOTION-of-MULTIPLE-OBJECTS and
EXPLODING-OBJECTS graphics like this.
No hiccups (pauses).
No jumpiness (gaps) in motion.
Continuous displacements and piece-wise
continuous velocities (mathematically speaking).
List of Tk Wiki GAMES --- to run, show code, or both