On 9/8/2011 3:10 AM, William Zwicky wrote:
> Note that I don't have permissions to post a binary, so we'll need a
> volunteer for that. And if you'd prefer to be the one to BUILD the binary,
> let me know.
I can probably post the binary, but I probably shouldn't build it. I
don't use ant or make or any of the tools which use the build.xml and
other files which everybody carefully maintains.
> If you're working on something now, please respond with an estimate of how
> long it'll take (powers of ten - 1, 10, 100 days).
Well, while you're talking about releases, I want to mention something
else about the refactor (now that I'm diving back into the code and
remembering what the hell I was thinking at the time). The *original*
refactoring plan was to make "core" go away, entirely. Everything in
core was going to get neatly organized into org.jsynthlib somehow. Two
things postponed this:
- CVS (which is what sourceforge was using at the time) didn't support
"moving" files across directories. When they got moved, CVS would treat
them as one file being deleted and another, unrelated one being added.
This would affect people's ability to see diffs between versions on
either side of the date when the file was moved. SVN, I'm told, *does*
support moving, so it's my hope that this will preserve the revision
history when the files get moved.
- When I saw how many synthdrivers and other UI components were
subclassing Actions.MenuFrame, I freaked and decided to un-tangle that
mess... which is what I'm just finishing up now.
If I move files around while I'm working in branches/UIRefactor, then
that's going to create chaos when we try to merge this into trunk. So,
I'm not going to move any existing files until *after* the merge to
trunk, but they *will* move after that and everything will look a lot
cleaner.
- Joe
|
