User talk:Gerardo GR

Mi primer post en esta simulación de bitacora.

Primeros pasos

La primer actividad que estoy realizando como practicante del proyecto OpenOffice es conseguir OpenOffice y las herramientas necesarias para desarrollar extensiones (en la plataforma de desarrollo eclipse).

Instalando las herramientas

Ya he instalado exitosamente openoffice, de hecho cree un script para instalarlo en slackware y lo subi en una pagina que se dedica a distribuir esos scripts. Tambien he instalado el SDK de openoffice. Por ultimo termine de instalar el plug-in de eclipse para desarrollar aplicaciones con UNO para openoffice. Para instalar este plug-in segui esta guia, la recomiendo es util para llevar acabo esta tarea.
Despues de haber realizado la tarea de preparar el entorno de desarrollo (SDK,plug-in, etc), me preparo para correr algun ejemplo, el que he realizado con exito fue el del link mencionado anteriormente. El unico inconveniente que tuve, fue que al añadir una libreria externa, y correr la aplicación en openoffice a traves de un macro, me produjo la exepción de que no se encuentra la clase de la libreria añadida. Al finalizar el dia, me dedique a leer la guía de desarrolladores.

Conociendo la API de OpenOffice

El dia de hoy (01 de septiembre del 2011), lei la documentación acerca de la API de OpenOffice. Lo que aprendi es que utiliza un lenguaje llamado UNO que funciona como una interfaz entre los lenguajes de programación, entre ellos c++, basic y java. Por lo mismo que UNO funciona como interfaz, este tiene muchas interfaces que permiten el manejo de los objetos de openoffice.
Al mismo tiempo que iba leiendo la documentación, corri los programas de ejemplo y los analize. Uno de los ejemplos que corri, fue el siguiente, con este programa de ejemplo, tambien aprendi a como configurar el IDE eclipse para utilizar el SDK de openoffice y a configurar el build.xml (ant) para compilar diferentes programas, le hice unas pequeñas modificaciones para poder tener un script mas flexible. El cual quedo de la siguiente manera:

<?xml version="1.0" encoding="UTF-8"?>
<project basedir="." default="all" name="FirstLoadComponent">
 
	<!-- The following build script works with a standard installation of OpenOffice 3.0.1
	     and OpenOffice SDK 3.0.1 as described in section >Linux RPM-based Installation< 
	     of the document found at http://download.openoffice.org/common/instructions.html. -->
 
	<!-- This script is tested with the Eclipse IDE and stand-alone, without any IDE support. -->
 
	<!-- Paths based on the standard installation of OOo 3.0.1 and OOo SDK 3.0.1 on unix -->
	<property name="OFFICE_ROOT" value="/opt/openoffice.org" />
	<property name="OFFICE_HOME" value="${OFFICE_ROOT}/basis3.3" />
	<property name="OO_SDK_HOME" value="${OFFICE_HOME}/sdk" />
	<property name="OO_URE_HOME" value="${OFFICE_ROOT}/ure" />
 
	<target name="init">
		<property name="OUT_DIR" value="${basedir}/build/Example/" />
		<!-- For eclipse we need to set the output folder to this path -->
		<property name="BIN_DIR" value="${basedir}/bin/" />
 
		<!-- This variables help to have a more flexible build.xml.
			 APP_CLASS: name of the class.
			 OUT_JAR: name of the generated jar file.
			 PKG_NAME: name of the package tree we have in Eclipse -->
		<property name="APP_CLASS" value="FirstLoadComponent" />
		<property name="OUT_JAR" value="${APP_CLASS}.jar" />
		<property name="PKG_NAME" value="Example" />
	</target>
 
	<path id="office.class.path">
		<filelist dir="${OFFICE_HOME}/program/classes" files="unoil.jar" />
		<filelist dir="${OO_URE_HOME}/share/java" files="jurt.jar,ridl.jar,juh.jar" />
	</path>
 
	<fileset id="bootstrap.glue.code" dir="${OO_SDK_HOME}/classes">
		<patternset>
			<include name="com/sun/star/lib/loader/*.class" />
		</patternset>
	</fileset>
 
	<!-- Since the Eclipse IDE has an incremental compiler build in we do not need
	     to run the >compile< target in this case -->
	<target name="compile" depends="init" unless="eclipse.running">
		<mkdir dir="${BIN_DIR}" />
		<javac debug="true" deprecation="true" destdir="${BIN_DIR}" srcdir=".">
			<classpath refid="office.class.path" />
		</javac>
	</target>
 
	<target name="jar" depends="init,compile">
		<mkdir dir="${OUT_DIR}" />
		<jar basedir="${BIN_DIR}" compress="true" jarfile="${OUT_DIR}/${OUT_JAR}">
			<exclude name="**/*.java" />
			<exclude name="*.jar" />
			<fileset refid="bootstrap.glue.code" />
			<manifest>
				<attribute name="Main-Class" value="com.sun.star.lib.loader.Loader" />
				<section name="com/sun/star/lib/loader/Loader.class">
					<attribute name="Application-Class" value="${PKG_NAME}.${APP_CLASS}" />
				</section>
			</manifest>
		</jar>
	</target>
 
	<target name="all" description="Build everything." depends="init,compile,jar">
		<echo message="Application built. ${APP_CLASS}!" />
	</target>
 
	<target name="run" description="Try running it." depends="all">
		<java jar="${OUT_DIR}/${OUT_JAR}" failonerror="true" fork="true">
		</java>
	</target>
 
	<target name="cleanbin" description="Clean all binaries." unless="eclipse.running">
		<delete>
			<fileset dir="${BIN_DIR}">
				<include name="**/*.class" />
			</fileset>
		</delete>
	</target>
 
	<target name="cleanall" description="Clean all build products." depends="init,cleanbin">
		<delete file="${OUT_DIR}/${OUT_JAR}" />
	</target>
 
</project>

Archivos de propiedades de las extensiones

Le llamo archivos de propiedades de extensiones aquellos archivos xml que describen las propiedades de la extension, como son el nombre de la extension, la liga de donde se descargara una version actualizada, etc. Toda esta información le servira a la gestor de extensiones para poder realizar cierta funcionalidad, como el despligue de la licencia, o la actialización de la extension. Estos archivos son realativamente sencillos de entender y considero que para poder poner en practica este nuevo conocimiento lo mejor es empezar a leer bien codigos de ejemplo. El haber leido esa información me permitio entender mejor como se manejan las extensiones y que tipo de archivos son necesarios. Ahora me dispongo a analizar codigo de extensiones existentes para seguir con mi avance en las practicas.

Creando interfaces graficas con UNO (parte 1)

He aprendido que UNO proporciona interfaces para el despliegue de interfaces graficas apartir de una libreria parecida a AWT de java. Esta libreria AWT de UNO nos permite manipular cada objeto grafico cambiando sus propiedades, agregando eventos, etc. Para poder instanciar algun elemento grafico que creamos, es necesario crearlo apartir de un contexto, que por lo general es de alguna instancia de algun programa de openoffice, si no existiese alguna instancia de openoffice en ejecución, se puede crear una y trabajar en ella.
Es importante destacar, que no es necesario utilizar esta libreria de UNO, se puede utilizar la libreria AWT de java, o se puede utilizar una combinaciń de ambas, lo importante de hacer uso de la de UNO, es que nos permitira la independencia del lenguaje de programación, y asi comunicar varios lenguajes de programación, de ser necesario. Template:Insert template

Creando interfaces graficas con UNO (parte 2)

Lo interesante de utilizar la libreria AWT que proporciona UNO, es que esta se incorpora de manera nativa a OpenOffice, lo que permite gestionar información de los documentos o elementos en su interior de mejor manera. Mucho del trabajo de las GUIs es bastante sencillo, se utilizan una serie de interfaces, como la de XComponentContext que nos permite obtener la instancia de OpenOffice que se encuentra en ejecución, para al final terminar con un objeto grafico que deseemos instanciar o utilizar.
Para poder realizar mejor las GUIs de las extensiones, he optado por utilizar el IDE netbeans, debido a que tiene un soporte mas completo para el desarrollo de extensiones (en comparación a eclipse), el cual simplifica mucho del trabajo necesario.

Creando interfaces graficas con UNO (parte 3)

Uno de los archivos mas importantes para las GUIs de UNO es el Addons.xcu, pues es el que describe cuales son los componentes de una extension. Entre los campos mas importantes estan de este archivo estan:

• Tipo de componente (boton, campo de edición, combobox, etc)
• Nombre del componente
• Comando con el que se relaciona
• y hasta un notificador del cambio de estado.

Lo importante de estos archivos no es aprenderse totalmente la sintaxis, sino saber para que sirve cada uno de estos campos y saber (en caso de que el IDE no lo proporcione), cual cambiar para que se lleve acabo algun cambio en la presentación de la extension.

Luego de haber discutido con Alexandro (mi asesor de practicas profesionales) el codigo de gdocs, entendi que el uso de la libreria AWT de java debe ser usada en la menor medida posible, y esto es lógico debido a que nos limitaria al lenguaje de programación java, iendo asi en contra de la filosofia de UNO, que es la de proporcionar una serie de interfaces independientes del lenguaje que nos permiten interactuar con el programa OpenOffice. Asi que de esta manera me he propuesto replantear la manera de crear una GUI apartir de la AWT de UNO.

Lectura de codigo de ejemplo

Hasta el momento, he terminado de entender el codigo de la extension gdocs. Al tratar de entender por completo el codigo, me he tardado mas tiempo de lo esperado, sin embargo el haber leido este codigo me permitio entender mejor la logica que se maneja en el desarrollo de extensiones. Tambien me percate que este codigo tiene una gran deficiencia, utiliza la libreria AWT de java, y no la de UNO, esto es un problema porque que la GUI se vuelve dependiente del lenguaje en que se programo y tambien genera un mayor gasto en recursos. Entonces mi siguiente actividad, despues de haber terminado de entender el codigo, es realizarle alguna modificación, que en este caso sera migrar la GUI de java a la GUI de UNO.
En las previas entradas de esta bitacora hable del desarrollo de la GUI en UNO, hasta ejecute una serie de programas de ejemplo que vienen en los tutoriales, lo cual me dio una muy buena idea de como utilzarla, pero ahora el reto sera utilizarla por mi mismo manipulando los diferentes componentes para que realizen lo que se desea.

Ordenando el area de trabajo para las modificaciones a la extension gdocs

La actividad que realize por el momento con la extension gdocs, fue establecer el area de trabajo en el IDE para poder compilar y realizar el despligue de la extension en OpenOffice.
Empeze a realizar pruebas con los codigos de ejemplo que vienen en el wiki del desarrollo de GUI con UNO.

Jugando con la GUI que proporciona UNO

Actividades:

• Crear un dialogo, configurar, y desplegar un dialogo.
• Agregarle XEventListeners.
• Agregarle al dialogo controles como: botones y campos de texto.

En base al conocimiento adquirido apartir de estas actividades realize unas clases que me permiten manipular de mejor manera los componentes de la GUI, un poco mas al estilo de Swing, pero sin tanta complejidad, solamente para realizar el trabajo. Tengo pensado que con estas clases, se pueda facilitar el trabajo del cambio de la GUI de la extension gdocs.

GUI de gdocs convertida a GUI de UNO

Los componentes de la GUI de la extensión gdocs que ya "traduje" a componentes de GUI de UNO son:

• WaitWindow
• UploadDialog

Me di cuenta que en realidad como mi tarea no es concentrarme en el desarrollo de una libreria para facilitar el trabajo del desarrollo de GUI en UNO, entonces dedicare completamente a terminar la conversion de la GUI de esta extension, obviamente utilizando almenos la "sublibreria" con la que cuento para poder facilitarme el trabajo, pero siempre teniendo en cuenta cual es mi objetivo.

Probando mi trabajo anterior y buscando un GUI Builder para UNO de OpenOffice.org

El dia de hoy, me dedique a probar la GUI que ya habia terminado, el frame UploadDialog, el cual a primera vista parece terminado, la funcionalidad de los actionlistener funciona sin problemas, no hay incongruencias en el renderizado de la imagen, etc. Sin embargo me hace falta realizar mas pruebas con mas ventanas, para determinar la viabilidad del uso de mi sublibreria.
Una actividad importante que realize, fue el buscar un GUI Builder orientado a la tecnologia de UNO, desgraciadamente, no existe como tal un proyecto asi, pero mientras buscaba esta herramienta encontre que habia una propuesta del SOD 2008, para una herramienta como la que me hace falta. Luego al continuar con mi busqueda encontre que hay un TODO list de esta propuesta, es por esto que le envie un correo al encargado de dicho proyecto para averiguar cual es el estado actual del proyecto. Por ahora lo que me queda es esperar la respuesta, y seguir con mi desarrollo habitual (la conversion de la GUI de gdocs que se encuentra desarrollada en SWING a una GUI hecha en UNO).

3 Nuevas ventanas creadas

Estas 3 nuevas ventanas que cree, estan completamente hechas en UNO, estas podrian ser las ventanas que replazaran a las creadas en java swing de la extension gdocs. A continuación mostrare unas impresiones de pantalla de las ventanas de gdocs en comparación a las que cree.


NOTA: los nombres de las ventanas son en base a los que aparecen en el codigo fuente.
La primer ventana que mostrare es la que se llama UploadDialog.

Y esta es el equivalente creado en UNO


Esta siguiente ventana se llama Uploading

He aqui su equivalente

Por lo que se ve en el equivalente de la ventana Uploading, la "ProgressBar" no aparece, he hecho varios intentos para hacer aparecer la "ProgressBar" de UNO sin algun exito, probablemente sea un error en la implementación del servicio UnoControlProgressBarModel o la integración de este control al Dialog. A pesar de esto utilize un equivalente que sirve para el proposito, mostrar el progreso.

La ultima ventana de la que he creado su equivalente es la ServersManager

Su equivalente en UNO es esta


El equivalente de ServersManager en UNO utiliza un campo de texto en vez de un JList (de swing), todavia no he encontrado el equivalente de ese componente de swing en UNO.
Ahora mostrare el codigo que utilize para crear esta GUI, solamente mostrare el codigo de las clases mas significativas como los ancestros comunes, y 2 ejemplos de las implementaciones, como la creación del frame y los controles como un boton y un campo de texto.
La Clase SimpleDialog

/*
 * To change this template, choose Tools | Templates
 * and open the template in the editor.
 */
 
package util;
 
/* Omitire los imports
 */
 
/**
 *
 * @author gerhard
 */
public class SimpleDialog {
 
    protected XComponentContext xComponentContext = null;
    protected XMultiComponentFactory xMCF = null;
 
    // contenedores de los controles del dialogo
    protected XNameContainer xNameContainer = null;
    protected XControlContainer xControlContainer = null;
 
    protected XMultiServiceFactory xMSF = null;
 
    // la ventana, representada por un contorl
    protected XControl xControl = null;
 
    protected XTopWindow xTopWindow = null;
    protected XWindowPeer xWindowPeer = null;
 
    // Constructor de la clase
    public SimpleDialog(XComponentContext xComponentContext, XMultiComponentFactory xMCF,String[] properties, Object[] values) throws Exception{
        // inicilizamos los parametros princiaples.
        this.initilize(xComponentContext, xMCF);
        // Establecemos las propiedades del dialogo, como el tamaño de la ventana
        // el nombre de la ventana, etc.
        this.setProperties(properties,values);
    }
 
    private void initilize(XComponentContext xComponentContext,XMultiComponentFactory xMCF) throws Exception{
        this.xComponentContext = xComponentContext;
        this.xMCF = xMCF;
        Object dialogModel = this.xMCF.createInstanceWithContext("com.sun.star.awt.UnoControlDialogModel", this.xComponentContext);
        this.xMSF = (XMultiServiceFactory) UnoRuntime.queryInterface(XMultiServiceFactory.class, dialogModel);
        this.xNameContainer = (XNameContainer) UnoRuntime.queryInterface(XNameContainer.class, dialogModel);
        Object unoDialog = this.xMCF.createInstanceWithContext("com.sun.star.awt.UnoControlDialog", this.xComponentContext);
        this.xControl = (XControl) UnoRuntime.queryInterface(XControl.class, unoDialog);
        this.xControlContainer = (XControlContainer) UnoRuntime.queryInterface(XControlContainer.class, unoDialog);
        this.xTopWindow = (XTopWindow) UnoRuntime.queryInterface(XTopWindow.class, xControlContainer);
        XControlModel xControlModel = (XControlModel) UnoRuntime.queryInterface(XControlModel.class, dialogModel);
        this.xControl.setModel(xControlModel);        
    }
 
    private void setProperties(String[] properties, Object[] values){
        try{
            // establecemos las propiedades de la ventna
            XMultiPropertySet xMultiPropertySet = (XMultiPropertySet) UnoRuntime.queryInterface(XMultiPropertySet.class, this.xNameContainer);
            xMultiPropertySet.setPropertyValues(properties, values);
        } catch (com.sun.star.uno.Exception ex) {
            ex.printStackTrace(System.out);
        }
    }
 
    public XComponentContext getxComponentContext() {
        return xComponentContext;
    }
 
    public void setxComponentContext(XComponentContext xComponentContext) {
        this.xComponentContext = xComponentContext;
    }
 
    public XControlContainer getxControlContainer() {
        return xControlContainer;
    }
 
    public void setxControlContainer(XControlContainer xControlContainer) {
        this.xControlContainer = xControlContainer;
    }
 
    public XMultiServiceFactory getxMSF() {
        return xMSF;
    }
 
    public void setxMSF(XMultiServiceFactory xMSF) {
        this.xMSF = xMSF;
    }
 
    public XMultiComponentFactory getxMCF() {
        return xMCF;
    }
 
    public void setxMCF(XMultiComponentFactory xMCF) {
        this.xMCF = xMCF;
    }
 
    public XNameContainer getxNameContainer() {
        return xNameContainer;
    }
 
    public void setxNameContainer(XNameContainer xNameContainer) {
        this.xNameContainer = xNameContainer;
    }
 
    public XWindowPeer getxWindowPeer() {
        return xWindowPeer;
    }
 
    public void setxWindowPeer(XWindowPeer xWindowPeer) {
        this.xWindowPeer = xWindowPeer;
    }
 
    public short execute() throws com.sun.star.script.BasicErrorException, Exception{
        // creamos una ventana
        XWindow xWindow = (XWindow) UnoRuntime.queryInterface(XWindow.class, this.xControlContainer);
        xWindow.setVisible(false);
        Object oToolkit = this.xMCF.createInstanceWithContext("com.sun.star.awt.Toolkit", this.xComponentContext);
        XToolkit xToolkit = (XToolkit) UnoRuntime.queryInterface(XToolkit.class, oToolkit);
        // obtenemos una ventana de la instancia de OpenOffice
        XWindowPeer xWindowParentPeer = xToolkit.getDesktopWindow();
        this.xControl.createPeer(xToolkit, xWindowParentPeer);
        this.xWindowPeer = this.xControl.getPeer();
        // creamos el dialog.
        XDialog xDialog = (XDialog) UnoRuntime.queryInterface(XDialog.class, this.xControl);
        XComponent xDialogComponent = (XComponent) UnoRuntime.queryInterface(XComponent.class, this.xControl);
        // mostramos el dialog.
        short nReturnValue = xDialog.execute();
        // liberamos los recursos que utilizo el dialog.
        xDialogComponent.dispose();
        return nReturnValue;
    }
 
    // metodo para crear nombres unicos a los controles (ej. botones, campos de texto, etc).
    public String createUniqueName(String name) {
      boolean elementExists = true;
      int i = 0;
      String baseName = name;
      while (elementExists) {
          i += 1;
          name = baseName + Integer.toString(i);
          elementExists = this.xNameContainer.hasByName(name);
      }
      return name;
    }
 
}

La clase AbstractControl

/*
 * To change this template, choose Tools | Templates
 * and open the template in the editor.
 */
 
package util;
 
/* Omitire nuevamente los imports
 */
 
/**
 * Representación abstracta del algun componente grafico
 * @author gerhard
 */
public abstract class AbstractControl {
 
    // nombre unico identificador del control creado.
    protected String id = "";
 
    // representa el elemento grafico del control creado.
    protected Object control = null;
 
    /**
     * @param parent, quien contiene al control
     * @param interfaceRoute, ruta al servicio que implementa
     * @param controlName
     * @param properties
     * @param values
     */
    public AbstractControl(SimpleDialog parent, String serviceRoute, String controlName,String[] properties, Object[] values){
        try{
            // creamos el nombre unico.
            this.id = parent.createUniqueName(controlName);
            // creamos el modelo del servicio serviceRoute
            Object model = (parent.getxMSF()).createInstance(serviceRoute);
            XPropertySet props = (XPropertySet)UnoRuntime.queryInterface(XPropertySet.class, model);
            // establecemos el nombre al control
            props.setPropertyValue("Name",this.id);
            // asignamos las propiedades al control, como el tamaño etiqueta, etc.
            XMultiPropertySet xMPS = (XMultiPropertySet) UnoRuntime.queryInterface(XMultiPropertySet.class, model);
            xMPS.setPropertyValues(properties,values);
            // obtenemos el objeto que representa el componente grafico del control.
            (parent.getxNameContainer()).insertByName(this.id, model);
        }catch (com.sun.star.uno.Exception ex){
            ex.printStackTrace(System.out);
        }
    }
 
}

La clase OoButton

/*
 * To change this template, choose Tools | Templates
 * and open the template in the editor.
 */
 
package util;
 
/* Omitire los imports
 */
 
/**
 * Heredero de la clase abstracta AbstractControl, representa un boton.
 * @author gerhard
 */
public class OoButton extends AbstractControl{
 
    /**
     * Constructor del boton.
     * @param parent
     * @param properties
     * @param values
     */
    public OoButton(SimpleDialog parent, String[] properties, Object[] values){
        super(parent,"com.sun.star.awt.UnoControlButtonModel","ButtonCommand",properties, values);
        // obtnemos el control grafico del dialogo y lo guardamos en el objeto
        // control.
        XControl xControl = parent.getxControlContainer().getControl(this.id);
        this.control = (XButton) UnoRuntime.queryInterface(XButton.class, xControl);
    }
 
    /**
     * Añadimos el nuevo actionListener.
     * @param xActionListener
     */
    public void addActionListener(XActionListener xActionListener) {
        ((XButton)this.control).addActionListener(xActionListener);
    }
 
}

La clase OoTextField

/*
 * To change this template, choose Tools | Templates
 * and open the template in the editor.
 */
 
package util;
 
/* Omitire los imports
 */
 
/**
 * Heredero de la clase abstracta AbstractControl, representa un campo de texto.
 * @author gerhard
 */
public class OoTextField extends AbstractControl{
 
    /**
     * Constructor del campo de texto.
     * @param parent
     * @param properties
     * @param values
     */
    public OoTextField(SimpleDialog parent, String[] properties, Object[] values){
        super(parent,"com.sun.star.awt.UnoControlEditModel","TextField", properties, values);
        // obtnemos el control grafico del dialogo y lo guardamos en el objeto
        // control.
        XControl xTextControl = parent.getxControlContainer().getControl(this.id);
        this.control = (XTextComponent) UnoRuntime.queryInterface(XTextComponent.class, xTextControl);
    }
 
    /**
     * @return el String que tiene este TextField
     */
    public String getText(){
        return ((XTextComponent)this.control).getText();
    }
 
    /**
     * NOTA:Falta Implementar las demas funciones basicas de un Textfield.
     */
}

1 ventana y media mas traducida a GUI de UNO (de la extension gdocs)

Las siguientes ventanas fueron convertidas a la GUI de UNO. Al igual que en mi entrada anterior de la bitacora, mostrare el antes de la conversion y el despues.


NOTA: Esto es en realidad un JPanel (no un JFrame o JDialog) de java SWING, pero pienso utilizarla por herencia la ventana, para tener un efecto parecido al de incorporar un panel a una ventana.

Este es su equivalente en UNO


Esta es de las ventanas que mas me a costado trabajo implementar debido a su gran tamaño y a la gran cantidad de componentes graficos con los que cuenta. Pienso que es mejor rehacer la sección about y en vez de utilizar un Label por cada linea, utilizare un TextArea que sea ReadOnly y escribir todo el contenido en el, en vez de pelearme con las posiciones de los Labels.

Esto es lo que llevo de la traducción de esta ventana, todavia falta refinar la interacción con los radio buttons, e implementar los botones faltantes y la sección about.

Problemas con la implementación de la GUI en UNO

Como la extension gdocs utiliza el componente grafico JPanel para reutilzar una sección grafica, esto facilita mucho la implementación de las ventanas, pero UNO AWT no existe tal concepto, entonces lo que pienso hacer en dichos casos (al menos por el momento), es presentar primero la ventana que se utiliza del JPanel (en el caso de gdocs el JPanel LoginPanel), y luego mostrar la ventana que necesita de ese panel.
Otra de las actividades que realize, fue mejorar la logica de las ventanas, y añadir algunas funcionalidades mas a los controles. Por ejemplo para el dialogo, añadi un nuevo metodo llamado endExecute() que me permite cerrar la ventana cuando se le llame. Tambien le incorpore como nuevo atributo a la clase SimpleDialog un XDialog, el cual me permite llevar acabo la acción de endExecute.
No he subido la imagen de la nueva ventana que he creado, debido a que no la he terminado en su totalidad, me gustaria tener terminada la ventana, o almenos llegar a un punto en el que considere aceptable, para poder subir la imagen.

Implementación del control Grid de UNO

--Gerardo GR 09:10, 23 September 2011 (UTC)

Este nuevo control llamado

XGridControl

es el componente Visual que representa una tabla (o grid en ingles) en UNO AWT. Una de las tareas que realize el dia de hoy, fue la de implementar este componente a una de las ventanas que les estoy haciendo la conversion (de java Swing a UNO AWT). Para poder llevar acabo esta implementación. Primero tuve que crear una nueva clase OoGridColumn, la cual representa una columna dentro del Grid. A continuación mostrare el codigo de dicha clase

/**
 *
 * @author gerhard
 */
public class OoGridColumn {
 
    /* NOTA: Probablemente esten sobrando estos atributos */
    private XComponentContext xComponentContext;
    private XMultiComponentFactory xMCF;
 
    private XGridColumn xGridColumn;
 
    public OoGridColumn(XComponentContext xComponentContext,XMultiComponentFactory xMCF){
        this.xComponentContext = xComponentContext;
        this.xMCF = xMCF;
        try {
            Object obj = xMCF.createInstanceWithContext("com.sun.star.awt.grid.GridColumn", xComponentContext);
            this.xGridColumn = (XGridColumn) UnoRuntime.queryInterface(XGridColumn.class, obj);
        } catch (Exception ex) {
            Logger.getLogger(OoGridColumn.class.getName()).log(Level.SEVERE, null, ex);
        }
    }
 
    public void setTitle(String title){
        this.xGridColumn.setTitle(title);
    }
 
    public void setColumnWidth(int columnWidth){
        this.xGridColumn.setColumnWidth(columnWidth);
    }
 
    public void setHorizontalAlign(HorizontalAlignment horizontalAlignment){
        this.xGridColumn.setHorizontalAlign(horizontalAlignment);
    }
 
    public void setResizeable(boolean resizable){
        this.xGridColumn.setResizeable(resizable);
    }
 
    public XGridColumn getxGridColumn() {
        return xGridColumn;
    }
 
    /* NOTA: Falta implementar algunos metodos */
 
}

El constructor solamente crea este objeto apartir del contexto en el que se encuentra y el xMultiComponentFactory dado. Basicamente los metodos que contiene, son solamente reimplementaciones de los metodos de la clase XGridColumn. Utilizare este punto para señalar, que estas reimplementaciones en todo el codigo anterior visto en esta bitacora, es utilizado/creado para simplificar el mandejo de controles y encapsular las secciones mas complicadas de AWT UNO.
La siguiente clase que cree fue la de OoGridColumnModel, la que me permite agrupar las columnas y tener un modelo apartir de ellas.

/**
 *
 * @author gerhard
 */
public class OoGridColumnModel {
 
    /* NOTA: Probablemente esten sobrando estos atributos */
    private XComponentContext xComponentContext;
    private XMultiComponentFactory xMCF;
 
    private XGridColumnModel xGridColumnModel;
 
    public OoGridColumnModel(XComponentContext xComponentContext,XMultiComponentFactory xMCF){
        try {
            this.xComponentContext = xComponentContext;
            this.xMCF = xMCF;
            Object columnModel = this.xMCF.createInstanceWithContext("com.sun.star.awt.grid.DefaultGridColumnModel", this.xComponentContext);
            this.xGridColumnModel = (XGridColumnModel) UnoRuntime.queryInterface(XGridColumnModel.class, columnModel);
        } catch (Exception ex) {
            Logger.getLogger(OoGridColumnModel.class.getName()).log(Level.SEVERE, null, ex);
        }
    }
 
    public void addColumn(OoGridColumn ooGridColumn){
        this.xGridColumnModel.addColumn(ooGridColumn.getxGridColumn());
    }
 
    public XGridColumnModel getxGridColumnModel() {
        return xGridColumnModel;
    }
 
}

Este codigo es aun mas sencillo que el de la clase anterior. El constructor lleva acabo una acción parecida al de la clase anterior, que es implmentar el servicio propio de la objeto que representa esta clase, solo que aplicado a esta clase. El metodo importante que tiene esta clase es el de

addColumn

que permite añadir nuevas columnas al modelo actual.

Ahora para poder mostrar datos introducidos o generados dentro de esta tabla, es necesario un modelo de datos, especificamente un XGridDataModel, el cual contiene los valores para cada renglon nuevo. Ahora mostrare el codigo correspondiente

/**
 *
 * @author gerhard
 */
public class OoGridDataModel {
 
    /* NOTA: Probablemente esten sobrando estos atributos */
    private XComponentContext xComponentContext;
    private XMultiComponentFactory xMCF;
 
    XGridDataModel xGridDataModel;
 
    public OoGridDataModel(XComponentContext xComponentContext, XMultiComponentFactory xMCF){
        try {
            this.xComponentContext = xComponentContext;
            this.xMCF = xMCF;
            Object dataModel = this.xMCF.createInstanceWithContext("com.sun.star.awt.grid.DefaultGridDataModel", this.xComponentContext);
            this.xGridDataModel = (XGridDataModel) UnoRuntime.queryInterface(XGridDataModel.class, dataModel);
        } catch (Exception ex) {
            Logger.getLogger(OoGridDataModel.class.getName()).log(Level.SEVERE, null, ex);
        }
    }
 
    public void addRow(String rowNumber,Object[] objects){
        this.xGridDataModel.addRow(rowNumber, objects);
    }
 
    public XGridDataModel getxGridDataModel() {
        return xGridDataModel;
    }
 
}

Esta neva clase se parece mucho a la clase anterior, practicamente son las mismas operaciones (obviamente considerando que el constructor utiliza otro servicio,etc), ahora en vez de añadir columnas, para este modelo, se añaden filas (metodo

addRow

), lo interesante aqui es que los elementos de cada fila puden ser diferentes uno de cada otro, es por eso que el parametro para agregar una fila utiliza

Object

como sus elementos. El parametro

rowNumber

nos sirve para señalar donde se insertara la nueva fila.

Por ultimo la clase que importa (desde el punto de vista grafico), es la de OoGrid, la cual sirve de encapsulamiento de la clase XGridControl. Esta clase, al igual que todos los componentes graficos que he descrito en esta bitacora, hereda de la clase

AbstractControl

la que realiza muchas de tareas de inicialización de un objeto grafico, permite ocultarlas y presentar una manera mas sencilla de crear objetos graficos. A continuación mostrare el codigo (que en realidad no es muy largo).

/**
 *
 * @author gerhard
 */
public class OoGrid extends AbstractControl{
 
    public OoGrid(SimpleDialog parent, String[] properties, Object[] values){
        super(parent,"com.sun.star.awt.grid.UnoControlGridModel","Grid",properties,values);
        XControl xControl = parent.getxControlContainer().getControl(this.id);
        this.control = (XGridControl) UnoRuntime.queryInterface(XGridControl.class, xControl);
    }
 
}

Como se ve en el codigo, es muy sencillo, solo crea el objeto con las propiedades especificadas dentro del Dialog SimpleDialog parent.
Al utilizar esta nueva serie de clases logre crear un grid completo y funcional. Sin embargo aun tengo un error (pero no tengo certeza de que lo sea), no se muestra el titulo de las columnas. Seguire mejorando este control grafico debido a que es uno muy util.

Todas las ventanas de la extension gdocs traducidas a UNO AWT

--Gerardo GR 07:04, 24 September 2011 (UTC)
El dia de hoy he terminado de realizar la conversion de la ultima ventana de la extension de gdocs. En la siguiente entrada de mi bitacora mostrare las nuevas ventanas convertidas (igual que entradas anteriores de esta bitacora).
Habiendo terminado la conversion de las ventanas de la extension, me dispongo a mejorar la libreria de clases que tengo para facilitar la creación de GUIs con UNO, y empezar a añadir la funcionalidad a las nuevas ventanas de la extension de gdocs (las equivalentes en UNO).

Otra actividad que desarrolle el dia de hoy fue la de crear una nueva clase para desplegar imagenes, sigue la misma logica que las clases que he creado antes, o sea las herederas de la clase

AbstractControl

. Lo primero para poder desplegar una imagen, es tener un objeto grafico, esto lo logro a traves de una clase mas llamada

OoGraphic

, que contiene una imagen. Esta clase luego se le pasa como uno de los parametros de inicialización a la clase que representa un control de la imagen dentro de un dialog. A esta clase le llamo OoImageControl.

Resumen de actividades de la semana

--Gerardo GR 18:04, 24 September 2011 (UTC)
Esta entrada es un resumen de las actividades que realize en la semana.
La primer actividad que conclui, fue la de terminar de converitir las ventanas que les faltaban algunos detalles, las ventanas son las siguientes:

• ServersManager, la ventana que mostre en la entrada anterior del a bitacora, mostraba un campo de texto, en vez de una lista de elementos (el cuadro grande blanco).
• El equivalente en UNO de la ventana LoginPanel , la mandare a llamar desde la ventana que la necesite, no utilizare herencia (como habia dicho en una entrada pasada). Esta ventana todavia tiene el detalle que el campo donde se introduce la contraseña de la cuenta google docs, no enmascara los caracteres introducidos.
• La ventana ConfigDialog, esta terminada, le introduje los campos faltantes, pero realize un cambio en la estructura de la ventana, en vez de tener un campo dentro de la ventana que muestre el acerca de (about, en ingles), introduje un boton que lo muestra en un MessageBox.
• La ventana UploadDialog utiliza el LoginPanel descrito anteriormente, la manera de utilizarlo en esta equivalencia en UNO AWT, sera:

1. Llamar a LoginPanel
2. Introducir los recursos necesarios
3. Esconder la ventana LoginPanel
4. Utilizar los recursos del LoginPanel

• La ventana ImportDialog fue terminada de ser convertida a UNO AWT. Esta al igual que la de UploadDialog, utiliza el LoginPanel, por lo mismo se llevara acabo el mismo metodo para obtener los recursos necesarios de LoginPanel. Esta ventana de ImportDialog, tiene aun un error, y es con respecto al despligue de los datos dentro de la tabla. Ahora presentare las ventanas, la original y su equivalente en UNO AWT.
  

Original

Equivalente en UNO AWT

• La ventana WaitWindow, es simplemente una implemtación de un MessageBox, esta fue de las mas sencillas de implementar, no tiene ningun error (al menos no encontrado). Ahora mostrare el original y su equivalente.
  

Original

Equivalente en UNO AWT

• La ultima ventana convertida es la CaptchaWindow, esta solamente muestra una imagen ReCaptcha (la que genera una imagen que contiene un par de palabras), un campo de texto donde se introduce la palabra, y un par de botones, Cancel y Ok. Practicamente esta es un MessageBox, pero debido a que no es tan flexible la implementación que tengo de MessageBox, lo manejare como un Dialog de UNO. A continuación, la ventana Original y el equivalente en UNO AWT.
  

Originial

Equivalente en UNO AWT


Ahora la siguiente actividad para completar la conversion de las ventanas, es incluir toda la funcionalidad necesaria para la extension gdocs, por ejemplo agregar los Listeners.

Incorporando las ventanas a la extension gdocs

--Gerardo GR 02:15, 28 September 2011 (UTC)
Luego de haber terminado la conversion de la GUI de gdocs (al menos la parte de presentación), el siguiente paso es dotarla de la funcionalidad correspondiente. Para lograr esto, la manera en que me aproximare a implementar la funcionalidad en las ventanas, sera la de incluir los listeners en los controles apropiados, y cuando se requiera alguna clase que no tenga (las que realizan la funcionalidad), ir agregandolas, asi al menos desde mi punto de vista, no me abrumare con todas las clases y podre ir realizando pruebas poco a poco hasta llegar a la meta deseada.
Durante la realización de la actividad antes mencionada, me he encontrado con un error en la conversion a UNO AWT, mañana seguire explorando este problema y tratarea de encontrar una solución.

Mejorando la GUI en UNO AWT de la extension gdocs

La actividad que realize el dia de hoy, fue a igualar la funcionalidad que tienens las ventanas de la extension gdocs (java Swing) al equivalente. Empeze con la ventana WaitWindow, esta ventana tuvo que ser rehecha, debido a que como la tenia antes, un MessageBox, no me permitia llamarla cuando se le necesite, debido a que necesitaba de un padre que la llame, es por eso que la converti en un Dialog tal cual, el cual corrige el problema de los llamados. Tambien termine de implementar sus Listeners. La siguiente ventana con la que segui su implementación fue la de ConfigDialog, esta me llevo a rediseñar la GUI, debido a que uno de los campos (el de seleccionar el LookAndFeel) ya no estara disponible para esta version, esto se debe a que no hay tal cosa como el LookAndFeel en UNO AWT. Tambien es en esta etapa en la que los campos que requieran enmascaramiento de caracteres (campos de password) seran implementados, lo cual seguira la siguiente actividad al igual que seguir con la completación de los listeners.
Al principio en la implementación de la funcionalidad me costo un poco trabajo saber por donde empezar lo cual me llevo algo de tiempo, pero una vez establecido en que ventana me enfoque, resulta mas agil el avanze.

Descubrimientos durante la fase de implementación de la funcionalidad de las ventanas

--Gerardo GR 05:31, 30 September 2011 (UTC)
Como primer descubrimiento me gustaria destacar el hecho de que, al igual que en la fase de conversion (visual) de Java Swing a UNO AWT, no todo lo que se cree que ya se tiene listo significa que haya quedado bien despues de haber realizado algunas pruebas descubres que existen otros errores que no se tomaron en cuenta, entre ellos se encuentran:

1. El llamado a otra Dialog desde un Dialog, genera un bug que aun no he podido resolver, esto me lleva a replantear el codigo que tenia para soportar esta funcionalidad.
2. Incorporar nuevas clases a la libreria que tengo para los controles y dialogos.

Ampliando la libreria creada en base a UNO AWT (los OoButton,OoTextField,etc) y terminando 2 ventanas mas

--Gerardo GR 03:28, 5 October 2011 (UTC)
Parte del proceso de llevar acabo la conversion de la extension que he comentado en entradas anteriores de esta bitacora, es la incorporación de nueva funcionalidad a la libreria que utilizo para ayudarme en la creación y manejo de los Dialogs. Uno de los factores nuevos agregados a la libreria, son los listeners para los objetos, como lo son los buttons, checkboxes, radiobuttons,etc. Estos son usado ampliamente en la extension, obviamente porque son los que proveen de funcionalidad a las ventanas. Otras funcionalidades para estos componentes, son la inclusion de metodos para obtener datos relacionados a ellos, como lo son, setters y getters, entre otras cosas. Tengo que pensado que al terminar la extension, publicare esta libreria, donde ya habre incorporado las funciones basicas y sirva de marco de trabajo o base para futuras implementaciones de dialogs en las extensiones. Como ultimo punto con respecto a los controles graficos, he podido (porfin), utilizar el ProgressBar de UNO AWT. El error yacia en que el valor inicial estaba en 0, lo que daba la impresion de que no servia el ProgressBar.
Ahora bien, despues de lo mencionado, me gustaria agregar, que he terminado de agregar la funcionalidad a 2 ventanas de la extension gdocs, el ConfigDialog y el LoginPanel. Solo el unico detalle, es que no he podido llevar acabo la funcionalidad de deshabilitar y habilitar los controles graficos, almenos una manera que no consuma una cantidad enorme de recursos. Esta manera seria, destruyendo y construyendo el control cada vez que se desee habilitar o deshabilitar, lo que a la larga mermaria el rendimiento de la ventana, es por eso que por ahora no implmenetare esta funcionalidad hasta encontrar una mejor solución, o reportar la ausencia de esta funcionalidad en la interfaces como XButton, XTextField, etc.

Solucionando el problema de habilitación/deshabilitación de controles graficos

--Gerardo GR 02:20, 7 October 2011 (UTC)
La problematica con la que me encontraba a la hora de habilitar/deshabilitar algun control grafico, era que solo tenia en mente la solución de reconstruir (si ya estaba construido), el objeto grafico, pero ahora con la propiedad de habilitación puesta en falso/verdadero, lo cual consume a la larga muchos recursos (por estar creando y destruyendo objetos). Sin embargo, gracias a que mi asesor de practicas (Alexandro Colorado) me recomendo a una persona (Mauricio Baeza), que conoce de la API de UNO AWT, pude solucionar el problema. El me indico que la propiedad de los objetos se asignaban con un objeto XPropertySet, y que con este creado apartir del contexto del objeto grafico, podia asignarle cualquier propiedad. Este recordatorio del XPropertySet, me permitio implementar eficazmente la deshabilitación y habilitación del objeto. Ahora teniendo en mente esto, es mucho mas sencillo manipulara las demas propiedades del objeto grafico, solo es seguir el mismo metodo, solo que aplicado a una diferente propiedad.

Resumen de actividades de la semana

--Gerardo GR 05:18, 10 October 2011 (UTC)
Esta semana, entre las actividades mas destacadas que desarrolle fueron:

• Terminar 3 la funcionalidad de 3 ventanas.
• Incorporar nuevas funciones a las clases para el desarrollo de GUIs en UNO AWT (UNO GUI Lib)
• Subir el codigo de dicha libreria a GitHub, para que pueda ser descargado y poder hacer ramas de prueba y tener un respaldo, el link es el siguiente: UnoGuiLib
• Tambien realize algunas anotaciones con respecto a algunas mejoras para la libreria. Estas anotaciones tengo pensado implementaras cuando termine de llevar acabo la traducción de la extension, debido a que me tomaria mas tiempo llevarlas acabo, que enrealidad avanzar con la tarea principal.
• En el transcurso de esta semana pude implementar el control grafico de la "progresive bar" y tambien incorporar un nuevo metod para todos los controles graficos, el cual es su habilitación/deshabilitación. Gracias al consejo de Mauricio Baeza, el cual acudi por recomendación de Alexandro Colorado.

Subiendo el primer patch para la extension oo2gdocs

El dia de ayer, cree un "issue" para la extension oo2gdocs, el cual contiene el archivo .patch, con el que se puede hacer el cambio del codigo fuente de la GUI. El unico problema que tuve, es que a la hora de subir el patch, no me aparecio la opción de editarlo para que el "issue" sea un del tipo patch y no "defect", intente crear otro, pero la opción de "defect" era la unica que me ponia. Lo que se me hizo interesante de esaa actividad, es que la comunidad esta al pendiente de los avances del desarrollo, de hecho uno de los que siguen el desarrollo, me envio un correo señalando mi error con el tipo de "issue".
Siento que el aprendizaje mas grande que me dejo esta actividad, fue el hecho de poder crear avances, sin tener que hacer los cambios manualmente, o sea generar parches con diff. Es en realidad muy sencillo, lo que me pone a pensar en que en el proceso de desarrollo lo mejor es tener buenas herramientas para agilizar el trabajo y concentrarnos en el.
Con respecto al avance de la incorporación de la funcionalidad a las ventanas equivalentes en UNO AWT,en estos momentos, estoy trabajando en la ventana llamada ImportDialog, pero esta como es de las principales, hace un amplio uso de las demas ventnas, y clases de la misma extension.

Una ventana mas con funcionalidad completada

--Gerardo GR 05:40, 13 October 2011 (UTC)
El dia de hoy termine la implementación de la funcionalidad de una ventana mas. La ventana se llama ImportDialog, esta es una de las que tiene mayor cantidad de funciones, debido a que es la que se encarga de el cargado de los archivos de google docs a OpenOffice.org.
Al igual que las ventanas anteriores, aun tiene algunos detalles que deben ser resueltos para un funcionamiento mejor, sin embargo algunos son solo cuestiones de estetica o de funcionalidad secundaria, o sea que no influyen en la tarea principal de la ventana.
Al haber terminado esta ultima ventana incorpore nuevas clases y funciones como:

• OoPointer, que representa el cursor de la ventana.
• El llamado a un dialogo para obtener nombres de archivos y directorios (como el JFileChooser de java Swing).
• Asginarle el cursor a el dialog deseado.

La siguientes ventanas a implementar son la UploadDialog y CaptchaDialog.
Otra actividad (no relacionada al desarrollo como tal), que realize, fue la de contactar al desarrollador de la extension Oo2gdocs, esto fue, para hacerle saber sobre el desarrollo que llevo y que probablemente se implemente mi trabajo. Al terminar con todas las ventanas, enviare una version alfa al desarrollador de la extension.

Algunas complicaciones en la conversion

Me temo que aun con lo que llevo convertido de java Swing a UNO-AWT, hay algunas cuestiones que no tienen sus equivalentes de manera trivial, o sea no se aplican de la misma manera que en java Swing, una de ellas es la de esconder y mostrar las ventanas. Existe la forma de hacerlo, y en el mejor de los casos, creo que en realidad es un problema que tengo con la libreria que utilizo para crear ventanas.
Un detalle que aun no he encontrado su equivalente, es el de asignar el item seleccionado en un ComboBox de UNO-AWT. En el API no se menciona nada de eso, es por esto que envie un correo tanto a el mailing list del grupo api y extensions , apartir de lo que me respondan determinare si es necesario crear un ticket en bugzilla para ello.

Una buena noticia es que he acabado de incorporar la traduccion de la funcionalidad a las nuevas ventanas en UNO-AWT, pero aun quedan varios detalles (como lo mencione antes) que no hay equivalentes. Antes de poder enviar la version alfa a Przemelek (correo de el desarrollador de la extension Oo2gdocs), me asegurare que por lo menos se logre parecer el comportamiento de las ventanas.

Mejorando la primera version completada

--Gerardo GR 06:54, 18 October 2011 (UTC)
Luego de haber podido implmentar (en su mayoria), la traducción de java Swing a UNO-AWT sobre la extension ooo2gdocs, he empezado a corregir algunos errores que deje atras para efectos de un mayor avance por dia. Desgraciadamente como me di cuenta el dia de hoy, algunos de estos errores, llegan a requerir cambios considerables en lo que llevaba, sin embargo, es bueno desde el punto de vista de desarrollo el que seuceda, esto mejor darme cuenta ahorita del error y no despues cuando ya le mande el nuevo codigo a el desarrollador de la extension.
Uno de los cambios principales fue en el manejo de los objetos que almacena un ComboBox, debido a que en realidad la interfaz XComboBox no almacena objetos, tuve que agregar en la clase que me sirve de encapsulación (OoComboBox), una lista que almacena objetos, teniendo asi (para la desgracia de los recursos) 2 veces los mismos objetos, solo que uno es el objeto en si y el otro es solo su representación en forma de String. Otro percance que tengo, y que es de bastante ayuda el tenerlo como lo modificare, es el modificar los nombres de los campos de las ventanas, de esta manera es mas facil para el programador (en este caso yo, o cualquier persona que lea mi codigo), entender que operaciones se llevan acabo donde.
Espero que terminando de atender estos errores, pueda tener la version alfa y poder enviarsela a Przemelek.

Avanzando con la mejora de lo que llevo de la conversion

Acabo de terminar de pasar los nombres de los campos graficos de las clases equivalentes de la extension Oo2gdcos, a nombres mas comprensibles. Antes los tenia como ooTextfField1, ooTextField2, lo que hacia dificil la lectura del codigo. Creo que esto ayudara a los demas programadores a entender mejor mi codigo. Ahora estoy revisando lo que llevo de la traducción, para poder dejarla lo mas parecida posible a su funcionamiento equivalente, en otras palabras, estoy mejorando lo que ya tenia.
Dejando de lado la parte de programación, he contactado a Robert Vojta, quien parece ser el lider del proyecto de desarrollo de un plug in para netbeans, que permite el diseño de dialogos. Le mande este correo para ver cual es el estatus del correo, y para hacerle saber lo que llevo de mi trabajo y si es que puede de ser de ayuda para el proyecto. Por ahora espero su respuesta y publicare lo relevante con respecto a esto en una siguiente entrada de mi bitacora.

Mejorando la primera version completada (parte 2)

En estos momentos, me encuentro terminando de implementar la ventana ImportDialog, la cual es la que muestra todos los archivos que tenemos en nuestra cuenta de google docs, en un dialogo. El problema que tengo, y que estoy tratando de solucionar, es el de despliegue de los archivos, al parecer tiene que ver con que el numero de columnas no esta siendo ocupado por el numero de entradas del documento (un GridInvalidDataException). Luego de terminar esta implementación, practicamente la ventana de ImportDialog, habra sido terminada, y seguire con la ventana de UploadDialog, la cual fue la que me hizo replantearme la logica del despliegue de los dialogs.

Mejorando la primera version completada (parte 3)

--Gerardo GR 06:50, 22 October 2011 (UTC)
Hasta ahora, he llegado en el punto en el que estoy perfeccionando las ventanas restantes, las cuales son solo 2, UploadDialog e ImportDialog, las mas importantes de la extension Oo2gdocs. La funcionalidad de ImportDialog he podido convertir su funcionalidad en un 70%-80%, ahorita solamente tengo algunos detalles con el filtrado de los documentos. Por este detalle, he decidido mejor enfocarme a terminar la ventana UploadDialog, ya que esta no involucra el manejo de Tablas (grids), lo que en su mayoria a causado los retrasos en el terminado de la version alfa.

Resumen de actividades

Debido al mantenimiento y migración que se le estaba dando al wiki de OpenOffice.org a ASF, no pude generar las entradas diarias a la bitacora, es por esto que esta entrada sera un resumen de las actividades que no registre.

Experiencia del trabajo colaborativo

Debido a que tuve algunas dificultades con respecto al desarrollo de la conversion, recurri constantemente a la lista de correos. Ahi preguntaba cuestiones espeficificas. Esta es una practica necesaria en el uso de la lista de correos, debido a que mucha gente esta inscrita a esta y para que te proporcionen ayuda eficientemente es necesario crear mensajes concisos y condensados. Gracias a la ayuda de muchas de las personas de la lista de correos me mantuve avanzando en el proyecto. Esto me dejo un aprendizaje muy importante que es:

   Cuando se empieza a formar parte de un gran proyecto de software libre, es necesario recurrir a la ayuda pertinente para poder avanzar, esto es 
 porque gente que esta en el proyecto tiene un mejor entendimiento del mismo. Aunque podamos entender nosotros mismos el proyecto (por las 
 habilidades), debido a que el progreso del proyecto es de naturaleza asincrona y distribuida, la manera de incorporarse rapidamente al 
 proyecto es preguntando y escuchando  porlos diferentes medios de comunicación como: listas de correo y canales de IRC.

Avance de la conversion de Oo2gdocs Java Swing a UNO-AWT

Durante el desarrollo de esta actividad, aparte de recurrir a la ayuda, tuve tambien que hacer algunas sustituciones en la extension, con el fin de que pudiera ser compatible con versiones anteriores de OpenOffice.org. El cambio mas importante fue el de quitar el XGrid del ImportDialog y poner en su lugar una XListBox. El XGrid realmente no fue el que se modifico en la ultima version de Oo (3.4 beta), fue un elemento llamado XGridDataModel, que permitia manejar los datos dentro del XGrid, ahora esta funcionalidad la lleva acabo un objeto llamado XMutableGridDataModel. Al terminar de reimplementar la GUI de la extension Oo2gdocs, envie a la pagina del proyecto , un issue-enhancement la mejora, subiendo la extension empaquetada y algunos parches del mismo. Gracias a esto el desarrollador: Przemysław Rumik, se dio cuenta de mi aporte, y en estos momentos se encuentra evaluando el desarrollo para incluir en la distribución esta alternativa de su extension, con lo que me quede con el aprendizaje de que: En los proyectos de software libre, lo importante es dar a concer tus aportaciones y ponerlas a disposición de la comunidad, asi todos nos
beneficiamos del desarrollo.