On Jun 29, 6:04 pm, r...@zedat.fu-berlin.de (Stefan Ram) wrote:
> Juha Nieminen <nos...@thanks.invalid> writes:
> >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.

> In this case, the UI-dependent part of the program is large
> and the UI-independent part of the program is small or missing.
> Sometimes it happens to be this way, and then a port to another
> GUI library will nearly be a complete rewrite. I do not see
> any other solution for this case than to live (cope) with it.

> A indication of such a type of program might be that it can
> not be ported to some kinds of environment at all. For example,
> when the definition of a program includes »drawing with the
> mouse«, it will not be possible to port it to a keyboard
> interface by its definition.

This sounds like the old lightweight client vs. heavyweight
client dicotomy. Looking at the larger picture: at least in
business applications (but also in some of the process control
work I've done as well), there is a large body of "business
logic" (or application logic, if the application isn't
business), which can (and definitely should) be completely
separated from the GUI. In the lightweight client model, it is
so completely separated that it runs in a different program,
often on a different system. In which case, of course, the
client is almost pure GUI.

Regardless of where it is located, I would keep this business
logic completely separate from the GUI. In most cases, the GUI
itself will use some variant of MVC, in which the "model" serves
as a bridge between the GUI and the business logic (and doesn't
implement any of the business logic itself). (It's not all that
unreasonble to have the business logic run in a separate
process, even if it is on the same machine.)

--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34