DirWin beta - tiny file manager

[MikeLockmoore]

I have a new, tiny file manager to share.  This is a one-pane file manager, less than 55KB in this version.  It has some similarities with Fluff:

* Drag-and-drop file copying/moving, plus keyboard and menu options for doing copies and moves, including to another instance of DirWin

* File associations with applications (although simpler)

* Double-click navigation of file system

* Opens terminal in current directory

* Sort files by name, date, and size (but not type)

* Show or hide "hidden" (dot-something) files

Some differences from Fluff
* File path input changes directories as you type, can jump back to higher directories easily

* Command-line allows you to issue direct commands or alter the command line for an associated file type

* No tree view

* No GUI to update file associations (edit the .dirwin.conf file when DirWin is not open)

* File type identification for additional file types by file extension pattern only (won't peek inside file contents)

* No "use sudo" option (Guy should be happy  

* No file replacement warning and skip option

* No "cloning" of files by pasting file back into the same directory (use Cmd field instead)

* No file properties window and no GUI to change properties (use Cmd field instead)

* Columns not individually sizable, but will grow and shrink along with overall window size

This source code is for a BETA-level software release and is for careful testing by adventurous users only!  While care was taken to eliminate bugs, this release likely still still contains bugs and may crash and/or unintentional file deletion or corruption.  Use at your own risk!  Thoughtful and detailed feedback on bugs, usability issues, and improvement ideas is appreciated.

For those who don't want to build their own copy, I have requested that this BETA release (0.7.1) be posted in the official repository.  

List of known issues in Version 0.7.1:

A. The Makefile "all" target will copy the executable to /home/tc/bin and the help stuff to /usr/share/doc/dirwin.  Either create these directories yourself or comment out this part of the Makefile.  I'll revise the Makefile in future versions to do this stuff optionally

B. Keystroke shortcut for type-specific associated application uses the Alt key with a number key.  In my installation, only the left Alt key seems to be recognized; the right Alt + a number is ignored.

[Guy]

It is handy to have a file manager in the base. If you have something good enough, the team will probably want to include it.

I don't know enough about that file manager to have a valid opinion on it.

I like xfe. If you could make xfe, or something like it, without dependencies, I am sure it would be popular.

[Jason W]

dirwin.tcz is now in the repo.

[MikeLockmoore]

I like xfe. If you could make xfe, or something like it

Guy: I like xfe too.  I've mentioned before that my motivation to create the Fluff file manager was to have something like xfe but running "native" as a FLTK app so I didn't need the Fox GUI toolkit library (multiple megabytes) to run it.

But the Core Team decided Fluff is a bit too big and complex for Tiny Core Base.  So if Fluff can't make it, I don't think anything else that is even _more_ like xfe is going to make it either.

[Guy]

I would aim for the best, but keep it as small as possible, not the smallest, unless it is the best.

They are likely to include a high quality app, even if it is slightly larger than ideal.

They are not likely to include an inferior app, even if it is small.

Even if they don't include it in the base, Xfe, or something like it, without dependencies, as an extension, would be very handy when installing Tinycore. You could just copy one file and use install local.

Keep up the good work.

[roberts]

Nice! I am liking it. I hope we get more feedback on this as I would like to have a basic file manager in the base.

[vinnie]

The concept seems interesting

[MikeLockmoore]

roberts, vinnie: Thanks for the kind words.

Users: Here is a sample .dirwin.conf file showing several application associations I configured for my general use:

Code: [Select]

# DirWin file utility configuration file
# Auto-written Mon May 30 12:09:45 2011

# NOTE: if you hand-edit, please take care to spell
#       and structure configuration statements carefully!

# Main Window placement and size
MainWide = 846
MainHigh = 370

# Options
ConfirmDelete = 0
ShowAllFiles = 1
SortOrder = 0
# Sorting: 0=name+asc, 1=name+desc, 2=size+asc, 3=size+desc
#          4=date+asc, 5=date+desc

# Filetype Application Associations
Associations:
# (extension or *), (type label), (action label), (cmd spec)
# example..
# .jpg,image,view,flpicsee %s &
# Make sure there is at least one 'script' association below!
.sh,script,Run,aterm -e ./%s &
.tcz,TCE,Run,tce-run %s &
.lst,list,Edit,editor %s &c
.c,c c++,Hack,geany %s &
.cpp,c c++,Hack,geany %s &
.cxx,c c++,Hack,geany %s &
.h,c c++,Hack,geany %s &
.fi,fluid,Edit,fluid %s &
.flume,math,Calc,flume %s &
.jpg,image,View,flpicsee %s &
.jpeg,image,View,flpicsee %s &
.JPG,image,View,flpicsee %s &
.png,image,View,flpicsee %s &
.PNG,image,View,flpicsee %s &
.gif,image,View,flpicsee %s &
.bmp,image,View,flpicsee %s &
.xbm,image,View,flpicsee %s &
.xpm,image,View,flpicsee %s &
.jpg,image,Edit,mtpaint %s &
.jpeg,image,Edit,mtpaint %s &
.JPG,image,Edit,mtpaint %s &
.png,image,Edit,mtpaint %s &
.PNG,image,Edit,mtpaint %s &
.gif,image,Edit,mtpaint %s &
.mp3,media,Play,mplayer %s &

Also attached as a file.

[jur]

I like it too. A file manager in base is a very nice to have, even if one usually uses something with more features. Once I got use to fluff, I didn't feel the need to use something else much at all.

[Jason W]

+1 for liking it.

One little issue I see when using on large directories that contain thousands of files and or subdirectories. The routine that uses the "du -ck" command takes a very long time to complete before changing to that directory having to individually measure each file in all subdirectories.  In fact, with my mounted nfs share, it not only takes a long time but does not cd to that directory, it just stalls and remains in the current dir.

In fact, I see the same behavior when trying to navigate to /usr, at least on my system with a lot of stuff installed.  It stalls then doesn't go to it.

Oh, and I tried Fluff on this setup, and it does not have these issues, FWIW.

[MikeLockmoore]

Jason: Thanks for the feedback.  My directories are mostly small, so this issue was not very visible to me. 

I'll think about doing the "du -ck" differently, or delaying it so it is not in the critical path for displaying the directory content... the status line with the file sizes can wait a bit, if neccessary.

[MikeLockmoore]

A few things I thought of adding to DirWin if the size cost is reasonable (a few more KB?)...

1) Tab-completion for the path input field when the child directory is unambiguous.

2) Scroll/select directory items in the contents list as the user types the name... like the tab completion in the path input field, but can highlight both files and subdirectories in the list.

I think 2) is not too hard.  1) is already being done in the FLTK standard File Open dialog box, so I may look at their code and see if they expose some functionality I can directly use, or at least have a clever method I can reimplement.

 

[curaga]

Tab-completition is mighty fast when the dirs are in ram, I've noticed

[aus9]

hi Team

Is there a size limitation on what file manager might be candidates for inclusion

According to my eyesight
fluff_upgrade 61 K
dirwin ............25 k


2) Is there a minimum feature that whatever file manager is chosen?


-----------------IMHO for below

3) a) if user double-clicks a file.....that action will cause the associated (viewer, web browser, multi-media player etc) execute
b) if user sees a file, they can "easily" copy it....by mouse or by menu options or by keyboard actions
.....I am not fussed which

Ditto ....delete , remove or move or rename.
I personally don't care if there is no trashcan.....we can warn the newbie

c) The user can see the file sizes and the file types (where applicable)

d) The user can see a way of displaying dot files  (hidden files)

I have no objection if you read newbie for user....heh heh

[MikeLockmoore]

aus9: 61K and 25K are the compressed sizes of each.  After booting, they could occupy 2 to 3 times that of your RAM and/or filesystem space.  That may not be much for many users, but the Fluff executable is noticably larger than other Tiny Core Base applications, and some users are pressing for more features that would make it even bigger.

My goal with DirWin is to cover the proverbial 80% to 90% of features that people use frequently and see how small I can make it so it is more similar to other applications included in Tiny Core base.  But I'm _not_ pushing for it to be included in Tiny Core Base any time soon.  I'd like to refine it to make it more robust and efficient.  Maybe it can be considered later.

Jason:  For now, I'm planning to make the "du -ck" storage space check an optional thing, defaulted to off each time you start DirWin.  If you want to check the storage space of the selected items, you can use the menu to tggle on that part of the status display. Thay way, you only "pay" in terms of you time when the information is important to you.  And you can turn it off again.

I've noticed that the first time the system does a "du -ck" in a mounted filesystem, the scan can be quite slow, but later scans are much, much faster.  Does anyone know a better way to get this information?  Especially if it does not take much code?