Menu
▾
▴
jsynthlib-devel
|
From: Joe E. <jo...@em...> - 2005-02-17 06:07:10
|
My apologies for dropping off of the map for a year-and-a-half. When I drifted off back then, there was some eager talk about implementing XML-based patch driver specs. Since I've been watching CVS all this time, I've noticed that there's been some work in this area. I'm eager to help out on something... so I'm wondering what next feature everybody is trying to get into JSL. I could go scour the archvies, but it seems easier just to ask to see what the "hot" items are these days. - Joe |
|
From: Hiroo H. <hir...@co...> - 2005-02-18 02:28:37
|
Joe> I'm eager to help out on something... so I'm wondering what next feature Joe> everybody is trying to get into JSL. I could go scour the archvies, but Joe> it seems easier just to ask to see what the "hot" items are these days. There are two proposal. 1. XML driver 2. package structure change (move to org.jsynthlib) 2.1 making consensus We had discussion and I made summary a few times. But I could not continue the job for my laziness. 2.2 making change It is too much work for a person to make the all of changes. How can we share the work? I think the refactoring feature in Eclipse may reduce the work a lot, but I'm not sure. -- Hiroo Hayashi |
|
From: Joe E. <jo...@em...> - 2005-02-18 11:13:16
|
Hiroo Hayashi wrote: >2. package structure change (move to org.jsynthlib) > >2.1 making consensus >We had discussion and I made summary a few times. But I could not >continue the job for my laziness. > >2.2 making change >It is too much work for a person to make the all of changes. How can we >share the work? > >I think the refactoring feature in Eclipse may reduce the work a lot, >but I'm not sure. > > Yes, it would. Also, IDEA has the same refactoring features and it really does work very easily. I could probably do all of this in an evening. Although I was a big proponent of this idea back when I proposed it a couple of years ago (and I still would like to see it happen) one big downside to this has occured to me (which has probably been mentioned already). This will probably have *dramatic* effects on version-comparison in the CVS tree. Right now, on SourceForge, you can go into the CVS tree and compare any verison of a file to any other version of it. If we move the files in the CVS tree, I fear that CVS will think that we deleted a file and added another (instead of figuring out that we just moved one). I don't know how smart CVS is about things like that. The alternative would be to merely change the *package* directives in the source so that they *compiled* to a different directory structure, while leaving the *source* files in their *old* structure. This would be the worst possible solution, in my opinion. In fact, I feel that it would be worse than how it is *now*. Has this consideration already been addressed? - Joe |
|
From: Hiroo H. <hir...@co...> - 2005-02-19 03:26:47
|
Rib, Rib> > I think the refactoring feature in Eclipse may reduce the work a lot, Rib> > but I'm not sure. Rib> Rib> Yeah. Most of it should probably take an hour or so using eclipse. Rib> Splitting the synthdrivers into manufacturer packages might be harder, Rib> though. Could you teach me where this feature is described in Eclipse help? I found Java Development User Guide->Tasks->Refactoring->Renaming a package but this just renames a package and is not what I'm looking for. Or does the way described in Java Development User Guide->Tasks->Using the Package Explorer-> Moving folders, packages, and file change package and import statements? -- Hiroo Hayashi |
|
From: Joe E. <jo...@em...> - 2005-02-19 10:54:13
|
Hiroo Hayashi wrote: >Rib, > >Rib> > I think the refactoring feature in Eclipse may reduce the work a lot, >Rib> > but I'm not sure. >Rib> >Rib> Yeah. Most of it should probably take an hour or so using eclipse. >Rib> Splitting the synthdrivers into manufacturer packages might be harder, >Rib> though. > >Could you teach me where this feature is described in Eclipse help? > > I could look around. What version of Eclipse are you using? I just tried it in IDEA and it is *obscenely* easy. You just select file(s), right-click, and select "Refactor->Move...". It then prompts you with a list of all of the existing packages. I could probably do it in a little over a minute. It shouldn't be too difficult, however, to do it with a global search-replace. You'd need to do four of them: search for "package core" and replace with "package org.jsynthlib" search for "import core" and replace with "import org.jsynthlib" search for "package synthdrivers" and replace with "package synthdrivers" search for "import synthdrivers" and replace with "import org.jsynthlib.synthdrivers" Then, drag all files and folders "core/" into "org/jsynthlib/" and drag the synthdrivers/ directory into "org/jsynthlib/" as well. That would get you 90% of the way there. The nice thing about it is that it should work for stuff with text *after* it. For example "package synthdrivers.Alesis5M" would also get turned into "package org.jsynthlib.synthdrivers.Alesis5M", etc. - Joe |
|
From: Joe E. <jo...@em...> - 2005-02-19 11:13:22
|
Hiroo Hayashi wrote: >Could you teach me where this feature is described in Eclipse help? > >I found > Java Development User Guide->Tasks->Refactoring->Renaming a package >but this just renames a package and is not what I'm looking for. > >Or does the way described in > Java Development User Guide->Tasks->Using the Package Explorer-> > Moving folders, packages, and file >change package and import statements? > > Well, I just tried it in Eclipse 3.0.1 and it seems to work. Here's how: You must be in the *Java* perspective. From there, you right-click on a file and select "Refactor->Move..." and it presents you with the current list of packages (like like IDEA does). There is also a checkbox to tell it to update all references to the moved files. I guess... now the only real question is how to arrange the new package structure. Since this is probably going to cause a hiccup in the CVS revisions of all of the files, we don't want to have to do this *again* in the future. Let's make sure that we get it right this time. - Joe |
|
From: Steven S. <ste...@co...> - 2005-02-19 18:27:55
|
Joe Emenaker wrote: > Hiroo Hayashi wrote: > >> Could you teach me where this feature is described in Eclipse help? >> >> I found >> Java Development User Guide->Tasks->Refactoring->Renaming a package >> but this just renames a package and is not what I'm looking for. >> >> Or does the way described in >> Java Development User Guide->Tasks->Using the Package Explorer-> >> Moving folders, packages, and file >> change package and import statements? >> >> > Well, I just tried it in Eclipse 3.0.1 and it seems to work. Here's how: Have you (needed to) set up any specific user libraries in eclipse for this project? |
|
From: Hiroo H. <hir...@co...> - 2005-02-19 20:15:06
|
Steven> Have you (needed to) set up any specific user libraries in eclipse for Steven> this project? See "How to set up Eclipse for JSynthLib?" on the FAQ in programming.html. -- Hiroo Hayashi |
|
From: Hiroo H. <hir...@co...> - 2005-02-23 04:58:05
|
Hi Rib,
Rib> Of course we need to move the menu stuff out of the Desktop classes
Rib> first,
I've been working on this and it is almost done on my local work space.
Once 0.20 CVS tag will be made I'll check it in.
I have two questions to you to complete the work. JSLFrame has the
following code for Mac OS.
public void setVisible(boolean b) {
if (MacUtils.isMac()) {
if (b && getJMenuBar() == null) {
setJMenuBar(Actions.createMenuBar());
} else if (!b) {
// Remove menubar so frame can be disposed.
// http://archives:arc...@li.../archives/java-dev/2003/Dec/04/disposingofjframesusescr.001.txt
//JMenuBar mb = getJMenuBar();
setJMenuBar(null);
desktop.getInvisible().getJFrame().requestFocus();
requestFocus();
}
}
....
Q1. It seems that a frame can not be disposed unless menu bar is removed
by calling setJMenuBar(null). Is it still true for J2SE 1.4 and/or
later which is the requirement of JSynthLib? (In other words, do we
still have to do this hack?) The URL in the comment above is not valid
now.
Q2. There are two requestFocus() call in the code above. Do we really
need the first one ("desktop.getInvisible().getJFrame().requestFocus();")?
I think the effect of the first one is hidden by the second one.
Thanks.
--
Hiroo Hayashi
|
|
From: Hiroo H. <hir...@co...> - 2005-02-23 06:55:32
|
OK. I'll add some more information on the comment. Thanks. Rib> The problem was that you not only had to set the JMenuBar to null, but Rib> also deactivate and then reactivate the window before disposing it. Rib> The new URL is http://lists.apple.com/archives/java-dev/2003/Dec/msg00122.html Rib> Rib> It seems Apple was investigating the problem last July. I just tested Rib> it though, and unfortunately it still has not been fixed in the Rib> current Java release. Rib> However, instead of deactivating and activating the frame we can call Rib> both setMenuBar(null) and setJMenuBar(null). -- Hiroo Hayashi |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X