Consecuencias de Bonobo a la hora de desarrollar

Si para el usuario el uso de componentes facilita enormemente el trabajo, desde el punto de vista del programador, esto no es menos cierto. De hecho, el uso de componentes software ya existentes permite el desarrollo de aplicaciones muy potentes en horas, al simplemente tener que añadir la funcionalidad extra que se desea. Y la sinergia que surge entre la libertad del software libre y la reutilización de los componentes va a provocar que la productividad de los desarrolladores de software libre sea muy superior a la lograda actualmente con modelos de software cerrado.

También es especialmente útil a la hora de desarrollar aplicaciones muy complejas, pues se puede dividir el trabajo en distintos componentes independientes (cada uno de ellos desarrollado por un programador o equipo de programadores) y luego hacer que se comuniquen entre sí por medio de los interfaces Bonobo. De esta forma se están desarrollando, por ejemplo, el nuevo gestor de ficheros de GNOME, llamado Nautilus, y Evolution, el lector de correo, calendario y demás herramientas para trabajo en grupo. Aún no se tienen datos y experiencias de como ha ayudado Bonobo en la velocidad de desarrollo pero seguro que cuando se analice, los datos serán muy buenos. Y sobretodo en los proyectos venideros, cuando ya tendrán una importante base de componentes gracias a Evolution y Nautilus, y Sodipodi y ...

Otra ventaja a la hora de desarrollar con Bonobo, aunque ésta está más bien ligada al uso de CORBA que al de Bonobo, es el evitar el uso de protocolos de comunicaciones entre los componentes. El programador sólo tiene que centrarse en la implementación de los métodos en el componente, y de su acceso desde la aplicación que hace uso de él, sin necesidad de conocer el protocolo que se utiliza para la comunicación entre las distintas partes. Esto evita horas y horas de desarrollo. Aún recuerdo a algún compañero de trabajo con su hoja de papel definiendo el formato de los paquetes de intercambio de datos, los estados de la comunicación ... algo horrible de hacer, poco creativo y muy propenso a errores.

Mirando más a fondo las librerías de Bonobo en GNOME, podremos observar que los desarrolladores de Bonobo (Miguel de Icaza, Nat Friedman, Michael Meeks y muchos otros) han puesto especial énfasis en hacer un API fácil de usar. Esto va a hacer que el número de componentes Bonobo se dispare en cuanto éste sea oficialmente liberado (que, si no hay retrasos en los planes del equipo de GNOME, será a finales de verano, con motivo de la salida de GNOME 2.0), lo que va a significar, sin ninguna duda, la salida de aplicaciones cada vez más potentes y fáciles de usar. Ya existen varias aplicaciones haciendo uso extensivo de Bonobo, como Nautilus (el nuevo gestor de ficheros de GNOME, aún en desarrollo), Gnumeric (hoja de cálculo que permite insertar gráficos y demás detalles visuales desde otras aplicaciones), Evolution (lector de correo con capacidades de trabajo en grupo: calendario, agenda compartida...), GNOME-DB (acceso a distintas bases de datos), Glade (diseñador visual de pantallas), Sodipodi (gráficos vectoriales), y otras, pero la explosión de aplicaciones usando Bonobo está por llegar.

Así, se ha intentado evitar que los programadores que usen las librerías de Bonobo tengan que usar directamente el código generado por ORBIt (la implementación de CORBA usada por el proyecto GNOME), lo que se agradece enormemente, pues no es nada trivial el uso del mismo. De esta forma, es posible implementar un control Bonobo en minutos, come veremos luego en la parte práctica del artículo, o un contenedor capaz de embeber cualquier componente en apenas un par de horas. Otros aspectos, como los componentes "empotrables" o los 'monikers' son algo más complicados de implementar, aunque no debemos olvidar en ningún momento que estamos hablando de un sistema muy potente, por lo que la dificultad en alguno de sus aspectos no debe echarnos para atrás. De hecho, tampoco es que sea muy complicada la implementación de estos aspectos, pero si es cierto que requieren de una comprensión completa de los aspectos más básicos.

Y para aquellos que os guste programa en otros lenguajes como Perl y Python ir preparando bien vuestras neuronas. La arquitectura Bonobo facilita que si, tienes un ORB en tu lenguaje preferido, vas a poder utilizar este lenguaje para programar toda la arquitectura Bonono.

Para conseguir esta facilidad de uso, se han creado distintos objetos GTK (GTK es la librería en la que está basada GNOME, y que implementa un sistema de objetos) para encapsular cada uno de los interfaces IDL de Bonobo. Esta implementación orientada a objetos permite, aparte de un uso e implementación sencillos de los componentes, la extensión de componentes ya existentes mediante el uso de herencia (como en C++). El sistema de objetos de GTK define una serie de propiedades (atributos o variables) y de señales (métodos virtuales) mediante los cuales las aplicaciones interactúan con dichos objetos.

A partir de este momento nos vamos a volcar en la implementación de Bonobo, revelando los detalles técnicos en los que se sustenta la arquitectura y dando ejemplos de el uso real de Bonobo en un gran proyecto como en "gnome-db".