Many of the double-click/drag—drop operations are pre-configured in xfmrc based on the following format:
Xfm recognizes file names three ways: by the file name itself (e.g., core or Makefile), by its extension (*.c means c source files), or by its prefix (README*). The most common pattern used for the file_name is *.suffix, which, to have it recognize C files, is *.c, with the * permitting any file name ending in .c to be recognized. The push-action (activated by double clicking the icon) is what you most likely will change in the xfmrc file. For example, I changed the push-action on *.gif files to xv rather than xpaint. I also added:
*.au:xfm_au.xpm:cat $* >/dev/audio: *.dat:xfm_data.xpm::
The first plays au files (audio files) when they are double clicked (read the Sound HOWTO, if you haven't configured sound), while the second merely associates the xfm_data icon to data files that I have created for executable programs.
Drop actions are those that occur when a file is dragged onto the icon. I don't have any drop actions defined for my File Manager window.
The programs and icons that constitute the Applications manager are dictated by the xfm-apps file. The entries in that file have a somewhat different form:
name is the title that appears in the Applications window, icon is the name of the icon to use, push-action is what to do when the icon is double-clicked, and drop is what happens when a file is dropped on the icon. A simple example is
PSPrinter:::printer.xpm::exec lpr $*
Double clicking this printer icon does nothing, while dropping a PostScript file on it from the file manager window results in the file being printed. The remaining entries in this file look like:
Xterm:::xterm.xpm:exec color_xterm -sl 600 -sb -fn * 7x14 -j -ls -e tcsh:$* Xclipboard:::clipboard.xbm:exec xclipboard: Scilab:::math4.xpm:exec scilab: Graphics::.xfm/xfm-graphics:xfm_appmgr.xpm:LOAD: System::.xfm/xfm-system:xfm_apps.xpm:LOAD: Calendar:::calendar.xpm:exec xcalendar: CD:/cdrom::cdrom.xpm:OPEN: (*This line should not be broken)
Toolbox, Graphics and System are icons that change the Applications window to another containing a different set of application icons. For example, I made a simple graphics tool box with the following entry in xfm-apps:
The LOAD command loads the .xfm/xfm-graphics file below:
Apps::.xfm/xfm-apps:xfm_apps.xpm:LOAD: XFig:::draw.xpm:exec xfig: exec xfig -P -e ps -startf 16 $* XPaint:::xpaint.xpm:exec xpaint:exec xpaint $* XV:::xv.xpm:exec xv:exec xv $* mpeg:::movie.xpm::exec mpeg_play -loop $*
The Apps line gets me back to the previous window: xfm-apps.
In the other applications file, System, I have in .xfm/system
Apps::.xfm/xfm-apps:xfm_apps.xpm:LOAD: Xsysinfo::::xsysinfo: TOP::::exec xterm -e top: who:::view.xpm:exec who|xless: lpq::::exec lpq |xless:
By piping the last two commands to xless, an xwindow is created that displays the results of the Unix commands.
Dialog boxes allow the input of command line parameters, such as:
LaTeX::::(latex %Latex_file\:%;beep):(latex $*;beep) grep:::grep.xpm::grep '%Regular expression\:%' $*
The percent signs delimit the comment for the dialog box (with the \ escaping the :). The beep is to tell me when the operation is done; it is defined as echo -n '^G'.
If you prefer a different default editor than emacs, then you need to add an entry to the .Xdefaults file in your root directory. The xfm man page lists resources that you can change. I changed two by adding Xfm*defaultEditor: textedit and Xfm*updateInterval: 3000. (Be sure to run xrdb .Xdefaults to get the changes implemented if you want them before you next start X.) The update interval change was to refresh the directories more often than the default 10000 milliseconds. You can also change the default directory paths to the pixmap files; this may be important if your pixmaps are not in the default location (add Xfm*pixmapPath: your_path Alternatively, to make changes for all users, root can change options in the Xfm file in /usr/X386/lib/X11/app-defaults.
Practical Task Scheduling Deployment
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.View Now!
|The Firebird Project's Firebird Relational Database||Jul 29, 2016|
|Stunnel Security for Oracle||Jul 28, 2016|
|SUSE LLC's SUSE Manager||Jul 21, 2016|
|My +1 Sword of Productivity||Jul 20, 2016|
|Non-Linux FOSS: Caffeine!||Jul 19, 2016|
|Murat Yener and Onur Dundar's Expert Android Studio (Wrox)||Jul 18, 2016|
- Stunnel Security for Oracle
- The Firebird Project's Firebird Relational Database
- SUSE LLC's SUSE Manager
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Managing Linux Using Puppet
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- Google's SwiftShader Released
- SuperTuxKart 0.9.2 Released
- Doing for User Space What We Did for Kernel Space
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide