From: Peter G. <pe...@ar...> - 2003-01-30 01:39:33
|
Bug 676944: I often work on multiple projects at once. It would be really helpfull if I could put all the files for each project that I'm working with under it's own folder in the buffer list which I can expand and collapse as needed. I like this idea, but it's a tad underspecified. Initially, I assume, there are be no folders in the buffer list, but the right button menu has a "New folder" option, which lets you create a folder and give it a name. Once you create a folder, you can drag/drop buffers from the buffer list into it. (Can folders contain other folders? I don't really see why not...) When you exit j, the organization of folders and the buffers they contain is saved in session.xml, and restored the next time you started j. What happens if you delete a folder? The only hard case is if it contains modified buffers; you are then prompted to save them or discard the changes, just as if you were exiting j. So, there are at least four non-trivial coding tasks: 1. Convert SidebarBufferList.java to contain a SidebarList (and delegate to it), rather than extend the SidebarList class, as it does now. 2. Implement a tree that has the functionality of the sidebar list, and modify SidebarBufferList to contain that, instead of the SidebarList. 3. Implement drag/drop in the tree component to move buffers from one folder into another. 4. Modify the save/restore session code (and the format of session.xml) to support folders as well as buffers. Taken all together, this is a fairly big project. In any event, I don't have time to work on it right now, but I do basically like the concept. Any thoughts? -Peter |
From: Peter G. <pe...@ar...> - 2003-01-30 04:14:47
|
> That sounds like what I was thinking (albiet much more verbose =) I'm nothing if not verbose... ;) > > So, there are at least four non-trivial coding tasks: > > > > 1. Convert SidebarBufferList.java to contain a SidebarList (and > > delegate to it), rather than extend the SidebarList class, as it > > does now. > > This seems to be a decent non-invasive first step. I can code > it up and send you a patch (assuming that you're not planning > on doing much to it in the near future yourself =) Yeah, being non-invasive is the whole point of this step. It should be pretty much just a mechanical transformation of the code, and everything should work exactly the same after as before. > > 2. Implement a tree that has the functionality of the sidebar > > list, and modify SidebarBufferList to contain that, instead of > > the SidebarList. > > I notice that you inherit JList for SidebarList. With that knowledge, > is it safe to presume that the tree version could inherit from (or > contain a) JTree? This seems like something else that I would be able > to do. I think I had some idea initially that the component would be a list (or derived from a list) until the user made a folder, and then the list component would be replaced with a tree. But that seems pretty silly, now that I think about it. It could always be (or contain) a JTree; in the no-folder case, the tree would just be nothing but leaves. Right? > > 3. Implement drag/drop in the tree component to move buffers > > from one folder into another. > > Mildly trivial if able to use a JTree (assuming 1.4. Earlier than 1.4 > is a bit trickier. But who knows, by the time it gets done, 1.4 might > be final on OS X =) It's definitely OK to use a JTree, and I think it's OK to assume 1.4. As long as it's a patch (rather than checked-in code), assuming 1.4 is no problem at all. When it comes time to check in the new code, there will be build and packaging issues to resolve, but similar issues have already been resolved for the wheel mouse code, for example. And, as you point out, maybe OS X will have caught up by then. > > 4. Modify the save/restore session code (and the format of > > session.xml) to support folders as well as buffers. > > Looking over the Session code, I'm pretty sure I see where this would > go in. Doesn't look too bad either. Hmmmm...and my initial fears of > compatability problems when the new version imports an old version > of the session.xml file are melting away the more I think about it. I think this step should be straightforward. This step is another situation where you can write the code to handle the folders on save and restore, and then at least verify that the new code works correctly in the no-folder case, so it's another non- intrusive step. (I like non-intrusive steps.) -Peter |
From: Mike R. <ro...@ty...> - 2003-01-30 06:39:20
|
> I think I had some idea initially that the component would be a list > (or derived from a list) until the user made a folder, and then the > list component would be replaced with a tree. > > But that seems pretty silly, now that I think about it. > > It could always be (or contain) a JTree; in the no-folder case, the > tree would just be nothing but leaves. Right? Yes. And the having nothing but leaves will make it look like it is a list. > It's definitely OK to use a JTree, and I think it's OK to assume 1.4. Excellent. That will certainly make things go smoother. > As long as it's a patch (rather than checked-in code), assuming 1.4 is > no problem at all. > > When it comes time to check in the new code, there will be build and > packaging issues to resolve, but similar issues have already been > resolved for the wheel mouse code, for example. Ant is pretty groovy that way. > And, as you point out, maybe OS X will have caught up by then. It's in beta, so my fingers are crossed. > This step is another situation where you can write the code to handle > the folders on save and restore, and then at least verify that the new > code works correctly in the no-folder case, so it's another non- > intrusive step. (I like non-intrusive steps.) That's what I ended up realizing. I love it when things just fall into place like that. Mike |
From: Peter G. <pe...@ar...> - 2003-01-30 04:22:17
|
> A quick question: > Is there a specific reason that SidebarList.java is > abstract? Is it safe to just make it not abstract? > The only thing I see is the lack of definition of > public String getLabelText() from NavigationComponent. Well, it might have been more precise in the first place to make refresh() and updatePosition() abstract in SidebarList.java, since they just have empty implementations. It certainly wouldn't hurt the existing code to make it not abstract (you could just make getLabelText() return ""). It probably makes more sense to extend it, though, since you'll probably end up moving code to that class from SidebarBufferList.java, and you don't want that code in SidebarList since it's also used for tag lists (in modes other than Java). |
From: Peter G. <pe...@ar...> - 2003-01-30 04:29:00
|
> > > 1. Convert SidebarBufferList.java to contain a SidebarList (and > > delegate to it), rather than extend the SidebarList class, as > > it does now. > > There more I look at it, the more I wonder if this part is > necessary. What if I created a SidebarTree and SidebarBufferTree > class that behave much like the current SidebarList and > SidebarBufferList? The SidebarBufferTree would extend > SidebarTree to mimic the way things currently are. Or, is > the point that you want to get away from SidebarBufferList > extending SidebarList? No, the SidebarTree/SidebarBufferTree approach is fine, too. My original thought was that the tree would be a specific user option (enableBufferListTree = true, or some such), but I don't think there's any real reason it shouldn't always be a tree (it will just look like a flat list if the user hasn't created any folders). If it had been a user option, then SidebarBufferList would have delegated to a JList-derived class for a flat list and to a JTree- derived class for a tree. But I no longer think that's necessary (in fact now I think that was a silly idea in the first place). So SidebarTree and SidebarBufferTree end up being essentially drop-in replacements for SidebarList and SidebarBufferList, right? |