>I will meet your challenge with another challenge: If a wxWindows
>port of AbiWord was completed and it functioned well, would the
>AbiWord group be willing to use wxWindows as its standard
>interface and move its porting efforts into wxWindows?
>
>Let's strike a deal. :)
>
>wxWindows developers: Anybody interested in tackling this
>challenge??? (see: http://www.abisource.com for more info)
No promises from me, but that's mostly because I don't feel
comfortable making this promise on behalf of the whole AbiWord
dev team.
I guess you could say that I "founded" the AbiWord project. For
a while, virtually all of the dev work was done by employees here
at our company.
However, it was always our vision that AbiWord would become a
community-developed project, like Apache or the Linux kernel.
That vision is becoming a reality. Individuals in the community
who are not employees of this company, have made very substantial
contributions to this project.
Consider Thomas Fletcher. He did the BeOS port. Switching whole-hog
to wxWindows would deprecate most of his hard work, and given the
status of wxWindows on BeOS now, it would be a step backward for
the BeOS version of AbiWord. Who has the authority to do this?
Me thinks no one.
Shaw Terwilliger. Unlike Thomas Fletcher, Shaw is an employee of
this company. However, he's done a lot of work on the GTK version
of AbiWord. Does Shaw *want* to see that work tossed in favor
of a wxWindows version? For example, Shaw's font chooser dialog
looks better than the one in wxGTK, IMO. Giving that up would be
no fun.
I don't think you'll find anyone who feels like they have the
"authority" to accept your challenge on behalf of the team.
If *I* don't feel like I have that authority, then I seriously
doubt anyone else does. :-)
However, this just means that you can go forward with probabilities
instead of guarantees. Build a port of wxAbiWord. If it worked
well, on Win32 and GTK, I would find it seriously tempting. We
would definitely need a BeOS port before the group would even
consider an 'official' switch. If a wxMAC port came along for the
ride, the issue becomes very compelling.
However, before you take these risks, consider the following issue:
Orienting our porting efforts around wxWindows would substantially
change the nature of community participation in the AbiWord
project.
Being native on each platform means that
we can recruit and attract developers who are experienced with
native development on their favorite platform. If the code base
were wxWindows-based, almost any new programmer on the team would
have to learn a new API for GUI work. (Granted, the API is similar
to stuff from the world of Win32, but it's not identical.)
Of course, the solution to these kinds of problems is to convince
talented GUI hackers to help work on the respective
platform ports of wxWindows itself. Go for it. Thomas Fletcher's
email address can certainly be found in the archives of this list.
Convince Thomas to work on wxBeOS instead of AbiWord. This would
be a nice boost for wxWindows on that platform.
However, though I will not speak for Thomas, I'm confident that
the motivations involved in choosing to work
on a word processor are different from the motivations to choose
to work on an XP class library. These projects attract a different
kind of developer.
(Likewise, why not put Shaw's cool font dialog right into wxGTK?)
Final disclaimer -- I find wxWindows really attractive. I would
love to be using it. I'm involved in the planning phase of a project
now in which we might use it. I would very much like to see it get more
widespread adoption in the Open Source community.
Eric W. Sink, Software Craftsman
eric@abisource.com