Stefan Ram wrote:
> Separation still is possible, but just the other way around:
> You abstract away every part of your program that is not
> directly related to the user interface - but »abstract« now
> is the wrong verb: You stash it away in a »model« and a
> non-UI-related library to the maximum extend possible.

This is a good design, but possible (or, more precisely, feasible)
only if the core code of your program is not heavily dependent on the
GUI itself.

I have used this design myself many times. The typical situation is a
program which reads some input data, performs some lengthy and heavy
calculations/processing on it, and outputs the results to a file. The
core implementation (including I/O and the calculations) is easy to put
into its own separate module, and then it's easy to create a
command-line interface as well as a GUI application (using whichever
library) which uses this module in question. (Perhaps the thing which
needs the most careful design is how to pass the user-defined options
from the UI to the module.)

However, not all programs are like that. Many programs require, for
example, user input in real-time (such as mouse and keyboard events),
drawing things on screen, update some GUI elements (such as the value of
some spinbutton) and other such GUI-dependent functionalities. This is
where abstracting the core code from the GUI becomes laborious, if not
outright unfeasible.