In an MVC patterned GUI application, can, should, and how can one best isolate the controllers from the GUI layout?

I have been fiddling with this for a while but can't seem to settle on a particular answer to the dilemma. I have been building this GUI program that is organized around an MVC-style pattern, and I run into the following issue: as one may know if one is familiar with this architectural pattern, the "controller" objects are supposed to handle events generated by the "view" objects (the stuff that presents the GUI to the user) that come from user input, such as a button click.

However, in some cases, the response to clicking a button may involve in it the need to put up another view, such as a dialog box or a pane in a window, depending on just how our GUI is laid out. But when doing this, it seems "logical" to me that the controller should not have to worry about the layout of the GUI, only that it needs to put up a view like such. That is, views have context to them, and nest together, and we want the controller not to have to know about that context and nesting.

The trick is, then, how to best go about achieving that isolation - or to know if it is really "bad design" to not have it there, as the simplest and most obvious solution is to just forget it, make the view in the controller, and the controller has to know the context, and has to be changed if we rearrange the GUI. But that seems to go against principles like the "single responsibility principle" of object-oriented programming (which this program uses). It gives the controller more "reasons to change". And that's clearly not ideal if it can be avoided.

The alternative, I come up with, is to use a "view manager" that has full control over the creation of views, which knows all the context. But even here, there seems to be a more subtle leak of knowledge in that, because "which view goes with which containing view" can become ambiguous in the case that there are multiple containing views available. If a controller asks for the sub-view, but not the parent (no knowledge of that, remember?) then the view manager has a dilemma as to where to put that sub-view unless it's informed of it somehow, or else (as in the current program), the view manager only allows one view, and then returns that same view to the controller, which then has the apparent issue of potentially creating a subtle cross-talk between controllers, if the controller was designed under the assumption it would be getting a separate view just for its own use.

Is there a more elegant answer to this?