Siguiendo el objetivo de mostrar qué ofreció el pasado mayo la Comunidad KDE en cuanto a aplicaciones. Hace unos días hablé de las nueva aplicaciones del ecosistema, después de Dolphin y hace un par de días de Itinerary. Hoy toca hablar de las novedades de Neochat en KDE Gear 24.05, una aplicación de charla que le permite aprovechar todas las ventajas de la red Matrix.

Las novedades de NeoChat en KDE Gear 24.05

Poco a poco se está estableciendo la red Matrix como la más libre y segura para aquellas personas que valoramos nuestra intimidad. La Comunidad KDE hace tiempo que la utiliza y no para de promocionarla.

Y, como no podía ser de otra forma, debe oferecer un cliente a la altura para poder utilizarlo en los entornos de trabajo KDE. Su nombre es NeoChat y ofrece las siguientes novedades:

Se ha movido la búsqueda a una ventana emergente para permitirle buscar conversaciones independientemente del espacio en el que se encuentre.

Además, ahora NeoChat también escaneará ahora PDF y otros archivos enviados al chat para encontrar documentos de viaje y mostrará toda la información relevante directamente en la conversación. Todo el procesamiento se realiza en nuestro dispositivo y no se envía ningún tipo de información privada a servidores de terceras partes. De manera similar, los documentos de texto se mostrarán directamente en la línea de tiempo.

Más información: KDE Gear 24.05

La entrada Las novedades de NeoChat en KDE Gear 24.05 se publicó primero en KDE Blog.

Tumbleweed es una distribución de GNU/Linux «Rolling Release» o de actualización contínua. Aquí puedes estar al tanto de las últimas novedades.

openSUSE Tumbleweed es la versión «rolling release» o de actualización continua de la distribución de GNU/Linux openSUSE.

Hagamos un repaso a las novedades que han llegado hasta los repositorios esta semana.

Y recuerda que puedes estar al tanto de las nuevas publicaciones de snapshots en esta web:

• https://victorhck.gitlab.io/tumbleweed_snapshots/

El anuncio original lo puedes leer en el blog de Dominique Leuenberger, publicado bajo licencia CC-by-sa, en este este enlace:

• https://dominique.leuenberger.net/blog/2024/06/opensuse-tumbleweed-review-of-the-week-2024-25/

Esta es la semana anterior a la openSUSE Conference, y muchas de las personas que empaquetan, estarán allí, aún así han tenido tiempo para actualizar el software y se han publicado 5 snapshots esta semana (0613, 0614, 0617, 0618, y 0619)

Las actualizaciones más importantes que han llegado:

• libxml 2.12.8
• Ruby 3.3.3
• VLC 3.0.21, ver http://www.videolan.org/security/sb-vlc3021.html
• Mesa 24.0.9, 24.1.0 & 24.1.1: Mesa 24 trajo algunos fallos gráficos en las tarjetas gráficas AMD/.ATI, que no pudimos detectar en openQA. Se publicó una versión (en su mayoría) fija en el canal de actualización para acortar el tiempo)
• Mozilla Firefox 127.0
• KDE Gear 24.05.1
• Linux kernel 6.9.4 & 6.9.5

Y ya preparándose para próximas actualizaciones:

• KDE Plasma 6.1
• NodeJS 22.3.0
• Perl 5.40.0
• transactional-update
• Pytest 8.2
• dbus-broker
• GCC 14

Si quieres estar a la última con software actualizado y probado utiliza openSUSE Tumbleweed la opción rolling release de la distribución de GNU/Linux openSUSE.

Mantente actualizado y ya sabes: Have a lot of fun!!

Enlaces de interés

• ¿Por qué deberías utilizar openSUSE Tumbleweed?
• zypper dup en Tumbleweed hace todo el trabajo al actualizar
• ¿Cual es el mejor comando para actualizar Tumbleweed?
• ¿Qué es el test openQA?
• http://download.opensuse.org/tumbleweed/iso/
• https://es.opensuse.org/Portal:Tumbleweed

——————————–

Since a few weeks ago, librsvg is now in oss-fuzz — Google's constantly-running fuzz-testing for OSS projects — and the crashes have started coming in. I'll have a lot more to say soon about crashes in Cairo, which is where the majority of the bugs are so far, but for now I want to tell you about a little bug I just fixed.

The fuzzer found a memory leak that happens when librsvg tries to parse an invalid XML document that has definitions for XML entities — the things that you normally reference like &foo; in the middle of the XML.

For example, this invalid document causes librsvg to leak:

<!DOCTYPEY[<!ENTITY a ''

Valgrind reports this:

$ valgrind --leak-check=full ./target/debug/rsvg-convert leak.svg 
...
Error reading SVG leak.svg: XML parse error: Error domain 1 code 37 on line 2 column 1 of data: xmlParseEntityDecl: entity a not terminated

==3750== 
==3750== HEAP SUMMARY:
==3750==     in use at exit: 78,018 bytes in 808 blocks
==3750==   total heap usage: 1,405 allocs, 597 frees, 205,161 bytes allocated
==3750== 
==3750== 247 (144 direct, 103 indirect) bytes in 1 blocks are definitely lost in loss record 726 of 750
==3750==    at 0x4845794: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==3750==    by 0x4BD857F: xmlCreateEntity (entities.c:158)
==3750==    by 0x4BD932B: xmlNewEntity (entities.c:451)
==3750==    by 0x2EBC75: rsvg::xml::xml2_load::sax_entity_decl_cb (xml2_load.rs:152)
==3750==    by 0x4BED6D8: xmlParseEntityDecl (parser.c:5647)
==3750==    by 0x4BEF4F3: xmlParseMarkupDecl (parser.c:7024)
==3750==    by 0x4BEFB95: xmlParseInternalSubset (parser.c:8558)
==3750==    by 0x4BF50E9: xmlParseDocument (parser.c:11072)
==3750==    by 0x2ED266: rsvg::xml::xml2_load::Xml2Parser::parse (xml2_load.rs:466)
==3750==    by 0x4A8C49: rsvg::xml::XmlState::parse_from_stream::{{closure}} (mod.rs:628)
==3750==    by 0x2ACA92: core::result::Result<T,E>::and_then (result.rs:1316)
==3750==    by 0x34D4E2: rsvg::xml::XmlState::parse_from_stream (mod.rs:627)
==3750== 
==3750== LEAK SUMMARY:
==3750==    definitely lost: 144 bytes in 1 blocks
==3750==    indirectly lost: 103 bytes in 3 blocks
==3750==      possibly lost: 0 bytes in 0 blocks
==3750==    still reachable: 73,947 bytes in 746 blocks
==3750==         suppressed: 0 bytes in 0 blocks

Let's see what happened.

The code in question

Even after the port to Rust, librsvg still uses libxml2 for parsing XML. So, librsvg has to deal with raw pointers incoming from libxml2 and it must do their memory management itself, since the Rust compiler doesn't know what to do with them automatically.

Librsvg uses the SAX parser, which involves setting up callbacks to process events like "XML element started", or "an entity was defined".

If you have a valid document that has entity definitions like these:

<!ENTITY foo "#aabbcc">
<!ENTITY bar "some text here">

Then libxml2's SAX parser will emit two events to instruct your code that it should define entities, one for foo and one for bar, with their corresponding content. Librsvg stores these in a hash table, since it has to be able to retrieve them later when the SAX parser requests it. In detail, libxml2 requires that you create an xmlEntityPtr by calling xmlNewEntity() and then keep it around.

xmlEntityPtr xmlNewEntity (xmlDocPtr      doc,
                           const xmlChar *name,
                           int            type,
                           const xmlChar *ExternalID,
                           const xmlChar *SystemID,
                           const xmlChar *content);

Later, you must free each of your stored entities with xmlFreeNode() (it supports different data types, including entities), or if you are using libxml2 2.12.0 or later, with xmlFreeEntity().

void xmlFreeNode (xmlNodePtr node);
void xmlFreeEntity (xmlEntityPtr entity);

Librsvg creates a SAX parser from libxml2, calls it to do the parsing, and then frees the entities at the end. In the following code, XmlState is the struct that librsvg uses to hold the temporary state during parsing: a partially-built XML tree, some counters on the number of loaded elements, the current element being processed, things like that. The build_document() method is called at the very end of XmlState's lifetime; it consumes the XmlState and returns either a fully-parsed and valid Document, or an error.

struct XmlState {
    inner: RefCell<XmlStateInner>,  // the mutable part

    // ... other immutable fields here
}

type XmlEntityPtr = *mut libc::c_void;

struct XmlStateInner {
    // ... a few fields for the partially-built XML tree, current element, etc.
    document_builder: DocumentBuilder,

    // Note that neither XmlStateInner nor Xmlstate implement Drop.
    //
    // An XmlState is finally consumed in XmlState::build_document(), and that
    // function is responsible for freeing all the XmlEntityPtr from this field.
    //
    // (The structs cannot impl Drop because build_document()
    // destructures and consumes them at the same time.)
    entities: HashMap<String, XmlEntityPtr>,
}

impl XmlState {
    fn build_document(
        self,
        stream: &gio::InputStream,
        cancellable: Option<&gio::Cancellable>,
    ) -> Result<Document, LoadingError> {
        // does the actual parsing with a libxml2 SAX parser
        self.parse_from_stream(stream, cancellable)?;

        // consume self, then consume inner, then consume document_builder by calling .build()
        let XmlState { inner, .. } = self;
        let mut inner = inner.into_inner();

        // Free the hash of XmlEntityPtr.  We cannot do this in Drop because we will
        // consume inner by destructuring it after the for() loop.
        for (_key, entity) in inner.entities.drain() {
            unsafe {
                xmlFreeNode(entity);
            }
        }

        let XmlStateInner {
            document_builder, ..
        } = inner;
        document_builder.build()
    }
}

There are many Rust-isms in this code.

• After doing the actual parsing with parse_from_stream(), self is destructured to consume it and extract its inner field, which is the actual mutable part of the XML loading state.

• The code frees each xmlEntityPtr stored in the hash table of entities.

• The inner value, which is an XmlStateInner, is destructured to extract the document_builder field, which gets asked to .build() the final document tree.

Where's the bug?

The bug is in this line at the beginning of the build_document() function:

        self.parse_from_stream(stream, cancellable)?;

The ? after the function call is to return errors to the caller. However, if there is an error during parsing, we will exit the function here, and it will not have a chance to free the values in the key-value pairs among the entities ! Memory leak!

This code had already gone through a few refactorings. Initially I had an impl Drop for XmlState which did the obvious thing of freeing the entities by hand:

impl Drop for XmlState {
    fn drop(&mut self) {
        unsafe {
            let mut inner = self.inner.borrow_mut();

            for (_key, entity) in inner.entities.drain() {
                // entities are freed with xmlFreeNode(), believe it or not
                xmlFreeNode(entity);
            }
        }
    }
}

But at one point, I decided to clean up the way the entire inner struct was to be handled, and decided to destructure it at the end of its lifetime, since that made the code simpler. However, destructuring an object means that you cannot have an impl Drop for it, since then some fields are individually moved out and some are not during the destructuring. So, I changed the code to free the entities directly into build_document() as above.

I missed the case where the parser can exit early due to an error.

The Rusty solution

Look again at how the entities hash table is declared in the struct fields:

type XmlEntityPtr = *mut libc::c_void;

struct XmlStateInner {
    entities: HashMap<String, XmlEntityPtr>,
}

That is, we are storing a hash table with raw pointers in the value part of the key-value pairs. Rust doesn't know how to handle those external resources, so let's teach it how to do that.

The magic of having an impl Drop for a wrapper around an unmanaged resource, like xmlEntityPtr, is that Rust will automatically call that destructor at the appropriate time — in this case, when the hash table is freed.

So, let's use a wrapper around XmlEntityPtr, and add an impl Drop for the wrapper:

struct XmlEntity(xmlEntityPtr);

impl Drop for XmlEntity {
    fn drop(&mut self) {
        unsafe {
            xmlFreeNode(self.0);
        }
    }
}

And then, let's change the hash table to use that wrapper for the values:

    entities: HashMap<String, XmlEntity>,

Now, when Rust has to free the HashMap, it will know how to free the values. We can keep using the destructuring code in build_document() and it will work correctly even with early exits due to errors.

Valgrind's evidence without the leak

# valgrind --leak-check=full ./target/debug/rsvg-convert leak.svg 
==5855== Memcheck, a memory error detector
==5855== Copyright (C) 2002-2024, and GNU GPL'd, by Julian Seward et al.
==5855== Using Valgrind-3.23.0 and LibVEX; rerun with -h for copyright info
==5855== Command: ./target/debug/rsvg-convert leak.svg
==5855== 
Error reading SVG leak.svg: XML parse error: Error domain 1 code 37 on line 2 column 1 of data: xmlParseEntityDecl: entity a not terminated

==5855== 
==5855== HEAP SUMMARY:
==5855==     in use at exit: 77,771 bytes in 804 blocks
==5855==   total heap usage: 1,405 allocs, 601 frees, 205,161 bytes allocated
==5855== 
==5855== LEAK SUMMARY:
==5855==    definitely lost: 0 bytes in 0 blocks
==5855==    indirectly lost: 0 bytes in 0 blocks
==5855==      possibly lost: 0 bytes in 0 blocks
==5855==    still reachable: 73,947 bytes in 746 blocks
==5855==         suppressed: 0 bytes in 0 blocks

Moral of the story

Resources that are external to Rust really work best if they are wrapped at the lowest level, so that destructors can run automatically. Instead of freeing things by hand when you think it's right, let the compiler do it automatically when it knows it's right. In this case, wrapping xmlEntityPtr with a newtype and adding an impl Drop is all that is needed for the rest of the code to look like it's handling a normal, automatically-managed Rust object.

Dear Tumbleweed users and hackers,

It’s the week before openSUSE Conference, when all through the world, contributors get ready to travel. People might be busy with their final preparations to meet at the conference next week, and prepare their slides for the talks, but nothing can stop them from keeping Tumbleweed rolling. This week, we have received 5 snapshots (0613, 0614, 0617, 0618, and 0619)

The most relevant updates included were:

• libxml 2.12.8
• Ruby 3.3.3
• VLC 3.0.21, see http://www.videolan.org/security/sb-vlc3021.html
• Mesa 24.0.9, 24.1.0 & 24.1.1: Mesa 24 brought some graphical glitches on AMD/.ATI graphic cards, which we could not catch in openQA. A (mostly) fixed version was published in the update channel to shorten the time)
• Mozilla Firefox 127.0
• KDE Gear 24.05.1
• Linux kernel 6.9.4 & 6.9.5

Staging projects are currently testing the integration of these changes:

• KDE Plasma 6.1
• NodeJS 22.3.0
• Perl 5.40.0
• transactional-update: enable soft reboot; see https://microos.opensuse.org/blog/2024-06-13-soft-reboot/
• Pytest 8.2
• dbus-broker: some networking issue after upgrades left to work out
• GCC 14: phase 2: use gcc14 as the default compiler – lots of help needed: https://build.opensuse.org/project/show/openSUSE:Factory:Staging:Gcc7

With all this, I am looking forward to seeing many of you at the openSUSE conference in Nuremberg next week!

Hoy mismo (21/6/2024) se ha publicado la nueva versión de MyGNUHealth 2.2.

Pero ¿Ya sabes qué es MyGNUHealth?

MyGNUHealth es un programa de software libre con el que es muy sencillo llevar un registro de salud personal. Esta aplicación se puede utilizar en computadoras de escritorio y dispositivos móviles.

Te ayuda a tomar el control de tu salud, y con la aplicación podrás registrar, valorar y actuar proactivamente sobre los determinantes de los principales ámbitos de tu salud (biopsicosocial).

MyGNUHealth no pretende reemplazar el consejo de un profesional de la salud. consulta siempre con profesionales que son las mejores fuentes para su salud y bienestar, aunque este programa te podrá servir como herramienta de algo tan importante como la salud.

Este nuevo MyGNUHealth 2.2 viene con muchas mejoras y correcciones de errores. Algunos aspectos destacados de esta nueva versión:

• Soporte para Kivy 2.3.0
• MyGNUHealth ahora tiene soporte para diferentes idiomas: Inglés, español y chino están disponibles para su uso, y francés, alemán e italiano están listos para ser traducidos. Habrá un componente de traducción para MyGNUHealth en la instancia Weblate de Codeberg.
• Funcionalidad Bluetooth: a partir de la serie MyGH 2.2, se proporciona integración Bluetooth para dispositivos abiertos compatibles y rastreadores de salud. Se incluye la vinculación con el Pinetime Smartwatch (experimental) y la posibilidad de vinculación a cualquier dispositivo de hardware libre (glucómetro, báscula, tensiómetro, etc).
• Los gráficos ahora permiten seleccionar rangos de fechas con widgets de calendario
• El Libro de la Vida tiene un formato revisado para las páginas.
• Se ha mejorado el formato de los gráficos e incluyen etiquetas del eje x.

En cuanto a la compatibilidad con hardware sanitario, el proyecto necesita obtener una lista de dispositivos médicos disponibles que respeten la privacidad y libertad de las personas que los utilizan, así que informa al proyecto si tienes información al respecto.

Gracias a Kivy, el código base de MyGNUhealth se puede migrar a otras arquitecturas y sistemas operativos como Android AOSP o teléfonos con sistemas GNU/Linux.

Además de Savannah, han incorporado Codeberg al entorno de desarrollo de GNU Health. Las listas de correo, noticias y descargas de archivos están en GNU, mientras que los repositorios de desarrollo están en Codeberg.

Se puede descargar el código fuente más reciente de MyGNUhealth desde el sitio ftp de GNU, pypi (usando pip) o desde el paquete de su sistema operativo (como openSUSE).

La actualización debería ser sencilla y todo el historial de salud que ya tuvieras almacenado permanecerá en la base de datos MyGH. En cualquier caso, es seguro siempre de hacer una copia de seguridad antes de actualizar o de manera diaria.

Mantén un seguimiento de tu salud y diversos datos relacionados con la salud gracias a MyGNUHealth y/o colabora con este gran proyecto comprometido a nivel tecnológico y social con el bienestar y la libertad de las personas.

Enalces de interés

• https://savannah.gnu.org/news/?id=10644
• https://codeberg.org/gnuhealth
• https://translate.codeberg.org/projects/gnuhealth/
• https://docs.gnuhealth.org//mygnuhealth/
• https://victorhckinthefreeworld.com/2022/06/15/que-es-gnu-health-su-creador-nos-responde/

Leap 15.6 install media were refreshed to address an issue with old secure boot signing key for ppc64le and s390x.

Refreshed images from Leap 15.6 Build 710.3 are already available for download at get.opensuse.org. So now you can enjoy installation with secure boot on more exotic architectures.

Happy Hacking!

_{^{(Image made with DALL-E)}}

Como muchos de vosotros sabréis KDE Blog es un blog personal. No es una decisión que yo haya tomado y que sea inamovible, sino que por circunstancias no he conseguido tener colaboradores que se sumen al proyecto de forma constante. En cierto modo lo comprendo: llevar un blog no está de moda y requiere cierta disciplina. No obstante, siempre encuentro algunos colaboradores como en ocasiones Rubén Gómez que me ha ayudado con la serie de creación de videojuegos. De esta forma me complace presentar una artículo que no es mío, sino de Ivan Gregori, Ingeniero industrial, apasionado de KDE y el software libre desde 2020, reciente miembro de KDE España al que podéis encontrar en las redes sociales siguientes: Mastodon: @ivangj@mastodon.social; PeerTube: @ivangj@fediverse.tv; YouTube: https://www.youtube.com/@Nuketowner

¿En qué debería KDE trabajar en los próximos 2 años? ¡Participa!

En 2022, y como ya indicamos en este blog, KDE se marcó 3 grandes objetivos (KDE Goals) que seguir durante los siguientes 2 o 3 años. 2 años después, están abiertas las propuestas para las siguientes grandes tareas que abordar, y te enseñamos aquí como puedes aportar tu granito de arena.

Como ya es tradición en KDE, cada 2 o 3 años se proponen, se debaten, y se consolidan varios objetivos clave que la comunidad de KDE debería seguir en sus desarrollos e innovaciones hasta la conclusión del periodo. En 2022, los «KDE Goals» marcados fueron

• KDE para todos: empujón a la accesibilidad
• Automatización y sistematización de los procesos internos
• Software sostenible
  y la conclusión y análisis del cumplimiento llegará durante el Akademy 2024 que se celebra del 7 al 12 de Septiembre en Würzburg, Alemania.

Debido a la cercana conclusión de estos objetivos, la comunidad KDE ya ha abierto los plazos para empezar a proponer ideas… ¡y aquí es donde tú entras en juego! En una fantástica entrada de blog de Lydia Pintscher (vicepresidencia de KDE e.V.) se detalla el funcionamiento del sistema, así como los plazos. Te lo contamos brevemente.

¿Cómo funciona?

Las propuestas y búsqueda de equipos están abiertas hasta el 5 de julio. Desde ese momento y hasta el 15 de agosto, las propuestas serán estudiadas y mejoradas; y finalmente estas serán votadas hasta el 31 de agosto. El 6 o 7 de septiembre, en el Akademy 2024 se presentarán oficialmente.

¿Qué perfiles se buscan?

Solamente se necesita que estés claramente interesado en empujar un proyecto adelante. No tienes por qué saber programar, ni tener experiencia en otros proyectos de KDE. Tampoco estarás solo; así que si estás verdaderamente motivado en aportar algo, ya sea en ideas, compromiso, liderazgo, código, traducciones… no pierdas esta oportunidad. (Obviamente, el inglés es un requisito implícito…)

De hecho, que sepas que el proceso está particularmente buscando nueva gente, con nuevas ideas, y no necesariamente desarrolladores.

¿Cómo puedes participar?

Echa un vistazo a la tabla de Phabricator, donde puedes ver todas las propuestas realizadas hasta ahora. Se recomienda que antes de hacer ninguna propuesta, compruebes que no hay ninguna propuesta similar sobre la que ya pudieras expandir. Quizás aparezcan ideas interesantes a las que te apetezca sumarte.

Si crees que tu idea merece la pena, en la columna «Backlog» encontrarás la plantilla T17356 Goal template, que podrás copiar para crear tu propuesta.

Aunque los KDE Goals suelen mirar a gran escala (véase los elegidos en 2022), hay algunas propuestas más específicas este año. Veremos si pasan el filtro y cuáles son los grandes objetivos para los próximos años.

¿Te apuntas?

La entrada ¿En qué debería KDE trabajar en los próximos 2 años? ¡Participa! se publicó primero en KDE Blog.

Here is a little gift for the weekend. openSUSE Leap Micro 6.0 RC is now available! Images can be found at get.opensuse.org.

The main difference from Beta is a working upgrade path from 5.5 and slightly smoother upgrade support to commercial products. So let’s test it out.

Upgrade instructions

I’d personally recommend a clean install, especially in between major versions on a system that can be redeployed with self-install within 2 minutes. At the same time, the online upgrade takes longer. Another aspect to consider is that we don’t have a developed migration test suite for online migration, unlike for Leap 15.X.

The easiest way to test the upgrade would be in a VM. Get Leap micro 5.5 images from get.opensuse.org and ensure you have all updates applied via transactional-update.

I’d recommend upgrading to 6.0 via SSH or console instead of cockpit, as the service might stop responding. Upgrade instructions and known issues are captured in the SDB:System_upgrade_to_LeapMicro_6.0 wiki page.

Make sure to check known issues before proceeding.

Documentation

Please refer to SLE Micro 6.0 documentation including Release notes.

Reporting Issues

Please refer to the Leap Micro section in our Submitting bug reports page.

Next steps

Leap Micro 6.0 GA can be expected before oSC2024 next week.

Cómo hacer que Klipper, el portapapeles del escritorio Plasma de KDE, muestre su contenido en la posición del puntero del ratón

A veces los pequeños detalles aportan algo más de lo que creemos y en el día a día pasan desapercibidos.

Eso es lo que me pasa con muchas de las cosas buenas que ofrece el escritorio Plasma de KDE a las que estoy a costumbrado y que echo de menos cuando uso (por obligación) sistemas privativos.

Uno de esos detalles es Klipper, el portapapeles del escritorio Plasma de KDE. Os propongo un artículo muy sencillo, pero que a mí personalmente me resulta muy útil y algún truco más.

Klipper aparece en la bandeja del sistema de nuestro escritorio Plasma de KDE. Pinchando sobre el icono, nos muestra una lista de los últimos textos que hemos copiado y que podemos volver a utilizar para pegarlo en donde lo necesitemos.

Códigos QR

Pero no solo eso, algo que me gusta mucho es la posibilidad de generar un código QR con el texto que escojamos del portapapeles, así lo podremos escanear con el móvil y tenerlo en nuestro dispositivo.

Basta con pulsar sobre el icono de Código QR que aparece al lado de la entrada del portapapeles que queremos compartir.

No lo uso mucho, pero ahí está la opción.

El portapapeles en la posición del cursor

Pero es esta opción sobre la que quería escribir hoy. Si estamos navegando por la red, o editando un texto con Kate, por ejemplo, copiando un texto, seleccionado con el cursor y después lo queremos pegar en otra ubicación.

Es «muy molesto» (vale no es molesto, pero sí un movimiento inútil) el tener que mover el cursor hasta la posición de la bandeja del sistema (normalmente en una esquina de la pantalla) para pinchar sobre el icono del portapapeles para seleccionar una entrada copiada anteriormente.

Podemos abrir la lista del portapapeles en la misma posición en la que se encuentra el ratón sin necesidad de desplazarnos hasta la bandeja del sistema. Simplemente pulsaremos el atajo de teclado Meta+V. Pruébalo ahora mismo…. ¡Bum! ¡Qué sorpresa! ¿Verdad?

Como todo en Plasma ese atajo es configurable a nuestros gustos, pero para mí la opción predeterminada me parece buena.

Un truco sencillo que quizás no sabías y que te hubiera gustado saber antes ¿Qué más sorpresas nos tiene reservadas KDE?

Siguiendo el objetivo de mostrar qué ofreció el pasado mayo la Comunidad KDE en cuanto a aplicaciones. Hace unos días hablé de las nueva aplicaciones del ecosistema y ayer hablé de Dolphin. Hoy toca hablar de las novedades de Itinerary en KDE Gear 24.05, una aplicación que sigue ganando adeptos, sobre todo entre aquellas personas que no le veían utilidad, como me llegaron a comentar en Akademy-es.

Las novedades de Itinerary en KDE Gear 24.05

Hay aplicaciones que cuando las ves no pareces hacerle caso. Este es le caso de Itinerary, un asistente de viajes digital que tiene como prioridad proteger su privacidad ya que no escanea nada que tu no le digas que escanee, con lo que solo adquirirá la información que le proporciones y no tendrás miedo a que nadie se lleve información de tu equipo.

Esta aplicación va creciendo poco a poco, y ya se ha convertido en un clásico dentro de las novedades de cada lanzamiento de KDE Gear. En este ocasión, Itinerary viene con las siguientes novedades

El asistente de viajede KDE ahora muestra ahora más información sobre las instalaciones de trenes y autocares (cuando dispongan de dicha información). Esto incluye características de confort general, como aire acondicionado o wifi, así como otras cosas específicamente relevantes cuando se viaja con niños pequeños, bicicletas o sillas de ruedas. Estos servicios también pueden calificarse por disponibilidad (por ejemplo, si requieren una reserva especial) y marcarse como interrumpidos. Esta información se muestra cuando se consulta el diseño de los coches del tren y cuando se buscan conexiones.

Por otra parte, el equipo de Itinerary, en colaboración con otros proyectos de código abierto, ha empezado a trabajar en un servicio de rutas de transporte público internacional, independiente de fabricantes y gestionado por la comunidad, llamado Transitous. El objetivo de Transitous es centrarse en los intereses de los usuarios en lugar de en los de los operadores de transporte. Es de uso gratuito, respeta la privacidad de los usuarios y no se detiene en las fronteras.

Más información: KDE Gear 24.05

La entrada Las novedades de Itinerary en KDE Gear 24.05 se publicó primero en KDE Blog.