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.
Discrimination based on social skills and social groups exists and geeks experience it a lot. One facet of it is the pseudo inclusive pee...
Using the nice META-INF/service, one can declare it's own little status-bar piece by implementing StatusLineElementProvider . You basic...
People will never bother to do anything manual unless absolutely necessary. This is why I believe the current NetBeans "empty" jav...
During my lobby period for the NetBeans Platform at my workplace I did with a coleague a quick port to the NetBeans Platform of a Swing appl...