A
The world's
... Open Source,
... cross-platform,
... word processor!
two reactions
· Cool!
· Are you
whoops, wrong conference :-)
No, we're not.
But many people think we are...
"Portability is for canoes."
Jim McCarthy
Director, Program Management
Microsoft Visual C++
The design and implementation of cross-platform (XP) software is
Some people just port.
· Ick.
Others use a complete
· Commonly, designers attempt to provide a complete API layer which
In the AbiWord project, we:
· embrace the fact that platform-specific code is a
· adopt an architecture which helps us
· rather than an architecture which helps us
three familiar terms
GUI graphical user interface (pixels++)
QA quality assurance
CM configuration management (builds)
three less familiar ones
XP cross-platform
XAP cross-application
AP app-specific policy
1.
· complete platform insulation layer
(wxWindows, XVT, Java)
2.
· separate teams which loosely share code
(Internet Explorer, Spyglass Mosaic)
3.
· mix of shared and platform code with well-defined APIs in between
(AbiWord, Mozilla)
PROS:
· write & maintain less code
(faster development cycle)
· CM can usually be done once
FAQ:
· why not use wxWindows ??
CONS:
· performance, bloat
· lowest-common-denominator
· app usually ends up with non-native feel
· QA needs to be done N times. really!
· false sense of speed (tough problems get shifted to the end of the project cycle)
· bugs in the layer are
· platform GUI knowledge is no help
PROS:
· fast development cycle
(teams don't wait on each other)
· everything is native
(good performance, size, etc)
· each version takes full advantage of each platform's capabilities
CONS:
· development progress is uneven
· different app behavior on each platform
· bugs often must get fixed N times
· CM and build issues need to get done N times
· doesn't scale
GOAL:
· best of both worlds
· ultralight framework provides direct access to native GUI services
· the rest of the time we stay in XP code
THE TRICK:
· solve a few key problems, then stop
· abstraction is a means, not an end
PROS:
· all native
(good performance, no unusual bloat)
· app
· maximum use of shared code minimizes duplicated effort
CONS:
· people break the build
· overall development progress is slower
PRO:
· overall development progress is never deceiving
GOAL:
· >90% of the code we write is XP
first, some building blocks
· use existing libraries
· tree structure
· common build environment
· the donut rule
then, the design
~350,000 lines of code to build AbiWord
~45% of that is XP code we got "for free"
expat 9,438
ispell 5,812
libiconv 46,002
libpng 20,211
wv 60,907
zlib
156,169
coding standards (ANSI C) help a
some nodes of the tree are entirely XP
others are a mix of XP and platform code
IDEA:
· parallel makefiles are evil
SOLUTION:
· diving make system (picks right platform)
· use vanilla
· runs on all Unix flavors, plus BeOS
· via Cygwin, also runs on Win32
· Mac??
· FAQ: what about
GOAL:
· product
· developers can focus on adding features
· QA always has a working build to test
· problems show up earlier
(and thus are more likely to get fixed)
HOW?
· tools can help (Tinderbox)
developers on all platforms share:
· a single CVS repository
· a single build system
· so, impact of broken build is magnified
SOLUTION:
· stub any platforms you don't implement
· social engineering ... the donut rule
CONSTRAINTS:
· leverage developers' platform expertise (build a totally native application)
· do so with as much XP code as possible
· keep our sanity intact, more-or-less
KEY QUESTION:
· where do we draw the API boundaries?
GOAL:
· spend as much time as possible in XP code
BUT:
· need to get there first
· application launches in platform code
· GUI constantly sends platform events
· all output triggers platform calls, too
· we're surrounded!
· Events (
· Graphics (
· Utilities (
· Top-level framework (
NOTE
· each of these has XP and platform sides
HERESY !!
· advanced C++ features aren't portable
· Linus likes ANSI C, and so do we
BUT...
· ... if you're
· specify XP stuff as abstract C++ classes
· concrete, platform-specific subclasses
· also helps kill leaks (destructors)
fairly vanilla 2D graphics API
· Select fonts and colors
· Draw text, line, polyline, etc.
· Draw images
subclasses
·
·
·
·
printing is handled by appropriate subclass
GOAL: zero app-specific platform code for:
·
·
·
·
· all events are table-driven from XP code
BENEFITS:
· flexible keybindings (default, emacs, vi)
· easy localizations (including icons)
· zero work to keep platform UIs consistent
CONSTRAINTS:
· look totally native
(leverage common platform dialogs)
· minimize the amount of platform code
BE PRACTICAL:
· currently
·
· PRO: consistent look and feel
· CON: dialogs take longer to develop
single platform is the baseline
· a lot simpler to develop
· a lot faster to develop
our approach
· seems slower than other XP approaches
the results
· a
· a very high quality piece of software
the $64,000 question
· is the additional time investment worth it?
How practical has our approach been?
· quality of the product
· platforms supported
· executable size
· % XP code
· developer support
we ship binaries for
· Windows (95, 98, NT)
· Linux (Intel, PowerPC, Alpha)
· BeOS (Intel, PPC)
· FreeBSD (Intel)
· Solaris (Sparc)
in the works
· QNX/Photon
· MacOS (just started)
the usual suspects:
·
·
Open Source alternatives:
·
·
Q: how big is "Hello World" in
Overall, to get the framework running on a single platform, it takes about 26,000 lines of code (
16,684 9,272 64%
Here's where our approach really shines:
66,422 6,621 91%
very healthy Open Source project
· ~70 names in CREDITS.TXT
· many first-timers
· we wrote
go where the "GUI hackers" are
· pixel-twiddling is its own art form
·
over a dozen localizations
· including Indonesian and Catalan