Ok, I never used window groups as I wasn't that used to have that many interdependent windows.
It seems easier to add a "Palette" inside your JPanel and it surely is easier to handle than to make a separate window tha listens on the Lookup/activated nodes and reacts.
TopComponentGroup seems like the next logical step: if you already started using a whole bunch of windows that are interconnected somehow put them in the same group.
The teoretical advantage would be that
1. You get to easily open and close the whole group. You don't even have to know *who* is in the group. (Note the nice decoupling you get there).
2. The Group implementation remembers the closed/open state of contained TopComponents and restores them in the same way. This makes it consistent with the user.
Well, it's number 2 that annoys the hell out of me. For example: what if I *don't* want to remember the state ? What if I have 3 TopComponents that work together but they should *always* be in an open() state together ?
What do you do then ? Of course: do it manually. You lose the decoupling and have to keep hard references to your "buddy"-windows and .open() or .close() them by hand when needed.
Which means that by this point TopComponentGroup is useless and you might as well remove all the code/xmls. Grr.
I saw The Trouble with Harry (1955) a while back and it didn't have a big impression on me. But recently I rewatched it and was amazed a...
English is obviously the lingua-franca of everything computer and computer-science related. Having a single language does help everybody sin...
As Apache NetBeans became a top level Apache project and finished the incubation process I was asked for an interview and my photo. Only ...
People will never bother to do anything manual unless absolutely necessary. This is why I believe the current NetBeans "empty" jav...