Oh great Locians; J.W. Bizzaro wrote: >Since you're working on containers and getting into PyGTK, how about making a >prototype widget to go in the windowlet of a container: a list widget. > Surely! I just updated loci-file with two (double the excitement!) widgets: 1. container_list.py: A GtkCList embedded in a scrolling window that you can initiated with listWidget(). 2. container_tree.py: A GtkCTree embedded in a scrolling window that can be initiated with treeWidget(). Both widgets have an optional initiation with some data already added. To get these, just call them up and pass them a 1 (ie. myList = listWidget(1)). I hope these widgets are what you were looking for! You can take a look at the widgets in action by updating your copy of loci-file. I just committed some changes so there are now three buttons to push (wow!): 1. 'Container loci': same as before, outputs XML from a selected directory structure into XMLoutput.xml 2. 'Display a listing': Takes the info from XMLoutput.xml and displays it in a list widget. I still need to learn to add pictures next to the names so that you can tell the difference between documents and directories. 3. 'Display a tree': Displays the example tree. I'm currently stuck trying to figure out how to parse the XML into a tree. 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. You can get the toolkit by going to: http://www.python.org/topics/xml/download.html. The newest version is PyXML-0.5.2.tar.gz, but I couldn't get this to install for me, so I am using PyXML-0.5.1. So whatever you can get to work should be okay, I'm not doing anything really fancy. If anyone has the chance to check out the changes, please drop me any comments you have! J.W. Bizzaro wrote: >I'd suggest looking at the 'xmllib' module that actually comes with Python. >We probably should use it (an althernative is Gnome's LibXML) for all of our >XML work. Of course it'll save quite a bit of coding for reading and (I >think) writing XML. Look at 'xmlparse.py' (bottom half of file) in the >loci-core module for an example of its use in parsing. Sorry I had to go above this. I couldn't figure enough out from xmlparse.py to know how to work this lib, and there is some pretty helpful documentation on the SAX stuff. I'm not sure about all the differences, but if necessary I can probably scale back later not to use the XML toolkit. J.W. Bizzaro wrote: >There is one catch to 'file2XML.py': It recursively descends subdirectories, >which is not needed (it's neat that you made it do that though). A container >only needs to know the contents (types, etc.) of its top level directory. >Only if you DnD a 'sub-container'/subdirectory out of the list, will the >contents of the subdir need to be known: That's when a new container, >containing the subdirectory, is made. Well, give all the credit for the recursive descending to the writers of os.path.walk(), not me! The reason I did this is for flexibility. I would really like to represent the contents of a container as a tree, instead of a list (hence the two widgets) so that a user can look into subdirectories to see what is there, without having to create a new container. I am having trouble parsing the XML into a tree, so I can't demo this yet, but I'll keep working on it. Even with the recursive descending, it is no problem to display the info as a list. I would be interested to hear people's thoughts on the tree vs. list representations. J.W. Bizzaro wrote: >The only 'problem' we're having with making new directories via CVS is that >the ownership is by default username.username. It needs to be username.cvs. >I can fix that as root, and any user can fix it, by going to I will definately do this next time. I tried to use the command 'cvs add loci-file', which, according to the book "Open Source Development with CVS", *should* allow me to add a directory, but this gives something like the following error: cvs add: in directory .: cvs [add aborted]: there is no version here: do 'cvs checkout' first Any ideas why that is? J.W. Bizzaro wrote: >So all of $LOCI_ROOT is public unless otherwise specified? I'd agree if the >rest of the filesystem was _privately_ accessible. That is the picture I was imagining. If we are following the Apache model, there are no opportunites for outside users to reach any directories besides those inside $LOCI_ROOT. Same with ftp servers, right? I'm not positive how to do this, but it seems definately possible! >Are you sure the Workspace scrolled automatically when you dragged a locus? I >never added that functionality. I don't know, I may have just been drinking heavily and imagined it! Brad