Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Singletons and Swing

Reply
Thread Tools

Singletons and Swing

 
 
Jason Cavett
Guest
Posts: n/a
 
      02-18-2008
On Feb 16, 7:07 pm, Martin Gregorie <(E-Mail Removed)>
wrote:
> Jason Cavett wrote:
> > On Feb 15, 3:15 pm, Daniel Pitts
> > <(E-Mail Removed)> wrote:
> >> Jason Cavett wrote:
> >>> On Feb 15, 12:16 am, Jason Cavett <(E-Mail Removed)> wrote:
> >>>> On Feb 14, 10:16 pm, Daniel Pitts
> >>>> <(E-Mail Removed)> wrote:
> >>>>> 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.
>
> --
> martin@ | Martin Gregorie
> gregorie. | Essex, UK
> org |


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.
 
Reply With Quote
 
 
 
 
Daniel Pitts
Guest
Posts: n/a
 
      02-19-2008
Jason Cavett wrote:
> On Feb 16, 7:07 pm, Martin Gregorie <(E-Mail Removed)>
> wrote:
>> Jason Cavett wrote:
>>> On Feb 15, 3:15 pm, Daniel Pitts
>>> <(E-Mail Removed)> wrote:
>>>> Jason Cavett wrote:
>>>>> On Feb 15, 12:16 am, Jason Cavett <(E-Mail Removed)> wrote:
>>>>>> On Feb 14, 10:16 pm, Daniel Pitts
>>>>>> <(E-Mail Removed)> wrote:
>>>>>>> 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.
>>
>> --
>> martin@ | Martin Gregorie
>> gregorie. | Essex, UK
>> org |

>
> 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.

--
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>
 
Reply With Quote
 
 
 
 
Thomas A. Russ
Guest
Posts: n/a
 
      02-19-2008
Jason Cavett <(E-Mail Removed)> writes:

> 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.


--
Thomas A. Russ, USC/Information Sciences Institute
 
Reply With Quote
 
Jason Cavett
Guest
Posts: n/a
 
      02-20-2008
On Feb 19, 12:21 pm, (E-Mail Removed) (Thomas A. Russ) wrote:
> Jason Cavett <(E-Mail Removed)> writes:
> > 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.
>
> --
> Thomas A. Russ, USC/Information Sciences Institute


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."
 
Reply With Quote
 
Jason Cavett
Guest
Posts: n/a
 
      02-20-2008
On Feb 19, 11:47 am, Daniel Pitts
<(E-Mail Removed)> wrote:
> Jason Cavett wrote:
> > On Feb 16, 7:07 pm, Martin Gregorie <(E-Mail Removed)>
> > wrote:
> >> Jason Cavett wrote:
> >>> On Feb 15, 3:15 pm, Daniel Pitts
> >>> <(E-Mail Removed)> wrote:
> >>>> Jason Cavett wrote:
> >>>>> On Feb 15, 12:16 am, Jason Cavett <(E-Mail Removed)> wrote:
> >>>>>> On Feb 14, 10:16 pm, Daniel Pitts
> >>>>>> <(E-Mail Removed)> wrote:
> >>>>>>> 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.

>
> >> --
> >> martin@ | Martin Gregorie
> >> gregorie. | Essex, UK
> >> org |

>
> > 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.
>
> --
> Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>


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).
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Swing is dead! Long live Swing. Knute Johnson Java 32 02-29-2012 05:10 PM
Why not using javax.swing.event with swing? S.T Java 2 05-25-2007 12:10 AM
javax.swing.Popup, javax.swing.PopupFactory lizard Java 0 01-30-2006 09:34 PM
Swing Model Classes Updating Swing Components on a Thread Other Than AWT mkrause Java 0 05-06-2005 04:32 PM
Java 1.2 Swing vs. Java 1.5 Swing Big Daddy Java 2 04-16-2005 01:14 PM



Advertisments