feb
21

“Programming with gtkmm 3″, guía del desarrollador

La guía oficial de la Gnome Foundation es un muy buen punto de partida para cualquier desarrollador que quiera introducirse en el mundo de Gnome/GTK+ en C++, pero no existe una versión oficial en formato ebook o PDF. Generalmente no suele pasar mucho tiempo hasta que alguien hace el trabajo de maquetarlo correctamente, pero esta vez no he sido capaz de encontrar ninguna versión en condiciones de la guía de programación oficial de gtkmm para poder pasármela al tablet, así que he acabado haciendo mi propia versión. Podéis descargárosla desde el siguiente link:

Programming with gtkmm 3 (PDF)

feb
16

Configurando Eclipse para programar en C++/GTK3 (Linux)

Cuando empecé a investigar sobre las herramientas de desarrollo para Gnome me topé con el nombre de Anjuta varias veces. Anjuta es el IDE oficial del proyecto Gnome, ofrece un soporte sólido para el desarollo de programas GTK mediante los lenguajes de programación C y sus bindings para C++, Java, JavaScript y Vala.

La verdad es que el aspecto de la herramienta es bueno, incluye hasta un diseñador de interfaces WYSIWYG, pero receloso como soy de duplicar el conocimiento, me mostraba reticente a tener que aprender a usar una nuevo entorno de desarollo. Por ello y antes de ponerme manos a la obra, me propuse investigar si existía alguna forma de usar una herramienta que era por mí de sobra conocida: el IDE Eclipse.

Eclipse era originalmente un IDE destinado principalmente al desarrollo de aplicaciones Java, pero con el paso del tiempo fue ganando soporte para otros idiomas a través de plugins y builds específicos. Para C/C++ en particular, existe el plugin CDT, que añade soporte básico para compilación, enlazado, debugging, resaltado y autocompletado para este lenguaje. Configurar CDT y compilar usando la librería estándar de C/C++ es bastante fácil, sin embargo no se puede decir lo mismo del proceso para añadir soporte a librerías externas/no estándar como GTK, sobre todo para un novato como yo. La información que existe en internet sobre el tema es difusa y en muchos aspectos inexacta, y la interfaz de configuración de Eclipse no ayuda demasiado.

Es por ello que he decidido redactar este tutorial paso a paso sobre como configurar Eclipse para desarrollar en C++/GTK. No soy un experto, así que agradeceré cualquier corrección o experiencia que pueda añadir exactitud al proceso.

El punto de partida

Parto de una distribución Linux-Fedora 16 de 64 bits, con Eclipse para Java instalado. Las instrucciones para la instalación de paquetes serán las propias para este sistema operativo, así que tendrás que buscar el nombre del paquete correspondiente si usas otro. Si añades los comandos de tu distribución en los comentarios para instalar cada uno de los paquetes que aparecen en este tutorial gustoso los añadiré junto a los de Fedora.

Instalando soporte para C++/GTK

Primero, tenemos que instalar el compilador de C++. Para Fedora, podemos usar el comando de consola:

yum instal gcc-c++

Las librería GTK, así como las librerías de Gnome fueron diseñadas para C99, lo que significa el soporte para otros lenguajes se hace mediante bindings. En particular, el binding de GTK para C++ se llama gtkmm. En principio, instalar gtkmm debería ser suficiente para instalar como dependencia las librerías necesarias para desarrollar en GTK. El comando para Fedora sería:

yum install gtkmm30

Instalamos también las librerías de desarollo de gtkmm. Técnicamente, instalar las librerías de desarrollo debería resolver las dependencias necesarias para instalar gtkmm.

yum install gtkmm30-devel

Técnicamente, el sistema está listo para compilar.

Instalando Eclipse y el plugin CDT

Hay que instalar el plugin CDT para añadir soporte para C/C++ a eclipse. El comando en Fedora sería

yum install eclipse-cdt

Si no tienes instalado Eclipse, la resolución de dependencias de esta del paquete lo instalará también.

Creando un proyecto y activando el entorno de desarollo para C++/GTK

Arrancamos Eclipse, abrimos el menú contextual desde el explorador de proyectos, seleccionamos “New Project” > “C++ Project”.

Creando un nuevo proyecto en C++

Creando un nuevo proyecto en C++

Vamos a crear una carpeta de código fuente y a incluir un fichero de C++ con un ejemplo muy simple de ventana en GTK para Gnome 3. Al final usaremos este código, en las primeras imágenes hemos usado una versión más corta para probar el autocompletado más tarde:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
#include <gtkmm.h>
#include <gtkmm/button.h>
 
int main(int argc, char *argv[])
{
  Gtk::Main kit(argc, argv);
 
  Gtk::Window window;
  Gtk::Button button("Hello World");
 
  window.add(button);
  button.show();
 
  Gtk::Main::run(window);
 
  return EXIT_SUCCESS;
}

Como se puede ver en la imagen, Eclipse no reconoce ni las cabeceras ni las instrucciones de gtkmm.

Eclipse marca la semántica de gtkmm no reconocida

Eclipse marca la semántica de gtkmm no reconocida

El primer paso será hacer que Eclipse reconozca la semántica y el autocompletado de código para gtkmm. Para ello, tenemos que indicarle a Eclipse en qué directorio puede encontrar los archivos de cabecera y las definiciones de funciones y símbolos necesarios. En el explorador de proyectos de Eclipse, pulsamos el botón derecho sobre el nombre del proyecto y elegimos la opción “Properties” del menú contextual.

A continuación navegamos a través de las opciones de la barra lateral hasta alcanzar las opciones de construcción del proyecto(C/C++ Build ->Settings->GCC C++ Compiler->Includes). Usando el botón de añadir, añadimos el directorio donde se encuentran las cabeceras de gtkmm en nuestro sistema operativo. En Fedora 16, ese directorio se encuentra en la ruta /usr/include/gtkmm.

Incluyendo los archivos de cabecera de gtkmm

Incluyendo los archivos de cabecera de gtkmm para habilitar el autocompletado y el reconocimiento de sintaxis


Configurando el compilador

Mediante la combinación de teclas CTRL+B le indicaremos a Eclipse que compile y enlace los archivos binarios a partir del código fuente. En el estado actual, Eclipse no será capaz de compilar porque pese a poder resolver los símbolos específicos de gtkmm, no será capaz de resolver las referencias a otros símbolos dentro de gtkmm.h, así como enlazar los archivos binarios de objetos donde se implementa la funcionalidad de GTK. Para ayudarnos a configurar de manera rápida el compilador y la localización en el sistema de archivos de las dependencias viene en nuestra la herramienta pkg-config.

Resolviendo dependencias de una manera rápida y sencilla con pkg-config

Lo que viene a continuación es una pequeña explicación de como funciona pkg-config. Si ya sabes como funciona, o te da igual mientras funcione, pasa al siguiente apartado

pkg-config es, a grosso modo y entre otras cosas, una herramienta de configuración y resolución de dependencias. Permite a través de una cadena que representa una librería o recurso obtener una cadena de texto preformateada según el estandar de argumentos de entrada de gcc que contiene las definiciones necesarias para poder compilar el recurso especificado.

Un ejemplo es la mejor manera entender como funciona. Si ejecutamos el siguiente comando desde la consola:

[user@laptop]$ pkg-config --libs --cflags gtkmm-3.0
-DGSEAL_ENABLE -pthread -I/usr/include/gtkmm-3.0 -I/usr/lib64/gtkmm-3.0/include -I/usr/include/atkmm-1.6 -I/usr/include/giomm-2.4 -I/usr/lib64/giomm-2.4/include -I/usr/include/pangomm-1.4 -I/usr/lib64/pangomm-1.4/include -I/usr/include/gtk-3.0 -I/usr/include/cairomm-1.0 -I/usr/lib64/cairomm-1.0/include -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/gtk-3.0/unix-print -I/usr/include/gdkmm-3.0 -I/usr/lib64/gdkmm-3.0/include -I/usr/include/atk-1.0 -I/usr/include/glibmm-2.4 -I/usr/lib64/glibmm-2.4/include -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/sigc++-2.0 -I/usr/lib64/sigc++-2.0/include -I/usr/include/pango-1.0 -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12  -pthread -lgtkmm-3.0 -latkmm-1.6 -lgdkmm-3.0 -lgiomm-2.4 -lpangomm-1.4 -lgtk-3 -lglibmm-2.4 -lcairomm-1.0 -lgdk-3 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0 -lcairo-gobject -lpango-1.0 -lfreetype -lfontconfig -lgmodule-2.0 -lcairo -lsigc-2.0 -lgobject-2.0 -lgthread-2.0 -lrt -lglib-2.0
[user@laptop]$ _

La linea de retorno de la instrucción(la segunda), sería la lista de argumentos que habría que pasarle al compilador para que pueda resolver las dependencias de un archivo de código fuente que use cualquier recurso de gtkmm versión 3.0.

Como puede verse, mediante el argumento de compilador -I se incluyen los directorios donde se encuentran las cabeceras y archivos de objetos, dependientes del sistema operativo y la configuración local del usuario. Quizás os suene la importación -I/usr/include/gtkmm-3.0, que especifica el directorio que hemos usado antes para activar el autocompletado en Eclipse. También es interesante ver que especifica las opciones -lgkt-3 -lgtkmm-3.0, que mediante la opción -l de gcc especifica que se va a usar la librería gtkmmm para el enlazado.

En esta llamada a pkg-config hemos usado tres argumentos:

  • --cflags: ordena a pkg-config que devuelva en la cadena todos los argumentos que el compilador necesitaría para poder compilar(ojo, no enlazar) un código fuente que contenga referencia a recursos y símbolos agrupados en el paquete de nombre especificado.
  • --libs: ordena a pkg-config que devuelva en la cadena todos los argumentos que el enlazador necesitaría para poder enlazar código fuente y objetos que contengan referencias a recursos y símbolos agrupados en el paquete de nombre especificado.
  • gtkmm-3.0: es el nombre del recurso, también llamado paquete, para el cual se quieren obtener las dependencias. Los paquetes con las definiciones de dependencias normalmente se instalan automáticamente cuando instalamos el paquete de desarrollo concreto mediante el gestor de paquetes de nuestro sistema operativo. Por ejemplo, cuando antes hicimos:

    yum install gtkmm30-devel

    en alguna parte del sistema de archivos se instaló un archivo llamado “gtkmm-3.0.pc” que contenía las definiciones de dependencias para gtkmm.

    Aparte del paquete que hemos usado para gtkmm versión 3, existen otros paquetes como gtk+3.0 o zlib. Por poner un ejemplo, considerando la instalación de mi sistema operativo similar a la de cualquier programador, más de 120 paquetes de resolución de dependencias están instalados. Las definiciones de paquetes instaladas en el sistema operativo pueden mostrarse ejecutando el siguiente comando:

    pkg-config  --list-all

    También existen paquetes de dependencias para versiones antiguas y para compilado multiplataforma. Si hubiésemos querido obtener las dependecias para gtkmm 2.4 en vez de la 3.0, nos hubiera bastado con cambiar el nombre del paquete a gtkmm+2.4.

Llegados a este punto, la potencia de pkg-config viene de la combinación de esta orden con la sintaxis específica de bash. Una sentencia que contenga otra sentencia en la misma línea encerrada entre comas francesas 「`」 se ejecutará sustituyendo el contenido de las comas por la cadena de salida de la sentencia entre comas. Un ejemplo:

[user@laptop]$ echo "Esto está fuera de las comas francesas`echo "'Y esto está dentro de las comas'"`"
"Esto está fuera de las comas francesas 'Y esto está dentro de las comas'"
[user@laptop]$ _

La utilidad de esta funcionalidad se demuestra al permitirnos combinar gcc y pkg-config de la siguiente manera:

[user@laptop]$ g++ main.cpp -o main.bin `pkg-config --libs --cflags gtkmm-3.0`
[user@laptop]$ _

Podemos saber cuál es realmente el comando ejecutado usando echo de la siguiente manera:

[user@laptop]$ echo "g++ main.cpp -o main.bin `pkg-config --libs --cflags gtkmm-3.0`"
"g++ main.cpp -o main.bin -DGSEAL_ENABLE -pthread -I/usr/include/gtkmm-3.0 -I/usr/lib64/gtkmm-3.0/include -I/usr/include/atkmm-1.6 -I/usr/include/giomm-2.4 -I/usr/lib64/giomm-2.4/include -I/usr/include/pangomm-1.4 -I/usr/lib64/pangomm-1.4/include -I/usr/include/gtk-3.0 -I/usr/include/cairomm-1.0 -I/usr/lib64/cairomm-1.0/include -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/gtk-3.0/unix-print -I/usr/include/gdkmm-3.0 -I/usr/lib64/gdkmm-3.0/include -I/usr/include/atk-1.0 -I/usr/include/glibmm-2.4 -I/usr/lib64/glibmm-2.4/include -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/sigc++-2.0 -I/usr/lib64/sigc++-2.0/include -I/usr/include/pango-1.0 -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12  -pthread -lgtkmm-3.0 -latkmm-1.6 -lgdkmm-3.0 -lgiomm-2.4 -lpangomm-1.4 -lgtk-3 -lglibmm-2.4 -lcairomm-1.0 -lgdk-3 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0 -lcairo-gobject -lpango-1.0 -lfreetype -lfontconfig -lgmodule-2.0 -lcairo -lsigc-2.0 -lgobject-2.0 -lgthread-2.0 -lrt -lglib-2.0"
[user@laptop]$ _

Se ve el resultado, ¿No? La sentencia anterior compila el archivo main.cpp y expande la orden pkg-config de tal forma que añade al final de la sentencia todas los argumentos necesarios para resolver cualquier dependencia necesaria para gtkmm. Esta instrucción con esta sintaxis tan elegante soluciona de una tacada la mayoría de los problemas de compilación dependiente del entorno y nos va a servir ahora para finiquitar la configuración de compilación de Eclipse de una manera rápida y sencilla.

Resolviendo dependencias en Eclipse usando pkg-config

Finalmente, vamos a lograr compilar el programa anterior añadiendo la sentencia pkg-config a la configuración de montaje de Eclipse. Abrimos el menú de configuración del proyecto pulsando el botón derecho sobre el nombre del proyecto y seleccionamos “Properties/Propiedades”.

Primero configuramos el compilador para añadirle dependencias. Seleccionamos “C/C++ Build ->Settings->GCC C++ Compiler->Miscellaneous” y en el campo de texto “Other flags” añadimos el siguiente token:

`pkg-config --cflags gtkmm-3.0`

Atención con las comas francesas 「`」, son importantes. Consulta el apartado “Resolviendo dependencias de una manera rápida y sencilla con pkg-config” para más información.
Configurando la resolución de dependencias en eclipse con pkg-config

Configurando la resolución de dependencias en el compilador de eclipse con pkg-config

A continuación vamos a configurar el enlazador. Seleccionamos también desde el menú propiedades del proyecto  ”C/C++ Build ->Settings->GCC C++ Linker->Miscellaneous” y en el campo de texto “Linker flags” añadimos el siguiente token:

`pkg-config --libs gtkmm-3.0`

Atención con las comas francesas 「`」, son importantes. Consulta el apartado “Resolviendo dependencias de una manera rápida y sencilla con pkg-config” para más información.
Configurando la resolución de dependencias en el enlazador de Eclipse con pkg-config

Configurando la resolución de dependencias en el enlazador de Eclipse con pkg-config

Técnicamente está listo para construir el proyecto. Lo que hemos hecho es indicar a Eclipse que añada las sentencias de resolución de dependencias al final de la instrucción que usa para llamar al gcc.

Compilando…¡Hola Mundo!

En Eclipse-CDT podemos configurar varias configuraciones de compilación personalizadas. Por defecto, Eclipse añade a todos los proyectos nuevos las configuraciones “Debug” y “Release”, aplica la primera por defecto. Toda la configuración que hemos hecho hasta ahora se ha aplicado a la configuración de “Debug”, así que si en este momento compilar mediante “Release” obtendremos el mismo resultado que al principio. Habría que reconfigurar de nuevo “Release” o cualquier nueva configuración de manera análoga a lo hecho anteriormente para hacerlo funcionar.

Si pulsamos CTRL+B construiremos el proyecto usando la configuración por defecto “Debug”. La salida por consola debería ser algo parecido a los siguiente:

**** Build of configuration Debug for project Hola_Mundo ****
 
make all
Building file: ../src/main.cpp
Invoking: GCC C++ Compiler
g++ -I/usr/include/gtkmm-3.0 -O0 -g3 -Wall -c -fmessage-length=0 `pkg-config --cflags gtkmm-3.0` -MMD -MP -MF"src/main.d" -MT"src/main.d" -o "src/main.o" "../src/main.cpp"
Finished building: ../src/main.cpp
 
Building target: Hola_Mundo
Invoking: GCC C++ Linker
g++ `pkg-config --libs gtkmm-3.0` -o "Hola_Mundo"  ./src/main.o
Finished building target: Hola_Mundo
 
**** Build Finished ****

Eclipse genera una carpeta con el nombre de la configuración en la cual crea todos los archivos necesarios para construir el proyecto basándose en la configuración de construcción de éste. Por ejemplo, para la configuración “Debug” creará una carpeta de mismo nombre en la raíz del proyecto conteniendo el código objeto, una estructura de makefile, el binario,etc..

Archivos autogenerados después de construir el proyecto

La carpeta "Debug" y todo su contenido fueron autogenerados después de construir el proyecto

Ninguno de los archivos autogenerados al construir el proyecto debe ser modificado manualmente. Eclipse reescribe todos los archivos cada vez que se le ordena construir el proyecto, así que todos los cambios se perderán. Si quieres editar alguna de las configuraciones, por ejemplo la del makefile, tendrás que hacerlo cambiando el campo correspondiente en las opciones del proyecto.

Si pulsamos CTRL+F11 ordenaremos a Eclipse arrancar la última versión construida del proyecto. ¡Hola Mundo!

¡Hola Mundo!

¡Hola Mundo!

ene
25

Enviando correo desde la consola con sendmail

Tan fácil como instalar el paquete “sendmail” y hacer lo siguiente:

user@user:~$ echo "
To: destinatario@dominio.com
From: remitente@dominio.com
Subject: Este es el asunto
En la siguiente línea va el contenido del mensaje
" | sendmail destinatario@dominio.com

Atención con las comillas, una comilla abierta en bash te permite seguir escribiendo en la siguiente línea.

ene
20

El trabajo no es lo mismo que el esfuerzo

La obra de Haruki Murakami rebosa de pequeñas conversaciones de gran valor entre sus personajes. En la conversación a continuación participan dos personas, Watanabe y Nagasawa.

Watanabe, el narrador, se considera a sí mismo la persona más corriente del mundo. La vida no tiene especial interés para él, pero sin embargo no es un ser depresivo. Se limita a dejarse llevar por las corrientes de la vida, observando la extrañeza del mundo desde la posición privilegiada de aquel que no tiene especial interés por nada,.

El otro interlocutor, Nagasawa, es de aquel tipo de personas que puede con todo. Cualquier cosa complicada parece sencilla si él lo realiza. Esto le lleva a acaparar siempre todo lo que esté a su alcance, a lograr cualquier meta, porque, según él, “cuando a tu alrededor todo son oportunidades, es muy difícil pasar de largo sin aprovecharlas”.

La amistad de Watanabe y Nasagawa nace cuando éste último le destaca por encima de los demás miembros de la residencia, mediocres según él y entre otras razones , por no haber leído la obra “El gran Gatsby“, de Scott Fitzgerald.

La conversación tiene lugar en la habitación de Nasagawa, en una residencia de estudiantes de Tokyo:

-¿No hay nada en la vida que te dé miedo? -le pregunté.

-No soy tan estúpido -dijo Nagasawa-. Por supuesto, muchas veces la vida me da miedo. Como a todo el mundo. La diferencia está en que no lo admito como premisa. Quiero llegar hasta donde pueda empleando todas mis fuerzas. Tomando lo que quiero, dejando lo que no quiero. Así es como vivo. Si meto la pata, me detengo y lo reconsidero. Si uno le da la vuelta a esta sociedad injusta, entiende que en el mundo puede explotar sus posibilidades.

-Eso me parece muy egoísta, la verdad.

-¡Yo no me quedo mirando al cielo esperando que caiga la fruta! A mi manera, me esfuerzo mucho. Me esfuerzo diez veces más que tú.

-Tal vez tengas razón -reconocí.

-Por eso a veces miro alrededor y me siento asqueado. Me digo: ¿por qué no se esfuerzan más estos tíos? Lo único que saben hacer es quejarse.

Miré, estupefacto, a Nagasawa.

-A mí me da la impresión de que en este mundo la gente se mata trabajando -tercié-. ¿Me equivoco?

-No es más que trabajo -explicó Nagasawa llanamente-. El esfuerzo del que hablo es algo que se hace por propia iniciativa, con un propósito determinado.

-¿Por ejemplo, mientras otros se quedan satisfechos al saber que han encontrado un empleo, tú empiezas a estudiar español?

-A eso me refiero. Antes de la primavera, dominaré el español. Ya hablo inglés, alemán y francés. Y el italiano, bastante bien. ¿Crees que todo eso se consigue sin esfuerzo?

El fumaba un cigarrillo; yo pensaba en el padre de Midori. A éste jamás se le había ocurrido estudiar español siguiendo unos cursos de la televisión. Probablemente, tampoco había pensado nunca en la diferencia entre esfuerzo y trabajo. Tal vez estuviera demasiado ocupado para ello.

extraido de「Norwegian Wood (ノルヴェイの森)」, de Haruki Murakami. Traducción de Lourdes Porta. Edición en España por Tusquets, 2011

 

jul
26

¡Vuelve JavaDiKt!


Copyright Luis A. Arce

Dice el refrán que más vale tarde que nunca, al fin tras un par de meses en el que los exámenes y un viaje han detenido completamente el desarrollo de JavaDiKt, puedo decir con orgullo que hoy ha sido publicada una nueva versión.

Las mejoras en esta versión se han enfocado principalmente en arreglar los numerosos fallos que la anterior trajo bajo el brazo:

  • Un diálogo animado es mostrado ahora mientras se está realizando una exportación
  • Arreglado el bug en el cual al exportar en PDF los caracteres unicode aparecían como “?”
  • Arreglado el bug en el que el panel de dibujo reconocía un trazo inexistente llamado “E”
  • Arreglado el bug que impedía a los usuarios de mac arrancar JavaDiKt usando el lanzador .app
  • Se han arreglado varios bugs menores

La última vez prometí que me pondría a mejorar la bases de datos, pero he considerado que arreglar estos fallitos era prioritario. Aunque los cambios parezcan pocos, puedo asegurar que han llevado bastante trabajo. El bug del lanzador para mac en particular ha sido especialmente tedioso de arreglar(si realmente está arreglado, espero que sí).

En otro orden de cosas, últimamente he estado alguna que otra cosilla con Android, y he llegado a la conclusión de que trasladar JavaDiKt a la plataforma de Google es viable. Por eso, voy la planificada reforma de la base de datos se va a centrar en que ésta sea compatible sin cambios tanto en PC como en móvil, en detrimento de hacer más estable su interfaz a corto plazo. Esto demorará ligeramente los planes que tenía de liberar la base de datos como API antes de Septiembre, pero el objetivo merecerá la pena.

Finalmente, comunicaros que el repositorio oficial de JavaDiKt ha cambiado de servidor. Seguiré usando la mayoría de las funciones de la forja de Red Iris(registro, ficheros, etc…) pero los últimos cambios en el código solo podrán obtenerse desde la siguiente dirección usando un cliente SVN usando como nombre de usuario y contraseña “guest”:

http://local.ajaest.net/rep/JavaDiKt/

El código fuente seguirá siendo empaquetado y subido a la forja cada 2 versiones como siempre.

Con esto y un bizcocho… poco más que añadir. No me queda más que despedirme de vosotros, intentaré que no pase tanto tiempo entre entrada y entrada, los próximos meses iré revitalizando el blog poco a poco.

may
13

¡JavaDiKt, mejor proyecto de educación en el CUSL!

Premiados en el V Concurso Universitario de Software Libre. De arriba a abajo y de izquierda a derecha: José Antonio Jiménez Carmona de "Predesys", Raúl Jiménez Ortega de "GeoRemindMe", Javier Angulo Lucerón de "Terminal Previewer", Sergio Garcia Mondaray de "Yakito", Miguel Sempere Sánchez de "SocialSight", Rubén Dugo Martín de "GeoRemindMe", Luis A. Arce González de "JavaDiKt" y David Saltares Márquez de "IberOgre y Sion Tower"

Terminada la fase final del V Concurso Universitario de Software Libre, después de muchas risas mezcladas con interesantes debates y ponencias, fueron entregados los premios de las distintas categorías:

  • Premio especial del Concurso Universitario de Software Libre a “Yakito“, de Sergio Garcia Mondaray de la Universidad de Castilla la Mancha.
  • Premio al mejor proyecto de Accesibilidad a “Geo Remind Me“, de Raúl Jiménez Ortega, Anna Peña Martínez y Rubén Dugo Martín de la Universidad de Granada.
  • Premio al mejor proyecto de Comunidad a “IberOgre y Sion Tower“, de David Saltares Márquez de la Universidad de Cádiz.
  • Premio al mejor proyecto de Educación a “JavaDiKt“, de Luis A. Arce González de la Universidad de Sevilla.
  • Premio al mejor proyecto de Innovación a “Predesys“, de José Antonio Jiménez Carmona de la Universidad de Sevilla.
  • Premio al mejor proyecto de Sistemas a “TP (Terminal Previewer), de Javier Angulo Lucerón de Universidad de Castilla la Mancha.

Enhorabuena a todos los ganadores, que tienen proyectos fantásticos y ademas son gente de puta madre. La experiencia ha sido fantástica, y la verdad, me anima muchísimo a pasarme por la !NotBarraLibreCamp de Cádiz el 27 de mayo.

Por mi parte, yo me voy contentísimo con el reconocimiento que le ha sido dado a mi proyecto. Hablando sinceramente, ha llegado más lejos de lo que pensaba allá por Octubre del año pasado, cuando empecé a esbozar a lápiz la interfaz de JavaDiKt en la hoja de un cuaderno.

Pero este premio no significa la final del proyecto. Aunque los dos próximos meses estaré hasta el cuello de exámenes y trabajos, el desarrollo de JavaDiKt volverá con fuerza en Julio. Estoy convencido a convertir JavaDiKt, tal y como dice su eslogan, en el diccionario de Kanjis definitivo.

Y a todos aquellos que apoyaron el proyecto, ya sea descargando, evaluando , usando, difundiendo,… ¡Muchas Gracias! ¡Sin vuestra ayuda sin duda ésto no sería posible!

may
11

Nueva versión de JavaDiKt

Ayer publiqué una nueva versión de JavaDiKt, la 1.1.5, podéis descargárosla desde aquí. Entre las mejoras incluidas están:

  • Añadidos exportadores HTML y PDF
  • Añadidos estilos “Tabla” y “Tarjeta de Estudio”
  • Añadido menú contextual de edición a aquellos componentes que aún carecían de él(Lista de diccionarios, variantes, ventana de radical, etc..)
  • Mejorada velocidad de arranque
  • Nuevo manual en HTML
  • Añadido icono de carga animado
  • Se han arreglado varios bugs menores

Durante los dos próximos meses empieza la temporada complicada de exámenes, así que, posiblemente, no habrá nueva versión al menos hasta Julio. A partir de entonces, empezaré las pruebas de calidad para sacar de una vez a JavaDiKt de la beta, junto a nuevos exportadores y funcionalidades.

Ésta es, además, oficialmente la última versión que participará en el Concurso Universitario de Software Libre. La  final, que se realizará los días 12 y 13 de mayo en la Escuela Técnica Superior de Ingenierías Informática y de Telecomunicación de la Universidad de Granada, contará con la participación de los proyectos finalistas, entre ellos JavaDiKt.

Aconsejo a todos los que tengáis interés os paséis por alguna de las ponencias, algunas de ellas muy interesantes, como “Software Libre,¿Hacia donde va?“, en la que participarán diversos ponentes relacionados con el mundo de las TIC y el Software Libre. Podéis ver la programación aquí.

 

may
04

Publicada la fuente TrueType de Javadikt

Tal y como prometí y como aperitivo para la próxima versión de JavaDiKt, he publicado hoy la fuente TrueType que usa éste programa. Se llama Sazanami-Hanazono Mincho, su originalísimo nombre viene de que esta fuente es fruto de la fusión de las fuentes libres Sazanami Mincho y Hanazono.

Me he permitido hacer un cutre-logo de 5 minutos que sigue más o menos la estética del logo de JavaDiKt, recalcando de esta forma que esta fuente es un subproyecto del proyecto JavaDiKt.

Tal y como escribí en la página oficial(en inglés), la fuente fue hecha de manera “ad-hoc” para JavaDiKt usando FontForge, y dado que apenas tengo conocimiento sobre programación de fuentes, no puedo asegurar 100% que la fuente funcione correctamente y que esté correctamente optimizada. Por eso animo a cualquiera que sepa un poco del tema a que la revise y colabore para mejorarla.

abr
29

JavaDiKt en abril. Trabajando, exportando… y nueva fuente TrueType

Después del sorpresón del concurso de Software Libre, toca seguir currando en la próxima versión de JavaDiKt. Poco a poco vamos alcanzando los objetivos de la versión Mirai, este mes me he centrado en ampliar las funcionalidades de exportación disponibles, de forma que en la próxima versión se podrá exportar en al menos dos formatos nuevos (PDF y HTML) usando tres estilos (“Texto plano“, Tarjeta de estudio” y “Tabla“, pulsa para ver ejemplos). En particular la exportación en tabla me parece la más interesante, podréis usar la interfaz de JavaDiKt para ordenar los Kanjis dentro de la tabla y elegir que columnas de información se mostrarán y en que orden gracias a al panel de selección y ordenación de campos.

Copyright Luis A. Arce

Panel de selección y ordenación de campos

En otro orden de cosas, para la próxima versión liberaré también la fuente TrueType usada en JavaDiKt para representar el texto en Japonés, que hasta ahora venía empaquetada dentro del archivo jar. Me costo mucho encontrar una fuente libre capaz de representar los 13108 caracteres almacenados en la base de datos de KANJIDICT, que pudiese mostrar todos los caracteres de la codificación Latin-1 y que no fuese tan pesada como las fuentes pan-Unicode que existen, , así que lo que hice fue crearme una usando dos fuentes libres muy parecidas, la fuente Sazanami Mincho del Wada Laboratory de la universidad de Tokyo y la fuente Hanazono Mincho, del proyecto GlyphWiki. El resultado de esta fusión es la fuente “Sazanami-Hanazono Mincho”, podéis observar que no me he comido la cabeza con el nombre.

Copyright Luis A. Arce

Descripción de fuente Sazanami-Hanazono Mincho

Dado que la licencia más restrictiva es la de Sazanami mientras que Hanazono es practicamente de dominio público, usaré la licencia está para liberarla, que es de tipo BSD. De esta manera pretendo que la persona que haga una exportación pueda usar la misma fuente que en el programa para modificar los archivos resultantes si quiere para que se muestren como en JavaDiKt, así como intentar cerrar el vacío que yo me encontré al buscar una fuente de estas características.

Poco más contar, ya tengo ganas que llege la final de Granada, a ver si consigo sacar la versión 1.1.5 antes.

abr
27

¡JavaDiKt finalista del V Concurso Universitario de Software Libre!

Madre mía, no podía haber empezado el día. Hoy, la organización del V Concurso Universitario de Software Libre ha publicado la lista de proyectos finalistas del concurso, entre las que se encuentra JavaDiKt. Podéis consultar la noticia aquí, la lista completa de nominados es:

  • Geo Remind Me, de Raúl Jiménez Ortega, Cristian González Guerrero y Rubén Dugo Martín de la Universidad de Granada. [Blog][Código]
  • IberOgre y Sion Tower, de David Saltares Márquez de la Universidad de Cádiz. [Blog][Código]
  • JavaDiKt, de Luis Alfonso Arce González de la Universidad de Sevilla. [Blog][Código]
  • Predesys, de José Antonio Jiménez Carmona de la Universidad de Sevilla. [Blog][Código]
  • TP (Terminal Previewer), de Javier Angulo Lucerón de Universidad de Castilla la Mancha. [Blog] [Código]
  • Yakito, de Sergio Garcia Mondaray de la Universidad de Castilla la Mancha. [Blog][Código]

Menciones especiales:

  • PirannaFS, de Jesús Leganés Combarro de la Universidad Rey Juan Carlos. [Blog][Código]
  • FreePhyloTree, de Aarón Bueno Villares de la Universidad de Cádiz [Blog][Código]
  • SocialSight de Miguel Sempere Sánchez de la Universitat D’Alacant. [Blog][Código]
  • Cormoran, de Jaime Gil de Sagredo Luna de la Universidad de Alcalácomo [Blog][Código]

Mi enhorabuena a todos los finalistas, mencionados  y a todos los concursantes en general, son todos grandes proyectos. El nivel del concurso está altísimo, creo que podemos estar orgullosos en España de nuestra comunidad de Software Libre.

Animo también a todo el mundo a que acuda a la fase final que se realizará el 12 y el 13 de Mayo en la Escuela Técnica Superior de Ingeniería Informática y Telecomunicación de la Universidad de Granada. Aparte de la entrega de premios, hay varios actos y presentaciones programadas alrededor del Software Libre, el horario provisional puede consultarse aquí.

De manera extra-oficial, también caerán unas cuantas cervecitas :) . ¡Nos vemos en Granada!

Entradas más antiguas «