> 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.)