J.W. Bizzaro wrote: > class WidgetMain() > >The name may change, but it should be the same for all widgets. > Gotcha! Makes sense now that I've been looking in-depth at the code. We can change the name when we try to fit the widgets into loci-core. J.W. Bizzaro wrote: >> Note that since this now does XML parsing, loci-file requires something >> new. I used the SAX (simple API for XML) complient parser from the python >> xml toolkit. > >The licenses are acceptable. I'd like to keep the number of extra packages >that the user needs to install to a minimum though. Does SAX provide what >straight xmllib cannot? Well, I did some looking at the xmllib documentation (in the general python library docs) and now I have a better idea of what XML tools are in the python distribution and what extra stuff is in the xml toolkit. While it seems like basically whatever parser you use is a matter of personal preference, I see a couple of advantages for the SAX parser: 1. SAX is based on a generalized API, which gives it some extra modularity over any other parser application. In addition, it might be likely that programmers have had exprience with SAX in other languages, which might make the Loci code easier to follow and maintain by others. 2. From a bioinformatics standpoint, the proposed biopython BLAST parser has a SAX-like interface, so it makes learning SAX twice as worthwhile for anyone who will be used the BLAST parser and coding on Loci (namely, me!) In general, I think we really do need the extra stuff from the xml toolkit. It provides a DOM implementation, which we will really need, and architectural forms processors, in addition to SAX and some other parsers. In addition, if we want to stick with xmllib, the xml toolkit has some kind of C extension that supposedly makes it 5 times as fast. With all the XML work that we will need to do, my vote is definately for keeping the xml toolkit. Any thoughts? >How long would it take to do this for a large filesystem? at a remote >location? > >These are the reasons why I wanted to use a list. If trees are (1) made fast >enough and (2) aren't used for every container, they would be good to use. >Can you give us some feedback about these issues? Sure. Since the tree implementation works in the new filegui.py thingy, everyone can check it out on different size directories to their heart's content. While I think it is plenty fast for medium sized directories (with 5 or so levels) if we want to stick with a tree representation we definately need some limitations. I accidentally started parsing my /usr directory (with 5 MB worth of stuff) and needless to say, I had to go in and kill that process! I think a good way to limit the parsing and also keep a tree representation would be to have the tree created only a certain number of levels deep. Then, the user could have an idea of the contents of subdirectories, and if they need to go into one subdirectory whose contents weren't listed, they could drag the subdirectory as a new loci and see it that way. I think I could implement this without too many problems. How does this sound to everyone? Any thoughts on the number of levels to go? Other ideas? BTW, I don't think that the tree representation will be good for databases. My thought is that a listing of the different databases available in a particular locus will be good enough for that. I think that there will probably be too much info in a database to represent in a simple GUI. Thanks for your comments on this! Brad