"Themes in GNOME" is a complicated topic in technical and social terms. Technically there are a lot of incomplete moving parts; socially there is a lot of missing documentation to be written, a lot of miscommunication and mismatched expectations.

The following is a brief and incomplete, but hopefully encouraging, summary of the status of themes in GNOME. I want to give you an overall picture of the status of things, and more importantly, an idea of how you can help. This is not a problem that can be solved by a small team of platform developers.

I wish to thank Alexander Mikhaylenko for providing most of the knowledge in this post.

Frame of reference

First, I urge you to read Cassidy James Blaede's comprehensive "The Need for a FreeDesktop Dark Style Preference". That gives an excellent, well-researched introduction to the "dark style" problem, the status quo on other platforms, and exploratory plans for GNOME and Elementary from 2019.

Go ahead, read it. It's very good.

There is also a GUADEC talk about Cassidy's research if you prefer to watch a video.

Two key take-aways from this: First, about this being a preference, not a system-enforced setting:

I’m explicitly using the language “Dark Style Preference” for a reason! As you’ll read further on, it’s important that this is treated as a user “preference,” not an explicit “mode” or strictly-enforced “setting.” It’s also not a “theme” in the sense that it just swaps out some assets, but is a way for the OS to support a user expressing a preference, and apps to respond to that preference.

Second, about the accessibility implications:

Clearly there’s an accessibility and usability angle here. And as with other accessibility efforts, it’s important to not relegate a dark style preference to a buried “Universal Access” or “Accessibility” feature, as that makes it less discoverable, less tested, and less likely to be used by folks who could greatly benefit, but don’t consider themselves “disabled.”

Libadwaita and the rest of the ecosystem

Read the libadwaita roadmap; it is very short, but links to very interesting issues on gitlab.

For example, this merge request is for an API to query the dark style and high-contrast preferences. It has links to pending work in other parts of the platform: libhandy, gsettings schemas, portals so that containerized applications can query those preferences.

As far as I understand it, applications that just use GTK3 or libhandy can opt in to supporting the dark style preference — it is opt-in because doing that unconditionally in GTK/libhandy right now would break existing applications.. If your app uses libadwaita, it is assumed that you have opted into supporting that preference, since libadwaita's widgets already make that assumption, and it is not API-stable yet — so it can make that assumption from the beginning.

There is discussion of the accessibility implications in the design mockups.

CSS parity across implementations

In GNOME we have three implementations of CSS:

• librsvg uses servo's engine for CSS selector matching, and micro-parsers for CSS values based on servo's cssparser.

• GTK has its own CSS parser and processor.

• Gnome-shell uses an embedded version of libcroco for parsing, but it does most of the selector matching and cascading with gnome-shell's own Shell Toolkit code.

None of those implementations supports @media queries nor custom properties with var(). That is, unlike in the web platform, GNOME applications cannot have this in their CSS:

@media (prefers-color-scheme: dark) {
  /* styles for dark style */
}

@media (prefers-color-scheme: light) {
  /* styles for light style */
}

Or even declaring colors in a civilized fashion:

:root {
  --main-bg-color: pink;
}

some_widget {
  background-color: var(--main-bg-color);
}

Or combining the two:

@media (prefers-color-scheme: dark) {
  :root {
    --main-bg-color: /* some nice dark background color */;
    --main-fg-color: /* a contrasty light foreground */;
  }
}

@media (prefers-color-scheme: light) {
  :root {
    --main-bg-color: /* some nice light background color */;
    --main-fg-color: /* a contrasty dark foreground */;
  }
}

some_widget {
  background-color: var(--main-bg-color);
}

Boom. I think this would remove some workarounds we have right now:

• Just like GTK, libadwaita generates four variants of the system's stylesheet using scss (regular, dark, high-contrast, high-contrast-dark). This would be obviated with @media queries for prefers-color-scheme, prefers-contrast, inverted-colors as in the web platform.

• GTK has a custom @define-color keyword, but neither gnome-shell nor librsvg support that. This would be obviated with CSS custom properties - the var() mechanism. (I don't know if some "environmental" stuff would be better done as env(), but none of the three implementations support that, either.)

Accent colors

They are currently implemented with GTK's @define-color, which is not ideal if the colors have to trickle down from GTK to SVG icons, since librsvg doesn't do @define-color - it would rather have var() instead.

Of course, gnome-shell's libcroco doesn't do @define-color either.

Look for @accent_color, @accent_bg_color, @warning_color, etc. in the default stylesheet, or better yet, write documentation!

The default style:

Accent color set to orange (e.g. tweak it in GTK's CSS inspector):

/* Standalone, e.g. the "Page 1" label */
@define-color accent_color @orange_5;

/* background+text pair */
@define-color accent_bg_color @orange_4;
@define-color accent_fg_color white;

Custom widgets

Again, your app's custom stylesheet for its custom widgets can use the colors defined through @define-color from the system's stylesheet.

Recoloring styles

You will be able to do this after it gets merged into the main branch, e.g. recolor everything to sepia:

@define-color headerbar_bg_color #eedcbf;
@define-color headerbar_fg_color #483a22;

@define-color bg_color #f9f3e9;
@define-color fg_color #483a22;

@define-color dark_fill_color shade(#f9f3e9, .95);

@define-color accent_bg_color @orange_4;
@define-color accent_color @orange_5;

Of course shade() is not web-platform CSS, either. We could keep it, or redo it by implementing calc() function for color values.

Recoloring icons

Currently GTK takes some defined colors and creates a chunk of CSS to inject into SVG for icons. This has some problems.

There is also some discussion about standardizing recolorable icons across desktop environments.

How you can help

Implement support for @media queries in our three CSS implementations (librsvg, gnome-shell, GTK). Decide how CSS media features like prefers-color-scheme, prefers-contrast, inverted-colors should interact with the GNOME's themes and accessibility, and decide if we should use them for familiarity with the web platform, or if we need media features with different names.

Implement support for CSS custom properties - var() in our three CSS implementations. Decide if we should replace the current @define-color with that (note that @define-color is only in GTK, but not in librsvg or gnome-shell).

See the libadwaita roadmap and help out!

Port applications to use the proposed APIs for querying the dark style preference. There are a bunch of hacky ways of doing it right now; they need to be migrated to the new system.

Personally I would love help with finishing to port gnome-shell's styles to Rust - this is part of unifying librsvg's and gnome-shell's CSS machinery.

Sigo con la promoción del nuevo podcast de la Asociación sin ánimo de lucro KDE España, así que bienvenidos al cuarto episodio de KDE Express con Walter que sigue con la senda de la tercera entrega presentado a un miembro de la Komunidad (término inventado por ellos mismos).

Cuarto episodio de KDE Express con Walter

Comenté hace poco que había nacido KDE Express, un audio con noticias y la actualidad de la Comunidad KDE y del Software Libre con un formato breve (menos de 30 minutos) que complementa los que ya genera la Comunidad de KDE España de forma casi mensual con sus ya veteranos Vídeo-Podcast que podéis encontrar en Archive.org, Youtube, Ivoox y Spotify)

Seguimos pues con sus episodios cortitos y dedicados a miembros de la Comunidad KDE de habla hispana, llegando al número 4 de su primera temprada que, en palabras del equipo de KDE Express, se introduce de la siguiente forma:

«Continuamos con el formato comunidad KDE, en esta ocasión con un compañero de Home Studio Libre, Walter. Que nos contara sus comienzos en GNU/Linux y en KDE, su camino hasta llegar a esta comunidad, las aplicaciones que más utiliza y algunas de las cosas que más le gustan de Plasma

Algunos de los proyectos mencionados:

• Puppy Linux – Una minidistro para equipos con muy muy pocos recursos.
• INTER Y NET PODCAST

PD: Un saludo a Fran y a todo HSL «.

A mi me sigue gustando mucho, es rápido, directo al grano y muy dinámico, con lo cual es ideal para aquellos que les guste tener su pincelada de Kdeera en su podcaster. Evidentemente, no se profundiza en temas aunque si se da una visión muy personal de los mismos.

Así que sigo dando mi más sincera enhorabuena a José Picon, Brais Arias y a David Marzal por el esfuerzo y dedicación… y aprovecho para comentar que si alguien está interesado en colaborar (bien sea para iniciarse o bien sea porque cree que puede aportar alguna cosa) no tiene más que ponerse en contacto con ellos enviando un mail a esta dirección kde_express@kde-espana.org.

Por cierto, también podéis encontrarlos en Telegram: https://t.me/KDEexpress

Tal y como estaba previsto en el calendario de lanzamiento de los desarrolladores, el martes 31 de agosto la Comunidad KDE ha comunicado que ha sido lanzada la quinta actualización de Plasma 5.22. Una noticia que aunque es esperada y previsible es la demostración palpable del alto grado de implicación de la Comunidad en la mejora continua de este gran entorno de escritorio de Software Libre.

Lanzada la quinta actualización de Plasma 5.22

No existe Software creado por la humanidad que no contenga errores. Es un hecho incontestable y cuya única solución son las actualizaciones. Es por ello que en el ciclo de desarrollo del software creado por la Comunidad KDE se incluye siempre las fechas de las actualizaciones.

De esta forma, el martes 31 de agosto ha sido lanzada la quinta actualización de Plasma 5.22, la cual solo trae (que no es poco) soluciones a los bugs encontrados en esta semana de vida del escritorio y mejoras en las traducciones. Es por tanto, una actualización 100% recomendable.

Más información: KDE

Las novedades básicas de Plasma 5.22

La lista principal de las novedades de Plasma 5.22 son las siguientes:

• Grandes mejoras visuales, donde destaca la nueva funcionalidad de transparencia adaptativa: esto significa que el panel y los widgets que contiene serán agradablemente translúcidos por norma general, aunque se volverán completamente opacos si existen ventanas maximizadas para evitar cualquier distracción.
• Nueva pantalla de inicio de las Preferencias del Sistema donde además de las acciones más habituales que solemos hacer los usuarios tendremos el acceso a los módulos que más utilizamos.
• Mejoras en las actualizaciones en diferido, útiles para algunos usuarios, no tanto para otros, y que como es habitual en esta versión se han pulido para contentar a todos.
• Los widgets de la Bandeja del sistema (situados normalmente en la parte inferior derecha del panel) son mucho más consistentes en aspecto y también más útiles
• Mejoras en KWin, Wayland, el lanzador de «todo» Kunner y, por supuesto, en las notificaciones.

Más información: KDE

Collecting process accounting logs on Linux with syslog-ng

Process accounting logs are collected into binary log files on Linux. You can turn them into human readable format locally, using various tools. You can also use syslog-ng to read those files.

Lean how syslog-ng can parse those binary logs, create name-value pairs from them and store the results from my latest blog: https://www.syslog-ng.com/community/b/blog/posts/collecting-process-accounting-logs-on-linux-with-syslog-ng

Most people only know that I work in IT. Some even call me a hacker – which I really appreciate :-) However, by university degree I am an environmental engineer (and English - Hungarian translator). Even if I never worked in my field, except for some student jobs, I still follow any news related to the environment closely. This is why I was very happy to learn, that my home city, Budapest, introduced bee pastures in the city.

Bee pastures

So, what are bee pastures? Most people expect that public areas in a city have shortly cut grass. It is convenient for humans, you can walk on it, you can play games on it or bask in the sun. The price is that it needs to be cut regularly and there are no flowers: bees cannot eat there. Bees have an essential role in our ecosystems. Unfortunately, the area where they eat and live is continuously shrinking, due to humans. Establishing bee pastures, areas with the right mix of flowering plants can help the bee population to survive and grow. Establishing bee pastures in selected areas of cities can help in multiple ways. It helps the bees, it looks nice and can also save costs on lawn mowing.

Where it went wrong in Budapest

Turning a grass area into bee pasture does not mean that it does not need maintenance any more. It just means less frequent maintenance. Of course, there are also some properly maintained bee pastures in Budapest. The problem is, that in most cases, in practice it means an area with a “Bee Pasture” sign and completely left alone. In real life I have only seen this problematic version, where behind the “Bee Pasture” sign one could only see overgrown areas, full of highly allergenic plants.

My Facebook post

Facebook is aware, that I like reading about environmental issues. So, one of the posts on my time line was a photo from the UK, which showed bee pastures on the streets and parks of a small town. It looked like what you would expect when someone mentions bee pasture. I shared the photo with a short text: “This is a fantastic idea, and there are places where they do this properly”.

Offending two sides

So, where is the problem? If you read so far, you can see that I support a progressive idea and criticize how it is carried out. The discussion below my post grew into a flame-war. To understand why, here is some background information. The “bee pasture” idea came from the leaders of the city of Budapest, led by a major opposition figure. What does it mean? Anyone supporting the opposition parties support bee pastures, even if in practice it means large fields of allergenic plants. Anyone supporting the governing party considers the bee pasture idea crazy, even where it is implemented properly. My post offended both sides, as I supported an opposition idea, but I criticized how it was implemented.

This post was only shared with my Facebook friends. Still, after a few days my post was reported enough times to be deleted.

How does it come to an IT blog?

You might wonder how this story is related to IT, the primary focus of my blog. It is related. Most of the time I am independent. There are hot debates in IT as well, where I avoid taking a side – at least publicly. If I need to write about the topic publicly for example to inform syslog-ng users in a question, I keep a safe distance from all sides involved. I do not judge who is good, who is bad, just focus on how the given problem affects syslog-ng users. Just to mention a few:

• ElasticSearch vs. OpenSearch – the most frequently used log destination in syslog-ng
• RHEL vs. CentOS Stream vs. CentOS replacements – the most frequently used operating system to run syslog-ng

Taking a side, seeing everything in black and white is easier: less thinking, feeling of belonging. But that’s not how I work in IT or in real life.

You can also make a difference if you have a garden. Make sure that you have some flowering plants in parts of your garden all around the year. And avoid using chemicals as much as possible.

Veamos como evitar eliminar un archivo por error mediante el comando rm desde la terminal en GNU/Linux

Estamos trabajando en una terminal de nuestro sistema GNU/Linux y estando seguros de lo que hacemos, con los dedos planeando el teclado a toda velocidad, sin querer eliminamos un archivo con el comando rm que no queríamos borrar…

Nuestros dedos se detienen en el acto y asumimos lo ocurrido con una mezcla de pánico, tensión y culpabilidad… ¿podemos recuperar ese archivo?

La respuesta corta es: no. O por lo menos no, con las herramientas habituales de nuestro sistema.

La respuesta larga es sí: podremos utilizar herramientas disponibles para recuperar ese archivo.

La respuesta para el futuro es: vamos a ver algunas soluciones para impedir este sufrimiento en el futuro.

Si no ha pasado mucho tiempo desde que lo hemos eliminado hasta que nos hemos dado cuenta del error, quizás el sistema no haya sobre escrito nada en el lugar que ocupaba ese archivo y quizás haya una posibilidad de recuperación.

Hay herramientas forenses para la exploración del sistema de archivos y para tratar de recuperar aquello que deseamos. Y otras herramientas con interfaz gráfica para estas lides, así la que conozco y he utilizado alguna vez fue PhotoRec.

Pero este artículo no trata tanto sobre cómo recuperar un archivo que hemos borrado con el comando rm de GNU/Linux, si no más bien de cómo impedir que nos suceda en el futuro.

rm interactivo

Una opción para impedir eliminar archivos no deseados es utilizar la versión interactiva del comando rm (-i) En la versión interactiva del comando, este nos preguntará si deseamos borrar el archivo. Para ello añadiremos el siguiente alias, en el archivo de configuración de nuestra shell (.bashrc, .zshrc o la que utilicemos)

alias rm="rm -i"

Es decir, nos da una oportunidad antes de borrar el archivo por completo. No impide el error, pero sí hace que quizás antes del “desastre” nos llegue un rayo de iluminación y seamos conscientes de nuestro incipiente error, pudiendo decir a rm que no borre el archivo que le habíamos mandado.

Muy bien, esto parece ser una solución interesante si queremos borrar 1 o 3 o 5 o incluso 10 archivos. Nos pedirá 1, 3, 5 o 10 confirmaciones, algo manejable… pero ¿qué pasa si queremos borrar 100 archivos, y es algo habitual en nuestro flujo de trabajo?

Es algo exasperante tener que confirmar 100 eliminaciones de archivos, al final, dejaremos de prestar atención a los archivos que nos presenta y quizás borremos alguno que no queríamos.

Utilizar una “papelera de reciclaje”

Cuando utilizamos un gestor de archivos con interfaz gráfica como Dolphin, Thunar, etc, estamos acostumbrados a que al borrar un archivo, este pasa a una papelera antes de ser eliminado por completo.

Podemos echar un vistazo a esa papelera y volver a recuperar los archivos que queramos porque los hayamos borrado por error. ¿Por qué no tener algo así en la consola? Veamos cómo tener algo similar.

Lo primero, vamos a crear una carpeta oculta en nuestro /home. Ya sabéis que anteponiendo un punto (.) a un nombre de archivo o carpeta, en sistemas GNU/Linux esto hace que sea oculto. Para ello ejecutaremos:

$ mkdir ~/.Papelera

Esto nos creará la carpeta oculta llamada Papelera en nuestro /home. Podemos ver que existe con el comando ls -a Y veremos no solo nuestra carpeta recién creada, si no también los archivos ocultos en nuestro /home.

Después tendremos que crear un alias (ya sabes en .bashrc, zshrc o el que utilices) para el comando rm que a partir de ahora utilizaremos como del (viene de delete, pero puedes llamarle como prefieras). En ese archivo añadiremos la siguiente línea:

alias del='mv --verbose --backup=simple --suffix=$(date +".(%F_%T)") --target-directory=$HOME/.Papelera/'

Ahora cuando queramos eliminar un archivo lo haremos con del, en vez de con rm. Con esto no se borrarán los archivos, simplemente se moverán a la carpeta oculta Papelera y podremos recuperar los archivos en caso de error.

Si borramos archivos que tienen el mismo nombre, este alias irá añadiendo fecha y hora al nombre para diferenciar uno de otro.

De vez en cuando tendremos que ir borrando el contenido de la carpeta .Papelera, para que no empiece a ocupar mucho sitio e nuestro sistema, albergando todos los archivos que vayamos eliminando.

Quizás una tarea cron o similar pueda servirnos para ir vaciando esa carpeta de manera regular (quizás una vez al mes o similar…)

¿Qué te han parecido estas soluciones alternativas para evitar errores? ¿Te ha pasado alguna vez eso de borrar un archivo que no deberías? ¿Conoces o utilizas otros métodos/herramientas? Compártelo en los comentarios para ayudar a otras personas.

Fuente del artículo:

• https://www.gnu.org/software/coreutils/faq/coreutils-faq.html#I-used-rm-to-remove-a-file_002e-How-can-I-get-it-back-now_003f

For some people, vacation season is just the right time for housekeeping or for learning new skills. And that’s exactly what the YaST team has been doing in the latest two sprints.

• We improved some YaST internals including:
  • Management of the Help button in text mode
  • Unmounting of file-systems at the end of installation
  • Handling of progress bars
• Our users also made YaST better with their contributions
• The dedicated subset of the YaST Team keeps making progress regarding the Release Tools

Let’s go into the details.

Keeping the YaST Internals in Shape

In the software development world is not uncommon to sweep the dirt under the carpet. If something seems to work from the user point of view, just leave it as it is. But there is no carpet to hide anything when you develop Free Software with an open spirit. And in the YaST Team we simply don’t feel comfortable when we know the pieces under the hood are not really well adjusted. Thus, we invested some of our summer time fixing some internal issues (both real and potential), although none of them currently have visible impact of our users.

• All YaST screens contain a Help button that shows an explanatory text. But, what happens if there is no such text? It’s a theoretical problem (there is ALWAYS a help text) but the situation in the ncurses text mode really needed a better handling.
• Unmounting file-systems at the end of the installation process is another of those things that seem to work flawlessly… until you take a look to the YaST logs and find out it used to be an slightly convulted process. But we restructured the component taking care of the process and things now look equally good in the surface and under the hood.
• The way progress bars are handled in YaST is admitedly error-prone and could result in the user interface crashing in some extreme situations. We also improved that by making the Yast::Progress internal module more robust.

Integrating Community Contributions

Another of the great things of working in an Open Source project is getting contributions from your own users. In that regard, we recently added support for the AFNOR variant of the French keyboard, which was useful to realize we haven’t incorporated such layout to SUSE Linux Enterprise. We did now, so both SLE and openSUSE got better thanks to the openSUSE community. Something that will soon happen also to the YaST Journal module as soon as we merge this other contribution currently under review.

Release Tools: We Keep Learning

And talking about collaboration, in our previous post we told you about our new mission of helping with the development and maintenance of the (open)SUSE Release Tools. We keep working on that front, although progress can only be slow when most of the people we have to interact with (and a big part of the YaST Team itself) is on vacation. Nevertheless, we keep researching possible solutions for the known problems, improving the testing infrastructure and using a test-driven approach to lower the entry barrier for newcomers.

See you soon

The vacation season in Europe is comming to an end, so we hope to have more exciting news for upcoming blog posts. Meanwhile, please keep helping us and having a lot of fun!

Securing the sudo to sudo_logsrvd connection

Using sudo_logsrvd to centrally collect sudo session recordings from your network is a huge step forward in security: users cannot delete or modify session recordings locally. However, by default, transmission of recordings is not encrypted, making it open to modifications and eavesdropping. Encrypting the connection between sudo and sudo_logsrvd can eliminate these problems. Larger environments usually either have in-house PKI tooling in place, or colleagues who know all openssl options off the top of their heads. However, small and medium enterprises often lack the infrastructure or knowledge to work with TLS certificates.

This blog can help you to secure connections between sudo and sudo_logsrvd when there is no PKI tooling available to you, or you want to create all the certificates yourself using openssl. It is based on the sudo_logsrvd manual, but changed in such a way that all information is entered on the command line. While interactive certificate generation works fine for a single cert, generating multiple client certificates is easier when everything is on the command line.

Read my blog at https://blog.sudo.ws/posts/2021/08/securing-the-sudo-to-sudo_logsrvd-connection/

Veamos cómo borrar en GNU/Linux un archivo en el que el nombre comienza con dos guiones (por ejemplo –help) desde una consola

Nunca se me había ocurrido, pero puede ocurrir, que estemos en nuestro sistema GNU/Linux en una terminal y queramos borrar (o cambiar de nombre) un archivo que tiene por nombre –help

Ejecuta:

$ echo "hola mundo" > --help

Ya tienes tu archivo precedido con dos guiones. Prueba ahora a borrarlo, cambiarle el nombre o simplemente ver qué contiene con cat, vim, nano o como quieras y verás qué sucede.

Los comandos para hacer eso, seguro que los conoces. Para borrar utilizaremos el comando rm y para cambiar de nombre usaremos el comando mv

$ rm archivo.txt
$ mv archivo.txt archivo.md

Pero como también sabes, cada comando tiene unas opciones que se anteponen con un guión (-) para los formatos cortos y dos guiones (–) para formatos largos.

Ahora imaginemos que queremos borrar un archivo que precisamente comienza su nombre con dos guiones (–) y que para más intríngulis se llama –help

Al ejecutar los comandos, estos de forma predeterminada entienden lo siguiente como una opción no como el nombre del archivo, debido a los dos guiones con los que comienza el texto.

Si tenemos acceso a una interfaz gráfica, lo más sencillo sería abrir nuestro gestor de archivos y eliminarlo sin más o cambiarle el nombre, pero ¿qué pasa si solo tenemos una terminal?

Como dice el mantra: “If there’s a shell, there’s a way”. Qué más o menos traducido significa, que una terminal nos sacará de todos los apuros (o así…)

Tanto si el nombre comienza con uno o dos guiones, si queremos borrarlo, cambiarle el nombre, o cualquier otra cosa que queramos hacer con él, lo podremos hacer con varias opciones:

• anteponiendo al nombre ./
• anteponiendo al nombre —
• declarando la ruta completa del archivo

Y con cualquiera de esas opciones conseguiremos nuestro propósito. Veamos ejemplos con nuestro ejemplo de archivo llamado –help que está en nuestro /home

Podremos ver el contenido de ese archivo con cualquiera de estas opciones, como hemos visto antes:

$ cat ./--help
$ cat -- --help
$ cat /home/tu_usuario/--help

Y de igual manera si queremos eliminarlo:

$ rm ./--help
$ rm -- --help
$ rm /home/tu_usuario/--help

Ahora sí que dominamos un poco más la terminal de nuestra distribución GNU/Linux. Y podremos proponer un pequeño reto a alguien que esté aprendiendo.

Fuente del artículo:

• https://www.gnu.org/software/coreutils/faq/coreutils-faq.html#I-have-a-file-called-_002d_002dhelp_002e-How-do-I-remove-it_003f