How to FIX SWT in Karmic Koala

3 noviembre 2009

Para aquellos que no lo han probado y se pueden estar llevando una sorpresa, cualquier aplicacion que use SWT en Karmic Koala ( vease Eclipse, Lotus Notes, Vuze, etc … ) tiene algunos problemas graficos. Entre estos puede darse que botones no respondan al click o algunos paneles con trees se vean en blanco.

 

El reporte del error:

https://bugs.launchpad.net/ubuntu/+source/gtk+2.0/+bug/442078/comments/28

 

Starting from 2.18 on, GTK+ changed some of its internal behaviour (google for “client side windows”). This change is intentional, and needed for other development. It doesn’t make any difference to programs using GTK+ correctly, but it makes problems with programs that use GTK+ in weird ways, making wrong assumptions that only accidentally worked in the past. So, to ease the transition until those programs get fixed, an environment variable has been introduced to simulate the old behaviour.

 

La solucion consiste basicamente en declarar una variable de entorno antes del arranque de la aplicacion:

 

GDK_NATIVE_WINDOWS=true

 

En caso de querer arrancar el eclipse simplemente deberiamos crear un script al estilo:

 

run.sh

 

y dentro de este declarar:

 

export GDK_NATIVE_WINDOWS=true

/opt/eclipse/eclipse

 

donde /opt/eclipse/eclipse es el path al binario ejecutable del eclipse.

 

Es probable que esta misma solucion, arregle a otras aplicaciones que tambien usen SWT. En algunos lugares dicen de bajar las libs 2.16 ( las cuales si andan con SWT) y reemplazarlas por las 2.18 pero posiblemente se arruinen muchas cosas del sistema.

Existen ya unas versiones beta de algunas de las aplicaciones, las cuales tienen soporte para la 2.18. Por ejemplo segun tengo entendido para el Lotus Notes hay una version 8.5.1 que corre en Karmic Koala. La version 3.5.2 del Eclipse ya traeiria solucionado el problema.How to FIX SWT in Karmic Koala


Desarrollo Web

5 octubre 2009

Hace poco empece a hacer una aplicacion , que basicamente es apenas un ABM, y decidí probar un framework web nuevo, ya se que esta colmado de frameworks web, la idea de Google Web Toolkit – Google Code de que el lenguaje de deploy sea javascript , y se codifique en java, probablemente sea una deficiencia mia por no adentrarme tanto en javascript, por ahi es poco de miedo ( lo admito ), sin embargo, al ver Google Web Toolkit , lease GWT de aqui en adelante, me encontré con un problema de dificil integracion con maven, y la verdad que despues de 3 o 4 años de utilizar maven , no me imagino otra forma de hacer builds, entonces mirando los frameworks que referencia google en la wiki de GWT http://gwtgallery.appspot.com/ empecé a utilizar Vaadin viendo que utiliza GWT pero solo para el renderizado, hace una especie de compilacion del código java que genera la presentacion en runtime y le pasa esa presentacion compilada a javascript al cliente, la verdad que me sentí muy comodo dentro de lo que es Java, y programar al estilo Swing, problemas con anonymous inner classes, pero dentro de todo eso, haciendo uso de un IoC como google guice , logre generar codigo más o menos aceptable para la construcción del sitio en cuestión, la verdad que debo reconocer que me convenció mucho como framework a diferencia de wicket este framework no necesita de un template para renderizarse, sino que se utiliza, modificaciones a los css predeterminados del framework para modificarlo a gusto del usuario, tambien utilize por primera vez en un proyecto una base de datos de objetos como neodatis , volviendo a el tema del framework tengo que destacar tambien que esta muy bien documentado, y tienen un libro gratis en pdf para poder descargarlo, posee licencia apache 2.0 .
En cuanto a las contras, tengo que admitir que no es facil diseñar una navegacion , en wicket es muy sencillo , en el return un mensaje se puede devolver un objeto Page y el framework direcciona la navegación, aquí hay que reemplazar la main window de una application que es instanciada por cada usuario conectado, la abstraccion dificulta un poco esto ya que el que codifica tiene que modificar el estado de el objeto Application para poder cambiar de ventana.


Closures en C

28 septiembre 2009

Suena lindo no? Bueno no es tan así pero esta bastante cercano. Tras mis años viviendo encerrado en la cueva, alias mi casa, y mis noches programando en C descubrí que la clave para mejorar la delegación y mejorar la funcionalidad de nuestras aplicaciones en C es la de utilizar punteros a funciones.

Para dar un ejemplo de estos, voy a mostrarles una implementación que estuve desarrollando para el manejo de listas desde C

collections.h

#ifndef COLLECTIONS_H_
#define COLLECTIONS_H_
   #define _XOPEN_SOURCE 500
   #include "collections.h"

   struct link_element{
       void *data;
       struct link_element *next;
   };

  typedef struct link_element t_link_element;

   struct dlink_element{
       struct dlink_element *previous;
       void *data;
       struct dlink_element *next;
   };

   typedef struct dlink_element t_dlink_element;
#endif /* COLLECTIONS_H_ */

list.h

#ifndef LIST_H_
#define LIST_H_
    #define _XOPEN_SOURCE 500

    #include "collections.h"

    typedef struct{
        t_link_element *head;
        int elements_count;
        sem_t semaforo;
    }t_list;

   t_list *collection_list_create();
   int     collection_list_add( t_list *list, void *data );
   void  *collection_list_get( t_list *list, int num );
   void   collection_list_put( t_list *list, int num, void *data );
   void  *collection_list_switch( t_list* list, int num, void* data );
   void   collection_list_set( t_list* list, int num, void* data, void (*data_destroyer)(void*));
   void  *collection_list_find( t_list *list, int (*closure)(void*) );
   void   collection_list_iterator( t_list *list, void (*closure)(void*) );
   void  *collection_list_remove( t_list *list, int num );
   void   collection_list_removeAndDestroy( t_list *list, int num, void (*data_destroyer)(void*) );
   void   collection_list_removeByPointer( t_list *list, void *data, void (*data_destroyer)(void*) );
   void   collection_list_removeByClosure( t_list *list, int (*closure)(void*), void (*data_destroyer)(void*) );
   int     collection_list_size( t_list *list );
   int     collection_list_isEmpty( t_list *list );
   void   collection_list_clean( t_list *list, void (*data_destroyer)(void*) );
   void  collection_list_destroy( t_list *list, void (*data_destroyer)(void*) );
#endif /*LIST_H_*/

Un ejemplo básico de como crear una lista:

t_list *list = collection_list_create();
collection_list_add(list, "Leonardo");
collection_list_add(list, "Raphael");
collection_list_add(list, "Michelangelo");
collection_list_add(list, "Donatello");
collection_list_add(list, "Splinter");

Vamos a ver el caso de 2 funciones bastante útiles, la primera es el iterator con el cual podemos recorrer todos los elementos de la lista y el segundo es el find con el cual podemos buscar un elemento en la lista.

void ninja_print(char *name){ printf("%s\n", name); }
collection_list_iterator( list, &ninja_print );

Como se puede ver en este ejemplo, el código lo que hace es nos imprime cada uno de los elementos de la lista, hay que tener en cuenta que esto es totalmente posible de hacer en C salvo por un pequeño detalle. Solo la implementación GNU de C, es decir el GCC, nos permite definir inner functions. Por lo que podemos colocar la funcion ninja_print dentro de una función. Esto nos resultaría casi como hacer un Closure salvo por el detalle de que C no permite funciones anónimas. Nos encantaría ver algo así:

collection_list_iterator( list, void (*)(char *name){ printf("%s\n", name); }  );

Pero de momento el estándar no lo define, quizás habrá que esperar a la nueva revisión de C para ver este tipo de cosas.

Aun así vamos veamos algunos ejemplos mas, esta vez con el find:

int ninja_findMaster(char *name){ return strcmp(name, "Splinter" ) == 0; }
collection_list_find( list, &ninja_findMaster );

Esto resulta algo similar al iterator, salvo que ahora nuestro “closure” retorna un valor indicando si encontró algo no. Este ejemplo no tiene mucho sentido ya que el find nos devuelve un puntero al elemento encontrado y en este caso el elemento es lo que estábamos buscando. Así como esta implementada seria una buena forma de implementar un “collection_list_contains” y si “collection_list_find” devuelve NULL es que no encontró nada.
Pero en caso de que guardemos estructuras complejas dentro de la lista, podríamos utilizar el ninja_findMaster para buscar entre alguna de las propiedades del elemento y que nos retorne el putero al elemento en si.

Finalmente y una de las cosas mas interesantes es la forma de destruir la lista:

collection_list_destroy( list, &free );

Obviamente esto tiraría segfault porque los elemento son estáticos pero si fueran dinámicos nos simplificaría muchos. En caso de que la lista manejara un tipo complejo de datos, es decir algo que contenga punteros o descriptores en su interior, como buena practica se debería realizar un destructor para ese tipo de datos y pasárselo al collection_list_destroy.

Por ultimo, les dejo un ejemplo final

typedef struct{
   char* name;
   int age;
}t_person;

t_person *person_create(char* name, int age){
   t_person *person = malloc( sizeof(t_person) );
   person->name = name;
   person->age = age;
   return person;
}

void person_destroy(t_person *person){
   free(person);
}

int main(int argc, char** argv){
   t_list *list = collection_list_create();
   collection_list_add(list, person_create("Juan",20) );
   collection_list_add(list, person_create("Pedro",20) );
   collection_list_add(list, person_create("Hector",20) );

   int find_person(t_person *person){ return strcmp(person->;name,"Juan") == 0; }
   t_person *findedPerson = collection_list_find(list, &find_person);
}

Mientras que en Java el mismo find seria:

Persona findedPerson;
for( Person person: persons){
   if( person.getName().equals("Juan") ){
      findedPerson = person;
   }
}

CHAN???

<source languague=”java>
</source>

Seguir

Get every new post delivered to your Inbox.