Re: GNOME Office list, and Sun/AbiWord

[Joaquín Cuenca Abela <cuenca celium net>]

> 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, ...

In Abi we take the same path, at a smaller scale.
The idea is to have a XP class per dialog (which does all the logic
work) and a PD class per dialog/toolkit that shows the actual GUI.
The problem is that we touch the PD code too soon, and we finish redoing
the same dialog box 4 times (one time per supported toolkit).

The advantages are the disadvantages of your method (we provide platform
specific widgets and look and feel), and the advantages of your method
are our disadvantages (we have too many platform dependent code for the
GUI, ...).

If we use a gtk+ version with a good windows/MacOS/BeOS/QNX wrapper, and
a set of themes with the look of the windows/BeOS/QNX/MacOS toolkit, our
problems would be nearly over.

What do you think?

P.S.: Anybody knows if there is a plan to port gnome (specially bonobo)
to others platforms?  Miguel thinks that it's a "two hours work", but I
would sleep better if somebody boots in a windows machine, sit down and
port gnome to windows.
P.S.2: What to do with the non-GUI PD code (net code, etc.)?  Could we
insert it in glib?

-- 
Joaquín Cuenca Abela
e-mail: cuenca@celium.net