The current Abi framework is quite cool. Don't write it off too
quickly. Furthermore, even a wxWindows port will need to leverage a
fair amount of the existing framework, for things like keybindings.
Tossing the current framework will waste LOTS of time. The way to
approach a wx version is to rewrite the Win32 portions of the tree
using the wx APIs. In this sense, the current XP architecture makes
things much easier, since you know exactly what portions of the tree
require your attention.
I'm still pretty darn skeptical about wxWindows for an app like
AbiWord. It's true that I have reinvestigated wxWindows, and I like
what I see. However, AbiWord places really huge demands on its
underlying GUI APIs. I'll be shocked if wxWindows can handle
AbiWord's needs without at least some code changes to itself.
Most of my encouragement toward the development of a wxWindows version
of AbiWord arises from my *hope* that it could work out nicely. To
get everything working in a top-notch manner may require some
substantial level of work on wxWindows, but both projects would
benefit from the effort. This would be a Good Thing.
Nonetheless, until wxAbiWord exists and looks as good as the native
Win32 and GTK versions, some healthy skepticism is quite sensible.
--> 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
-- Eric W. Sink, Software Craftsman SourceGear Corporation eric@sourcegear.com