Hello all; I've been working in the middle on adding capabilities for "permanent storage" of loci, so that they can be saved in one session and recalled in a different session. I think this will be really important to have working if we want to have good functionality with the new merger with GMS and Overflow. So, I've come up with a proposal for implementing permanent storage in the GUI and would like to toss it out for people's comments before I get going with it (since I'm not so hot at user interfaces). I think this is pretty much based on ideas that Jeff posted previously. So here goes. 1. The permanent storage locus will be a "special case" of the container locus that we currently have. That is, the locus will look like the current container locus with a list/tree view of the contents. 1.1 For anyone who looks at the code, I'm planning on implementing this as a new class since I'm not really very happy with how I did widgets/container.py. Then I'll revamp these classes so one either inherets from another or (more likely) so they both inheret from a base class. 1.2 Each element in a list will be represented by the name of the locus and a little pixmap according to it's type. Anyone know where to get a bunch o' little pixmaps I could use for this? 1.3 The permanent storage locus will have to be special in that it is either always present on the desktop, or can be called up through a menu function. 2. The permanent storage locus will be implemented like a "separate hard drive" from the rest of the workspace. So anything which moves into permanent storage will be copied in, and anything that moves out will be copied out. 3. loci will be moved out of permanent storage onto a workspace (so they can be used or manipulated) via drag and drop (like things work now for normal containers). 4. loci will be moved into containers via drag and drop from a locus in the workspace. Right now I'm planning to implement a dnd from a locus on the workspace using a button 2 click (the middle button for 3 button mouse users and buttons 1 + 2 for 2 button users). Then we can explore further how to integrate dnd movement with the "regular local loci movement" and get how we'd work that straightened out. 5. I'm not positive the best way to view deeper levels of directories inside of the storage container. We could do this using: a. A GtkTree (like I had originally implemented for regular containers). I _might_ be able to make this faster on a second try. b, Make a double click on a container in the directory open up a window/another loci that displays the contents on this directory. c. Other ideas? 6. We will probably also need to implement a "trash" container to go along with this. I think that's what I've got for now. Any suggestions or comments would be very welcome! Brad