Comment 11 for bug 199437

zanonmark: Please try to use one issue per bug or request for enhancment in
the future and not one for two or more.

First of all it´s a just a very common prejustice that having only one
executable would be a bad thing and that anything (speed, less code size,
etc.) could be gained by "splitting" into multiple applications. The contrary
is the case. All modern Operating systems do support the concept of shared
libraries (.dll files on windows .so files on Linux/Solaris, .dynlib files on
Mac, ...). And all those modern OS´s support some method to load such shared
libraries on demand only. OpenOffice.org makes heavily use of that feature.
There is really not much code in the executable itself and what is there is
needed by all OOo application modules. Most of the real stuff is in the shared
libraries and that code is either module specific (for example the sc*.so file
on Linux contains Calc specific stuff only and is not in memmory when you edit
a text document) or is code that can be shared between modules. OOo source
code is highly modularized and constant work is being done on improving that
modularisation ( there currently is a "dialogdiet" effort for example ). If on
the contrary you would totatally split up things and develop individual
applications only independed of each other without carrying about wether there
are things can be programmed once and shared (like accessing configuration for
example) you would end up with bigger total memmory use, decreased speed etc.

On the using GTK+ or wxwindows topic: That or a similar 'idea' is popping up
every other week on the <email address hidden> mailinglist, see the archives
of that mailinglist for lot´s of details.

OOo already has a cross plattform UI library called VCL that has a very small
platform specific layer (that means there is not very much to port for
supporting a new platform) and OOo has a cross platform UI toolkit based on
that. Replacing every UI code in every application module and shared UI
library with something completly different would require hughe/heavily changes
and would be an nearly impossible effort to do.

What is planned for OOo 2.0 is to integrate something into the existing UI
layer that has the effect that widgets would at least look like
GTK/QT/WindowsXP/... widgets and would adapt to the current UI scheme used for
those "native" UI toolkits. What is also already planned for OOo 2.0 is
improved Desktop integration for GNOME and Windows. See gsl.openoffice.org and
http://tools.openoffice.org/releases/q-concept.html on those topics.

What is in discussion for future OOo versions is some kind of new UI toolkit
layer that would be similar to the current one from the application module
programming level but would make it possible to plug in "native" toolkits like
GTK+, wxwindows, Windows UI libraries, etc. on a lower abstraction level. For
kde integration there is an incubator project http://kde.openoffice.org/ that
might use this technic in the future among doing other things now and there
are also already developers that work on GTK/GNOME specific things.