Great! We're looking forward to working with you. :-)
>* wxWin vs. AbiSource framework
>
>At first we wondered why AbiSource didn't use wxWin, since in our
>initial research we found that first and thought it would be perfect,
>but after reading the long discussion on the list regarding the
>matter, it has cleared some of that confusion. As a result, we are
>strongly considering taking up the challenge of porting AbiWord to
>wxWin. I particularly do not think it is too late yet; in terms of
>AbiWord, maybe yes, but in terms of the whole suite (spreadsheet,
>presentation, database etc) it is still quite early.
Unlike Eric, I haven't reinvestigated wxWindows in the last year, so perhaps
his optimism is well-founded. Having someone attempt a full-bore wxWindows
port of AbiWord would be a *great* proof-of-concept, and I'd be very
interested to see how the final results compare to the existing "native"
versions.
Call me perverse, but I'd love to have my innate pessimism about
grand-unified-GUI-toolkits finally be proven wrong. That's a bet I expect
to win, but would be quite happy to lose. :-)
>Another reason
>is that wxWin is more documented that Abi framework, and the approach
>is more cleaner, in our opinion, in terms of ratio of XP and non-XP
>code (that is, we were surprised at the amount of /win and /unix code
>as compared to /xp code on the src tree).
Before you write off the Abi framework (abi/src/af/*), I'd encourage you to
take a closer look.
You're right that there's a lot of platform code in the framework, but...
... that's where it belongs!
It's our belief that the code there is essentially done. Jeff tried hard to
make sure that the work there could be done once, and then be immediately
leverageable to other applications. For example, now that we've written the
platform-specific glue code for toolbars, almost all app-specific logic for
the contents and behaviors of those toolbars are handled in XP code. Ditto
for menus, timers, keybindings, keyboard events, and drawing.
The one place where we're still doing more platform work than we'd like is
in the dialogs, but even there we're trying hard to do as much work in XP
code as feasible. (For example, see the current implementations of the
Paragraph dialog.) So far, it's seemed like the effort required to wrap all
the advanced widget types behind APIs like those in af/ev, af/gr, and af/xap
just wasn't worth the trouble. We'd prefer a solution which came closer to
what we've got with toolbars and menus, but haven't come up with one yet.
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.
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.
Paul