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'm exploring NetBeans Web Toolkit with the articles here NetBeans Web Toolkit is the new name I'm trying to give to Jaroslav Tu...
People will never bother to do anything manual unless absolutely necessary. This is why I believe the current NetBeans "empty" jav...
(This article is on google docs too). Introduction I'll present here how to use Maven projects with NetBeans IDE via the MevenIDE pr...
Note : This article is a living document and will be updated as I learn new useful information (last update 31st December 2016). I will mov...