Re: GNOME Office list, and Sun/AbiWord

[Torsten Schulz <Torsten Schulz germany sun com>]

On 8/31/2000, 2:33:23 PM, Martin Sevior 
<msevior@mccubbin.ph.unimelb.edu.au> wrote regarding Re: GNOME Office list, 
and Sun/AbiWord:


> On Thu, 31 Aug 2000, Torsten Schulz wrote:
> >
> >
> >     StarOffice founds on a system abstraction layer, which is not based 
on
> > 3-rd party products but totally developed in house. It does consist of
> > several libraries encapsulating ui toolkits, file system, networking,
> > threading... It is not in the Swing tradition because it was developed
> > before SUN has had their hands on it.
> >
> >     We are thinking about moving to GTK, but one important requirement 
will
> > be a very good Windows port of GTK. Please keep in mind, that windows is
> > one of the main plattforms of StarOffice/OpenOffice and this will last
> > for more than the next year.

> Have you thought of, or can you sub-class your GUI/event handling/file
> system/networking to different target platforms? This is the approach Abi
> has taken and is the reason for its toolkit independence. This has the
> added benefit that each platform is a native application with native
> widgets, native look and feel and best possible speed. In an open source
> environment this works really well because you get developers interested
> in their own platforms doing a lot of the "localization" work. Abi has
> native ports to BeOS and QNX already. MacOS is in the works. A side
> benefit is good code because sloppy stuff gets picked up on different
> compilers.

	Our approach is to define a minimal set of functionality for each area 
of system abstraction layer (SAL) and implement this platform dependent. 
On top of this there are platform independent C++ libraries to 
encapsulate the minimal functionality in a handy way to the upper layers 
of StarOffice. E.g. the Visual Component Library (VCL) is one of these 
C++ libraries, hiding the platform specific UI functionality.

	The advantages are: less platform dependent code, the apps behave almost 
the same way on every platform, maintainability, ...

	The disadvantage is, that you can't provide platform specific widgets 
and look and feel, because the minimal set of functionality, defined in 
SAL, is very low level. This is why our last MAC version (4.0 or so) 
looks exact the same like all other ports. And this was disappointing to 
many MAC users.

	Sub classing and using platform specifics is not practicable with our 
current architecture. But perhaps OpenOffice will move totally to a new 
direction?

Torsten