Menu
▾
▴
jsynthlib-devel
|
From: Hiroo H. <hir...@co...> - 2005-02-10 05:28:19
|
Hi, I'm thinking to make the following changes. Please give me your comments before we start fixing them. 1. Cross Breed Now cross breed command randomly selects one of patch in the active library frame, then cross the patch with another patch which is also selected randomly from the same kind of patches in the library. I think it is better to let users select the first patch. For example when there are some patches for DX7 and some patches for Kawai K4 in a library, a user want to specify for which synth new patch will be. 2. "Remove Driver" button Now there is a "Remove Driver" button on a Device Details dialog window (Preference -> Synth Driver -> Show Details -> Loaded Drivers). I don't understand what this function for? In what situation is this button used? I think the button should be removed. 3. "File -> Exit" behavior in SDI (multiple window) mode When a library, scene, patch editor, or bank editor is closed, a dialog window asking save data or not pops up. But when "File -> Exit" is selected, JSynthlib exits without saving data. This is inconsistent. The dialog window should pop-up when "File -> Exit" is selected. 4. Toolbar window close in SDI mode. Now when Toolbar window is closed, JSynthlib does not exit. I think it is more straight-forward for a user if JSynthlib exits. 5. menu bar This is not visible for users. This may be a question to Rib. Now menu bar is created in JSLDesktop class. This make it difficult for JSLDesktop class to be generic class, because the menu bar is JSynthlib specific. I think it would be better to create and add the menu bar out side of JSKDesktop class. -- Hiroo Hayashi |
|
From: Jeff W. <jww...@ya...> - 2005-02-10 14:33:00
|
Hiroo, I have a suggestion for useability. How about adding a Cancel button to the "Unsaved Data" dialog? All it would do is close the "Unsaved Data" dialog and take no further action. The same thing could be done for the "Save Changes?" dialog when exiting a patch editor. The Save Changes? dialog has the following three choices: "Place Changed Version on Clipboard", "Revert to Original", and "Keep Changes". A Cancel button, would do nothing but close the Save Changes dialog and return the user to the editor. Thanks, Jeff --- Hiroo Hayashi <hir...@co...> wrote: > 3. "File -> Exit" behavior in SDI (multiple window) > mode > > When a library, scene, patch editor, or bank editor > is closed, a dialog > window asking save data or not pops up. But when > "File -> Exit" is > selected, JSynthlib exits without saving data. This > is inconsistent. > The dialog window should pop-up when "File -> Exit" > is selected. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com |
|
From: Hiroo H. <hir...@co...> - 2005-02-11 05:06:39
|
Jeff, Thank you for your comment. I was thinking same thing. I'll try that. Jeff> I have a suggestion for useability. How about adding a Jeff> Cancel button to the "Unsaved Data" dialog? All it Jeff> would do is close the "Unsaved Data" dialog and take Jeff> no further action. Jeff> Jeff> The same thing could be done for the "Save Changes?" Jeff> dialog when exiting a patch editor. The Save Changes? Jeff> dialog has the following three choices: "Place Changed Jeff> Version on Clipboard", "Revert to Original", and "Keep Jeff> Changes". A Cancel button, would do nothing but close Jeff> the Save Changes dialog and return the user to the Jeff> editor. -- Hiroo Hayashi |
|
From: Hiroo H. <hir...@co...> - 2005-02-11 05:56:53
|
Hi Rib,
Rib> > 4. Toolbar window close in SDI mode.
Rib> >
Rib> > Now when Toolbar window is closed, JSynthlib does not exit. I think it
Rib> > is more straight-forward for a user if JSynthlib exits.
Rib>
Rib> I did it this way to act like Mac applications. Maybe this should be
Rib> a platform dependent feature.
At the lunch time I asked my colleague about the MacOSX interface. It
getting more clear. Correct me if I am misunderstanding.
The menu bar set by setJMenuBar() is shown at the top of the screen (not
the frame).
The menu bar for the active frame at that point is shown at the top of
screen.
What is shown at the top of screen, if setJMenuBar() is not called on
the active frame?
For other OSs, the toolbar looks like a kind of the center window. But
for MacOSX it looks line just a one of frames.
Is this the common way for toolbar in SDI mode on MacOSX?
When all of frames are closed, it is not strange if the menu bar at the
top of screen remains. (The 'invisible' frame is for this purpose.)
This behavior on MacOSX is almost the behavior of JDesktopPane. It
would be a clean implementation, if JDesktopPane had a mode in which
mode the whole screen was treated as a desktop pane.
Anyway now I understand your JSL* class much more.
Rib> > 5. menu bar
Rib> >
Rib> > This is not visible for users. This may be a question to Rib.
Rib> >
Rib> > Now menu bar is created in JSLDesktop class. This make it difficult for
Rib> > JSLDesktop class to be generic class, because the menu bar is JSynthlib
Rib> > specific. I think it would be better to create and add the menu bar out
Rib> > side of JSKDesktop class.
Rib>
Rib> The problem is that the menu bar has to be created for every JSLFrame.
Rib> Maybe we should make a MenuFactory interface, and pass an instance of
Rib> it to the JSLDesktop.
It is better for each JSLFrame to have its own menu bar. There can be a
JSLFrame without menu bar. It's a choice of application program.
To keep the current behavior JSynthLib can add menubar on JSLFrame
(which does not have menu bar by default) by extending JSLFrame.
I think this is a flexible and clean way. The biggest problem now I see
is the name of the extended class.
org.jsynthlib.jsynthlib.JSLJSLFrame class !!!?
--
Hiroo Hayashi
|
|
From: Hiroo H. <hir...@co...> - 2005-02-13 18:47:59
|
Hi Rib,
Rib> > For other OSs, the toolbar looks like a kind of the center window. But
Rib> > for MacOSX it looks line just a one of frames.
Rib> >
Rib> > Is this the common way for toolbar in SDI mode on MacOSX?
Rib>
Rib> Actually Mac programs are not supposed to have this type of
Rib> "application global" toolbar. Instead all functions should be
Rib> accesible from the menus, and possibly also keyboard shortcuts. If
Rib> toolbars do exist, they are supposed to be attached to the window that
Rib> they act on. The user is supposed to be able to chose which buttons
Rib> are on the toolbar, or hide the toolbar entirely.
The following implementation may be better.
No toolbar window on MacOS
toolbar is attached on every frame.
toolbar can be removed by user preference.
default is enabled on MacOS, and is disabled on other OSs.
How do you think?
Rib> > To keep the current behavior JSynthLib can add menubar on JSLFrame
Rib> > (which does not have menu bar by default) by extending JSLFrame.
Rib> >
Rib> > I think this is a flexible and clean way. The biggest problem now I see
Rib> > is the name of the extended class.
Rib> >
Rib> > org.jsynthlib.jsynthlib.JSLJSLFrame class !!!?
Rib>
Rib> Again, this design was based on the Mac interface guidelines -- The
Rib> menu items stay constant for the whole application, but may be enabled
Rib> or disabled based on what window is active instead of having menu
Rib> items added or removed over time. But you are right, maybe this
Rib> shouldn't be required by the JSLDesktop classes.
OK. Extending JSLDesktop/JSLFrame class seems a right way .
I cannot accept "JSLJSLFrame". "MyFrame" is a candidate. I don't like
it, but have no better name.
Another way is to rename "JSLDesktop"/"JSLFrame" class. For example
"MMDesktop" and "MMFrame". "MM" stands for "Multi Mode".
Do you have any suggestion?
--
Hiroo Hayashi
|
|
From: Hiroo H. <hir...@co...> - 2005-02-13 21:04:55
|
Rib> > The following implementation may be better. Rib> > Rib> > No toolbar window on MacOS Rib> > toolbar is attached on every frame. Rib> > toolbar can be removed by user preference. Rib> > default is enabled on MacOS, and is disabled on other OSs. Rib> > Rib> > How do you think? Rib> Rib> That sounds really good. OK. I'll do that. Rib> > I cannot accept "JSLJSLFrame". "MyFrame" is a candidate. I don't like Rib> > it, but have no better name. Rib> > Rib> > Another way is to rename "JSLDesktop"/"JSLFrame" class. For example Rib> > "MMDesktop" and "MMFrame". "MM" stands for "Multi Mode". Rib> > Rib> > Do you have any suggestion? Rib> Rib> How about something like MenuFrame or JSLMenuBarFrame? Sold! -- Hiroo Hayashi |
|
From: Hiroo H. <hir...@co...> - 2005-03-02 13:34:22
|
Hi, I've checked in the following fix on the main trunk. ----------------------- Make JSLDesktop, JSLFrame, and JSLWindowMenu JSynthLib independent. Move Menu related code to AppConfig. Add configuration option of Tool Bars for frames in SDI mode. no toolbar window in SDI mode for Mac OS. ----------------------- I might break something as usual especially for MacOS X which I cannot test well. Let me know if you see anything wrong. Thanks. On Sun, 13 Feb 2005 15:04:59 -0600 Hiroo Hayashi <hir...@co...> wrote: Hiroo> Rib> > The following implementation may be better. Hiroo> Rib> > Hiroo> Rib> > No toolbar window on MacOS Hiroo> Rib> > toolbar is attached on every frame. Hiroo> Rib> > toolbar can be removed by user preference. Hiroo> Rib> > default is enabled on MacOS, and is disabled on other OSs. Hiroo> Rib> > Hiroo> Rib> > How do you think? Hiroo> Rib> Hiroo> Rib> That sounds really good. Hiroo> Hiroo> OK. I'll do that. Hiroo> Hiroo> Rib> > I cannot accept "JSLJSLFrame". "MyFrame" is a candidate. I don't like Hiroo> Rib> > it, but have no better name. Hiroo> Rib> > Hiroo> Rib> > Another way is to rename "JSLDesktop"/"JSLFrame" class. For example Hiroo> Rib> > "MMDesktop" and "MMFrame". "MM" stands for "Multi Mode". Hiroo> Rib> > Hiroo> Rib> > Do you have any suggestion? Hiroo> Rib> Hiroo> Rib> How about something like MenuFrame or JSLMenuBarFrame? Hiroo> Hiroo> Sold! Hiroo> -- Hiroo> Hiroo Hayashi -- Hiroo Hayashi |
|
From: Rib R. <ri...@gm...> - 2005-03-03 07:50:34
|
I did a little testing today. It seems that MDI is the default. I think maybe GUI_MDI and GUI_SDI are switched in AppConfig.getGuiStyle. Also, I wonder if it would be more user friendly to automatically open a default library at startup when in SDI mode, and maybe even for MDI too. On a Mac, ~/Documents/JSynthLib.patchlib would probably be a good location for this. I don't know about on other OSs. Perhaps the location should be an option in AppConfig. On Wed, 02 Mar 2005 07:34:17 -0600, Hiroo Hayashi <hir...@co...> wrote: > Hi, > > I've checked in the following fix on the main trunk. > > ----------------------- > Make JSLDesktop, JSLFrame, and JSLWindowMenu JSynthLib independent. > Move Menu related code to AppConfig. > Add configuration option of Tool Bars for frames in SDI mode. > no toolbar window in SDI mode for Mac OS. > ----------------------- > > I might break something as usual especially for MacOS X which I cannot > test well. Let me know if you see anything wrong. > > Thanks. > > On Sun, 13 Feb 2005 15:04:59 -0600 > Hiroo Hayashi <hir...@co...> wrote: > > Hiroo> Rib> > The following implementation may be better. > Hiroo> Rib> > > Hiroo> Rib> > No toolbar window on MacOS > Hiroo> Rib> > toolbar is attached on every frame. > Hiroo> Rib> > toolbar can be removed by user preference. > Hiroo> Rib> > default is enabled on MacOS, and is disabled on other OSs. > Hiroo> Rib> > > Hiroo> Rib> > How do you think? > Hiroo> Rib> > Hiroo> Rib> That sounds really good. > Hiroo> > Hiroo> OK. I'll do that. > Hiroo> > Hiroo> Rib> > I cannot accept "JSLJSLFrame". "MyFrame" is a candidate. I don't like > Hiroo> Rib> > it, but have no better name. > Hiroo> Rib> > > Hiroo> Rib> > Another way is to rename "JSLDesktop"/"JSLFrame" class. For example > Hiroo> Rib> > "MMDesktop" and "MMFrame". "MM" stands for "Multi Mode". > Hiroo> Rib> > > Hiroo> Rib> > Do you have any suggestion? > Hiroo> Rib> > Hiroo> Rib> How about something like MenuFrame or JSLMenuBarFrame? > Hiroo> > Hiroo> Sold! > Hiroo> -- > Hiroo> Hiroo Hayashi > -- > Hiroo Hayashi > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Jsynthlib-devel mailing list > Jsy...@li... > https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel > |
|
From: Hiroo H. <hir...@co...> - 2005-03-04 05:44:46
|
Hi,
Rib> I did a little testing today. It seems that MDI is the default. I
Rib> think maybe GUI_MDI and GUI_SDI are switched in AppConfig.getGuiStyle.
This is my mistake. I tend to use the word MDI for multiple window
interface...
And you made a fix for MacUtils.isMac(). I don't think it's good idea
to check the value of property "apple.laf.useScreenMenuBar" in isMac()
method. isMac() should just check if MacOS or not. And I think the
condition System.getProperty("java.vm.version").startsWith("1.4") also
should be removed. This does not work for JDK 1.5 or greater. And 1.4
or greater is requirement for any OS now.
How do you think?
Rib> Also, I wonder if it would be more user friendly to automatically open
Rib> a default library at startup when in SDI mode, and maybe even for MDI
Rib> too. On a Mac, ~/Documents/JSynthLib.patchlib would probably be a
Rib> good location for this. I don't know about on other OSs. Perhaps the
Rib> location should be an option in AppConfig.
You can specify a library file as a command line argument. I always
invoke a default library by using the argument.
And if we define default file, we can use "Patch Library Path" which
user specifies. But adding a user preference "default library" may be
better idea.
--
Hiroo Hayashi
|
|
From: Hiroo H. <hir...@co...> - 2005-03-05 19:34:10
|
Hi,
Rib> You're probably right about the version string. I also agree that
Rib> checking for the ScreenMenuBar probably shouldn't be in isMac(). The
Rib> problem is that without it, JSynthLib starts up with an empty menu,
Rib> and a single frame (with no title bar) containing a menu. Someone who
Rib> see's that is going to think that JSynthLib is broken. By making
Rib> isMac return false in this case, the behavior is acceptable. Another
Rib> solution, if we had a library open automatically, would be to hide the
Rib> "invisible" frame and the toolbar on a Mac without the screen menu
Rib> bar, but still make JSynthLib quit when you close the last frame. But
Rib> this seems too complicated.
Why don't we enable 'invisible window mode' only when MacOS and
ScreenMenuBar mode?
if (isMac && System.getProperty("apple.laf.useScreenMenuBar").equals("true"))
((JSLFakeDesktop) proxy).createInvisibleWindow(mb);
else
((JSLFakeDesktop) proxy).createToolBarWindow(title + " Tool Bar", mb, tb);
I've checked in this fix.
Rib> > And if we define default file, we can use "Patch Library Path" which
Rib> > user specifies. But adding a user preference "default library" may be
Rib> > better idea.
Rib>
Rib> I didn't know you could do that. However I assume that most Mac users
I added the feature Oct 31, 2004.
Rib> will use the Application Bundle, which doesn't have a way to specify
Rib> command line arguments. So I think it would still be a good idea to
Rib> have an option to open a library on startup.
Rib>
Rib> This would mean another place in AppConfig where we test for
Rib> MacUtils.isMac(). Maybe we need to come up with a better way have
Rib> default options be OS dependent.
I agree with you it's good idea to add preference option to specify the
default library file for any OSs. I can do that easily.
Thanks.
--
Hiroo Hayashi
|
|
From: Hiroo H. <hir...@co...> - 2005-03-07 00:31:10
|
Hiroo> I agree with you it's good idea to add preference option to specify the Hiroo> default library file for any OSs. I can do that easily. It's in head. -- 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