The 'feFileMan' subsystemDOWNLOAD page
NOT AVAILABLE YET.
|
A prototype of the GUI interface of the 'feFileMan' utility. Poke this image to see the image in a separate window or tab. |
! Note !
This 'feFileMan' utility is PROPOSED, NOT IMPLEMENTED YET.
It MAY be implemented in a preliminary form, someday, in the
'FILEmanagers' toolchest of the FE 'tkGooies' subsystem.
If it ever becomes a 'bell-and-whistles' file manager
(with Open-with, Rename, Delete, Cut, Copy, Properties, etc.
popup options --- including a 'Nautilus Scripts' capability),
then it may be implemented in its own 'feFileMan'
install file. (That may be well beyond 2022.)
< Go to the 'FE FileMan' Download Link
and Instructions, below. >
( Skip the Introduction )
|
INTRODUCTION : Most Linux users are well aware of the turmoil in the Linux 'distro' universe in the past few years (2010-2012) as major desktop systems such as Gnome and KDE have gone to major new versions (Gnome 3.x and KDE 4.x) that seem to be trying to imitate the Apple iPad and iPhone approach of 'finger-tip based' (rather than 'mouse-based') interaction --- an approach based on a desktop flooded and overflowing with scrollable icons. In the meantime, the 'high-end' Linux file managers (such as Gnome-Nautilus and KDE-Dolphin or Marlin or whatever) are getting much less attention in areas of concern for mouse-users --- especially the users who need to use list-view rather than icon-view, in a file manager that can deal with over a thousand files --- not just 10's or 100's of files. The file managers mentioned above are starting to experience some 'regressions' as a result of the neglect. As I have pointed out in an 'Operating Systems' section of the Contact Page of this freedomenv.com site: "Sheez! There are more important things than imitating Apple 'surface effects', ubuntu-and-gnome-developer-people. You don't seem to appreciate what you have in the Nautilus file manager. In all the articles describing Gnome 3, I have seen nary a word on the file manager. That just stinks. It's just really sad what these developers --- and the Linux pundits --- value most highly." The file manager is the app that I use the most, in my login sessions. I probably open Nautilus file manager windows more often than I open web browser windows and email windows. Some Argentinians have been concerned about the nice things of Gnome 2.x that have been jettisoned (or unappreciated and ignored) in Gnome 3.x. The Argentinians have started a 'fork' of Gnome 2.x called MATE (MAH-tay) --- including a fork of the Nautilus file manager, which they call 'Caja' (Spanish for box or gift). Unfortunately, they forked from a Gnome 2.x version that already had some 'regressions'. I have submitted bug-reports and feature-requests for Nautilus and MATE. Links to these can be seen near the bottom of a 'Linux Mint Debian Edition (LMDE) Install Notes' page. But I have little faith that Gnome 3.x and MATE developers will heed these suggestions/requests. And they will probably never make some of the underlying 'thumbnail-making-of-images', of the Gnome/MATE GUI's, an option for the user. Hence, their systems will always suffer from 'processing bloat'. And hence many Linux users will probably continue to use the 'lighter-weight' Xfce and LXDE desktops and their Thunar and PCman file managers. Unfortunately, those file managers do not have the 'Nautilus-scripts' capability. So I may eventually release my own file manager project. An early version of the proposed GUI can be seen in the following screenshot image. |
Image of a PROTOTYPE implementation of
the 'feFileMan' GUI a 'two-pane' file manager,
like
'Midnight Commander' and
'FileZilla' and
'WS_FTP'.
Poke this image to see the image
in a separate window or tab.
|
The file lists of the 2 large directories in this image of the GUI --- directories /usr/lib and /usr/share/doc (about 1500 files each) --- came up in a fraction of a second. They take about 5 to 15 seconds, at least, with Nautilus, depending on the type of computer that I am on (and maybe depending on the Linux distro/kernel release). It is pretty sad, but also quite fortunate, that I can make a file manager with a scripting language (Tcl-Tk) that is faster than the compiled file managers Nautilus and Dolphin. A Search for Other Tcl-Tk Linux File Managers : I have done a search on terms like 'file manager' on wiki.tcl.tk and found 'TkMC' and 'FileManager'. The 'TkMC' GUI is a two-directory-paradigm file manager like an old 'Midnight Commander' file manager GUI --- thus the 'MC' in 'TkMC'. I like the speed of these file managers in bringing up lists of filenames in large directories, but they lack the key feature that I need --- a Nautilius-scripts-type capability --- the capability to apply a script (from a hierarchical directory structure of utility scripts) to one or more selected files. And they certainly lack the polish and depth-of-support of the Nautilus and Dolphin file managers. I have also looked at other Tk file managers referred to in the wiki.tcl.tk pages (FileRunner, TOXfile, filerusher, sfm, tkdesk, tkfichier), but most of them are no longer being maintained and several of them require Tk extensions or compilation of libraries. All of these Tk file managers are unsuitable for me because they do not have the capability to blend in with my Tk software systems (feHandyTools, feAppMenus, xpg) --- and, most importantly, they do not include the 'Nautilus-scripts' capability. Rather than taking their code and re-writing them to allow for setting 'compatible' color-schemes and fonts and widget-geometry --- and adding the Nautilus-scripts capability, I have decided to start from my own code base. Perhaps I will look at the Tk code of some of these other file managers, say when I am looking for techniques to use in implementing copy/cut-and-paste or drag-and-drop (someday?) --- or when I am looking for a way to handle 'broken' symlinks --- or how to handle symlinks (symbolic links, a.k.a. 'soft links') when they point to directories and when they point to 'regular' files. Basis of 'feFileMan' : The 'feFileMan' file manager is a 'Midnight Commander' kind of interface --- two directory listings shown side-by-side. Actually, I based the interface on the old 'WS_FTP' interface of an MS Windows FTP client that used to be available for free, in a 'lite' version. Another app with an interface in that category (a 'dual directory' interface) is the 'Filezilla' FTP client that is available on Linux and that I use almost daily to maintain my web pages. I actually had an old 'host2host' Tk script, with a similar dual-directory interface, that I devised around 1999, to allow for viewing directories on different SGI/IRIX (Unix) hosts, via the 'rsh' (remote shell) command. I have taken that script and removed all the 'rsh' stuff (and the pair of host names capability) to make the starter code base for the 'feFileMan' Tk script.
NOTE1: Through the magic of the Sun-Microsystems-developed NFS (Network File System) software, hierarchical directory structures on remote disk drives can be accessed AS IF they are on disk drives that are connected locally to your workstation.
NOTE2: It did this by running the command 'rsh ls -Ap' on the remote host to fill the listbox in the 'host2host' GUI running on your local machine. The only requirement was that you had to have the necessary permissions (.rhosts file setup) to run 'rsh' on the remote host. The 'feFileMan' Tk GUI script could run the 'ls -Ap' command on your local host to show the files on locally connected disk drives, or files that are NFS-mounted to your local host. Features to be added : The GUI image above is incomplete. I will be adding a 'Scripts...' button to the 2 'button stacks' on the 'feFileMan' GUI. I have the Tcl-Tk code for 'select-file(s)-and-apply-a-script' capability already --- in the 'feHandyTools' system, in a file-selector GUI, similar in function to 'tk_getOpenFile', but with the added 'apply-a-script' capability. I just need to incorporate calls to that GUI into this 'feFileMan' GUI. I will probably replace the 'cp' label in the middle of the GUI with a couple of 'cp' and 'mv' radiobuttons. I also plan to add a 'ToggleScrollbars' button alongside the 'ToggleLayout' button. And I may add 'ChgColor', 'ChgFont', and 'Embellish' buttons to the top of the GUI. The 'ToggleLayout' button toggles among 4 different layouts of the 2 button-stacks and the 2 filename-listboxes. The 'ToggleScrollbars' button would toggle the vertical scroll-bars of the 2 listboxes from left side to right side, and back. In any case, when I get those enhancements into 'feFileMan', I will need to test it out with almost daily use over several months before releasing it as a new FE subsystem --- a 'production capable' system. And even then, the usual warnings and disclaimers will need to be added. The bottom line is that I hope to have a quite capable and reliable release of 'feFileMan' available . . . someday. But I have so many utilities to add to the 'tkGooies' system, I do not know when (or if) I will ever get back to working on this 'feFileMan' system. (Perhaps 2025?) Detailed Documentation for 'feFileMan' : A link to a quite detailed description of the 'feFileMan' file manager utility will be put here, when (and if) it is released. The 'feFileMan' description will add to the FE library of subsystem descriptions --- the previously released descriptions being
The 'feFileMan' download file and install instructions are to be posted below (if I ever implement this monster). |
|
'FE FileMan' DOWNLOAD LINK The download file for 'feFileMan' (a self-extracting install file) is to be presented here --- along with download and install intructions. One pre-condition is that I live long enough to get around to coding and testing and releasing this 'bad boy' --- after all the higher-priority projects on my FE to-do list. |
FE FileMan . . . A FAST, NON-BLOATED, HIGH-CAPACITY
file manager for Linux.
|
Bottom of this FE = Freedom Environment
To return to a previously visited web page, click on the
Back button of your web browser a sufficient number of times.
OR, use the History-list option of your web browser.
< Go to Top of Page, above. >
|
Perhaps I should call 'feFileMan'
'feSkinnyMan' or 'feRunningMan' ---
'cause it's FAST and NON-BLOATED.