GNOME 3 assistant for DevAssistant

UPDATE: Now you can just type “da pkg install gnome3” in your terminal!

Every time that you start to write a new application for your favorite Linux Desktop, in your favorite programming language, you must to do the same repetitive and annoying steps: checkout some cool GNOME application; copy some configure.ac; some Makefile.am; perhaps a src/main.c… and after 15 minutes you are ready to rock the world.

A couple of weeks ago I published a GNOME 3 application template in C in my GitHub, but you need to edit a lot of files to adapt the code for your desired application name, so I start to write some bash scripts to automatize the task. Then I realized that DevAssistant allows you to create your own assistants, so I have written a DevAssistant that uses my template code as a base. You can check it out in my GitHub repository and create your GNOME applications at the speed of light, at least the basic scaffold, in the meantime that the promising Builder is available in our stable distributions.

The steps to create your own application you need DevAssistant version >= 0.10 (there is a COPR for Fedora 21) and follow this simple steps:

$ cd
$ git clone --recursive git@github.com:alvaropg/da-c-gnome3.git
$ export DEVASSISTANT_PATH=~/da-c-gnome3
$ da create gnome3 -n ~/myproject

The assistant is like a 0.0.0.0.1 version so perhaps you can find some bugs. Please, let me know if you experiment some error with a comment or with a bug in GitHub.

Weekly digest

Forever onwards

The last few months have been a tough time for me. But things are getting better, step by step. I took the decision to change my job, moved to a new flat and landing a new job where I’m more confortable, developing in C, Python and something of GTK! (well, 2.4, nothing is perfect). I’m in Visual Tools right now, a little company that works with digital video, so I’m working with FFmpeg, RTSP, some GTK for the local interface and other cool stuffs.

During this time I’ve had some difficults to maintain Almanah and the Facebook integration in GNOME Photos as was required. But now I have found the time. A new version of Almanah is going to be released in a few days and I have updated the Facebook integration branch in GNOME Photos, so I hope that I have no problems to do the job for GNOME 3.12.

Photo notifications in GNOME Shell

I have been working in a mockup about a possible new dimension to the GNOME Shell notifications.

Due to the high use of social networks by the users, it’s possible to offer a more social Desktop, with a great taste (I think). So, if some contact shares a photo in certain social network (like Mediaglobin, flickr, Instagram, Facebook, …) we can show a notification like that:

So, It would be cool if the new GNOME Photos application implement social integration and allow the users to stay connected with contacts photos in this way.

What do you think?

Status update

GObject library for Instapaper

I have been working in a GObject library for Instapaper API for a while, just for take some experience with librest. At the moment, you can only retrieve your bookmarks list and get the text content (parsed by Instapaper from the original URL). You can check it in my GitHub. The plans it’s to build a simple read-it-later like (I really like Words for Mac, here a review) application for GNOME 3, but without a clear roadmap or any deadline.

Almanah

After releasing three new versions for Almanah, 0.10.8 with tag support for test purpose; 0.9.1 and 0.10.1 with a critical bug fixed affecting the database encryption, it’s time to return the proposed roadmap and start to work in the SQLite VFS for a better diary database security. I’m very exciting about this work, because I have never work in something like that, something that this kind of “low-level” work. I hope to have something visible in one week.

Almanah tagging support

I have been working for a while in a new feature for Almanah, tagging support. And is ready for user testing, so feedback is welcome.

At the moment there is no great functionality, just tag the diary entries, but is the first step to allow the user make searches based in tags, print just entries with some tag, and so on.

This new feature has required some design modifications to the main window, including a new header in the diary entry view, where the tags are placed. Take a look.

I have used the EggWrapBox for this header, so the widgets wraps along the space with something similar to a responsive design🙂 As you see, the space between the tag bar and the entry is some ugly, I have thinking to place something like a thin line…

The tag widgets have been written from scratch with Cairo and fixed colors, so remains a lot of work in accessibility and the use of theme colors. The little “x” in the right allow the user to remove the tag for this entry, but I think it’s small and dificult to press, so need some work.

I have make a screencast to show you all the flow:

Of course, you can get the code and test it. Get it from Git git://git.gnome.org/almanah.

Aprender de las cosas más pequeñas

Estoy trabajando en el etiquetado de entradas para Almanah y por pequeña que pueda parecer implementar esta mejora, he aprendido algo sobre cuestiones que uno da por supuesto durante el desarrollo y he disfrutado con ello.

Lo primero al comenzar esta mejora fue plantear el esquema de la base de datos. Para Almanah empleamos una base de datos SQLite muy sencilla, con una única tabla para guardar las entradas, la cual tiene una clave primaria formada por tres campos: año, mes y día.

Sin muchas vueltas la primera solución que me vino a la cabeza es crear dos nuevas tablas, una para las etiquetas (con dos campos, etiqueta y un entero como clave primaria) y otra para la relación entre entrada y etiqueta (los tres enteros de clave de la entrada y al clave de la etiqueta). Sencillo, ¿no? Siempre he trabajado de esta manera de forma automática. Pues resulta que al compartir con Philip (el creador de Almanah) algunas cuestiones sobre lo que estaba realizando, entre ellas el esquema, me planteó porqué no usar una única tabla, con las claves de la entrada y un campo más de tipo texto para la etiqueta.

Pensé, “eso debe ser muy ineficiente porque buscar por una cadena en lugar de por un entero para buscar las entradas de una etiqueta dada debe costar mucho”, pero ¿porqué? ¿cuáles eran las ventajas reales y los inconvenientes de emplear una u otra forma? Así que nos pusimos a investigar un poco.

Después de las primeras búsquedas en StackOverflow mi propuesta de dos tablas parecía que se llevaba la palma, pero un poco más de indagación y empezamos a ver pruebas de carga con búsquedas en campos de tipo entero y tipo texto y las diferencias eran minúsculas para un volumen de datos medio, al rededor de un millón. Y por último encontré esta respuesta en StackOverflow que me pareció condensaba lo que yo estaba planteando y me hacía cambiar el punto de vista: lo importante no es el tipo, sino el volumen de lo que almacenas y el patrón de acceso. ¿Alguien más no está cansado de oír que una llave principal es mejor y más rápida siendo un entero? Pues desacte de esa idea, porque hay factores que influyen, la respuesta correcta a que tipo de clave primaria usar es: depende. Lo primero es tener claro su uso, su tamaño (de longitud), si se querrá modificar, …

Para confirmar todo esto realicé mis propias pruebas con los dos esquemas empleando unas 3000 entradas y 3 etiquetas por entrada. Pensé que estos datos serían reales y permitirían conocer el comportamiento para una situación posible, es decir, un usuario que emplease Almanah de manera intensiva y tras varios años. Los resultados fueron indiferentes, la velocidad de acceso era inferior a 0.06 segundos.

Por último, me pregunté si SQLite ofrecía algo de material al respecto. Pese a que la web da una sensación de anticuada, cuenta con documentación técnica muy completa y encontré muy interesante el siguiente enlace sobre planificación de queries porque me dí cuenta de como maneja SQLite las entradas, las claves y la importancia de los indices (siempre teniendo en cuanta las queries que se emplearán). También me resultó de mucha utilidad el documento sobre los tipos de datos, sobre todo el punto 3 sobre comparación porque la comparación entre enteros se realiza antes con una llamada a atof (convirtiéndolo en un número de coma flotante). Interesante, ¿verdad

La conclusión de todo esto es que siempre hay que ser crítico y poner en duda todo lo que te llevas entre manos, todas tus ideas dadas por supuestas y analizar hasta el fondo el porqué de las ideas. La recompensa por ello es muy gratificante y siempre sales ganando.

Finalizada la primera fase del nuevo diseño de Almanah

Tras muchos meses de trabajo, aunque sin mucho tiempo que poder dedicar, por fin está finalizado el nuevo diseño de la ventana principal de Almanah. Aquí la captura de rigor.

El principal objetivo con el nuevo diseño es, principalmente, adaptar Almanah a GNOME 3 aprovechando la ocasión para buscar una mejor experiencia en la redacción de la entrada en el diario por parte del usuario. Está claro que habrá mucho que mejorar, por ahora la ventana principal es muy rudimentaria y no cuenta con muchas opciones, pero este ahora es el reto y el comienzo.

Las principales mejoras son:

  • Barra de tareas más sencilla, con sólo cuatro botones: estilo de fuentes, selección de fecha, marcar como importante y un botón de menú a la derecha del todo para realizar acciones sobre la entrada (insertar fecha, enlaza, cortar, etc.). Aquí un captura del selector de fecha, del cual estoy orgulloso, si bien tiene algunos defectos por pulir.
  • Integración con GMenu. Eso ha permitido eliminar la barra de menús de la aplicación y ganar en claridad. Aquí captura.
  • Nueva zona de “eventos”, que permite ver los eventos del día (tareas creadas o concluidas y eventos del calendario). Espero que pronto se muestren los eventos ocurridos desde la última vez que el usuario escribió en el diario. Captura también.

Estos cambios sólo están disponibles en el repositorio, puesto que no se tiene pensado realizar una versión nueva de manera inmediata, si bien, mi compromiso es realizar una hoja de ruta para una próxima versión, incluyendo, al diseño ya comentado, la gestión de etiquetado, permitir al usuario introducir más de una entrada al día y dos tareas de fondo sin mucha visibilidad: realizar un añadido a SQLite para trabajar con los datos encriptados de manera directa ganando en seguridad (ahora se desencripta el fichero y queda expuesto) y centralizar la gestión del diario en una librería para poder realizar añadidos externos, como una extensión para GNOME Shell.

Resumen semanal

Durante esta semana he retomado mis estudios sobre informática y he conseguido algunos avances en Almanah.

  • Matriculado en el curso Computer Architecture, aunque voy tres semanas tarde, espero ponerme apunto en una semana y media…
  • Tras muchas vueltas, he conseguido que se muestre el menú de aplicación (GMenu). Por alguna razón, no es posible empleando cargar el GMenu desde un fichero .ui empleando  gtk_builder_add_objects_from_file, pero si cargando el fichero simplemente con gtk_builder_add_from_file. Ahora toca retocar la estructura de acciones, porque Almanah centra la funcionalidad en la ventana principal, que es única, pero considero que poco a poco debe ser la aplicación quien debe centralizar esta actividad, respecto a acciones generales, claro.