[Upstream] [hardy] GTK+ integration is less than ideal

[David Prieto]

Binary package hint: openoffice.org

This bug is related to this Ubuntuforums thread: http://ubuntuforums.org/showthread.php?t=715877

GTK integration in OOo has some flaws that make using it on a Gnome environment less satisfying than it could be. After seeing how good work Mozilla has done at making Firefox look like a normal GTK app, couldn't something similar be done with OOo? Can't we learn something from how they've managed to get such fine results?

[zanonmark (info-marcozanon)]

I know that this report is quite silly, because it's too "general", but...

Is it possible, in the future, to port OpenOffice to use GTK+ or, even better, wxWindows?
This would allow to have a multiplatform suite (every Win; GTK Linux; every Mac; more to come, maybe BeOS?) by writing a class-based amount of code, and also to integrate more the suite with the Gnome world, which Sun likes a lot... :)
Also, is there any rumour about splitting OpenOffice in multiple applications, for speed reasons?

Thanks :)

[Stefan-baltzer (stefan-baltzer)]

Reassigned to Bettina.

[Bernd-eilers (bernd-eilers)]

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.

[David Prieto (frandavid100-gmail)]

It doesn't use theme icons. Sure, it uses a theme that is supposed to resemble tango icons, but still... they're not the ones you choose. Firefox lets you do that. Besides, some of them look so fuzzy, just take a look at "new" and "open".

[David Prieto (frandavid100-gmail)]

Pressed buttons do not look like normal GTK pressed buttons.

[David Prieto (frandavid100-gmail)]

Fonts are not antialiased. The menu arrows do not follow the theme.

[David Prieto (frandavid100-gmail)]

The arrows at the end of the scrollbars do not look like normal GTK ones; dropdown boxes have a weird shadow to them as well as not being very responsive. To top it off, stuff like dropdown boxes or tooltips tend to "flicker", I don't know if you may have noticed. Even buttons flicker when you hover over them.

[Gert Kulyk (gkulyk)]

Though I fully agree with your claim for better gtk/gnome integration, I don't think this is something that can be "fixed" in ubuntu. It is an issue that has definitly to be solved upstream.

The font-issue eventually will be solved soon, switching to cairo-text-rendering (LP #197622). Fedora has done some aditional work on gtk-integration, e.g. patching ooo to use gtk-print. I'm not using Fedora, but looking at their cvs-patch-repro it seems like these additional changes are breaking kde-integration, which would result in a lot of complaints from the people using kde if ubuntu would use these patches.

The other things are not trivial to be implemented - e.g. have you ever looked at the structure of the icon-themes shipped with openoffice.org? Of course it would be nice to have the same theme that is used for the rest of the desktop, but there has to be changed a lot of code for implementing something like that, and this additionally has to work for different toolkits (on Linux this is plain X, GTK, QT) on different platforms (Win, Linux, *BSD, Solaris, Mac) to be accepted upstream. And this has to be done upstream, because maintaining patches with such an impact on the overall code-base is not possible.

[kripken (kripkenstein)]

I agree with Gert that this is an issue for upstream. But anyhow, as we are already discussing it, here are my conclusions after reading some stuff there, specifically,

http://www.openoffice.org/servlets/BrowseList?list=discuss&by=thread&from=120242
http://ui.openoffice.org/issues/show_bug.cgi?id=9304

Instead of a wrapper around native widget toolkits for each platform, they wrap around calls to lower-level drawing routines (this is called VCL). I'm not sure I fully grasp why they see this as better. It seems that the main advantage is that to add a new platform one needs to only wrap a few low-level drawing routines, instead of a large number of widget-level stuff. This seems peculiar since there are only say 5 main environments to support. But perhaps they are concerned about new platforms appearing.

[Ace-dent-a (ace-dent-a)]

OpenOffice.org Issue Tracker - Feedback Request.

The Issue you raised is currently 'Unconfirmed' pending review, but has not been
updated within the last 3 years. Please consider re-testing with one of the
latest versions of OOo, as the problem(s) may have already been addressed.
Either use the recent stable version: http://download.openoffice.org/index.html
or consider trying the new OOo 3 BETA (still in testing):
http://download.openoffice.org/3.0beta/

Please report back the outcome so this Issue may be Closed or Progressed as
necessary - otherwise it may be Resolved as Invalid in the future. You may also
wish to search for (and note) any duplicates of this Issue that may have
advanced further by checking the Issue Tracker:
http://www.openoffice.org/issues/query.cgi

Many thanks,
Andrew

Cleaning-up and Closing old Issues as part of:
~ The Grand Bug Squash, pre v3 ~
http://marketing.openoffice.org/3.0/announcementbeta.html

[Bettina-haberer (bettina-haberer)]

To grep the issues easier via "requirements" I put the issues currently lying on
my owner to the owner "requirements".

[Robert Roth (evfool)]

There was some progress on this, the issues described in comment 4 seem to be gone, except the weird dropdown box shadow. The scrollbars do look as the native ones, no flickering buttons and tooltips for me using Maverick and OO.o 3.2.1.

[Björn Michaelsen (bjoern-michaelsen)]

[This is an automated message.]
There are no new official OpenOffice.org releases in Ubuntu packaging anymore => Won't Fix

If the problem persists, please mark this bug as "also affects project Libreoffice" or "also affects distribution Libreoffice (Ubuntu)" if that has not happened already.

Please leave references to upstream OpenOffice.org bugs in place to allow cross pollination.

[OOoForum (oooforum)]

.