Singletons and Swing

[Jason Cavett]

I am attempting to design a menu system for an application I am
writing. In it, I want an InsertMenu that exists within multiple
different menus. Currently, I am attempting to do this by making the
InsertMenu a singleton. This is causing a weird issue.

I currently have two menus that hold the InsertMenu - a MainMenu and a
TreePopupMenu. The InsertMenu should be contained within both of
those. However, it seems as though it can only be in one menu at a
time. For example, if the TreePopupMenu has been created (which
happens after I've opened up a new project), the InsertMenu completely
disappears (with no errors or warnings) from the MainMenu.

Is it possible to accomplish what I'm trying to do?

Here is how I am creating my InsertMenu singleton. Could this be the
problem? Thanks.

/**
* This method initializes
*
*/
private InsertMenu() {
super("Insert New...");
initialize();
}

/**
* Provides access to the InsertMenu singleton.
*/
private static class InsertMenuHolder {
private static InsertMenu menu = new InsertMenu();
}

/**
* Provides access to the InsertMenu singleton from outside the
InsertMenu.
*
* @return the insert menu
*/
public static InsertMenu getInstance() {
return InsertMenuHolder.menu;
}

 

[Peter Duniho]

I am attempting to design a menu system for an application I am
writing. In it, I want an InsertMenu that exists within multiple
different menus. Currently, I am attempting to do this by making the
InsertMenu a singleton. This is causing a weird issue.

I currently have two menus that hold the InsertMenu - a MainMenu and a
TreePopupMenu. The InsertMenu should be contained within both of
those. However, it seems as though it can only be in one menu at a
time. For example, if the TreePopupMenu has been created (which
happens after I've opened up a new project), the InsertMenu completely
disappears (with no errors or warnings) from the MainMenu.

Is it possible to accomplish what I'm trying to do?

I doubt it. Don't take my word for it, as I'm inexperienced with Java.
But given that a Java menu is a component and has a parent, and given that
as far as I know in Java a component can have only one parent at a time
(that's a common enough restriction in a wide variety of parent-child code
designs and while I haven't seen an explicit statement to that effect in
the Java docs, it may exist and/or simply be implied), your menu can only
be a child of any one menu at a time.

You could probably change your singleton so that it's not actually a
menu. Instead, it would be a sort of menu factory that keeps track of its
actual menu instances. It's not really clear why you want this menu to be
a singleton anyway, but one possibility is that the menu is changeable and
you want to be able to have just a single instance that changes and have
those changes reflected anywhere the menu is used. If so, you can't do it
directly, but making your singleton a factory that tracks the created
menus would allow the factory to also update all of the created menus
appropriately as needed (assuming those changes always go through the
factory, of course).

Not relevant to anything, but I'm also a little puzzled as to the reason
for having the "InsertMenuHolder" class. Why not just have a private
static InsertMenu member in the singleton class itself?

Pete

 

[Jason Cavett]

I doubt it. Don't take my word for it, as I'm inexperienced with Java.
But given that a Java menu is a component and has a parent, and given that
as far as I know in Java a component can have only one parent at a time
(that's a common enough restriction in a wide variety of parent-child code
designs and while I haven't seen an explicit statement to that effect in
the Java docs, it may exist and/or simply be implied), your menu can only
be a child of any one menu at a time.

You could probably change your singleton so that it's not actually a
menu. Instead, it would be a sort of menu factory that keeps track of its
actual menu instances. It's not really clear why you want this menu to be
a singleton anyway, but one possibility is that the menu is changeable and
you want to be able to have just a single instance that changes and have
those changes reflected anywhere the menu is used. If so, you can't do it
directly, but making your singleton a factory that tracks the created
menus would allow the factory to also update all of the created menus
appropriately as needed (assuming those changes always go through the
factory, of course).

Not relevant to anything, but I'm also a little puzzled as to the reason
for having the "InsertMenuHolder" class. Why not just have a private
static InsertMenu member in the singleton class itself?

Pete

Ahhh...good point. I forgot about the parent thing.

The reason I want InsertMenu to be static is because I want it to
update everywhere. Using the Observable pattern didn't really fit
well in here either.

Your suggestions seems to be a good one, except one thing. If the
user closes a project, how can I make sure that the InsertMenu
associated with that project is destroyed?

In reference to your last question - I am lazily instantiating the
menu per: http://en.wikipedia.org/wiki/Singleton_pattern#The_solution_of_Bill_Pugh

 

[Peter Duniho]

[...]
Your suggestions seems to be a good one, except one thing. If the
user closes a project, how can I make sure that the InsertMenu
associated with that project is destroyed?

Define "project". But more generally, I'd say that'd be a function of the
rest of your code. I presume that normally, you'd just rely on the
destruction of the frame and contained objects associated with the
"project" to release the menu.

In this case, you'd also want to remove your menu instance from the
collection the factory is managing, right?

Depending on how you're dealing with the destruction of the project, I
suppose there are a variety of ways you could react to this event. But
one obvious answer seems to be that you could add a WindowListener to the
frame so that you are called when it's closing or closed. At that point,
you'd destroy whatever resources are associated with the project,
including the factory's reference to the menu (the menu(s)
itself(themselves) used by the frame would be destroyed with the
destruction of the frame, presumably...and I use the term "destroy"
loosely since I'm not really sure at what point things get disposed versus
just not being referenced any longer...I assume that disposing the frame
disposes all of the contents, but like I said, I'm new to Java ).

I assume that in this case by "InsertMenu" you mean the actual Java menu,
and not the factory itself (and of course that assumes we're talking about
going with a factory implementation rather than a singleton, as a
work-around to the "no multiple parents" issue).

In reference to your last question - I am lazily instantiating the
menu per:
http://en.wikipedia.org/wiki/Singleton_pattern#The_solution_of_Bill_Pugh

I see. Again, I doubt it matters but...do you really need this singleton
to be thread-safe? I like lazy instantiation, but I think it's a bit
clearer to write the code explicitly rather than relying on the specific
behavior of the language. If you don't need to synchronize access to the
singleton, the simple "if null then instantiate" approach won't clutter up
the code very much at all. Maybe that's just me though.

Pete

 

[Daniel Pitts]

I am attempting to design a menu system for an application I am
writing. In it, I want an InsertMenu that exists within multiple
different menus. Currently, I am attempting to do this by making the
InsertMenu a singleton. This is causing a weird issue.

I currently have two menus that hold the InsertMenu - a MainMenu and a
TreePopupMenu. The InsertMenu should be contained within both of
those. However, it seems as though it can only be in one menu at a
time. For example, if the TreePopupMenu has been created (which
happens after I've opened up a new project), the InsertMenu completely
disappears (with no errors or warnings) from the MainMenu.

Is it possible to accomplish what I'm trying to do?

Here is how I am creating my InsertMenu singleton. Could this be the
problem? Thanks.

[snip...]
In stead of sharing a menu-item instance, its common to share an Action
instance. Often the best way to do that is to extend AbstractAction.

The problem that you're seeing is that most swing components (including
JMenus, JMenuItems, etc...) know about their parent. If they are added
to a different container, they remove themselves from there other parent.

The other approach could be to have a simple method that constructs this
menu in a certain other menu (think createInsertMenu(mainMenuBar).

it is still desirable to share Action instances (they share "disabled"
flags and icons and such).

Anyway, hope this helps,
Daniel.

 

[Jason Cavett]

I am attempting to design a menu system for an application I am
writing. In it, I want an InsertMenu that exists within multiple
different menus. Currently, I am attempting to do this by making the
InsertMenu a singleton. This is causing a weird issue.

I currently have two menus that hold the InsertMenu - a MainMenu and a
TreePopupMenu. The InsertMenu should be contained within both of
those. However, it seems as though it can only be in one menu at a
time. For example, if the TreePopupMenu has been created (which
happens after I've opened up a new project), the InsertMenu completely
disappears (with no errors or warnings) from the MainMenu.

Is it possible to accomplish what I'm trying to do?

Here is how I am creating my InsertMenu singleton. Could this be the
problem? Thanks.

[snip...]
In stead of sharing a menu-item instance, its common to share an Action
instance. Often the best way to do that is to extend AbstractAction.

The problem that you're seeing is that most swing components (including
JMenus, JMenuItems, etc...) know about their parent. If they are added
to a different container, they remove themselves from there other parent.

The other approach could be to have a simple method that constructs this
menu in a certain other menu (think createInsertMenu(mainMenuBar).

it is still desirable to share Action instances (they share "disabled"
flags and icons and such).

Anyway, hope this helps,
Daniel.

Hmmm...that is a good suggestion.

The reason I didn't originally do it is because I wanted to create the
menus on the fly. But after looking at the action classes, I realized
that you can "control" the menus via the actions (L&F, icons, etc).

I'm going to have to look more closely at this.

Thanks.

 

[Jason Cavett]

[snip...]
In stead of sharing a menu-item instance, its common to share an Action
instance. Often the best way to do that is to extend AbstractAction.

The problem that you're seeing is that most swing components (including
JMenus, JMenuItems, etc...) know about their parent. If they are added
to a different container, they remove themselves from there other parent.

The other approach could be to have a simple method that constructs this
menu in a certain other menu (think createInsertMenu(mainMenuBar).

it is still desirable to share Action instances (they share "disabled"
flags and icons and such).

Anyway, hope this helps,
Daniel.

Hmmm...that is a good suggestion.

The reason I didn't originally do it is because I wanted to create the
menus on the fly. But after looking at the action classes, I realized
that you can "control" the menus via the actions (L&F, icons, etc).

I'm going to have to look more closely at this.

Thanks.

Alright. My coworker and I came up with a good solution that solves
the issue and gives us context sensitive menus.

Basically, we made InsertMenu *not* a singleton and, instead,
overwrote JMenuItem so that, when it is enabled or disabled, it is
also set visible/invisible, respectively (overwrote "setEnabled" and
"setVisible" so they stay consistent). That way, when the Action (we
have an ActionFactory) is enabled or disable, it will carry over to
our JMenuItem.

It works beautifully and is much better than having a Singleton of the
InsertMenu.

Thanks for the help.

 

[Daniel Pitts]

Jason Cavett wrote:
I am attempting to design a menu system for an application I am
writing. In it, I want an InsertMenu that exists within multiple
different menus. Currently, I am attempting to do this by making the
InsertMenu a singleton. This is causing a weird issue.
I currently have two menus that hold the InsertMenu - a MainMenu and a
TreePopupMenu. The InsertMenu should be contained within both of
those. However, it seems as though it can only be in one menu at a
time. For example, if the TreePopupMenu has been created (which
happens after I've opened up a new project), the InsertMenu completely
disappears (with no errors or warnings) from the MainMenu.
Is it possible to accomplish what I'm trying to do?
Here is how I am creating my InsertMenu singleton. Could this be the
problem? Thanks.
[snip...]
In stead of sharing a menu-item instance, its common to share an Action
instance. Often the best way to do that is to extend AbstractAction.
The problem that you're seeing is that most swing components (including
JMenus, JMenuItems, etc...) know about their parent. If they are added
to a different container, they remove themselves from there other parent.
The other approach could be to have a simple method that constructs this
menu in a certain other menu (think createInsertMenu(mainMenuBar).
it is still desirable to share Action instances (they share "disabled"
flags and icons and such).
Anyway, hope this helps,
Daniel.

Hmmm...that is a good suggestion.

The reason I didn't originally do it is because I wanted to create the
menus on the fly. But after looking at the action classes, I realized
that you can "control" the menus via the actions (L&F, icons, etc).

I'm going to have to look more closely at this.

Thanks.

Alright. My coworker and I came up with a good solution that solves
the issue and gives us context sensitive menus.

Basically, we made InsertMenu *not* a singleton and, instead,
overwrote JMenuItem so that, when it is enabled or disabled, it is
also set visible/invisible, respectively (overwrote "setEnabled" and
"setVisible" so they stay consistent). That way, when the Action (we
have an ActionFactory) is enabled or disable, it will carry over to
our JMenuItem.

It works beautifully and is much better than having a Singleton of the
InsertMenu.

Thanks for the help.

Just a hint, it is often (not always) better to show that the item is
still there, just not available. Hiding (rearranging) menus in any way
often leads to user confusion.

 

[Jason Cavett]

On Feb 14, 10:16 pm, Daniel Pitts
Jason Cavett wrote:
I am attempting to design a menu system for an application I am
writing. In it, I want an InsertMenu that exists within multiple
different menus. Currently, I am attempting to do this by making the
InsertMenu a singleton. This is causing a weird issue.
I currently have two menus that hold the InsertMenu - a MainMenu and a
TreePopupMenu. The InsertMenu should be contained within both of
those. However, it seems as though it can only be in one menu at a
time. For example, if the TreePopupMenu has been created (which
happens after I've opened up a new project), the InsertMenu completely
disappears (with no errors or warnings) from the MainMenu.
Is it possible to accomplish what I'm trying to do?
Here is how I am creating my InsertMenu singleton. Could this be the
problem? Thanks.
[snip...]
In stead of sharing a menu-item instance, its common to share an Action
instance. Often the best way to do that is to extend AbstractAction.
The problem that you're seeing is that most swing components (including
JMenus, JMenuItems, etc...) know about their parent. If they are added
to a different container, they remove themselves from there other parent.
The other approach could be to have a simple method that constructs this
menu in a certain other menu (think createInsertMenu(mainMenuBar).
it is still desirable to share Action instances (they share "disabled"
flags and icons and such).
Anyway, hope this helps,
Daniel.
--
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>
Hmmm...that is a good suggestion.
The reason I didn't originally do it is because I wanted to create the
menus on the fly. But after looking at the action classes, I realized
that you can "control" the menus via the actions (L&F, icons, etc).
I'm going to have to look more closely at this.
Thanks.

Alright. My coworker and I came up with a good solution that solves
the issue and gives us context sensitive menus.

Basically, we made InsertMenu *not* a singleton and, instead,
overwrote JMenuItem so that, when it is enabled or disabled, it is
also set visible/invisible, respectively (overwrote "setEnabled" and
"setVisible" so they stay consistent). That way, when the Action (we
have an ActionFactory) is enabled or disable, it will carry over to
our JMenuItem.

It works beautifully and is much better than having a Singleton of the
InsertMenu.

Thanks for the help.

Just a hint, it is often (not always) better to show that the item is
still there, just not available. Hiding (rearranging) menus in any way
often leads to user confusion.

That's a good point - not something I thought of.

As an argument, though (and, of course, there's no way you could have
known this about my application), hiding the menu items that aren't
available keeps the menu list from becoming exceptionally long which
requires the user to search through a list of items.

Either way, I will make sure I do some usability testing before I make
the context sensitive menus live.


Thanks!

 

[Martin Gregorie]

On Feb 14, 10:16 pm, Daniel Pitts
Jason Cavett wrote:
I am attempting to design a menu system for an application I am
writing. In it, I want an InsertMenu that exists within multiple
different menus. Currently, I am attempting to do this by making the
InsertMenu a singleton. This is causing a weird issue.
I currently have two menus that hold the InsertMenu - a MainMenu and a
TreePopupMenu. The InsertMenu should be contained within both of
those. However, it seems as though it can only be in one menu at a
time. For example, if the TreePopupMenu has been created (which
happens after I've opened up a new project), the InsertMenu completely
disappears (with no errors or warnings) from the MainMenu.
Is it possible to accomplish what I'm trying to do?
Here is how I am creating my InsertMenu singleton. Could this be the
problem? Thanks.
[snip...]
In stead of sharing a menu-item instance, its common to share an Action
instance. Often the best way to do that is to extend AbstractAction.
The problem that you're seeing is that most swing components (including
JMenus, JMenuItems, etc...) know about their parent. If they are added
to a different container, they remove themselves from there other parent.
The other approach could be to have a simple method that constructs this
menu in a certain other menu (think createInsertMenu(mainMenuBar).
it is still desirable to share Action instances (they share "disabled"
flags and icons and such).
Anyway, hope this helps,
Daniel.
--
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>
Hmmm...that is a good suggestion.
The reason I didn't originally do it is because I wanted to create the
menus on the fly. But after looking at the action classes, I realized
that you can "control" the menus via the actions (L&F, icons, etc).
I'm going to have to look more closely at this.
Thanks.
Alright. My coworker and I came up with a good solution that solves
the issue and gives us context sensitive menus.
Basically, we made InsertMenu *not* a singleton and, instead,
overwrote JMenuItem so that, when it is enabled or disabled, it is
also set visible/invisible, respectively (overwrote "setEnabled" and
"setVisible" so they stay consistent). That way, when the Action (we
have an ActionFactory) is enabled or disable, it will carry over to
our JMenuItem.
It works beautifully and is much better than having a Singleton of the
InsertMenu.
Thanks for the help.

Just a hint, it is often (not always) better to show that the item is
still there, just not available. Hiding (rearranging) menus in any way
often leads to user confusion.

That's a good point - not something I thought of.

As an argument, though (and, of course, there's no way you could have
known this about my application), hiding the menu items that aren't
available keeps the menu list from becoming exceptionally long which
requires the user to search through a list of items.

Either way, I will make sure I do some usability testing before I make
the context sensitive menus live.

IMO there are two sides to this question: you need to consider both the
access rights of the signed-on user and the immediate context:

Access rights: never show a user any menu item he doesn't have the
rights to use.

Context: always show the user all the menu items he;s entitled to use,
but grey out the ones that are not valid in the current context.

Applying these two rules keeps the menu sizes under control and, equally
important, a given user always sees the same items in every menu, but
can't use those that are illogical and/or inappropriate in the immediate
context.

The same rules should also apply to buttons.

 

[Jason Cavett]

Jason Cavett wrote:
On Feb 14, 10:16 pm, Daniel Pitts
Jason Cavett wrote:
I am attempting to design a menu system for an application I am
writing. In it, I want an InsertMenu that exists within multiple
different menus. Currently, I am attempting to do this by making the
InsertMenu a singleton. This is causing a weird issue.
I currently have two menus that hold the InsertMenu - a MainMenu and a
TreePopupMenu. The InsertMenu should be contained within both of
those. However, it seems as though it can only be in one menu at a
time. For example, if the TreePopupMenu has been created (which
happens after I've opened up a new project), the InsertMenu completely
disappears (with no errors or warnings) from the MainMenu.
Is it possible to accomplish what I'm trying to do?
Here is how I am creating my InsertMenu singleton. Could this be the
problem? Thanks.
[snip...]
In stead of sharing a menu-item instance, its common to share an Action
instance. Often the best way to do that is to extend AbstractAction.
The problem that you're seeing is that most swing components (including
JMenus, JMenuItems, etc...) know about their parent. If they are added
to a different container, they remove themselves from there other parent.
The other approach could be to have a simple method that constructs this
menu in a certain other menu (think createInsertMenu(mainMenuBar).
it is still desirable to share Action instances (they share "disabled"
flags and icons and such).
Anyway, hope this helps,
Daniel.
--
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>
Hmmm...that is a good suggestion.
The reason I didn't originally do it is because I wanted to create the
menus on the fly. But after looking at the action classes, I realized
that you can "control" the menus via the actions (L&F, icons, etc).
I'm going to have to look more closely at this.
Thanks.
Alright. My coworker and I came up with a good solution that solves
the issue and gives us context sensitive menus.
Basically, we made InsertMenu *not* a singleton and, instead,
overwrote JMenuItem so that, when it is enabled or disabled, it is
also set visible/invisible, respectively (overwrote "setEnabled" and
"setVisible" so they stay consistent). That way, when the Action (we
have an ActionFactory) is enabled or disable, it will carry over to
our JMenuItem.
It works beautifully and is much better than having a Singleton of the
InsertMenu.
Thanks for the help.
Just a hint, it is often (not always) better to show that the item is
still there, just not available. Hiding (rearranging) menus in any way
often leads to user confusion.

That's a good point - not something I thought of.

As an argument, though (and, of course, there's no way you could have
known this about my application), hiding the menu items that aren't
available keeps the menu list from becoming exceptionally long which
requires the user to search through a list of items.

Either way, I will make sure I do some usability testing before I make
the context sensitive menus live.

IMO there are two sides to this question: you need to consider both the
access rights of the signed-on user and the immediate context:

Access rights: never show a user any menu item he doesn't have the
rights to use.

Context: always show the user all the menu items he;s entitled to use,
but grey out the ones that are not valid in the current context.

Applying these two rules keeps the menu sizes under control and, equally
important, a given user always sees the same items in every menu, but
can't use those that are illogical and/or inappropriate in the immediate
context.

The same rules should also apply to buttons.

Normally I'd agree with you, but the problem at hand doesn't seem to
apply here.

Basically, within my application, users are creating trees. However,
only certain nodes can have certain parents. Additionally, there are
many different types of nodes. If I just gray out the ones they don't
need, they still have a huge list to search through when, instead, if
I hide the ones they don't need, they only have 3 or 4, max.

Is there possibly another way to approach this that I haven't thought
of? Thanks.

 

[Daniel Pitts]

On Feb 15, 3:15 pm, Daniel Pitts
Jason Cavett wrote:
On Feb 14, 10:16 pm, Daniel Pitts
Jason Cavett wrote:
I am attempting to design a menu system for an application I am
writing. In it, I want an InsertMenu that exists within multiple
different menus. Currently, I am attempting to do this by making the
InsertMenu a singleton. This is causing a weird issue.
I currently have two menus that hold the InsertMenu - a MainMenu and a
TreePopupMenu. The InsertMenu should be contained within both of
those. However, it seems as though it can only be in one menu at a
time. For example, if the TreePopupMenu has been created (which
happens after I've opened up a new project), the InsertMenu completely
disappears (with no errors or warnings) from the MainMenu.
Is it possible to accomplish what I'm trying to do?
Here is how I am creating my InsertMenu singleton. Could this be the
problem? Thanks.
[snip...]
In stead of sharing a menu-item instance, its common to share an Action
instance. Often the best way to do that is to extend AbstractAction.
The problem that you're seeing is that most swing components (including
JMenus, JMenuItems, etc...) know about their parent. If they are added
to a different container, they remove themselves from there other parent.
The other approach could be to have a simple method that constructs this
menu in a certain other menu (think createInsertMenu(mainMenuBar).
it is still desirable to share Action instances (they share "disabled"
flags and icons and such).
Anyway, hope this helps,
Daniel.
--
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>
Hmmm...that is a good suggestion.
The reason I didn't originally do it is because I wanted to create the
menus on the fly. But after looking at the action classes, I realized
that you can "control" the menus via the actions (L&F, icons, etc).
I'm going to have to look more closely at this.
Thanks.
Alright. My coworker and I came up with a good solution that solves
the issue and gives us context sensitive menus.
Basically, we made InsertMenu *not* a singleton and, instead,
overwrote JMenuItem so that, when it is enabled or disabled, it is
also set visible/invisible, respectively (overwrote "setEnabled" and
"setVisible" so they stay consistent). That way, when the Action (we
have an ActionFactory) is enabled or disable, it will carry over to
our JMenuItem.
It works beautifully and is much better than having a Singleton of the
InsertMenu.
Thanks for the help.
Just a hint, it is often (not always) better to show that the item is
still there, just not available. Hiding (rearranging) menus in any way
often leads to user confusion.
--
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>
That's a good point - not something I thought of.
As an argument, though (and, of course, there's no way you could have
known this about my application), hiding the menu items that aren't
available keeps the menu list from becoming exceptionally long which
requires the user to search through a list of items.
Either way, I will make sure I do some usability testing before I make
the context sensitive menus live.

IMO there are two sides to this question: you need to consider both the
access rights of the signed-on user and the immediate context:

Access rights: never show a user any menu item he doesn't have the
rights to use.

Context: always show the user all the menu items he;s entitled to use,
but grey out the ones that are not valid in the current context.

Applying these two rules keeps the menu sizes under control and, equally
important, a given user always sees the same items in every menu, but
can't use those that are illogical and/or inappropriate in the immediate
context.

The same rules should also apply to buttons.

Normally I'd agree with you, but the problem at hand doesn't seem to
apply here.

Basically, within my application, users are creating trees. However,
only certain nodes can have certain parents. Additionally, there are
many different types of nodes. If I just gray out the ones they don't
need, they still have a huge list to search through when, instead, if
I hide the ones they don't need, they only have 3 or 4, max.

Is there possibly another way to approach this that I haven't thought
of? Thanks.

Well, if there are different "types" of nodes, then the UI should
probably call that out some how. If you can categorize the nodes, you
might be able to create separate menus for each category of node, and
just enable/disable the menus based on category. If you have a lot, see
if you can get some sort of hierarchy going, and then have your menu's
do that. Test both approaches, because the other rule of thumb is the
more common a task, the less "clicks" it should take to complete.

 

[Thomas A. Russ]

Basically, within my application, users are creating trees. However,
only certain nodes can have certain parents. Additionally, there are
many different types of nodes. If I just gray out the ones they don't
need, they still have a huge list to search through when, instead, if
I hide the ones they don't need, they only have 3 or 4, max.

Is there possibly another way to approach this that I haven't thought
of? Thanks.

Perhaps the answer is to make the context menus appear as pop-up menus
on the nodes that are being manipulated. Since the menu is a pop-up,
users are (by now) used to it being contextual, and only showing the
allowed operations.

The fact that it only appears when summoned (traditionally by
right-click or control-click), means that it doesn't have the same
psychological permanence of menu bar menus -- and thus has a lower
expectation of always being the same.

 

[Jason Cavett]

Perhaps the answer is to make the context menus appear as pop-up menus
on the nodes that are being manipulated. Since the menu is a pop-up,
users are (by now) used to it being contextual, and only showing the
allowed operations.

The fact that it only appears when summoned (traditionally by
right-click or control-click), means that it doesn't have the same
psychological permanence of menu bar menus -- and thus has a lower
expectation of always being the same.

Actually, this is exactly what I am doing. The menu comes up only in
the tree when the user right clicks on a specific node. That's why I
didn't mind the menu not being "permanent."

 

[Jason Cavett]

Jason Cavett wrote:
On Feb 15, 3:15 pm, Daniel Pitts
Jason Cavett wrote:
On Feb 14, 10:16 pm, Daniel Pitts
Jason Cavett wrote:
I am attempting to design a menu system for an application I am
writing. In it, I want an InsertMenu that exists within multiple
different menus. Currently, I am attempting to do this by making the
InsertMenu a singleton. This is causing a weird issue.
I currently have two menus that hold the InsertMenu - a MainMenu and a
TreePopupMenu. The InsertMenu should be contained within both of
those. However, it seems as though it can only be in one menu at a
time. For example, if the TreePopupMenu has been created (which
happens after I've opened up a new project), the InsertMenu completely
disappears (with no errors or warnings) from the MainMenu.
Is it possible to accomplish what I'm trying to do?
Here is how I am creating my InsertMenu singleton. Could this be the
problem? Thanks.
[snip...]
In stead of sharing a menu-item instance, its common to share an Action
instance. Often the best way to do that is to extend AbstractAction.
The problem that you're seeing is that most swing components (including
JMenus, JMenuItems, etc...) know about their parent. If they are added
to a different container, they remove themselves from there other parent.
The other approach could be to have a simple method that constructs this
menu in a certain other menu (think createInsertMenu(mainMenuBar).
it is still desirable to share Action instances (they share "disabled"
flags and icons and such).
Anyway, hope this helps,
Daniel.
--
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>
Hmmm...that is a good suggestion.
The reason I didn't originally do it is because I wanted to create the
menus on the fly. But after looking at the action classes, I realized
that you can "control" the menus via the actions (L&F, icons, etc).
I'm going to have to look more closely at this.
Thanks.
Alright. My coworker and I came up with a good solution that solves
the issue and gives us context sensitive menus.
Basically, we made InsertMenu *not* a singleton and, instead,
overwrote JMenuItem so that, when it is enabled or disabled, it is
also set visible/invisible, respectively (overwrote "setEnabled" and
"setVisible" so they stay consistent). That way, when the Action (we
have an ActionFactory) is enabled or disable, it will carry over to
our JMenuItem.
It works beautifully and is much better than having a Singleton of the
InsertMenu.
Thanks for the help.
Just a hint, it is often (not always) better to show that the item is
still there, just not available. Hiding (rearranging) menus in any way
often leads to user confusion.
--
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>
That's a good point - not something I thought of.
As an argument, though (and, of course, there's no way you could have
known this about my application), hiding the menu items that aren't
available keeps the menu list from becoming exceptionally long which
requires the user to search through a list of items.
Either way, I will make sure I do some usability testing before I make
the context sensitive menus live.
IMO there are two sides to this question: you need to consider both the
access rights of the signed-on user and the immediate context:
Access rights: never show a user any menu item he doesn't have the
rights to use.
Context: always show the user all the menu items he;s entitled to use,
but grey out the ones that are not valid in the current context.
Applying these two rules keeps the menu sizes under control and, equally
important, a given user always sees the same items in every menu, but
can't use those that are illogical and/or inappropriate in the immediate
context.
The same rules should also apply to buttons.

Normally I'd agree with you, but the problem at hand doesn't seem to
apply here.

Basically, within my application, users are creating trees. However,
only certain nodes can have certain parents. Additionally, there are
many different types of nodes. If I just gray out the ones they don't
need, they still have a huge list to search through when, instead, if
I hide the ones they don't need, they only have 3 or 4, max.

Is there possibly another way to approach this that I haven't thought
of? Thanks.

Well, if there are different "types" of nodes, then the UI should
probably call that out some how. If you can categorize the nodes, you
might be able to create separate menus for each category of node, and
just enable/disable the menus based on category. If you have a lot, see
if you can get some sort of hierarchy going, and then have your menu's
do that. Test both approaches, because the other rule of thumb is the
more common a task, the less "clicks" it should take to complete.

Good suggestion on the "less clicks." There are definitely times that
I can populate additional nodes (for example, if you add Node A,
you're going to need Node B, so add them both).