From: Joe E. <jo...@em...> - 2006-02-28 03:37:04
|
Okay, I made that last one up... I'm planning to change some of the workings of JSLFrame, JSLDesktop, and other related windowing parts of JSL. I think I can reduce the number of windowing classes by about 30%, reduce the lines of code in the classes by about 30%, and still not break anything. Because JSL can operate in SDI or MDI mode, it needs to either use normal JFrames or JInternalFrames, depending upon which mode it's in. This presents a problem, since other JSL-specific frames (like PatchEditorFrame, for example) can't inherit from both. The current solution uses "proxies", where things like PatchEditorFrame ultimately inherit from JSLFrame... and JSLFrame avoids having to inherit from both by holding the JFrame or JInternalFrame as a data member (named "proxy"), and then passing every method call (like JSLFrame.repaint()) to the data member (ie, JSLFrame.repaint() would do nothing but call proxy.repaint()). I've done this very thing before, but I've never seen it done to such a large scale as this. In its present state, even though I understand it now, I think it's very confusing and awkward. I *think* I can figure out a smoother way to do all of this. However, so that I don't break any of the existing code, I'm going to put it down in: org.jsynthlib.desktop org.jsynthlib.desktop.mdi org.jsynthlib.desktop.sdi Now if you're wondering "Why? If it isn't broken, why fix it?". Well, because, although what's *there* works... it's difficult to *add* anything. It took me a couple of days, off and on, to figure out where to put the code for the application-frame icon. I also want to add a splash-screen for the initial load of JSL... but I'm at a loss for where to put it. So, anyway, I don't expect to have this new thing working for a couple of weeks. So, don't panic. And, if it doesn't work at all, I just won't put it on the CVS. But I'm just letting you all know what I'm working on so that you can comment on it. - Joe |