> > There are several (possibly orthogonal) points of view to consider when deciding
> > which path (Abi, wxWin, other) to take:
> >
> > [1] Native Look-and-Feel User Experience
> > [2] Insulating Programmers from Platform-/GUI-specific Coding
> > [3] Separating GUI-logic/code from Business-logic/code
> > [4] Feature/Bug consistency between platforms
[above saved for reference]
> Yes, OO people talk about Model-View-Controller architecture, but in
> reality frameworks forces you to put business logic in GUI logic
Hello,
why do you say this? MVC is a very nice thing, IMHO and allows to satisfy [3]
in a quite elegant way if it applies to your application.
> > My goals in building abi framework, were [1], [4], [3], and [2], and in that
> > order. That is, we were able to minimize platform code as a side-effect of
> > [3] and [4], but not eliminate it.
>
> Ah, I see. I wonder what are the priorities of GTK/GNOME or wxWin.
I'd say that for wxWin it's [1] (surely), [2] or [4] and [3] is the last. [3]
being the last doesn't mean that it's impossible to write the applications which
separate GUI from the logic with wxWin, but that the library doesn't force you
to do it (it might and may be this would be a good thing - but it probably never
won't because this, AFAIK, has never been a design point of it).
So it should come as no surprise that wxWin and ABI framework are quite
different because they have different design goals (although they do share
native look-and-feel goal and reject the "greatest common denominator"
principle).
Regards,
VZ