(snip... down to the meat)
> So in summary we now have several approach:
>
> 1. Full AbiSource approach
My goal of using wxWin is that I really not intrested in developing a API
from scratch like you have done. It seems that we have lost a potiential
pooling of intrest here. Anyhow, I have several platforms that wxWindows
does support, such BeOS, QT/KDE and QNX.
I know that some of these are under development or planned for wxWindow. At
the worst case I can grab wxWindows and build a port off the existing code.
I sure I can do that with XP, but it does seem that you are promoting this
very much on the web site. So, I would be less likely to use this approach,
because there is so little document on it. This reminds me of XUL on the
Mozilla site. Sounds great, looks good, but without some documents and
sample code I'm going to work wxWindows.
Sure I can get AbiWord and pull everthing apart. Plus, I'm sure that you
would love to help, but I doubt our project is your priority, etc.
> 2. Integrate {wxWin|GNOME} as an AbiSuite platform, but still use Abi
> approach in general
Same as above
> 3. Port AbiWord in full to {wxWin|GNOME}, and branch out totally to
> {wxWin|GNOME}-based office suite
This is the most intresting for me. I clearlly want to see a test case of
wxWindows. This will make me feel more comfortable. I would also try to
help, but I must say that my C++ programming skill are a bit rusty. We can
also use this a learning process for wxWindows 3.0
> 4. And there is still the unknown of the imminent opening of the
> StarOffice code, which is also XP...
If you belive that Sun is going to Open Source StarOffice under anything,
but the evil SCSL you got another think comming. SCSL is NOT Open Source! If
you like to learn more about this topic just look at
http://www.upside.com/texis/mvm/richard_brandt?id=380f44bb0, which is
excellent series of articles on Sun and AOL about OSS.