TBO's blog

Estoy pensando en cómo implementar el sistema de deshacer/rehacer de TBO, y no se cuál sería la mejor forma de hacerlo.
Las dos opciones que estoy barajando son:
1. Guardar el estado. La idea es que antes de cada operación que se pueda deshacer se guarde el estado actual del documento en la lista de deshacer.
pros: creo que es fácil de implementar/mantener
contras: El coste en memoria puede ser considerable, y clonar el estado en cada operación puede ser computacionalmente costoso.
2. Guardar la operación y su inversa. La idea es que antes de cada operación que se pueda deshacer se guarde la operación a realizar junto con su inversa en la lista de deshacer.
pros: Menor coste tanto en memoria como de calculo.
contras: Pueden existir operaciones cuya inversa sea muy compleja.
Me decanto por la segunda opción, pero lo mismo debería mirar un poco el código de gimp o inkscape un poco para ver qué es lo que hacen.

Hoy me he puesto y he grabado un vídeo del estado actual de TBO para mostrar un poco su funcionamiento. Aquí está el vídeo:

Aunque escriba poco en el blog, el desarrollo de TBO está siendo continuo y fluido. Me he puesto unos objetivos básicos en la forja de rediris con fechas y todo, y por ahora voy cumpliendo.
Si todo va bien, la versión 0.9 estará lista para finales de marzo.
También se puede seguir el desarrollo desde mi rama git
Voy a poner aquí el log del subversion para que se vea el avace:
Herramienta de texto (sin funcionalidad)
10 files changed, 236 insertions(+), 1 deletions(-)
Borrado de objetos y selección corregida
4 files changed, 35 insertions(+), 15 deletions(-)
Ojos, bocas y nuevos cuerpos
19 files changed, 1465 insertions(+), 112 deletions(-)
Rotación de objetos.
4 files changed, 138 insertions(+), 12 deletions(-)
Mejorados algunos detalles de interfaz
5 files changed, 13 insertions(+), 12 deletions(-)
Ya se pueden mover/redimensionar los monigotes :D
5 files changed, 267 insertions(+), 28 deletions(-)
Ya se pintan los monigotes en las viñetas!!
10 files changed, 166 insertions(+), 5 deletions(-)
Todo listo para añadir monigotes a las viñetas
1 files changed, 4 insertions(+), 17 deletions(-)
Unselect tool, liberando memoria y esas cosas
10 files changed, 58 insertions(+), 6 deletions(-)
Añadidos eventos sobre monigotes y bien escalados
1 files changed, 29 insertions(+), 3 deletions(-)
Monigotes en la herramienta de monigotes
1 files changed, 36 insertions(+), 6 deletions(-)
Mejoras visuales en las herramientas doodle y selector
2 files changed, 5 insertions(+), 5 deletions(-)
Tool Area scrollable & fondo & scroll drawing area
2 files changed, 18 insertions(+), 4 deletions(-)
Arreglado GtkWarging del action_group
1 files changed, 8 insertions(+), 5 deletions(-)
Plantillas de monigotes con un expander
3 files changed, 135 insertions(+), 76 deletions(-)
Buscando plantillas de doodle en el fs
1 files changed, 65 insertions(+), 0 deletions(-)
Ejemplo de uso de gmarkup.
3 files changed, 126 insertions(+), 0 deletions(-)
Mejor sistema de llamadas a eventos herramientas
16 files changed, 371 insertions(+), 111 deletions(-)
Herramienta de dibujado de monigote (no funcional)
17 files changed, 323 insertions(+), 35 deletions(-)
Añadida la vista detalla de viñeta
6 files changed, 128 insertions(+), 21 deletions(-)
Herramientas avanzadas del selector
2 files changed, 94 insertions(+), 26 deletions(-)

Aunque no escriba mucho en el blog el desarrollo de TBO sigue adelante. He hecho algunas cosillas interesantes en cuanto a la estructura del proyecto y a la "metodología" de desarrollo y en cuanto al código el proyecto empieza a tomar color y ya casi parece una aplicación :P

Esta es la pinta que tiene ahora mismo la aplicación. Ahora mismo se puede:
- Crear un nuevo cómic
- Añadir/borrar/moverse entre páginas
- Añadir/borrar/seleccionar/mover/escalar viñetas
Próximos pasos:
- Añadir una barra lateral para meter controles de las herramientas
- Implementar el guardado y apertura de ficheros .tbo (tengo que definir cómo serán los ficheros .tbo)
- Añadir el modo de edición de viñeta (aquí está to el meollo)
Cambios estructurales/desarrollo
Con respecto al desarrollo, he dejado de usar cmake para usar las autotools. Esto puede ser una decisión arbitraria, y en realidad lo es, pero es que la mayoría de los proyectos gnome/gtk utilizan este tipo de herramientas y para hacer más "compatible" TBO he decidido utilizar esto.
El cambio de cmake a autotools no ha sido traumático ni mucho menos, hay un montón de documentación por ahí y además me he basado en el código del proyecto epiphany.
Por otra parte, antes estaba usando bazaar (además del svn de rediris con bzr-svn) para gestionar las versiones de TBO, pero me ha dado por cambiarme a git, y ahora es lo que estoy usando (con git svn para el svn de rediris). Así que la evolución del proyecto se puede seguir los cambios desde aquí.
Por ahora no tengo mucho más que decir. Si todo va bien y consigo una versión funcional quiero intentar meter TBO en el proyecto gnome, guadalinex->ubuntu->debian y que sea algo más o menos utilizado.
Todas las sugerencias, parches y críticas serán bien recibidas.

Ahora que he decidido implementar TBO con C me han surgido problemas que no había tenido en cuenta, como por ejemplo la compilación. Con python no es necesario compilar nada, así que puedes escribir tu código modularizado sin ninguna precupación, pero cuando comienzas a escribir códgio en C y separas funcionalidad en diferentes ficheros comienzas a necesitar herramientas que faciliten la compilación, como son los makefiles, que compila solo las partes modificadas no teniendo así que compilar todo el proyecto siempre que se haga una modificación, sino que simplemente se compila lo modificado.
Los makefiles ofrecen una gran potencia, pero escribir un makefile completo con soporte multiplataforma es muy complejo, así que existen herramientas que te facilitan la vida como las autotools o cmake.
Para estas herramientas tú escribes un fichero donode especificas qué quieres compilar (e instalar con make install) y qué librerías necesitas, con número de versión incluso, y con un simple comando comprueban que todas las librerías necesarias están instaladas y generan un makefile para poder compilar e instalar.
La mayoría de los usuarios avanzados de linux habrá utilizado alguna vez las autotools para compilar, ejecutar un ./autogen.sh, un ./configure, etc. Yo me he decidido por utilizar cmake. Por qué cmake, pues porque me lo recomendó Alex (del proyecto robodo), es lo que usan en kde para compilar todo, me lo explicó por encima y me pasó un tutorial básico.
Hice unas cuantas pruebas y me gustó. Una de las cosas buenas de cmake es que puedes compilar en un directorio de compilación para no tener que ensuciar tu directorio de código, por ejemplo creas un directorio build dentro de src y dessde ahí ejecutas cmake ../ y te mete todo el código compilado y demás ficheros dentro del directorio build. También ofrece una salida en la compilación coloreada, que aunque parezca que no es una funcionalidad importante :P
Aquí está mi fichero CMakeList.txt dentro de src:
project(TBO) cmake_minimum_required(VERSION 2.8) set(DATA_DIR ${CMAKE_INSTALL_PREFIX}/share/tbo-data CACHE string "Shared directory") CONFIGURE_FILE(${CMAKE_CURRENT_SOURCE_DIR}/config.h.cmake ${CMAKE_CURRENT_SOURCE_DIR}/config.h) FIND_PACKAGE(GTK2) set(SRCS tbo.c ui-drawing.c ui-menu.c ui-toolbar.c ) INCLUDE_DIRECTORIES(${GTK2_INCLUDE_DIRS}) add_executable(tbo ${SRCS}) target_link_libraries(tbo ${GTK2_LIBRARIES})
Además de compilarte de forma fácil todos los ficheros .c cmake/autotools te permite generar ficheros (config.h) definiendo variables. Esto lo utilizo yo para definir el directorio donde están los datos, imágenes y demás. Es la variable DATA_DIR definida en el fichero de cmake. En este fichero config.h.cmake defino DATA_DIR con la variable del cmake:
#cmakdefine DATA_DIR "${DATA_DIR}"
Y si le paso la opción -DDATA_DIR=... puedo cambiar el directorio de dónde el código pillará las imágenes y los ficheros de datos. El cmake generará un fichero config.h con #define DATA_DIR "..."
En definitiva, que cmake facilita mucho el proceso de compilación y la búqueda de dependencias en diferentes plataformas.


Lo he estado pensando bien, y me he decidido por implementar TBO con C, con GTK+Cairo, en lugar de usar python.
La razón por la cual prefiero usar C es porque con python ya he realizado algunas aplicaciones de escritorio, y aunque esta añade elementos con los que no he tratado, como el uso de cairo, la mayor parte de la aplicación será en pygtk, y creo que esa tecnología ya la conozco suficiente.
Por otra parte está el lenguaje C, siempre me ha gustado. Es simple a la vez que potente y elegante, y desde que programo en python, C lo tengo más que abandonado, por eso estoy perdiendo soltura.
Así pues prefiero usar C que será más divertido e instructivo, y además como sigo usando gtk y cairo no implicará mucha más complicación que si lo hiciera con python.


Con el proyecto TBO pretendo hacer un editor fácil de usar para poder crear cómics, presentaciones guías de programas, etc.
La idea del proyecto es presentar una interfaz (hecha con gtk) más o menos sencilla que ofrezca un editor para que quién no sepa dibujar pueda hacer un cómic en cinco minutos para hacer una presentación de algo, un tutorial de cómo funciona algo o para dibujar un cómic gracioso.
Para ello el editor dispondrá de diferentes modelos prediseñados para ir añadiendo a las viñetas y el usuario tan sólo tendrá que colocar los personajes y escribir los bocadillos correspondientes para tener un cómic.
Quiero desarrollar el proyecto con python, gtk y cairo. Y tengo intención de que se pueda exportar a png y pdf y además quiero que añadir nuevos sets de personajes a añadir.




