Todas las aplicaciones que incluyen componentes instalan, en el directorio $prefix/lib/bonobo/servers (donde $prefix es el prefijo de instalación de GNOME), una serie de ficheros, con extensión .server, que tienen un cometido muy parecido al de los ficheros .gnorba en libgnorba. La diferencia es que en bonobo-activation se han resuelto los problemas de extensibilidad que tenía libgnorba.

bonobo-activation mantiene un área dentro del sistema de ficheros, en la que se almacenan unos ficheros en los que se especifican las propiedades de cada componente instalado. Este área suele estar en $prefix/lib/bonobo/servers, donde $prefix es el prefijo de instalación de bonobo-activation, que puede saberse mediante la ejecución del siguiente comando:

      pkg-config --variable=prefix bonobo-activation-2.0
    

Si tenemos bonobo-activation bien instalado, este comando nos mostrará por pantalla el directorio usado para la instalación de bonobo-activation. En mi caso:

      $ pkg-config --variable=prefix bonobo-activation-2.0
      /gnome/head/INSTALL
    

En ese directorio (en mi caso, /gnome/head/INSTALL/lib/bonobo/servers) se almacenan unos ficheros con extensión .server. Antes de seguir con la explicación, veamos un ejemplo de fichero .server, que necesitamos instalar en ese directorio para que bonobo-activation/Bonobo sepan que hemos instalado un nuevo componente.

      <oaf_info>
      <oaf_server iid="OAFIID:GNOME_MiCalculadora_ControlFactory"
      type="exe"
      location="control-calculadora">
      <oaf_attribute name="repo_ids" type="stringv">
      <item value="IDL:GNOME/GenericFactory:1.0">
      </oaf_attribute>
      <oaf_attribute name="description" type="string"
      value="Factoría para crear controles MiCalculadora"/>
      </oaf_server>

      <oaf_server iid="OAFIID:GNOME_MiCalculadora"
      type="factory"
      location="OAFIID:GNOME_MiCalculadora_ControlFactory">
      <oaf_attribute name="repo_ids" type="stringv">
      <item value="IDL:Bonobo/Control:1.0"/>
      <item value="IDL:Bonobo/Unknown:1.0"/>
      </oaf_attribute>
      <oaf_attribute name="description" type="string"
      value="Control MiCalculadora"/>
      </oaf_server>
      </oaf_info>
    

Como se puede observar, este fichero usa XML como formato, y vemos que, dentro del nodo principal del fichero (<oaf_info>) hay dos subnodos, ambos de tipo oaf_server. Estos subnodos especifican los servidores (componentes) que queremos exportar, que en este caso son dos: el componente MiCalculadora y la factoría que permite crear objetos de tipo MiCalculadora.

Seguidamente, podemos observar que para cada servidor se especifican una serie de propiedades que especifican el tipo de componente y la localización del mismo (para la factoría es un simple ejecutable, pero para el otro componente, vemos que se especifica "factory" como tipo, y como localización, el OAFIID de la factoría, lo que hace que Bonobo sepa qué tiene que hacer para crear un componente MiCalculadora: cargar la factoría y pedirle que cree una nueva instancia del componente MiCalculadora).

Seguidamente aparecen los oaf_attribute, que son uno o más atributos que queremos darle al componente. El más importante de todos es "repo_ids", que especifica la lista de interfaces CORBA IDL implementados por el componente en cuestión. Así, vemos que nuestro componente factoría implementa el interfaz "IDL:GNOME/GenericFactory:1.0" y el componente MiCalculadora implementa tanto "IDL:Bonobo/Control:1.0" como "IDL:GNOME:Bonobo/Unknown:1.0" (ver primer artículo de la serie para saber más acerca de Bonobo/Unknown). Este campo es muy importante, pues es el que usa OAF para saber si un determinado componente implementa o no un determinado interfaz. Así que es una buena idea añadir a la lista de "repo_ids" todos y cada uno de los interfaces que nuestro componente implementa, empezando, por supuesto, por IDL:GNOME:Bonobo/Unknown:1.0.

El resto de oaf_attribute no son obligatorios y suelen usarse como medio informativo, como es el caso del atributo "description", que indica una descripción de lo que hace nuestro componente. Este campo es muy útil, por ejemplo, para una ventana en la que se le pida al usuario qué componente quiere cargar: en vez de mostrar el OAFIID, podríamos mostrar la descripción del componente. Esto es precisamente lo que hace el objeto BonoboSelectorWidget, que ya implementa todo lo necesario para preguntar a OAF qué componentes hay instalados, y mostrar toda la información sobre ellos en un bonito "widget". Y Bonobo nos facilita aún más las cosas al incluir el BonoboSelectorDialog, que a su vez usa el BonoboSelectorWidget. Para usarlo:

      const gchar* interfaces[] = { "IDL:Bonobo/Control:1.0", NULL };
      gchar* seleccionado = bonobo_selector_select_id("Selecciona control", interfaces);
      if (seleccionado) {
        GtkWidget* control = bonobo_widget_new_control(seleccionado, NULL);
	gtk_container_add(GTK_CONTAINER(ventana), control);
      }
    

Este código abriría una ventana en la que aparecería un listado de todos los controles Bonobo (debido a que hemos especificado sólo "IDL:Bonobo/Control:1.0") instalados en el sistema, y, según lo que devuelva la función bonobo_selector_select_id (NULL si el usuario no seleccionó ningún componente, o una cadena que contiene el nombre del componente seleccionado si el usuario así lo hizo), carga el componente en una ventana o no.

Figura 1. El selector de componentes de Bonobo