Así las cosas, comencé el desarrollo con SWT basándome solo en supuestos. Todo anduvo bien hasta que llegó la hora de programar la funcionalidad de zoom. Una vez finalizada, mientras testeaba dicha funcionalidad, realicé la siguiente prueba: primero generé un nuevo documento, que consistía en una matriz cuadrada de 200 casilleros de lado. Cada casillero es a su vez un cuadrado compuesto por 40 píxeles de lado. Navegué por la ventana, configurando la vista a diferentes niveles de zoom y usando las barras de desplazamiento. A medida que alejaba la vista y más celdas se visualizaban simultáneamente, comenzó a hacerse evidente una ralentización en la performance.

En el nivel más bajo de zoom, casi lograba visualizar la totalidad de las 40.000 celdas que componían el modelo completo. Con ese factor de zoom activo la aplicación tardaba alrededor de 7 segundos en terminar de renderizar todas las celdas, corriendo en un hardware de término medio. Eso era demasiado a mi criterio.

Entonces decidí hacer lo que en realidad debería haber hecho desde un principio: desarrollé una prueba relativamente sencilla de performance comparando SWT por un lado y Java 2D por otro. El API Java 2D es un componente estándar de la plataforma Java SE, por lo cual no es necesario referenciar a ninguna librería adicional para poder utilizarlo.

La prueba solo abarca el caso puntual al que hago referencia. De ninguna manera pretende comparar todas y cada una de las características gráficas disponibles en ambas librerías. En síntesis lo que hace es copiar una misma imagen una determinada cantidad de veces, llenando la superficie de otra imagen. La imagen original es escalada de forma tal de que todas las copias quepan en el destino, una al lado de la otra. Este proceso se repite una cantidad predefinida de veces y por último se muestra la imagen final en pantalla.

Para la ejecución de los test se copió una imagen cuadrada de 40 píxeles de lado en una grilla también cuadrada de 100 x 100 posiciones. Con esto ya tenemos 10.000 copias. Además, la misma prueba se ejecuta 20 veces seguidas. Por último, el test completo se repite 5 veces para obtener datos más generales. Todas las mediciones están expresadas en milisegundos.

Los resultados de las mediciones de tiempo realmente me sorprendieron. Java 2D resultó entre 3 y 12 veces más rápido que SWT, dependiendo en entorno de tiempo de ejecución. Mi hipótesis es que SWT no está utilizando la aceleración por hardware o bien no hace un uso muy eficiente de la misma. No se me ocurre otra explicación.

Recursos

Código fuente de ambos test. También se incluye la imagen de prueba y los archivos de proyecto específicos para Eclipse: Descargar

Cabe aclarar que cuando el evento es ejecutado, el Sash todavía permanece en la misma posición en la que estaba antes, y seguirá allí a menos que hagamos algo para cambiarlo. La posición en donde se soltó (la que determina la nueva distribución horizontal deseada para ambos paneles) es proporcionada a través del objeto "SelectionEvent", pasado como parámetro al evento. En la línea 08 podemos apreciar su asignación a una variable local. En la línea 10 se calcula la magnitud del cambio y en la 11 y 12 se cambia el ancho del panel derecho. Por último, en la línea 14 se invoca al método "layout" del contenedor inmediatamente superior a los elementos que están siendo reordenados. En este caso se trata del objeto "Shell" que representa la ventana. Mediante esta invocación se logra que el panel derecho y el mismo Sash se adapten al nuevo ancho del panel izquierdo.

Recursos

Código fuente de ejemplo: Descargar

Actualización

Ejemplos

ClsVector

ClsVector agrega un conjunto de métodos simples que se pueden utilizar para acceder a los elementos del vector obteniendo un tipo de dato específico. Esto nos evita tener que estar casteando constantemente los valores retornados.

Ejemplo de uso:

Estos métodos get tipificados son muy prácticos en el entorno Java ME, en donde no existe la posibilidad de utilizar programación genérica (generics).

ClsOrderedVector

En Java ME es imposible ordenar datos utilizando SQL y bases de datos relacionales, con lo cual un simple ordenamiento ascendente se puede tornar en todo un desafío.

La segunda extensión de la que se ocupa este artículo, llamada ClsOrderedVector, es una especialización derivada de la anterior, ClsVector. En ella se agrega todo el código necesario para poder ordenar los elementos alojados dentro del vector. Para poder hacerlo de una forma genérica, se construyó la interface IntComparator. El mecanismo de ordenamiento solo funcionará correctamente si todos los elementos son de un mismo tipo o al menos comparables entre sí. El algoritmo de ordenamiento utilizado es una implementación de QuickSort en lenguaje Java desarrollada por Sun Microsystems hace ya algunos años.

Ejemplo de uso:

Este segundo ejemplo va a ser un poco más sofisticado. Para el mismo se creó una nueva clase ClsPerson, cuyas instancias serán ordenadas dentro del vector. También se creó ClsPerson_Name_Comp que implementa la interface IntComparator.

Nótese la existencia de una relación muy estrecha entre la clase ClsPerson y el comparador ClsPerson_Name_Comp. Es por este motivo que el nombre elegido para el comparador comienza justamente con el nombre de la clase a la cual debe comparar. Por convención, la segunda parte del nombre indica la propiedad que se utiliza para la comparación (ordenamiento), y la última parte siempre es Comp para denotar que se trata de un comparador.



Código:

Se podrían crear más comparadores para ClsPerson si la clase tuviera otras propiedades por las cuales fuera necesario ordenar, o si se deseara realizar un ordenamiento descendente además de del ascendente mostrado en este ejemplo. El comparador asignado a un ClsOrderedVector puede cambiarse tantas veces como sea necesario llamando al método ClsOrderedVector.setMobjComparator(), pero hay que tener en cuenta que para que el ordenamiento realmente se ejecute es necesario llamar al método ClsOrderedVector.sort() que es el que realmente realiza el trabajo de ordenar el contenido del vector.

Una forma alternativa de mantener los datos ordenados dentro de un vector en principio vacío es primero setear el comparador adecuando  para luego ir insertando los elementos con el método ClsOrderedVector.orderedInsert().

Recursos

Este Zip incluye las clases analizadas, el código de ejemplo que las implementa, la documentación JavaDoc, y el proyecto para importar desde Eclipse:
Descargar

Implementación del agoritmo QuickSort realizada por Sun Microsystems:
http://java.sun.com/applets/jdk/1.4/demo/applets/SortDemo/QSortAlgorithm.java

Configuración de la placa de vídeo

Configuración de KDE

1. Ir a Configuración del Sistema
2. Solapa General >> ícono Comportamiento de las Ventanas
3. Sección Comportamiento de las Ventanas >> solapa Translucidez
4. Chequear Usar translucidez/sombras
5. Aparece un mensaje de advertencia diciendo que el soporte de translucidez es nuevo y puede causar problemas. En realidad ya no es tan nuevo, y personalmente nunca he tenido problemas. Acepte el diálogo con el mensaje si le gusta la aventura.
   
6. Al activar esta opción, se habilitan tres solapas adicionales en donde se pueden configurar los efectos a gusto de cada uno. Solo a modo de guía, adjunto pantallas con mi configuración actual.

Solapa Opacidad


Solapa Sombras


Solapa Efectos

Finalmente, unas pantallas de ejemplo mostrando el resultado final de todas estas configuraciones:

Esta transparencia solo se activa al mover la ventana

1. Navegar en alguno de los dos paneles hasta el archivo que se desea editar (ej. /etc/fstab)
   
   
   
   
   
2. Invocar el menú contextual del archivo
3. Ir al ítem de menú Acciones de Usuario >> Edit as Root
4. Se nos presentará el diálogo en el cual debemos introducir la contraseña del root
   
   
   
   
   
5. Al aceptar el diálogo de contraseña, si todo está correcto se nos abrirá el editor de texto KWrite ejecutándose con credenciales de root, con lo cual podremos modificar y grabar el contenido del archivo sin inconvenientes.
   
   
   

Mediante wxTheApp

Mediante wxGetApp()

#ifndef ClsApplication_H
#define ClsApplication_H

#include <wx/app.h>

class clsApplication : public wxApp
{
    DECLARE_CLASS( clsApplication )
    DECLARE_EVENT_TABLE()

public:
    clsApplication();
    virtual ~clsApplication();
};

DECLARE_APP( clsApplication )

#endif // ClsApplication_H