c++ - Keeping the GUI separate -

I have a program (among other things) that has a command line interface that lets the user insert strings, The problem that will then be sent to the network is that I am not sure how to connect the events, which is generated in the deep inside the GUI, for the network interface. For example, let me assume that my GUI class hierarchy looks like this:

GUI -> main window -> Commandline interface -> Entryfilled

There are some other GUI objects in each GUI object And everything is private, now the Entryfield Object generates an event / sign in which the message is entered. At the moment I am signing the class hierarchy, so the CLI class will look something like this:

  public: sig :: csignal & lt; Zero, string & gt; MsgEntered;  

and in c'tor:

  entryField.msgEntered.connect (sigc :: mem_fun (this, and CLI :: passUp));  

The passup function now emits the signal again for the hosting class (the main window) until I can do this in the main loop:

  Gui.msgEntered.connect (sigc :: mem_fun (Network Interfaces, and Network Interface :: SendMsg));  

Now it seems like a real bad solution. Every time I add something to the GUI, I have to wire it to everyone through the class hierarchy. I look at many ways around it. I can make all the items public, which will allow me to do this in the main loop:

.mainWindow.cli.entryField.msgEntered.connect (sigc :: mem_fun (networkInterface, Amp;; NetworkInterface :: sendMSG));

But it will be against the idea of ​​encapsulation. I can also pass reference to all the network interfaces on the GUI, but I would like to keep the GUI code as close as possible.

It seems like I have something important here. Is there a clean way to do this?

Note: I am using GTK + / gtkmm / LibSigC ++, but I am not tagging it this way because I did a lot of Qt Very problem with This is actually a general question.

Fewer in becoming a global pub / sub-hub, you are not going to go up some hierarchy above or below Get away from passing through even if you have a listener for a common interface or controller, you still have to add the controller to the UI event in some way.

With a pub / all hub, you add a second layer to the blocker, but there is still a duplication - Entryfield still publishes 'message ready-made event' and the listener / controller / network interface says That is 'listen to event to create' event, so there is a common event ID about which both sides need to know, and if you are not going to hard-code, then pass it on both the files in two places. Will (although globally it's an argument, which is not any great benefit in itself).

I have used all four methods - straight coupling, controlling, listener and pub-all - and in each heir, you cover coupling a bit, but you can never be away from some repetition , Even if it is the only published event id.

It really comes down to variance. If you feel that you have to switch to a different implementation of the interface, it is advisable to summarize the concrete interface as an administrator. If you think that you need other logic to see the state, then change it to a supervisor. If you need to reduce it between processes, or want to plug in more general architecture, then the pub / sub can work, but it offers a form of global state, and to check compile time Not responsible for

But if you do not need to separate parts of the system independently, then it's probably not worth worrying about it