Ceibal Jam/Aplicaciones
(Información preliminar, en el correr de los días voy a poner algo más elaborado. Geirea)
Objetivo
Se buscó responder a las siguientes interrogantes:
- ¿Es posible instalar aplicaciones propias en las XO del Plan Ceibal como un usuario común?
- ¿Cómo se empaqueta una aplicación para ser instalada en la XO?
- ¿Cómo se define el icono de una aplicación para que aparezca igual que el resto de las actividades?
- ¿Existe alguna forma fácil e independiente de distribuir nuestras aplicaciones entre los niños?
Estructura básica de una actividad
Al iniciar Sugar, las aplicaciones (actividades en la nomenclatura de OLPC) se buscan en dos directorios:
- /usr/share/activities
- /home/olpc/activities
El primero de ellos no puede ser modificado por el usuario; es necesario tener password de root, que en las laptops de OLPC no es conocido por el usuario. El usuario por defecto es llamado olpc, entonces el segundo directorio de la lista es el directorio home del usuario en el cual sí se pueden escribir y modificar archivos. Es en este último donde se pueden instalar las actividades que el usuario desee.
Usaremos como ejemplo una actividad de nombre Prueba. Las actividades se instalan en una estructura de directorios (debajo del directorio /home/olpc/activities/) como la que sigue:
Prueba.activity/ Prueba.activity/prueba.py Prueba.activity/setup.py Prueba.activity/activity/ Prueba.activity/activity/activity.info Prueba.activity/activity/activity-prueba.svg
Donde:
- prueba.py contiene el código principal de la actividad definido dentro de una clase en Python, pudiendo haber otros archivos con más código en el mismo directorio
- setup.py contiene un código muy simple que sirve para que Sugar realice la instalación de la actividad
- activity/activity.info es un archivo de texto que contiene la información básica de la actividad
- activity/activity-prueba.svg es el icono de la actividad
A continuación se describe en mayor detalle cada uno de estos archivos.
prueba.py
Este archivo contiene el código principal de la actividad, que debe formar parte de una clase que hereda de sugar.activity.Activity. A continuación se muestra un ejemplo de cómo hacer esto.
# prueba.py
# ejemplo de como escribir la clase principal de la actividad
from sugar.activity import activity
class prueba(activity.Activity):
def __init__(self,handle):
activity.Activity.__init__(self,handle)
# aca va el codigo de la aplicacion
# fin de prueba.py
En este ejemplo vemos:
- se importa la clase activity de la biblioteca sugar
- se define una clase prueba que hereda de activity.Activity
- en el constructor de dicha clase se llama al constructor de la clase madre (esto es típico de Python, el constructor debe ser llamado explícitamente)
setup.py
Este archivo es utilizado por Sugar para inicializar la actividad. El código debe ser el siguiente.
# setup.py from sugar.activity import bundlebuilder bundlebuilder.start() # fin de setup.py
activity/activity.info
En este archivo de texto se define el nombre de la actividad, el icono a ser utilizado por Sugar y el nombre de la clase que debe ser llamada para ejecutar la actividad, entre otras cosas.
[Activity] name = Prueba activity_version = 1 host_version = 1 bundle_id = uy.edu.fing.geirea.prueba icon = activity-prueba class = prueba.prueba show_launcher = yes
Los campos contenidos en este archivo son:
- name: el nombre de la actividad tal como debe aparecer cuando se pone el puntero del ratón sobre el icono en la interfaz Sugar
- activity_version: numero de versión de la actividad, en principio puede ser un entero asignado en forma secuencial
- host_version: version de Sugar para la cual la aplicación fue desarrollada
- bundle_id: nombre de identificación de la actividad, deberí ser único por lo que se recomienda usar el nombre de dominio escrito de forma inversa (en este caso es la actividad prueba desarrollada por geirea en fing.edu.uy)
- icon: este es el nombre del archivo svg que contiene el icono (la extensión svg no se pone)
- class: el nombre de la clase para ejecutar la actividad (en este caso es la clase prueba en el archivo prueba.py; el archivo va primero sin su extensión seguido de un punto y el nombre de la clase)
- show_launcher: el valor yes indica que el icono se debe mostrar en la interfaz Sugar junto con todas las otras aplicaciones
activity/activity-prueba.svg
Este archivo contiene el icono de la actividad en formato svg. Se puede crear con un editor vectorial como por ej. Inkscape. Por más información ver http://wiki.laptop.org/go/Making_SVG_Icons_for_Sugar
Otra forma de hacer un icono sencillo es copiar uno existente y modificarlo a mano. Por ejemplo, se puede copiar el icono de la actividad Terminal de /usr/share/activities/Terminal.activity/activity/activity-terminal.svg
Archivos auxiliares de una actividad
También se recomienda incluir otros archivos, aunque en la práctica se comprobó que no son estrictamente necesarios. Los archivos adicionales son:
Prueba.activity/NEWS Prueba.activity/TODO Prueba.activity/MANIFEST Prueba.activity/locale/ Prueba.activity/po/ Prueba.activity/bin/ Prueba.activity/lib/
Donde
- NEWS es un archivo de texto donde se deja constancia de las sucesivas revisiones de la actividad, las cosas que se incluyeron, que se modificaron, etc.
- TODO es un archivo de texto donde se escriben las cosas que quedan pendientes realizar
- MANIFEST es un archivo de texto que contiene la lista de archivos contenidos en el paquete de la actividad
- locale/ es un directorio donde se incluye información para traducir la aplicación a distintos idiomas en lo que respecta estrictamente a la interfaz Sugar (en este momento lo único que se traduce es el nombre de la actividad)
- po/ es un directorio donde se pueden incluir los archivos .po para traducir las cadenas de texto de la actividad a distintos idiomas. Por más información visitar http://wiki.laptop.org/go/PO_files
- bin/ es un directorio donde pueden ir los archivos ejecutables relacionados con la aplicación
- lib/ es un directorio donde pueden ir las librerías usadas por la aplicación
Empaquetado de una actividad
El empaquetado de una actividad se conoce con el nombre inglés de bundle. Hay dos tipos de bundles: los de actividades y los de contenidos, llamados activity bundles y content bundles respectivamente. Estos últimos son una colección de documentos accesibles mediante la actividad Browse, que se pueden empaquetar en un único archivo de extensión .xol.
Las activity bundles son las que nos interesan en este momento. Se trata simplemente de archivos zip que contienen todos los archivos y la estructura de directorios descritos más arriba. La extensión de este archivo debe ser cambiada a .xo. La actividad Browse está configurada para descomprimir e instalar automáticamente en el directorio /home/olpc/activities la actividad cuando se baja un archivo con esta extensión.
En las referencias hay algunos scripts que hacen este empaquetado automáticamente. Siendo el procedimiento tan sencillo, parece más razonable entender bien cómo funciona y después si uno desea recurrir a los scripts. De esta forma, se evita una aproximación del tipo caja negra, donde lo que ocurre automáticamente es un misterio, cuando en realidad es algo muy sencillo.
Conclusiones
Se concluye que sí es posible instalar aplicaciones propias en las XO del Plan Ceibal sin necesidad de tener usuario root y sin obstáculos que podrían ser firmas digitales, etc.
La aplicación se instala en el directorio /home/olpc/activities, siguiendo una estructura de directorios sencilla. La rutina principal de la aplicación debe incluirse en un archivo Python, como parte de una clase que hereda de la clase sugar.activitiy.Activity. Se deben además crear una serie de archivos auxiliares con un formato de texto muy sencillo. El icono de la actividad debe ser en formato svg; si se quiere que titile como los iconos de las actividades estándar, se debe retocar el archivo con un editor de texto para definir los colores en concordancia con la interfaz Sugar.
Toda la estructura de directorios se puede empaquetar en formato .zip y renombrar con extensión .xo. Cuando la actividad Browse baja un archivo con dicha extensión de una página web, realiza la descompresión e instala la actividad automáticamente.
Se concluye que es posible entonces empaquetar nuestras actividades, subirlas a una página web, y que después los niños puedan bajarla e instalarla automáticamente.
Referencias
http://wiki.laptop.org/go/Activity_tutorial
http://wiki.laptop.org/go/Porting_pygame_games_to_the_XO
http://wiki.sugarlabs.org/go/Running_Linux_Applications_Under_Sugar