GUI questions google won't answer

[Tolls]

In order the break the link between controller and GUI (at least from the GUI perspective) you need a listener.
So:

public interface MyGUIListener {
   void loadThingsIDisplay(some search criteria?);
   void getThing(int id);
}

These define the sort of interaction the GUI expects to have to do with the (non-GUI) outside world. That would be implemented by the Controller.
The GUI, which is just a normal class, not extending any JFrame or such, then accepts listeners. In most cases it will be just the one, but I suppose in hefty system you would want to break down the responsibilities a bit to avoid monster classes.

When the GUI needs a search it will then call loadThingsIDisplay() on its listener. That would be in a SwingWorker thread.

The Controller then does its work getting the info and hands the List<Things> back to the GUI via, presumably, a displayThings() method.

In this structure the Controller (at least the parts of the Controller immediately in contact with it) has access to the GUI pretty directly.

Does that make sense? It is late on a Monday...:)

[Fubarable]

Does that make sense? It is late on a Monday...:)

Yep that makes perfect sense. As always, thanks!

[ObedMarsh]

I appreciate everyones input, so many thanks!
I ended up with a main program which builds a controller object, nothing more.
Controller has the gui as a field value and then builds it in it's constructor. It also has inner classes which assigns listeneres to components in the GUI class, using corresponding methods I made in the GUI.
The controller also stores an arraylist of <abstract superclass> objects, which it can use to list information on accounts in an uneditable text area in the GUI. This proved possible by simply giving the superclass as many field values as possible and simply manipulating extended classes(specific accounts) by "nullifying" those values or making them unobtainable for the particular types.
The superclass(logical) has statis methods, to fx check if a value user enters in the input fields of the gui, are correct and the right syntax etc. These are used in the controller and in other non static methods. Fx I made a saveAccount() method, which saves all created account objects in a folder called "Accounts/<subfolder for customer>/<account number>.dat", another method searches for a <customer> account files and gets an array of <superclass> objects which is then displayed through the GUI. Overall the setup seems to work, not sure what an experienced programmer would say (probably alot xD ) but I'm satisfied for now.

It seems to work quite decently anyways.