i.File 0.2 Alpha

i.File is a file manager for Linux written for the Windows refugees that are arriving in Linux.
i.File is a file manager for Linux written for 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. i.File project 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.

Here are some key features of "i.File":

· 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.

Requirements:

· GCC 3.2/Visual C++ 6 or better and Lgi.

Main features:

  • 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.

last updated on:
January 18th, 2006, 20:48 GMT
price:
FREE!
developed by:
MemeCode Software
homepage:
www.memecode.com
license type:
Freeware 
category:
ROOT \ Desktop Environment \ File managers

FREE!

In a hurry? Add it to your Download Basket!

user rating 1

5.0/5
 

0/5

3 Screenshots
i.Filei.Filei.File

Add your review!

SUBMIT