|i.File is a file manager for Linux written for the the Windows refugees that are arriving in Linux only to find that the state of the user interface is rather poor. I personally somewhat fall into this catagory, although more as a power user than the average Joe. Both the leading file managers for KDE and Gnome are well... not to put too fine a point on it: crap. There are just not ready for everyday use by normal people, because of the untold number of bugs in the usability and function that are STILL there 3 years after they first infested Linux desktops. Not that this project will start off any better, but my hope is that it'll end far more successfully than the aforementioned software. Currently i.File is targetted at other developers in an attempt to get some help with bringing it up to speed. Enough of the basic code layout and implementation is done so that the user can see how things should work. And now it's just time to fill in the blanks and bust those bugs.|
- Requires: GCC 3.2/Visual C++ 6 or better and Lgi.
- Download Lgi and it's dependencies. Get it to build.
- Download and unzip the i.File source into the same parent directory (i.e. at the same level).
- cd ifile-src
- Which should give you an executable that runs.
- Be fast. i.File doesn't load icons for every file by it's mime type. Because that takes too long. All the algorithms are designed to make it fast. The use of hashtables is pervasive. At no point should "eye candy" ever take precedence over speed. Startup/shutdown time should be sub-second. Drag and drop should have latencies around 100ms at most.
- All views of the same inode (file/dir/etc) point back to the same object, thus when the object changes, all views of that automatically update.
- Network accesses and all other tasks that can take time should be threaded. There is no excuse for locking up the GUI thread while the application goes off to get some data.
- Be minimal. i.File is not a thumb nail viewer, or any other type of viewer. Applications do the viewing, not the file manager. Viewing tasks bloat up the file manager.
- Every file is typed with a mime type. This is marginally better than using a file's extension to associate it with an application.
- The Win2k implementation of Windows Explorer is the basis for some of the user interface because it works, people are used to it, and it's "the standard". And no the experiments with file manager UI in Linux didn't work. They suck badly, thats why there is i.File in the first place.
- Toolbar icons: History, MoveTo/CopyTo, Undo need implementing.
- Multiple copies/moves at the same time will probably break it. Or at least look bad.
- Mime-types are not cached for a while. Thus causing them to be recalculated when selected the previous directory.
- Right click menu on the GFileList to pick the visible fields. These choices should be saved back into the GFileNode so that the next time the user selects the folder it'll look the same. Maybe eventually this information can propagate back to some attributes on the directory node so that the setting is remember across sessions.
- Multiple instances of the application should merge to multiple windows in the same application. Possibly running in separate threads so that a crash only takes out the one window. Global file data should be made thread safe.
- Occasionally pasted files don't show up in the destination directory until you refresh.
- File's permissions and user information is not copied across with it.
- No replace dialog when moving or copying a file into a directory where it already exists.
- D'n'd for files and folders.
- When deleting something the next item is not selected in the tree and list.
- Added a plugin interface to the GFileNode object. Currently plugins can get events like OnBrowse and OnRefresh and add menu items into the right click menu.
- Intergrated the version control add-ons into the parent folder object (as plugins). This improves caching of meta-data and makes the code a lot cleaner.
- Fixed refreshing a folder view to re-read version control meta-data correctly.
- Used the new plugin interface to allow the SVN plugin to add an "Svn Update" and "Svn Commit" command to the right click menu of SVN checkout folders.
Download: Zip [Windows, 396K, 14/3/2006]
- Fixed the CVS file status code to not hang the search when looking for modified files.
- Fixed having a directory selected locking it so that it can't be deleted.
- Fixed new directories not showing up in the UI when pasting them.
- [Win32] Improved the open with menu to a functional state.
- Fixed a very embarrasing memory leak.
- [Win32] Fixed the quality of applications populating the "Open With" list. Windows is trying very hard to make it impossible to make that menu work, I keep finding little differences in the registry format with untried file types.
- Unified the network neighbourhood code and intergrated the win32 and linux backends. Adds network browsing support to the windows port.
- [Win32] Fixed deleting system/hidden/read-only files.
- [Win32] Fixed crash on very long error messages.
- [Win32] Limited delete error messages to first 16 errors.
- [Win32] Fixed backspace keyboard binding.
- [Win32] Added "Explore..." menu option in the right click menu.
- Fixed all the folders disappearing when returning to the folder view after searching.
- [Win32] Fixed running batch files.
- [Win32] Fixed some apps not having the right things in the open with menu.
- Fixed the full folder name not appearing in search results.
- Made the search smarter, if you don't use wildcards it does substring.
Download: Win32-Debug [Windows, 1560K, 18/8/2004]
Download: Binary [Windows, 342K, 3/8/2004]
Download: Binary [, 782K, 7/5/2004]
Download: Src [Common, 121K, 7/5/2004]
Other File Managers
Here I list some of the other options, so that we can learn from their mistakes... oh... um see what features we need to cover.
|nautilus||All right if you can stomach GTK. Also uses too much eye candy and doesn't have a friendly tree view mode. Havn't used it enough to tell whether it has more serious quirks.|
|konqueror||Wooo it browses the web as well! Wow talk about putting too much into the
file manager. Things I hate:
|emelfm||Based on GTK 1.x, do I need to continue?|
|filerunner||Looks like it was written in the 80's|
|fm||Another GTK+ file manager. Seems like a decent attempt despite being GTK based.|
|krusader||Good looking commander clone.|
|rox-filer||Um, are we using a GIG of ram for the file manager yet? No... well make the icons bigger!|
|systemg||Gtk... again. No need to go futhur.|
|worker||I'd imagine this is why Apple hire design people, to avoid programs like this.|
|zfm||Plugins = longer loading time.|