Re: GNOME Office list, and Sun/AbiWord
- From: Torsten Schulz <Torsten Schulz germany sun com>
- To: Martin Sevior <msevior mccubbin ph unimelb edu au>
- Cc: gnome-office-list gnome org, gnome-devel-list gnome org,gnome-hackers gnome org
- Subject: Re: GNOME Office list, and Sun/AbiWord
- Date: Thu, 31 Aug 2000 13:45:31 GMT
On 8/31/2000, 2:33:23 PM, Martin Sevior
<email@example.com> wrote regarding Re: GNOME Office list,
> On Thu, 31 Aug 2000, Torsten Schulz wrote:
> > StarOffice founds on a system abstraction layer, which is not based
> > 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
> > 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
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
] [Thread Prev