Entrevista en exclusiva al periodista Manuel Ligero y de cómo ha empezado a utilizar el editor Vim como herramienta a la hora de escribir sus artículos

Lo que más me fascina del blog (o una de las cosas que más me fascina) es la interacción con las personas que estáis al otro lado del cable “de internet” y leéis los artículos, ya sea de manera ocasional o de manera habitual.

Esa interacción, ese “feedback” siempre es interesante por lo inesperado y por lo enriquecedor del proceso “solitario” de escribir en un pequeño blog personal como este. Y en ocasiones surgen situaciones curiosas, como esta que hoy traigo hasta el blog.

Como sabéis desde hace tiempo, escribo en el blog mi propia experiencia adentrándome como neófito total en el uso del editor Vim. Han sido varios los artículos que has podido leer sobre Vim y espero que sean más, ya que siempre se descubren cosas interesantes de este editor de texto que no me resisto a compartirlas en el blog.

Cuando uno escribe, después no sabe “la vida” que tienen los artículos una vez que le das al botón publicar. Conozco las visitas que tienen, pero no la “historia” que hay detrás de cada una de esas visitas.

Hasta que de manera casual llegas a conocer una de esas historias detrás del artículo publicado. Como ha sido recientemente, en el que por Mastodon el usuario Manuel Ligero, me escribió y entre otras cosas “me echaba la culpa” de que por culpa de mi blog había empezado a utilizar el editor Vim como herramienta de trabajo.

He de decir, que un poco orgulloso sí me sentí, al conocer de primera mano que las letras que junto tienen significado y “mueven cosas” en las cabezas de quien las interpreta.

Pensé que quizás Manuel era programador o algo así, pero mi sorpresa fue cuando me dijo que era periodista “freelance”. ¡Vaya! Un periodista que utiliza Vim como editor de sus textos, dejando de lado otras opciones quizás más mayoritarias en su profesión, eso sí que era una sorpresa…

Me apetecía conocer un poco más en detalle del hecho, así que le pregunté si podía hacerle algunas preguntas para publicarlas en exlusiva en el blog y dar a conocer que Vim no solo es para “geeks” friki programadores.

Desde ya, le doy las gracias por haber aceptado la invitación y aquí puedes leer las preguntas que le hice y las respuestas que me dió.

Vhck: Hola Manuel, primero para poner el contexto ¿puedes decirnos de qué trabajas?

Manuel: Soy periodista, efectivamente. Escribo en la revista La Marea sobre cine y libros, fundamentalmente. Soy freelance y tengo que compatibilizar eso con otros trabajos, pero ese es mi favorito. Me siento muy afortunado porque me encanta lo que hago.

Vhck: Vamos al meollo de la cuestión. Me comentaste que has empezado a utilizar Vim como editor de texto, la herramienta principal de un escritor. ¿Hace cuanto que llevas usando Vim? ¿Qué te impulsó a dar ese cambio?

Manuel: Todos los humanos necesitamos cambiar nuestros hábitos de vez en cuando. Y los escritores y los periodistas… ¡también somos humanos! A veces no lo parece, pero sí.

Cambias de cuadernos, cambias de bolígrafos y, claro, también cambias de procesador de textos. En todos los casos, el cambio produce siempre un cosquilleo especial. Lo haces simplemente por probar. Unos te gustan y otros los desechas a la primera.

Yo llevo usando Vim desde hace un mes, aproximadamente. Y me encanta porque me centra. Me ayuda a no distraerme.

Vhck: Se habla mucho de la curva de aprendizaje de Vim para los recién llegados ¿Cómo fue tu caso y qué diferencias notas con el paso del tiempo y de uso de Vim?

Manuel: Al principio puede parecer un poco complicado, pero tampoco lo es tanto. No hay que ser un genio. Sólo tienes que aprender tres o cuatro comandos básicos (i, :A, :w, :q) y luego escribir, que es lo importante.

Los programadores usab una expresión “picar código” que también usamos los periodistas. Nosotros “picamos una entrevista”. Cada uno tiene su propio método pero muchos la “picamos” en bruto antes de editarla. Y para eso eso no necesitas cien mil tipos de letra. Sólo sentarte y empezar a picar.

Vhck: ¿Qué herramientas utilizabas antes y qué mejoras te aporta el uso del editor Vim respecto de esas herramientas?

Manuel: Antes usaba LibreOffice, pero ahora sólo lo hago para el volcado final del texto. Avanzo mucho más rápido con Vim, guardando el documento como “texto simple”.

Luego, ya, lo pongo bonito: cursivas, negritas, hiperenlaces, todo eso. Seguro que todo eso se puede hacer también con Vim, pero yo aún no sé. Quizás le esté dando un uso demasiado primario a la herramienta, pero a mí me vale. Avanzo más rápido. Eso es lo que me aporta: funcionalidad, concentración.

Vhck: ¿Has tenido alguna “incompatibilidad” al presentar textos escritos y editados con Vim en tu trabajo?

Manuel: No, porque como te digo, luego convierto ese texto a Formato de Texto Enriquecido, que creo que es el que menos problemas da para usarlo entre diferentes sistemas operativos. ¡Aunque corrígeme si me equivoco!

Vhck: En el tiempo que llevas de uso ¿Cual es la funcionalidad o plugin de Vim sin el que ahora y para tu trabajo ya no podrías dejar de utilizar (si es que hay alguno)?

Manuel: Creo que es demasiado pronto para contestar a eso. No soy un experto ni mucho menos. En principio, lo que me gusta de Vim es su simplicidad. Como estamos sometidos a tantos estímulos, yo agradezco mucho eso, la simplicidad, para no distraerme.

Para esto me gusta mucho Typora, también. No estoy diciendo que los Words de toda la vida están mal. Al contrario, tienen un montón de funcionalidades y eso está genial. Pero si lo que quieres es escribir, te vale con una hoja y un boli. O con Vim.

Vhck: ¿Aconsejarías el uso del editor Vim a otros periodistas o escritores? ¿En qué casos crees que Vim podría facilitarles su trabajo? 

Manuel: El procesador de texto es algo muy personal. Comprendo que haya mucha gente a la que le espante escribir a pelo en un terminal. A mí no. A mí me hace avanzar mucho más rápido.

Así que si a algún compañero o compañera le pasa lo mismo, pues que lo pruebe. Por probar no pasa nada. Lo mismo le ocurre como a mí y se engancha.

Vhck: La última palabra es tuya para que comentes lo que desees…

Manuel: Pues, sin querer dar la chapa, me gustaría que la gente entendiera la importancia que tiene el software libre y que aprendiera algo más de Linux, en cualquiera de sus versiones. Creo que Linux es una oportunidad extraordinaria para frenar la obsolescencia programada.

Hay mucha gente que tiene viejos equipos arrumbados porque no ha probado a quitarles el sistema operativo original y ponerles un Linux. Creen que es difícil, pero no lo es. Ya no.

Se llevarán una sorpresa, su bolsillo lo agradecerá (porque no necesitan comprar otro ordenador, aunque sí deberían hacer una pequeña aportación a los desarrolladores) y el medio ambiente también. No sólo lo agradecerá: es que lo necesita.

Muchas gracias a Manuel por su tiempo y haber accedido a responder a estas preguntas en exclusiva para el blog. ¿os ha parecido interesante? usad los comentarios del blog para opinar.

Espero que sirvan de “inspiración” o ejemplo para otros profesionales y como botón de muestra que hay herramientas libres que vale la pena descubrir.

En estos días que vamos a pasar mucho tiempo en casa, he pensado en rescatar y compartir un la entrevista a Álex Fiestas, Albert Astals y Aleix Pol que se realizó en Akademy-es 2019. Una tertulia informal pero interesante donde cuatro grandes desarrolladores de  la Comunidad KDE pasan un rato entretenido hablando sobre diversos temas.

Entrevista a Álex Fiestas, Albert Astals y Aleix Pol en Akademy-es 2019

En una terraza de Vigo, cerca del tráfico, varios integrantes de la Comunidad KDE decidieron finalizar su Akademy-es 2019 de Vigo organizada por KDE España con una charla distendida.

El objetivo es mostrar el lado más humano de una Comunidad que se define como «personas haciendo software para personas», así que, entre sorbo de cortado y sonido ensordecedor del tráfico Álex Fiestas (CTO de Mister Fantasy), Albert Astals Cid (ex-presidente de KDE España)  y Aleix Pol ( ex-presidente de KDE España y actual presidente de KDE e.V.) fueron entrevistados por José Millán (tesorero de KDE España) que les hizo hablar de su opinión de Akademy-es, las actividades de Barcelona Free Software (BFS), de las formas de atraer colaboradores al proyecto KDE, etc.

Hay que destacar que aunque hay mucho ruido de fondo, se puede entender casi todo lo que se dice, no obstante, fruto de la colaboración de algunos participantes del grupo de Telegram KDE – Cañas y Bravas, se ha realizado los subtítulos al castellano para esta entrevista.
Punto y aparte merece este hecho ya que esperamos que sea la primera de muchas colaboraciones del grupo auxiliar que se ha creado para ayudar al grupo de Comunicación de KDE España. Y es que tenemos mucho material pero poco tiempo para darle forma útil para la Comunidad y de forma desinteresada varias personas, no necesariamente técnicas, se han ofrecido para colaborar. Muchas gracias a ellas.
Y si estás interesado no dudéis en comentarlo en el grupo de Telegram de Cañas y Bravas y os añadimos al grupo de colaboración.

Ahora es el momento de ver la entrevista a Álex Fiestas, Albert Astals y Aleix Pol en Akademy-es 2019

Hoy quiero compartir con vosotros la entrevista en español que me han realizado para la web opensource.com

Hace unas semanas me llegó un correo en el que me pedían si me podían hacer una entrevista para publicarla en la web opensource.com

La verdad es que esa web está en mis feeds, y de hecho alguna vez he traducido alguno de sus artículos del inglés al español para publicarlos en mi propio blog.

Así que me resultó toda una sorpresa y también un honor el que quisieran dar a conocer mi pequeño blog en su web, tal como hicieron hace unos meses de un gran blog como el del amigo Lorenzo aka “atareao”.

Por tanto accedí y Chris Hermansen, editor de la web, me envió las preguntas, contesté y las han traducido al inglés y ya puedes leer el artículo en inglés en su web en este enlace:

• https://opensource.com/article/20/3/open-source-spanish

Le pedí permiso para poder publicar las preguntas y respuestas en español en mi blog, y me dijo que no había problema, así que además de visitar la página en inglés, puedes leer aquí la entrevista en español.

Desde aquí un agradecimiento enorme a Chris Hermansen y Don Watkins de la web opensource.com por la entrevista, vamos al lío:

Chris: Nos hemos encontrado varias veces en opensource.com, lo que me motivó  revisar tu presencia en el Internet.  Veo tu blog, Victorhck in the free world, con tus propios artículos y  varias traducciones de artículos originalmente en inglés.  ¿Qué te ha
 motivado en este proyecto maravilloso?  ¿Qué te motiva ahora mismo?

Vhck: Lo que me motivó hace ya casi 10 años fue el querer compartir aquello que iba aprendiendo sobre GNU/Linux y openSUSE. Quería que mi blog sirviera como ayuda a usuarios con similares problemas.

Ahora las distribuciones de GNU/Linux dan menos problemas, hay más hardware soportado y compatible, por lo que los artículos sobre tutoriales han quedado un poco relegados.

Pero sigue existiendo esas ganas de querer compartir y difundir sobre la pasión por el software libre y GNU/Linux.

Chris: Veo tu interés en openSUSE.  ¿Cómo elegiste esta distro?  ¿Estás ocupado con otras distros?

Un compañero de trabajo me habló sobre GNU/Linux y como el utilizaba openSUSE, me la recomendó hace ya 10 años. Desde aquella primera instalación de openSUSE 11.2 (creo recordar) no he dejado de utilizar openSUSE, salvo en puntuales ocasiones y por espacio de tiempo muy breve.

Y desde que se desarrolló Tumbleweed (la versión rolling release de openSUSE) mi vida geek es más feliz. Tengo un sistema estable y con las últimas versiones de los paquetes de software instaladas, sin necesidad de reinstalar mi sistema y volver a ponerlo a punto.

openSUSE me ofrece la oportunidad de disfrutar de GNU/Linux sin tener que preocuparme de GNU/Linux. No tengo que estar empleando tiempo en hacer que mi sistema funcione. Simplemente lo instalé, lo actualizo de manera regular (2 o 3 veces a la semana) y así tengo tiempo para el blog, y disfrutar de otras cosas.

Chris: ¿Qué haces “cuando no estás en el free world”? si no es muy personal… ¿desarrollador de software?  ¿Trabajas con software libre?

Vhck: Pues no soy ni desarrollador, ni programador, ni administrador de sistemas, ni nada de eso. Mi afición a la informática viene desde hace mucho tiempo, cuando con 14 años pedí que me apuntaran a un curso deBasic y Cobol.

Después la dejé a un lado por un tiempo. Y el descubrir GNU/Linux hace 10 años, me reconcilió con esta pasión que ha crecido más gracias a las comunidades con las que te vas poniendo en contacto gracias a internet.

Y en el trabajo, la verdad es que no disfruto de herramientas libres. Uso herramientas privativas en sistemas operativos privativos. Y muchas veces echo de menos mi openSUSE para realizar algunas tareas.

Chris: Un aspecto de tus artículos en general es que proveen una buena cantidad de detalles útiles.  Por ejemplo, este artículo sobre vim, que es probablemente mi “herramienta obligada para llevar a una isla desierta”.  ¿Cómo decides en un tema específico?  ¿Cómo decides el nivel de habilidad de tus lectores para tener una exposición útil?

Vhck: Ese artículo que mencionas sobre el editor Vim, pertenece a una serie que estoy escribiendo hace meses. Y se originó porque me empeñé en aprender a utilizar ese editor de texto del que todo el mundo habla bien, y mientras estoy en ese proceso de aprendizaje, comparto aquello que voy descubriendo en el blog, tanto para consultarlo yo mismo en el futuro, como para otras personas, por si les puede resultar útil.

Decido el tema sobre el que escribir, en función de lo que a mí me interesa. Lo bueno, es que coincide con algunos lectores que son los que visitan mi blog o están suscritos a él.

Chris: Además de artículos técnicos, sé que traduces artículos escritos originalmente en inglés.  ¿Cómo decides que un artículo merece traducción?

Vhck: Me gusta traducir aquello que me ha resultado interesante o útil. Y quiero compartirlo en el blog en español para la gran comunidad de “geeks” que o no tienen facilidad con el inglés o simplemente para difundir un recurso o web interesante.

Chris: En opensource.com  nos centramos mucho – quizás demasiado – en lectores que dominan el inglés.  De mi experiencia, existen mucha gente en otros sitios que prefieren información en su lengua materna.  Como escritor en castellano, ¿qué opinas sobre este tema?  ¿Tienes alguna idea del nivel de demanda para información sobre el software libre en (digamos) castellano?

Vhck: Las diferentes comunidades de proyectos de software libre (KDE, GNOME, openSUSE, Debian, Arch, etc) son comunidades globales, y utilizan el idioma inglés como idioma común para la documentación, foros, artículos, tutoriales, podcasts, etc.

Pero no hay que obviar, que hay comunidades locales, que prefieren consumir información en su propio idioma. Generalmente hay una parte de la comunidad que traduce no solo los paquetes de software, también la documentación o la wiki a otros idiomas.

Pero sigue habiendo una falta de información en idiomas distintos del inglés. Los blogs hacemos parte de ese trabajo de difundir, de dar a conocer, de ofrecer y generar contenido en un idioma diferente del inglés.

Chris: ¿A donde va Victorhck in the free world en el futuro?  ¿Podcasts?  ¿Canales de YouTube? ¿Incorporar otros escritores? 

Vhck: El próximo 2021 el blog cumplirá 10 años en la red. Puede no parecer mucho tiempo, pero para un blog pequeño y personal con contenido casi a diario, el mantener las ganas y la pasión por publicar después de 10 años, de verdad que es mucho tiempo.

He visto como muchos blogs cerraban, otros se reconvertían… no tengo planes para el futuro, me gusta improvisar. Pero lo que sí puedo afirmar ahora mismo, es que tengo el tiempo y las ganas para seguir escribiendo en el blog sobre openSUSE, GNU/Linux y software libre.

Quizás me tenga que reconvertir a otro formato, pero de momento
escribiendo me siento cómodo.

Chris: ¿Tienes otras aficiones aparte de este blog, como por ejemplo salto base o cocina de fusión?

Vhck: jejeje, ninguna de esas dos aficiones. Tampoco me gustan otras aficiones “geeks” como el manga o el anime.

Me gusta la música, me gustan los gatos y me gusta el chocolate.

No sé cual será la fórmula de la felicidad, pero disfrutar en compañía de mi pareja de la música en el sofá junto a mis 2 gatas y saboreando un trozo de chocolate negro (70% de cacao) se le acerca mucho…

Chris: Una última pregunta ¿Por qué firmas tus correos con GPG?

Victorhck: La verdad es que firmo los correos sin saber si el receptor utiliza GPG, es una manera de decir que yo utilizo GPG y que otros pueden enviarme correos cifrados si lo desean.

Al mismo tiempo, difunde el propósito de este gran software que sirve no solo para cifrar o firmar correos, si no también paquetes de software, repositorios, ISO’s de distribuciones de GNU/Linux y asegura que el software que has descargado es el mismo que los desarrolladores publicaron

Y hasta aquí la entrevista. De nuevo agradecer a Chris y Don redactores de opensource.com la entrevista.

Así ya me conocéis un poco mejor, aunque no sé si tiene eso algún interés… El interés es seguir difundiendo sobre el software libre cosa que sigo haciendo en mi blog…

Gracias si eres una de esas personas que pasas por el blog y algún artículo te ha parecido interesante…

Lo bueno de tener un proyecto abierto como KDE es que pueden trabajar personas con diversos intereses, desde técnicas (KDevelop o Kate) hasta artísticas (Krita o digiKam) pasando por lúdicas (KDE Games) o Educativas (KDE Edu). Así que no es de extrañar que aparezcan de nuevas si un desarrollador piensa que hay un hueco en este gran ecosistema. Me complace presentaros Ikona, una nueva aplicación creada para facilitar el diseño de iconos para Linux.

Ikona, programa para crear iconos para Linux

Una de las secciones habituales en el blog es la de personalización del escritorio mediante temas de iconos. De esta forma, hay unos 90 temas presentados, lo cual significa que tenemos opciones para todos los gustos, desde simples a barrocos, desde planos a 3D, desde muy windows-style hasta macqueros (o como quieran llamarse).

No obstante, nunca he hablado de ninguna aplicación que cree estos temas, ya que siempre he pensado que se hacían con programas como Inkscape o Gimp y mucho  talento y paciencia.

Así que me he asombrado descubrir que sí hay una aplicación de la Comunidad KDE para crear estos iconos, se llama Ikona y es una creación de Jan Pontaoski que ha lanzado directamente la versión 1.0.

En palabras del propio desarrollador:

«[…], esta es una primicia personal para mí. Es la primera vez que he lanzado una aplicación GUI que siento que está realmente pulida.

Creo que esta es también la primera aplicación de KDE que se ha lanzado que está predominantemente programada en Rust. Conozco rust-qt-binding-generator, pero no he visto ninguna aplicación de KDE que lo utilice.»

La aplicación nos permite utilizar una paleta de colores coherente con Breeze que podemos elegir al principio y exportar el icono a todos los tamaños estándar con un simple click.

Además, Ikona no es simplemente una aplicación visual, tiene la opción de trabajar mediante línea de comandos con ikona-cli, que nos permite, entre otras cosas, convertir iconos claros a oscuros con una simple orden.

Todo esto y mucho más ofrece de momento Ikona, si queréis más información no dudéis visitar jan Pontaoski’s Thoughts (o Ubunlog, que se me ha adelantado en la presentación española de la aplicación)

¿Utilizas Kitty como emulador de terminal y quieres darle un nuevo aspecto? instala un nuevo tema de colores

En un artículo anterior pudiste leer qué es eso de Kitty y cómo empezar a utilizar las funcionalidades que ofrece este emulador de terminal.

• https://victorhckinthefreeworld.com/2020/03/16/kitty-como-emulador-de-terminal-para-linux/

Tanto si te has animado a usarlo como si quieres ponerte a ello, quizás lo primero que quieres hacer es adaptarlo a tus gustos y configurar el esquema de color de esta terminal a tus preferencias.

Veamos cómo instalar nuevos temas de colores a Kitty, hay muchos entre los que escoger, seguro que alguno es de tu agrado.

Los temas de colores para Kitty están disponibles en un repositorio de GitHub:

• https://github.com/dexpota/kitty-themes

De entre toda la variedad, yo he preferido Dracula, un tema de colores que casa con todo mi sistema, ya que son varias las aplicaciones que tengo con esa combinación de colores.

Por tanto es ir a la carpeta themes del repositorio y escoger el archivo de configuración de esa combinación de colores.

Copio el contenido del archivo (recordad seleccionar la pestaña raw, para que nos muestre el archivo en texto plano) y lo pego en un archivo en mi equipo en la siguiente ruta:

~/.config/kitty/dracula.conf

Ahora tengo que decirle a Kitty que utilice ese esquema de colores, para ello edito el archivo de configuraciones kitty.conf que está en la misma ruta y añado la siguiente línea:

include dracula.conf

Cierro Kitty y lo vuelvo a abrir, y ahora habrá cambiado su aspecto al tema escogido, en el caso de mi ejemplo, a Dracula.

Si estás utilizando Kitty o piensas hacerlo, espero que este pequeño tutorial te haya servido.

Are you a student qualified to run for Summer of Code 2020? I'm willing to mentor the following project for librsvg.

Project: Revamp the text engine in librsvg

Librsvg supports only a few features of the SVG Text specification. It requires extra features to be really useful:

• Proper bidirectional support. Librsvg supports the direction and unicode-bidi properties for text elements, among others, but in a very rudimentary fashion. It just translates those properties to Pango terminology and asks PangoLayout to lay out the text. SVG really wants finer control of that, for which...

• ... ideally you would make librsvg use Harfbuzz directly, or a wrapper that is close to its level of operation. Pango is a bit too high level for the needs of SVG.

• Manual layout of text glyphs. After a text engine like Harfbuzz does the shaping, librsvg would need to lay out the produced glyphs in the way of the SVG attributes dx, dy, x, y, etc. The SVG Text specification has the algorithms for this.

• The cherry on top: text-on-a-path. Again, the spec has the details. You would make Wikimedia content creators very happy with this!

Requirements: Rust for programming language; some familiarity with Unicode concepts and text layout. Familiarity with Cairo and Harfbuzz would help a lot. Preference will be given to people who can write a right-to-left human language, or a language that requires complex shaping.

Details for students

Veamos un video tutorial sobre Kitty un emulador de terminal disponible para GNU/Linux

Kitty es un emulador de terminal creado por la misma persona que desarrolla Calibre (el gestor de libros electrónicos) rápido, con muchas funcionalidades y que utiliza la GPU para acelerar sus procesos.

Hace unos días escribí en el blog sobre Alacritty un emulador de terminal muy rápido y que también utilizaba la GPU para mejorar su rendimiento.

Yo desde hace tiempo utilizo Konsole, el emulador de terminal de la comunidad KDE, por que tiene un buen montón de funcionalidades que me parecen útiles y simplifican su uso haciéndolo más funcional.

Alacritty, frente a Konsole, tiene una carencia en muchas de esas funcionalidades, por lo que a pesar de que quizás si es más rápido, a la hora de utilizarlo, echo en falta muchas opciones que Konsole me ofrece.

A raíz del artículo de Alacritty, por Mastodon el amigo Ekaitz Zárraga me comentó la opción de Kitty, con funcionalidades similares a Konsole y además algunas otras.

También me ha animado a utilizarlo el reciente artículo del compañero Notxor, en el que en su blog escribía sobre el emulador de terminal Kitty.

Y oye, dicho y hecho, me dispuse a probarlo y ver qué tal se desenvolvía ese emulador de terminal en mi sistema y si conseguí quizás desbancar a Konsole.

En este video tutorial veréis el proceso de instalación y alguna funcionalidad básica y una primera toma de contacto con la aplicación Kitty.

Además también echaré un vistazo a un par de funciones complementarias, o también llamadas Kittens, que trae Kitty, como son el poder visualizar imágenes en la propia consola o el poder hacer un diff de un par de archivos.

El vídeo está subido a archive.org en formato libre .webm desde donde se puede descargar si se quiere.

También está disponible en YouTube, para quien prefiera esa opción, en el siguiente enlace:

https://www.youtube.com/watch?v=ht6PUY7BU6Y

Enlaces de interés

• Web oficial de Kitty
• Repositorio Kitty en GitHub
• Artículo de Notxor sobre Kitty

This article isn’t about anything “new”, like the previous ones on AppStream – it rather exists to shine the spotlight on a feature I feel is underutilized. From conversations it appears that the reason simply is that people don’t know that it exists, and of course that’s a pretty bad reason not to make your life easier 😉

Mini-Disclaimer: I’ll be talking about appstreamcli, part of AppStream, in this blogpost exclusively. The appstream-util tool from the appstream-glib project has a similar functionality – check out its help text and look for appdata-to-news if you are interested in using it instead.

What is this about?

AppStream permits software to add release information to their MetaInfo files to describe current and upcoming releases. This feature has the following advantages:

• Distribution-agnostic format for release descriptions
• Provides versioning information for bundling systems (Flatpak, AppImage, …)
• Release texts are short and end-user-centric, not technical as the ones provided by distributors usually are
• Release texts are fully translatable using the normal localization workflow for MetaInfo files
• Releases can link artifacts (built binaries, source code, …) and have additional machine-readable metadata e.g. one can tag a release as a development release

The disadvantage of all this, is that humans have to maintain the release information. Also, people need to write XML for this. Of course, once humans are involved with any technology, things get a lot more complicated. That doesn’t mean we can’t make things easier for people to use though.

Did you know that you don’t actually have to edit the XML in order to update your release information? To make creating and maintaining release information as easy as possible, the appstreamcli utility has a few helpers built in. And the best thing is that appstreamcli, being part of AppStream, is available pretty ubiquitously on Linux distributions.

Update release information from NEWS data

The NEWS file is a not very well defined textfile that lists “user-visible changes worth mentioning” per each version. This maps pretty well to what AppStream release information should contain, so let’s generate that from a NEWS file!

Since the news format is not defined, but we need to parse this somehow, the amount of things appstreamcli can parse is very limited. We support a format in this style:

Version 0.2.0
~~~~~~~~~~~~~~
Released: 2020-03-14

Notes:
 * Important thing 1
 * Important thing 2

Features:
 * New/changed feature 1
 * New/changed feature 2 (Author Name)
 * ...

Bugfixes:
 * Bugfix 1
 * Bugfix 2
 * ...

Version 0.1.0
~~~~~~~~~~~~~~
Released: 2020-01-10

Features:
 * ...

When parsing a file like this, appstreamcli will allow a lot of errors/”imperfections” and account for quite a few style and string variations. You will need to check whether this format works for you. You can see it in use in appstream itself and libxmlb for a slightly different style.

So, how do you convert this? We first create our NEWS file, e.g. with this content:

Version 0.2.0
~~~~~~~~~~~~~~
Released: 2020-03-14

Bugfixes:
 * The CPU no longer overheats when you hold down spacebar

Version 0.1.0
~~~~~~~~~~~~~~
Released: 2020-01-10

Features:
 * Now plays a "zap" sound on every character input

For the MetaInfo file, we of course generate one using the MetaInfo Creator. Then we can run the following command to get a preview of the generated file: appstreamcli news-to-metainfo ./NEWS ./org.example.myapp.metainfo.xml - Note the single dash at the end – this is the explicit way of telling appstreamcli to print something to stdout. This is how the result looks like:

<?xml version="1.0" encoding="utf-8"?>
<component type="desktop-application">
  [...]
  <releases>
    <release type="stable" version="0.2.0" date="2020-03-14T00:00:00Z">
      <description>
        <p>This release fixes the following bug:</p>
        <ul>
          <li>The CPU no longer overheats when you hold down spacebar</li>
        </ul>
      </description>
    </release>
    <release type="stable" version="0.1.0" date="2020-01-10T00:00:00Z">
      <description>
        <p>This release adds the following features:</p>
        <ul>
          <li>Now plays a "zap" sound on every character input</li>
        </ul>
      </description>
    </release>
  </releases>
</component>

Neat! If we want to save this to a file instead, we just exchange the dash with a filename. And maybe we don’t want to add all releases of the past decade to the final XML? No problem too, just pass the --limit flag as well: appstreamcli news-to-metainfo --limit=6 ./NEWS ./org.example.myapp.metainfo.tmpl.xml ./result/org.example.myapp.metainfo.xml

That’s nice on its own, but we really don’t want to do this by hand… The best way to ensure the MetaInfo file is updated, is to simply run this command at build time to generate the final MetaInfo file. For the Meson build system you can achieve this with a code snippet like below (but for CMake this shouldn’t be an issue either – you could even make a nice macro for it there):

ascli_exe = find_program('appstreamcli')
metainfo_with_relinfo = custom_target('gen-metainfo-rel',
    input : ['./NEWS', 'org.example.myapp.metainfo.xml'],
    output : ['org.example.myapp.metainfo.xml'],
    command : [ascli_exe, 'news-to-metainfo', '--limit=6', '@INPUT0@', '@INPUT1@', '@OUTPUT@']
)

In order to also translate releases, you will need to add this to your .pot file generation workflow, so (x)gettext can run on the MetaInfo file with translations merged in.

Release information from YAML files

Since parsing a “no structure, somewhat human-readable file” is hard without baking an AI into appstreamcli, there is also a second option available: Generate the XML from a YAML file. YAML is easy to write for humans, but can also be parsed by machines.The YAML structure used here is specific to AppStream, but somewhat maps to the NEWS file contents as well as MetaInfo file data. That makes it more versatile, but in order to use it, you will need to opt into using YAML for writing news entries. If that’s okay for you to consider, read on!

A YAML release file has this structure:

---
Version: 0.2.0
Date: 2020-03-14
Type: development
Description:
- The CPU no longer overheats when you hold down spacebar
- Fixed bugs ABC and DEF
---
Version: 0.1.0
Date: 2020-01-10
Description: |-
  This is our first release!

  Now plays a "zap" sound on every character input

As you can see, the release date has to be an ISO 8601 string, just like it is assumed for NEWS files. Unlike in NEWS files, releases can be defined as either stable or development depending on whether they are a stable or development release, by specifying a Type field. If no Type field is present, stable is implicitly assumed. Each release has a description, which can either be a free-form multi-paragraph text, or a list of entries.

Converting the YAML example from above is as easy as using the exact same command that was used before for plain NEWS files: appstreamcli news-to-metainfo --limit=6 ./NEWS.yml ./org.example.myapp.metainfo.tmpl.xml ./result/org.example.myapp.metainfo.xml If appstreamcli fails to autodetect the format, you can help it by specifying it explicitly via the --format=yaml flag. This command would produce the following result:

<?xml version="1.0" encoding="utf-8"?>
<component type="console-application">
  [...]
  <releases>
    <release type="development" version="0.2.0" date="2020-03-14T00:00:00Z">
      <description>
        <ul>
          <li>The CPU no longer overheats when you hold down spacebar</li>
          <li>Fixed bugs ABC and DEF</li>
        </ul>
      </description>
    </release>
    <release type="stable" version="0.1.0" date="2020-01-10T00:00:00Z">
      <description>
        <p>This is our first release!</p>
        <p>Now plays a "zap" sound on every character input</p>
      </description>
    </release>
  </releases>
</component>

Note that the 0.2.0 release is now marked as development release, a thing which was not possible in the plain text NEWS file before.

Going the other way

Maybe you like writing XML, or have some other tool that generates the MetaInfo XML, or you have received your release information from some other source and want to convert it into text. AppStream also has a tool for that! Using appstreamcli metainfo-to-news <metainfo-file> <news-file> you can convert a MetaInfo file that has release entries into a text representation. If you don’t want appstreamcli to autodetect the right format, you can specify it via the --format=<text|yaml> switch.

Future considerations

The release handling is still not something I am entirely happy with. For example, the release information has to be written and translated at release time of the application. For some projects, this workflow isn’t practical. That’s why issue #240 exists in AppStream which basically requests an option to have release notes split out to a separate, remote location (and also translations, but that’s unlikely to happen). Having remote release information is something that will highly likely happen in some way, but implementing this will be a quite disruptive, if not breaking change. That is why I am holding this change back for the AppStream 1.0 release.

In the meanwhile, besides improving the XML form of release information, I also hope to support a few more NEWS text styles if they can be autodetected. The format of the systemd project may be a good candidate. The YAML release-notes format variant will also receive a few enhancements, e.g. for specifying a release URL. For all of these things, I very much welcome pull requests or issue reports. I can implement and maintain the things I use myself best, so if I don’t use something or don’t know about a feature many people want I won’t suddenly implement it or start to add features at random because “they may be useful”. That would be a recipe for disaster. This is why for these features in particular contributions from people who are using them in their own projects or want their new usecase represented are very welcome.

Llegamos a la actualización mensual de rigor que demuestra que los desarrolladores de KDE no dejan de trabajar. Así que se congratulan en anunciar la actualización de marzo del 2020 de KDE Frameworks.  Con esta se llega a la versión 5.68, una plusmarca de compromiso y constancia que no parece que tenga un final cercano.

Actualización de marzo del 2020 de KDE Frameworks

A pesar de que para los usuarios corrientes esta noticia sea algo confusa ya que no se trata de realzar una nueva aplicación ni de una nueva gran funcionalidad del escritorio, el desarrollo de KDE Frameworks tiene repercusiones directas en él a medio y largo plazo.

La razón de esta afirmación es que KDE Frameworks es básicamente la base de trabajo de los desarrolladores para realizar sus aplicaciones, es como el papel y las herramientas de dibujo para un artista: cuanto mejor sea el papel y mejores pinceles tenga, la creación de una artista será mejor.

De esta forma, las mejoras en KDE Frameworks facilitan el desarrollo del Software de la Comunidad KDE, haciendo que su funcionamiento, su estabilidad y su integración sea la mejor posible,

El domingo 15 de marzo de 2020 fue lanzado KDE Frameworks 5.68, la nueva revisión del entorno de programación sobre el que se asienta Plasma 5, el escritorio GNU/Linux de la Comunidad KDE, y las aplicaciones que se crean con para él.

Hay que recordar que los desarrolladores de KDE decidieron lanzar actualizaciones mensuales de este proyecto y lo están cumpliendo con puntualmente. La idea es ofrecer pocas pero consolidadas novedades, a la vez que se mantiene el proyecto evolucionando y siempre adaptándose al vertiginoso mundo del Software Libre.

Una gran noticia para la Comunidad KDE que demuestra la evolución continua del proyecto que continua ganando prestigio en el mundo de los entornos de trabajo Libres.

Más información: KDE

¿Qué es KDE Frameworks?

Para los que no lo sepan, KDE Frameworks añade más de 70 librerías a Qt que proporcionan una gran variedad de funcionalidades necesarias y comunes, precisadas por los desarrolladores, testeadas por aplicaciones especí­ficas y publicadas bajo licencias flexibles. Como he comentado, este entorno de programación es la base para el desarrollo tanto de las nuevas aplicaciones KDE y del escritorio Plasma 5.

Aquí podéis encontrar un listado con todos estos frameworks y la serie de artículos que dedico a KDE Frameworks en el blog,

Recuerda que puedes ver una introducción a Frameworks 5.0 en su anuncio de lanzamiento.