LibreOffice, openSUSE y KDE

Un poco de historia

OOo, y así también todos sus derivados, tiene una interfaz gráfica basada en librerías GTK y(1) VCL. Dado que KDE usa las librerías Qt, esto ha dado siempre problemas a los usuarios de este entorno de escritorio.
VCL, que es la encargada de crear todos los menús y demás partes gráficas de la interfaz de OOo/LibO, por otra parte permite crear «plug-ins» para conectarse con distintas librerías como GTK o Qt.
Go-oo, la primera de las variantes de OOo, incluía un código para integrar la interfaz con KDE 3.x, el cual funcionaba bastante bien, haciendo no solo que go-oo respetara el tema de escritorio elegido, sino también ofreciendo los menú para leer/salvar archivos propios del escritorio.

La situación actual

Con el paso a KDE 4, el plug-in existente para KDE 3 no es ya de utilidad. go-oo (y OOo/LibO a partir de la versión 3.3) incluía el código para un plug-in de VCL que en principio sirve para KDE 4, código que fue heredado por LibO.
La pequeña diferencia entre los tres proyectos es que ni OOo ni LibO habilitan ese código en la versión que distribuyen, el cual siempre fue utilizado por defecto en go-oo y ahora en la versión de LibO que viene con openSUSE.
¿La razón para no habilitarlo? Este plug-in para KDE 4 nunca funcionó bien.
Si bien ya quedaron atrás la mayor parte de los enormes problemas que surgieron cuando fue introducido (por ejemplo, archivos de cero bits donde todo el contenido se perdía, partes de la interfaz que desaparecían, no permitiendo acceder a su contenido...), la experiencia de utilizar este plug-in sigue sin ser óptima: la interfaz se repinta constantemente cada vez que se cambia un menú, lentitudes grandes que surgen aleatoriamente, problemas con algunas extensiones, no respeta el estilo elegido... varias cosas que podrían hacer desistir de su uso.

El dilema

Los diálogos nativos de OOo/LibO para leer/salvar archivos son ciertamente lamentables, hay que admitirlo: no permiten establecer marcadores, están mal diseñados... Habilitar el plug-in de KDE 4 permite utilizar los magníficos diálogos nativos de este escritorio... al precio de soportar continuos problemas gráficos y un aspecto terrible de la aplicación.
Por otra parte, al deshabilitar el plug-in y si se utiliza un estilo como qtcurve u Oxygen que aplique a programas basados en GTK, la aplicación funciona fluidamente respetando el aspecto elegido para las aplicaciones nativas... al precio de perder los diálogos para abrir/salvar archivos.
Yo por mi parte paso mucho más tiempo viendo (y usando...) la aplicación que abriendo o salvando archivos. De hecho, para abrir un archivo uso siempre krunner/dolphin/folderview y NUNCA los diálogos de Abrir → Archivo, mientras que salvar un archivo nuevo lo hago solo cada tanto...
¿Integración para abrir/guardar archivos o integración gráfica?
Pues yo he elegido lo segundo.

La solución

Desgraciadamente, en openSUSE desinstalar los paquetes libreoffice-kde y libreoffice-kde4 no es suficiente ya que la librería VCL que sirve de integración con kde se encuentra en un paquete que no puede ser desinstalado sin quebrar completamente el programa.
Luego de desinstalar los paquetes mencionados, es suficiente abrir konsole y pasando a administrador con «su» escribir lo siguiente (mi sistema es de 64 bits) para eliminar completamente la molesta (des)integración:

¡¡¡Importante!!! El comando rm es sumamente peligroso, sobre todo si usado como administrador (borra lo que se le pide sin preguntar), por lo que úselo con responsabilidad... y bajo su propio riesgo...

rm /usr/lib64/libreoffice/basis-link/program/libvclplug_kde4lx.so rm /usr/lib64/libreoffice/basis-link/program/libvclplug_kdelx.so

He creado una entrada en openFATE para pedir una simplificación de este proceso, pero no parece ser muy popular... :(
Move libvclplug_kde4lx.so library to libreoffice-kde4 package


(1)  Edito (13/05/2011): LibO (u OOo) no depende de las librerías GTK, solo se conecta con ellas... y con Qt. De hecho, el plugin VCL para Qt ha mejorado enormemente en las últimas versiones de prueba de 3.4 por lo que el proceso comentado aquí seguramente no será necesario cuando 3.4 esté disponible.