Anyway, as the guy who wrote the abi framework, I guess I have to comment
[and hopefully without getting defensive of my baby :-]
There are a lot of good points here -- I think this is a case of more than
one right answer where each has ***good*** engineering goals/qualities.
As I've said before on this list, we evaluated wxWindows in the july-august 1998
time-frame -- it wasn't ready for our needs, but it has (from what i've heard)
come a long way since -- if we were starting the project today, we might proceed
differently.
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
Paul makes an excellent (but subtle (sorry Paul)) suggestion/challenge that
to-date the frameworks that supply [2] generally fail at [1]. Perhaps wxWindows
will be the one that succeeds at this -- I haven't studied it recently, so
someone else will have to comment here.
How many of us have seen and *puked at* applications that use some form of
GUI-layer translator/emulator and let you "port your Win32 application to unix
and have it look exactly like it does on win32" -- or vice versa -- the
resulting app (often) works, but it just doesn't feel/look right. or they are
bloated and sluggish. [i'm not going to name any names here :-] Or worse,
how many GUI kits force you to neuter your application by only giving you the
intersection of features available on all the platforms they support.
On the other hand, multi-platform projects that emphasize [1] without regard
for [2] (ie, have multiple teams working in parallel with (dis)functional
coordination), generally get what they deserve -- a lot of feature variance and
other suble differences that make documention and QA more difficult and the
end-user experience more frustrating. This is Item [4].
The significance of item [3] should not be overlooked -- whenever possible,
all business-logic should be in XP code -- this is frequently hard to do right
and contrary to the way we were taught GUI programming (where you put the
code in the XEvent callback, the WM_ message case, or the MFC onMessage
function) -- it's not conceptually difficult, but just not the *generally
accepted way* of doing it. [even with a good foundation, we failed to do this
properly on the Zoom dialog, but have succeeded on the Paragraph dialog
(i'll follow up in different note, if someone's curious).]
In building AbiWord, we chose to "roll our own" framework so that we could
leverage it in the other apps that we have planned for the suite. (But then
we may revisit this issue each time we start another one.)
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.
I think we've done a pretty good job of meeting our goals. Yes, there is a
good deal of platform-specific knowledge required -- but we've already
done most of the work. Dialogs constitute the bulk of the things remaining
for AbiWord. Using the framework for another application requires cloning
the abi/src/wp/ap tree and rebuilding XP data-tables (for menus, toolbars,
strings, keybindings, etc) and business logic and the platform-specific code for
creating the widget hierarchy of the document window (rulers, scrollbars, view,
etc) and some other class-munging. and, of course, some dialogs.
To be fair, there are a lot of good things about the framework we have and
there are some things which are not so good (things you'd do differently the
second time around) and things which are a hack (an out-of-place method
or method-argument that had to be added to get out of a bind rather than
redesign some class at 3am). But on the whole, it works and serves us well.
In regards to your earlier comments:
On Sat, 23 Oct 1999, Perry Ismangil wrote:
> On 22 Oct 99, at 19:14, the honourable Paul Rohr wrote this about wxWin vs. AbiSource framework:
> > Before you write off the Abi framework (abi/src/af/*), I'd encourage you to
> > take a closer look.
>
> Which we are doing so right now, in several ways, such as *printing*
> it, running it through an analyzer, etc.
>
> > Most importantly, though, we're *very* happy with the fact that the *entire*
> > guts of AbiWord (abi/src/text/*) happens in XP code, as does most of the
> > app-specific logic (abi/src/wp/*). Even with "all" that platform-specific
> > dialog code, the ratios of code in wp/xp vs wp/win (or wp/unix or wp/beos)
> > are approximately 8 to 1. That's still amazing.
>
> We noticed that too. It's true that for the application logic itself
> is nicely wrapped in XP. It's just the approach you took kind of
> overwhelmed us, when we found that for exapmle the main frame of an
> application directly call gtk/win32 API. Other XP framework would
> hide that in the libraries.
Part of this is an artifact of the naming scheme we chose for the class
hierarchies. We put the platform name in the class -- this gives us unique
function names in LXR and makes it easy to see the line between platform
and XP code, but does force an explicit branch to platform code. For example,
we have an abstract GR_Graphics class, from which the GR_Win32Graphics and
GR_UnixGraphics classes are derrived. All the methods are virtual, but
because of the naming, platform code has to call the constructor even though
all the drawing happens in XP code using the base class definition and the
virtual methods. Often you'll see nearly identical blocks of platform code,
with platform class names being the only difference. Had we gone with a
different naming scheme, we could probably have simplified some things (at the
expense of a little confusion in LXR) and hide the multiple implementations
with linker/Makefile tricks.
> So we feel that to learn/use the Abi XP framework we need to know GTK
> too, as opposed it being hidden somewhere. This is apparent whe one
> of our staff, who is familiar with GUIs in general but not GTK or
> Win32 specific, tried to abstract the framework to write a Hello
> program, hit an obstacle when in the first two functions, Main and
> Frame, found gtk_* calls.
yes, but it was never our point to hide it.
> Please note that I am not slamming or looking down at this approach.
> I am just pointing out a point of view of someone who is not entirely
> familiar with platform-specific GUI APIs, and hoping to be hidden
> from it by using XP frameworks.
no offense taken. these are valid questions & issues.
> > It's our belief that you could rapidly bring up the shell of another app
> > using the current framework. We haven't spent time documenting this stuff
> > yet, primarily because up until now, there was no interest in using it. If
> > you're seriously interested in evaluating the framework, let us know. I'm
> > sure Jeff would be happy to explain things for you.
>
> This would be great. We can probably even help you document it, if we
> can find a gullible student to take it up as a final project or
> something :)
>
> For starters, we could try to write a 'minimal' Abi-style app (the
> classic 'Hello World'), and grow from there.
Yes, that would be great. We started an "AbiHello" app about a 6 months to a
year ago to provide that very thing, but never had time to finish it. In the
source tree is abi/src/hello -- the "Hello-specific" portions corresponding to
abi/src/wp -- the WordProcessor-specific portions of the tree. This is
terribly out of date, and should probably just be deleted from the tree, but
you may find it useful.
One of the problems I've had on this project is that the "Framework" was in
some sense a "secondary" project. That is, we're writing AbiWord -- a word
processor. The end-user doesn't care about frameworks and shared code leverage
and engineering mumbo-jumbo; the end-user wants bullet lists and tables and
infinite undo/redo and spell-checking and to be able to import MSWord documents
and have it all on whichever platform they happen to own. Consequently, we've
never had the chance to build a framework and then use it for AbiWord; rather,
we've built AbiWord and have isolated things which have nothing to do with
a word processor in a way that (we project) will be useful for other
applications.
> I have also been contacted by GNOME people, offering yet still
> another approach: use GTK only API, and port GNOME to Win32. As for
> GNOME, the story is quite similar to your founding with wxWin. We
> didn't consider GNOME because we thought it was too platform-
> specific. But since one of the GNOME developers assured me it would
> be 'quite easy' to port GNOME to Win32, this brings a different light
> into the picture
All of these are possible -- it just depends upon your priorities and goals
as I've explained earlier. I know GTK and Win32 and you've seen our
results (and with the help of some very great volunteers, you can see the
BeOS version now and hopefully sometime soon the Mac version). As for the
other approaches, I haven't yet seen them and can only speculate....
sorry to be so long winded,
jeff