Juha Nieminen <nospam@thanks.invalid> writes:
>simple reason that it's good OOD), but trying to abstract away the
>non-standard GUI library completely from your program is usually more

This usually will not work, because the GUI library often uses
callbacks or acts as a framework and by this it enforces a
specific structure of the high level code of the application,
and different GUI libraries indeed have different APIs,
because.

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.

What is left over is a program that solely consists of UI
related parts (view and controller). This might be a text
console UI or a GUI. Now, this UI needs to be written for
every type of UI library used: For example, once for a console
library, once for GTK, once for WxWidgets, and so on. It is
the rest that cannot be abstract from the UI, because
everything else already has been stashed away in the model or
a non-UI-related library.

What is won by this approach is that the code for the model
and in the non-UI-related library does not have to be changed,
when writing the controller and view for a annother UI.