EnlightenDSM menus and icons can be altered to suit your needs. The options are:
The order of menu icons
The order of menu items
The actions of menu items
The number icons and menu items
 | Note: You may not remove the Configure menu from the main menu toolbar. Doing so would cause improper placement of the remaining menu icons in the main menu. |
The EnlightenDSM GUI is built through a small text database file containing objects and attribute lists. Alternative interfaces can be created by editing this file. A menu item could be added, for example, that would run a customized script. Another possibility would be to replace the Archive configuration menu item with your own backup tool.
| Note: During the EnlightenDSM start-up, the interface file will be scanned for syntax and for attribute matching. If an error is detected, EnlightenDSM terminates the start-up process and reports the line number and the reason for rejection on stderr. |
The EnlightenDSM GUI is defined in a configuration file. This file contains information describing the layout of the windows. You can edit the configuration file to make desired additions or modifications to the GUI. Then you can override the default configuration file $ENLIGHTEN/config/winn.out by setting the shell variable WINOUT_NET to the name of YOUR configuration file.
If EnlightenDSM finds the shell variable WINOUT_NET set and it contains the name of a readable file, this file will be used instead of the default configuration file. If the shell variable is set, but points to a file that does not exist or is unreadable, a warning will be issued. EnlightenDSM will then use the default configuration file.
EnlightenDSM is shipped with a backup copy of the configuration file called $ENLIGHTEN/config/winn.org. You can copy this over its corresponding .out file if you need to return the interface to its original state.
 | Warning: The format of the interface file is crucial to the successful start-up of EnlightenDSM and the consistency of the product. Be careful when making any modifications to this file. You should also test your modified interface before replacing the current version. |
While there is no order of declaration of menus within the interface file, the current group of Menu definitions occurs after the set of MODEL initializations. If you wish to alter the existing menu definitions, or add your own, you should do so at this location (between the MODELs and the Window definitions). You can quickly locate the first menu definition by searching for the keyword Define.
The only required order in the file is that menus must be defined prior to any reference to their use. Thus, a Menu must be defined before it is attached to an icon in a window, and a submenu must be defined before it is attached to a menu item.
| Note: A submenu is not a unique object; it is just the term for a Menu that's attached to a menu item as a pull-right style menu. |
The interface file uses a simple, yet concrete, syntax. Any line with a # as its first character is a comment. Any line with no characters (zero-length) is a break line. Otherwise, every line has three fields separated by tabs.
To create a menu, use the syntax:
DEFINE<tab>12<tab><menu-name> |
where <menu-name> is a single-word name that is unique among the defined menus and used internally for reference purposes only. For example, to add a “UserMenu1” menu, add the definition:
DEFINE 12 USERMENU1 |
Subsequent lines following the DEFINE statement set the menu attributes and menu items (and their attributes) for the current DEFINE menu. This occurs until the next DEFINE statement is reached.
The syntax for an attribute is:
<tab><attribute-type><tab><value> |
The valid attributes for menus are (order is not important):
| categ <number> |
| |
| context <string> |
| |
| pinned <value> |
| |
| label <string> |
|
Each category is in charge of windows and actions associated with it. The default interface shows the full range of windows accessible from a given category; it is not possible to change a window's accessibility from one menu category to another. Thus, it is not possible to call the User Query window from the Printer category. This restriction occurs since the window generation is determined by the Menu Category and the Return Code (as generated by menu items).
The valid (reserved) menu categories for EnlightenDSM are:
2 = Configuration |
3 = System |
4 = Disk |
5 = User |
7 = Printer |
8 = Archive |
9 = Events |
10 = Security |
11 = User-Defined Section 1 |
12 = User-Defined Section 2 |
15 = Network |
The valid (reserved) submenu categories for EnlightenDSM are:
51 = Spool |
53 = Activities |
55 = Statistics |
57 = Logins |
59 = cron |
60 = NFS |
61 = DNS |
62 = Aliases |
63 = Clocks |
You may give a string, enclosed in quotation marks, that EnlightenDSM uses to display at the bottom of the Main Menu Window as the mouse is dragged into the menu's associated icon. This is a form of context-sensitive help. If the text is longer than the window, it is “lopped off” at the window edge.
This attribute determines whether a menu is pinnable; it will remain visible by moving the mouse over the window push-pin, so its menu items are always accessible without going back to the menu icon. The value is either 0 or 1 (False or True). By default, a menu is not pinned, so you only need to specify this attribute if the menu will be pinnable.
For our UserMenu1 menu example, we might set the following attributes:
DEFINE 12 USERMENU1
categ 11
pinned 0
label “User Scripts 1”
context “"Help subsystem”
|
This example defines a Menu we can refer to later in the interface file as USERMENU1, within the User-Defined section, not pinned (so it will disappear after a selection is made), with the title “User Scripts 1”, and some help text showing that this menu comprises menu items that call up internally created executables.
Menus also contain Menu Items, which comprise a list of entries from which the user may select. A menu item may be a pull-right item, meaning that a small arrow appears to the right of the item label. If the user “follows” the arrow, a submenu appears.
A menu item is simply an attribute assigned to a menu. It is created using the attribute type `add'. Thereafter, any further attributes listed apply not to the menu itself, but to the menu item most recently added. The syntax for adding a menu item is:
<tab>add<tab><entry text>
|
where <entry text> is the actual text (enclosed in quotation marks) the user will see in the list of menu items. Items will appear in the menu in the order specified within the file, with the first item appearing at the top of the menu.
Attributes for menu items use the same syntax as those for Menus (see “Menu Attributes”). The valid attributes for a menu item are (order is not important):
| exec <string> |
| |
| state <value> |
| |
| submenu <value> |
| |
| return <value> |
|
A “system” call will be made for <string>, which is enclosed in quotation marks. Any program that could be called from a command-line interface (complete with arguments) is legal here. The program name must be ≤ 220 characters. If you do not wish to have the program block further execution of EnlightenDSM, run the program in the background by using the ampersand (&), just as you would from the command line.
The default state of an added menu item is active; the menu item is displayed clearly and is selectable by the user. Or you can have the menu item displayed but grayed-out; it is viewable but not selectable by the user. To make a menu item inactive, use the value eight (8). This option also will cancel the display of any subsequent submenus for this item.
You attach a previously defined submenu to the current menu item by giving its internal name (from the DEFINE statement) embedded in quotation marks. This attribute overrides any exec associated with the menu item; it can only display a pull-right menu.
The Return value links a menu item to a particular set of EnlightenDSM windows. The menu Category, along with the Return value, determines which window is then initiated. In a sense, these values are “reserved” codes. The default interface file has all the combinations of the Category values and Return codes. For example:
#2 - Configuration Section |
1 = Session Preferences |
2 = Alter Menu |
3 = Pool Configuration |
4 = User Authorization |
5 = New User Templates |
6 = EMD Data Expiration |
In addition to the reserved Return codes for Menus, there are also reserved Return codes for submenu categories. For example:
#53 - Activity Submenu |
1 = Who is Logged In |
2 = Process Status |
3 = CPU Summary |
Although a Submenu, by default, belongs in an associated Menu category, since it carries its own Category and Return codes, it can be placed anywhere. For example, you could place both the User Security and System Integrity submenus on their own User-Defined menu and call that menu “System Security.”
To change the names of any existing menu items, change either the `label' or `add' attribute arguments. The order of the menu items is not fixed, but be sure to keep all of a menu item's attributes with its corresponding add attribute.
To expand on the previous example of a user-defined UserMenu1 menu, you could add the following items:
#
# The following user utility menu is a predefined example.
# It can be used to add you own scripts into the ENL main menu.
#
# The definition exists here, but is currently deactivated in the
# DEFINE 7 MAINMENU definition further down. To activate it, the
# comment markers (#) must be removed from the following lines
#
# # add MENUBUTTON1
# # name “USERSCRIPT”
# # icon 12
# # menu USERMENU2
#
DEFINE 12 USERMENU2
categ 12
context “This is a mini-help line as the mouse moves over the icon”
label “User Scripts 2”
pinned 1
add “Script 1”
return 1
exec “xterm -e $ENLIGHTEN/bin/script1”
add “Script 2”
return 2
exec “xterm -e $ENLIGHTEN/bin/script2”
#
# The following user utility menu is a predefined example.
# It can be used to add you own scripts into the ENL main menu.
#
# The definition exists here, but is currently deactivated in the
# DEFINE 7 MAINMENU definition further down. To activate it, the
# comment markers (#) must be removed from the following lines
#
DEFINE 12 USERMENU1
categ 11
context “Help subsystem, by category and action”
label “User Scripts 1”
pinned 1
add “Script 1”
return 1
exec “xterm -e $ENLIGHTEN/bin/script1”
add “Script 2”
return 2
exec “xterm -e $ENLIGHTEN/bin/script2”
........
.......
.....
..
.
# add MENUBUTTON1
# name “USER MENU 1”
# icon 11
# menu USERMENU1
# add MENUBUTTON1
# name “USER MENU 2”
# icon 12
# menu USERMENU2
|
All menus are attached to icons in the Main Window. This definition is shown in the interface file as the first DEFINE 7 statement. Use the attribute add MENUBUTTON1 to attach a menu to its window (left to right, in order of declaration). An internal name attribute is not necessary, but is usually included.
Use the menu menu-name attribute to attach the previously defined menu to the menu button (the menu-name is shown in the line DEFINE 11 name). Use the icon icon-type attribute to assign the icon to be displayed as the menu button. The icons are pre-defined:
2 = The configure icon |
3 = A picture of a terminal |
4 = A picture of a disk |
5 = A picture of users |
6 = A picture of a terminal |
7 = A picture of a laser printer |
8 = A picture of a 1/4-inch tape |
9 = The Events icon |
10 = A picture of a lock |
11 = A picture of tools (User-Defined Menu) |
12 = A picture of tools (User-Defined Menu) |
You can also have multiple User-Defined menu buttons, as long as the return codes for the menu items are unique across all of them. For example, you can define two utility menus, “UTILITY1” and “UTILITY2,” with three menu items each, with UTILITY1 having menu items with return codes 1–3 and UTILITY2 having menu items with return codes 4–6.