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.
Haskell functions have this nice concept called 'guards' which allow you to define a condition and return a value when that conditi...
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...
I have used quite successfully a Raspberry Pi 2 running NetBSD 7 as a customer proxy and I assumed 7.0.2 would run on a Raspberry Pi 3. A...