Juha Nieminen <nospam@thanks.invalid> kirjutas:

>
> 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.
>

FYI: in our company, we are currently kind of experimenting with a
decoupled GUI-intensive design. The GUI is done by C# programmers and is
supposed to look very shiny and "professional". However, the C#
programmers don't have any glue (and should not) about *what* to display
on the interface. All display content is provided in an "abstract" XML
format from another (C++) background process (possibly on another
computer). Most user interactions (like dragging a gamma correction
scrollbar button) are sent back to the background process, which
prepares new content and notifies the GUI process about the changes in
the displayed content.

Yes, this is a lot of work, and I'm not so convinced it finally pays
off. The reasons for adopting this scheme were more company-political
than technical. However, having a clean separation layer between the
functionality and user interface seems to be a good thing to have. The
project is in the middle so I cannot say yet how it actually works out.

Paavo