KDAR, and libdar suggestions/questions

Hello Denis,

First, I have a basic implementation of dar for KDE using libdar. I call it 
"kdar" (go figure).

All it does now is list the contents of an archive in a collapsable 
directory tree view, and it can isolate an archive. 

Figuring out how to get the callback functions to work with the qt was 
quite a hassle, but that is more a reflection of my ignorance about 
callback functions and passing function pointers as arguments to other 
functions, not any inherent difficulties in the implementation. Once you 
know how, it's easy, right?! :) 

I'd like to get your opinion on the API for the tar_listing callback. I 
suggest that the two ui_printf statements in "catalogue::tar_listing" be 
removed since the GUI frontend developer should have a say in how the 
tar_listing output is explained to the user. For example, in my 
collapsable directory tree view, the column headings explain what each 
column is, so I don't need the extra ui_printf statements spitting out 
column headers to the warning_callback function.

My main API question though, is this: is there an easy way to get an 
on-demand listing of a given directory? I don't need a recursive listing 
of the contents of the directory, which is what "libdar::op_listing" 
currently does. I'm thinking of the equivalent to "/bin/ls -a ." as 
opposed to "/bin/ls -aR .". I thought it could be done by passing the 
appropriate filter mask to "op_listing", but I've had no success.

When I try with the command-line version of dar, e.g.

"dar -l test_archive path/to/the/requested/directory"

I get a complete listing of the archive, when all I want is the listing for 
the files in the given directory. The man page for dar suggests that 
adding the [list of paths] at the end of the command line should make the 
"-l" command act on the listed paths only, as long as there are no 
conflicts with the -X and -P options. Is this the intended behaviour for 
the -l command?

Do I have to dig deeper into the libdar API to be able to extract the 
contents of a given directory directly from the catalog, or is there a 
straightforward patch to libdar::op_listing?

The reason I'd like "on-demand" directory listings is that waiting for a 
listing of a 15-CD archive was very slow (after 45 minutes I gave up), and 
took up 95% CPU and 60-80% RAM. With on-demand listings, I could list the 
top-level directory in my tree view, then populate the subdirectories as 
the user clicks on them.

I appreciate your feedback,

JB

-- 
Johnathan K. Burchill, Ph.D.
Department of Physics and Astronomy
University of Calgary
2500 University Drive N.W.
Calgary, AB T2N 1N4
Canada

(403) 217-4286
[email protected]



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf