September 25, 2018

Como estaba previsto en el calendario de los desarrolladores, hoy martes 25 de septiembre la Comunidad KDE ha comunicado que ha sido lanzada la séptima actualización de Plasma 5.12 LTS. 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 pedazo de Software Libre.

Lanzada la séptima actualización de Plasma 5.12 LTS

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.

Por eso, y pensando que hay usuarios que ponen por delante de las novedades la estabilidad, la Comunidad KDE ofrece dos escritorios Plasma: el LTS y la estándard. El primero va por la versión 12, el segundo por la 13.

De esta forma, hoy martes 25 de septiembre se ha lanzado la séptima actualización de Plasma 5.12, la cual solo trae (que no es poco) soluciones a los bugs encontrados en estas dos semanas de vida del escritorio y mejoras en las traducciones.

Es por tanto, una actualización 100% recomendable que todo el mundo con Plasma 5.12 se debería realizar ya que solo mejora errores y traducciones.

Más información: KDE.org

Las novedades de Plasma 5.12 LTS

Muchas y variadas son las novedades que nos presenta Plasma 5.12, lo cual hace que sea una jugosa tentación aquellos que todavía no confían en el proyecto de la Comunidad KDE y una ilusionante vuelta de tuerca para aquellos que llevamos tiempo disfrutando de sus bondades.Lanzada la séptima actualización de Plasma 5.12 LTS

Una de las más importante, como no podía ser de otra forma en una LTS, es la mejora general del entorno, lo cual se materializa en mejoras de velocidad y en la optimización en el uso de la memoria. En otras palabras, cuando ejecutamos Plasma, ahora se usa menos CPU y menos memoria que en versiones previas. Por ejemplo, el tiempo que tarda en iniciarse un escritorio Plasma ha reducido drásticamente.

En cuanto a pequeñas mejoras tenemos:

  • Nueva funcionalidad “Color de noche” para reducir la exposición a la luz azul en las horas nocturnas.
  • Mejora de la usabilidad del menú global: al añadir una panel de menú global o un botón de decoración de ventana activa sin necesidad de ningún paso extra de configuración.Lanzada la segunda actualización de Plasma 5.12 LTS
  • Mejoras de accesibilidad en el KRunner: ahora se puede utilizar completamente con los lectores en pantalla, como Orca
  • La miniaplicación de iconos ahora usa el icono de web del sitio web
  • Vuelve a poderse seleccionar el texto de notificación, incluyendo una funcionalidad de copia de enlace
  • La disposición del menú de aplicaciones del Kickoff se ha simplificado.
  • La miniaplicación meteorológica ahora puede mostrar opcionalmente la temperatura junto al icono del estado del tiempo en el panel.
  • La actividad del sistema y el Controlador del sistema ahora muestran las gráficas para proceso del uso de la CPU.
  • El texto del widget Reloj ahora tiene un tamaño más adecuado.
  • Las sombras de las ventanas ahora están centradas horizontalmente y son más grandes
  • El diálogo de propiedades ahora muestra los metadatos del archivo.

Discover

Capítulo aparte merece Discover, el gestor de aplicaciones, temas, plasmoides y de cualquier cosa instalable de Plasma. Y es que son muchas las facetas que han mejorado y que lo convierten en un pieza básica del entorno Plasma.

Lanzada la sexta actualización de Plasma 5.12 LTS

Discover, pieza clave en el desarrollo del escritorio Plasma sigue mejorando.

De esta forma tenemos:

  • Mucha más estabilidad (quizás la más necesaria)
  • Mejoras en la implementación del Snap y el Flatpak (básica para la revolución que se está gestando para la instalación de aplicaciones)
  • Implementación de los URL apt: //
  • Las distribuciones pueden activar actualizaciones desconectado
  • Mejor usabilidad en factores de forma de teléfono: usa la acción principal del Kirigami, que tiene una vista específica para buscar
  • Integra las señales globales del PackageKit a las notificaciones
    • Actualización de distribución para los lanzamientos nuevos
    • Notificación de reinicio cuando el Discover instala o actualiza paquetes que requieren un reincio
  • Mejoras en la interfaz de usuario
    • Se han rediseñado las páginas de las aplicaciones para mostrar un software destacado.
    • Cabeceras más simples en secciones de no visualización
    • Vistas de navegación más compactas, con el fin de ver más aplicaciones de golpe
    • Las capturas de pantalla para aplicaciones son más grandes y tienen navegación por teclado
    • La lista de aplicaciones instaladas ordena alfabéticamente
    • IU más completa para configurar orígenes

Wayland avanza a pasos agigantados

Lo moderno se debe imponer poco a poco a lo obsoleto. Está claro que Wayland es el futuro y su integración en Plasma mejor en cada versión. De esta forma, por primera vez, se añade Wayland en el mantenimiento a largo plazo, así que se irán solucionando los errores en la series 5.12.x LTS.

Lanzada la segunda actualización de Plasma 5.12 LTS

Wayland y su ventana de configuración de pantallas. Cada día más cerca de reemplazar el veterano X.org

Para los más curiosos, estas son las nuevas funcionalidades de Wayland:

  • La resolución de la salida se puede definir desde el KScreen
  • Activación y Desactivación de las salidas desde el KScreen
  • Posibilidad de rotación de la pantalla
  • Rotación automática de pantalla a partir del sensor de orientación
  • Calibración automática de la pantalla táctil
  • Ya no se requiere más la implementación del XWayland; las aplicaciones que solo permitan las X todavía harán uso
  • Las ventanas del Wayland se pueden establecer a pantalla completa
  • Usa una política de planificación en tiempo real para mantener la fluidez de la entrada
  • Selección automática del Compositor en base a la plataforma usada
  • Comienza la implementación de las reglas de ventana
  • Color de noche para eliminar la luz azul de la pantalla en horario nocturno; esto es una sustitución solo por Wayland de la gran aplicación Redshift a las X

Wayland viene a Plasma y está a punto de ser el motor de visualización por defecto.

En resumen, un gran anuncio para una gran Comunidad que sigue apostando por el denostado escritorio y demostrando versión tras versión que Plasma es lo mejor que le puede pasar a tu ordenador.

¡KDE Rocks! ¡Larga vida a Plasma!

Lanzada la séptima actualización de Plasma 5.12 LTS

Plasma 5.14 is right around the corner, time to write again an update like I did for 5.13 on what was achieved in terms of Wayland and what is in the work.

On blocking and reprioritizing work

First I directly admit on what I did teaser for 5.14 in my last update but what will not make it: generic gamma color correction per display. There are two reasons for it. The first one is that some preliminary patches, which needed to be merged first, endured long review phases. The second reason is, that when these patches finally were accepted I had shifted my focus on some other topics, which I decided to give an higher priority.

Before delving into these other topics, a short analysis on why the reviews took so long: first there were of course some improvements possible to my patches, but after these got pointed out in the reviews I did fix them back then pretty quickly. The more striking reason is though that we are just short on people who can actually review KWin code changes, in particular with Martin being not maintainer anymore. That is not only a problem for my proposed code changes, but for anyone’s patches to KWin. And this hasn’t improved since back then. We must find a way to reduce the review pressure on the people being capable of doing reviews somehow, at best with only a minimal hit in code quality. I don’t have a full solution for this problem yet, we will see if we find a good one.

After this is out of the way, let us talk about these other features, which I prioritized higher.

Xwayland drag and drop translation

Drag and drop is an important workflow on desktop platforms. In our Wayland session Xwayland clients were able to do this between each other through the X protocol provided by Xwayland. Wayland native clients were able to do it with the Wayland interfaces for data sharing, what already has been implemented in most aspects in KWin and KWayland.

But these two world were separated. Wayland native clients could not drop something on an Xwayland client and vice versa. For that to work a translation layer needed to be created. We had already some small workaround to translate the clipboard in place, but a similar small workaround would not have worked for drag and drop.

Nevertheless I have a solution now, not a small one for sure, but it is similar to how Weston and wlroots try to solve the task, what will hopefully allow us to work closer together in this regard in the future. The solution also rewrites the clipboard mechanism to have it more in line with the other compositors and to be better integrated in the Xwayland handling part of KWin. All the details I omit here for now, but if there is interest I will write another article only about this subject.

In regards to the other compositors one last comment: the Weston solution seems to be only partly done and wlroots still struggles with a few remaining issues, but it was still immensely helpful to read their code to get a first understanding on what needs to be done besides some other literature. I hope I can repay the favor by providing now some more information to them on what I learned when I wrote my patches.

Pointer lock and confining reimagined

While Xwayland drag and drop translation took up the majority of my time in the last three months and is somewhat more important to the majority of our users, who do daily work in the browser, there is a particular subset of users, who will be very happy about a series of changes I did before that and which even already will be available in 5.14. I am talking about our support for pointer constraining, what consists of pointer locking and pointer confining, and the particular subset of users affected by that are gamers.

In the past we already supported pointer constraints, but the support lacked in numerous aspects. I won’t go into detail, but anybody who tried to play some games in a Wayland session can probably tell you about problems, starting from annoyingly often displayed warning messages to never locked or never unlocked cursors. A list of issues and what I did to solve them, can be found here.

The end result should be that pointer constraints can be used from 5.14 on without any hiccups and without even being noticed. This should improve the quality of our Wayland session for gamers drastically and I have planned some more changes for the future to improve it even more.

Touch drags and input redirection rework

A small missing item I noticed when working on Xwayland drag and drop was that we did not yet support Wayland native drags executed through input on a touch screen. To enable these only a few small code additions to KWayland and to KWin were necessary.

But when working on this feature and with my experience from the Xwayland drag and drop project it became all so more apparent to me that our input redirection code for pointer and touch devices needed a serious overhaul. In general the original idea behind it was fine: input redirection detects which client, decoration or internal window (a surface being created by KWin to use on its own, for example for depicting its effects) has device input focus. There is an update function per device, which redetermines the target, and there are filters to run though to channel off events in case of compositor overruling for example by some effect. But in detail there was much code duplication going on and the update function was recalled rather randomly throughout numerous filters.

My patch improves the code in both aspects: the update function gets called only once per event and code duplication is reduced through more inheritance usage. Also it is now more clear when the input focus is on the decoration of a client or if the client is an internal window and what to do then. Overall the effects of this rework will not be directly visible to the user, but it will give us a stronger foundation to build upon in the future.

Outlook

There is some more foundational work without a direct huge visible payoff necessary, in particular to how internal windows are being treated in KWin, which spawned some nasty problems in the past and needs a more thorough investigation than quick workarounds to ease the immediate pain.

Other foundational work, but which at least has direct impact, is the reorganization of our painting pipeline for multiple outputs at different frequencies, what was mentioned above already as an improvement for gamers. Doing this will not be a small feat and we will see when there is time for it. I hope sooner than later.

What should not be forgotten when talking about this particular feature is adaptive synchronization, better known under AMD’s trademark FreeSync and that we want to support this technology of course as well. But the patches to the kernel and Mesa only recently have been posted to the respective mailing lists and I have literally no idea what is necessary from our side to enable it.

This and others topics to discuss is what I am looking forward to when the X.Org Developer’s Conference 2018 starts tomorrow morning in A Coruña. I traveled a bit through Galicia in the last few days with a rental car and will arrive in the city at some point later today (by the way the picture accompanying this article is from one of the stops I made). Looking at the program and the attendees this should become a very interesting conference. If you are interested as well, you can follow the livestream starting tomorrow with the regular program.

September 24, 2018

Earlier this month i attended Libre Application Summit 2018 in Denver.



Libre Application Summit wants to be a place for all people involved in doing Free Software applications to meet and share ideas, though being almost organized by GNOME it had a some skew towards GNOME/flatpak. There was a good presence of KDE, but personally I felt that we would have needed more people at least from LibreOffice, Firefox and someone from the Ubuntu/Canonical/Snap field (don't get annoyed at you if I failed to mention your group).

The Summit was kicked off by a motivational talk on how to make sure we're ride the wave of "Open Source as won but people don't know it". I felt the content of the talk was nice but the speaker was hit by some issues (not being able to have the laptop in front of her due to the venue being a bit weirdly layouted) that sadly made her speech a bit too stumbly.

Then we had a bunch of flatpak related talks, ranging from the new freedesktop-sdk runtime, from very technical stuff about how ostree works and also including a talk by our own Aleix Pol on how KDE is planning to approach the release of flatpaks. Some of us ended the day having BBQ at the house the Codethink people were staying. Thanks for the good time!



I kicked off the next day talking about how we (lately mostly Christoph) are doing the KDE Applications releases. We got appreciation of the good work we're doing and some interesting follow up questions so I think people were engaged by it.

The morning continued with talks about how to engage the "non typical" free software people, designers, students, professors, etc.



After lunch we had a few talks by the Elementary people and another talk with Aleix focused on which apps will run on your Plasma devices (hint: all of them).

The day finished with a quizz sponsored by System 76, it was fun!



The last day of talks started again with me speaking, this time about how amazing Qt is and why you should use it to build your apps. There I had some questions about people worrying if QtWidgets was going to die, I told them not to worry, but it's clear The Qt Company needs to improve their messaging in that regard.



After that we had a talk about a Fedora project to create a distro based exclusively in flaptaks, which sounds really interesting. The last talks of LAS 2018 were about how to fight vandalism in crowdsourced data, the status of Librem 5 (it's still a bit far away) and a very interesting one about the status of Free Software in Research.

All in all i think the conference was interesting, still a bit small and too GNOME controlled to appeal to the general crowd, but it's the second time it has been organized, so it will improve.

I want to thank the KDE e.V. for sponsoring my flight and hosting to attend this conference. Please Donate! so we can continue attending conferences like this and spreading the good work of KDE :)

It’s about a month now since the end of Akademy 2018 and I’ve finally found the time to write up some of my impressions from my favorite event of every year, and to encourage all of you to embrace both your inner User Experience (UX) Researcher and your inner guerilla.

My Talk: Guerilla UX Testing

che-155389_1280.png

“Che Stallman”, CC0 from Pixabay / openclipart

I usually try to give at least one talk at each Akademy I attend, and this year I wanted to shake up the way KDE approaches UX design and research a bit again. The idea to give a talk about Guerilla UX came when we had one of those design discussions on Phabricator where different sides of the discussion had different ideas in their minds of what The User™ would want or need, and we had no way to tell which side knew our users better, or even if either side knew them well at all.

Usually, a UX person’s reaction (at least if they don’t suffer from delusions of grandeur) to such situations is “Why don’t we just test it with actual users?”. As a distributed community of mostly volunteers with limited personnel and monetary resources, however, this is much easier said than done. This is where Guerilla UX Research comes in: According to UX Magazine “Guerrilla research is a fast and low-cost way to gain sufficient insights to make informed decisions.”

In short: Guerilla Usability / User Experience Testing has you walk up to someone resembling your target audience (can be a stranger, can be someone you know as long as they are not aware of what you’re currently discussing), show them the product / UI / design you want to find something out about, give them a task and watch them use what you’ve made, recording any user experience issues you notice.

This is often all we need: A relatively quick and cheap way to gain some insight into how our users think and behave, even if the insight is only limited. It’s not as good as detailed user research with specifically selected participants, but as long as the test participants are at least similar enough to the actual target audience, it’s definitely better than generalizing from the project team’s own experience to that of the target audience.

I’d therefore heartily encourage everyone who needs to design a user interface or decide on features and isn’t 100% sure what their users need to take maybe a day (or maybe an hour each if you split the task among the team) to perform some guerilla user testing. I can promise you that you will be surprised by the results and that you will have fun!

For more details see the slides from my talk:

(in case the embedded viewer doesn’t work for you, here are the slides on Slideshare)

Akademy from the Perspective of a Board Member

This year’s Akademy was especially interesting for the board of directors of KDE e.V.. in several ways.

Sponsors Dinner

On Saturday, we could witness first-hand how KDE is able to connect different organizations: At the sponsors dinner, where representatives from all of Akademy’s sponsors spend an evening together with the board to share our ideas and projects.

I had the opportunity to sit at a table with representatives from four companies that are active in the hardware business and all are connected to KDE now: Blue Systems, Mycroft, Pine64, Purism and Slimbook. It was really cool to see the people from the different companies discuss their plans and their experiences with trying to make hardware in a FOSS-friendly, user-freedom-respecting and ethical way. All of them had already heard of the other companies before, but most of them had never met in person before, so we really had an effect there.

Annual General Assembly

On Monday, we had KDE e.V.‘s Annual General Assembly (the official minutes in German can already be found on our website, the English translation is still in preparation). For me personally, the biggest event of the AGM was the election of a new board member to replace Sandro Andrade, whose term had ended (thank you again for your great work on the board, Sandro!).

Before the AGM, Andy Betts was the only candidate for the position. Not really a problem since Andy was a great candidate, but an election with only one candidate where all one can do is vote for or against that candidate always feels a bit weird to me. That’s why I was happy when Tomaz Canabrava spontaneously stepped up as a second candidate during the AGM. Now we were in the comfortable position of having two excellent candidates to choose from.

After a great Q&A session with both candidates, Andy won the election. I’m very happy to have Andy on the board, though I would have been equally happy with Tomaz.

Meeting with The Qt Company

Right after the AGM, the board met with a delegation from The Qt Company (which included their CEO and CTO) to discuss how we can collaborate to make sure that Qt continues to serve both the needs of The Qt Company and those of KDE (and the ecosystem of Qt users as a whole).

We learned a lot about The Qt Company’s plans and the challenges they’ve overcome and are still facing, and were able to share our experiences as one of the key players in the Qt ecosystem. Overall it was a very informative and constructive meeting, and we’re looking forward to continue collaborating with The Qt Company toward our common goal: To keep Qt as great as it is!

My Highlights from the BoF Days

Unfortunately the meeting with The Qt Company coincided with two BoFs that I had really wanted to attend: One was about the VVAVE project, a very promising KDE music player and music discovery platform created by Camilo Higuita, the other was about the newly-rebooted KDE Human Interface Guidelines. I had contributed a lot to the original content of the HIG but haven’t had much time to work on it recently, so I’m eternally grateful that Fabian Riethmayer took over maintainership and is putting countless hours of work into them.

I spent the first half of Tuesday in two sessions about the current state and goals of the VDG (and Plasma design topics in particular), led by Andy, and the second half discussing mobile and convergence topics in the sessions about our convergent UI toolkit Kirigami UI (led by Maco Martin), and about the MauiKit (led by Camilo) which extends Kirigami further. We discussed what we consider to be the defining attributes of Kirigami, what the commonalities and differences between MauiKit and Kirigami are, and how to make sure that both users and developers have the best possible experience across both.

Trainings

Thursday, my last day at Akademy, I spent in the Online Fundraising and Campaigning training, led by Florian Engels from more onion (via NPO academy). All participants agreed that we learned a lot of practical strategies and tips for fundraising and campaigning, which we are sure to apply in the coming campaigns for KDE, Krita and Nitrux!

I also heard a lot of positive feedback on our other trainings: The training on Nonviolent Communication by freelance communication trainer Tilman Krakau, the Technical Documentation Training by Stefan Knorr from SUSE’s documentation team, and the Public Speaking training by Marta Rybczynska, technical public speaker and trainer, and active member KDE.

Since I was in charge of setting up the trainings and this was (as far as I know) the first time KDE offered professional training to our contributors at Akademy, I’m glad that they seem to have worked out very well!

Conclusion

As in every year, this was again a very successful Akademy, with lots of productive discussions, interesting talks, great conversations with friends over dinner and beer, and overall a wonderful time!

 

Hace un tiempo, la compañía SUSE empezó a realizar una serie de vídeos musicales paródicos con su mascota y el Software Libre como protagonistas. Así que hoy os presento el videoclip SUSE Now Hallelujah. Sonido excelente, imagen perfecta, buena coreografía y muy buen gusto en general.

Videoclip SUSE Now Hallelujah , nueva parodia

Desde What Does the Chameleon Say? (Ylvis – What Does the Fox Say parody), el primer vídeo que realizaron en el 2013, la la gente de SUSE ha ido realizando una serie de vídeos musicales donde mezcla música actual con temas del Software Libre.

Videoclip SUSE Now Hallelujah , nueva parodiaDe esta forma ya son más de 10 vídeos ya publicados con todo tipo de estilos musicales y artistas parodiados, todos de forma muy respetuosa. Así aparecen grupos conocidos como Marroon 5 y su Sugar o la parodia de “Can’t Stop the Feeling” de Justin Timberlake  que se convirtió en “Can’t Stop the SUSE”.

En esta ocasión le ha tocado el turno a “Faith” de Stevie Wonder y Ariana Grande, el cual se ha convertido “SUSE Now Hallelujah“, una preciosa y pegadiza canción con una característica luz verdosa.

 

Los otros vídeos de SUSE

Como he comentado, este no es el primer vídeo de SUSE (y espero que no sea el último). En las ediciones de SUSECon se solía realizar un vídeo.

En SUSECon de 2013, tuvimos el placer de ver a Jeff Farnsworth caracterizado como el Camaleón danzarín, que hacía mover el esqueleto a buena parte del personal de SUSE con su versión de “Get Lucky” de Daft Punk. Espectacular.

Pero aquí no acaba la cosa. En la misma reunió se atrevieron a Ylvis y su What Does the Fox Say, creando su propio “What Does the Chameleon Say?” que no tiene desperdicio.

 

Y para finalizar, nada mejor que recordar el gran éxito del 2012 OpenSUSE Gangnam Style, que parodiaba a la canción más pegadiza de ese año Gangnam Style de PSY.

 

En definitiva, una muestra de lo imaginativa y colaborativa que puede ser la Comunidad del Camaleón.

Vía:La mirada del replicante

As you may know, a little more than a month ago Akademy happened at the beautiful place of Vienna. On my first post, I told you about how I was freaking out before giving my talk about Atelier. So, to continue my history, on the following days of Akademy, Tomaz brought his printer from Munich... Continue Reading →

September 23, 2018

Volvemos a tema de diseño al blog con Nilium, un nuevo tema para Plasma de tono oscuro pero colorido. Una gran creación de David Linares, conocido como @mcder3 que sigue ofreciéndonos diseños muy cuidados.

Nilium, nuevo tema para Plasma

Los temas para el escritorio Plasma de la Comunidad KDE son sutiles pero importantes. La verdad es que todos se parecen mucho inicialmente, pero una vez instalados y tras un poco tiempo de uso ves las diferencias y decides si te gusta o no.

Y esto es así porque aunque los cambios son sutiles, abarcan a todo el sistema: iconos de la bandeja del sistema, pantalla de apagado, reinicio o cambio de usuario, animaciones al ejecutar aplicaciones, decoraciones de plasmoide, etc. Además, algunos de ellos combinan mejor con un tipo de iconos que con otros.

Es por ello, que me complace presentaros la nueva creación de David Linares (aka @mcder3) con la que tendremos un Plasma, como con todos sus diseños elegante y ligero, con transparencias adecuadas y con un tono oscuro y colorido. Una combinación de sus temas Noc y Helium.

Nilium, nuevo tema para Plasma

 

También es de destacar su pantalla de salida y las grandes personalizaciones con las que ha dotado al botón de inicio del lanzador de aplicaciones, al plasmoide reloj analógico o al de notas anclado a la barra de tareas.

Además, este tema combina muy bien con los ionos Antü y el colorido fondo de pantalla del mismo nombre, Nilium.

Todo muy sencillo pero visualmente muy atractivo.

 

Y como siempre digo, si os gusta el tema Nilium para Plasma podéis “pagarlo” de muchas formas, desde donaciones a mcder pasando por todo tipo de acciones en la página de KDE Store, que estoy seguro que el desarrollador lo agradecerá: puntúale positivamente, hazle un comentario en la página o realiza una donación. Ayudar al desarrollo del Software Libre también se hace simplemente dando las gracias, ayuda mucho más de lo que os podéis imaginar, recordad la campaña I love Free Software Day 2017 de la Free Software Foundation donde se nos recordaba esta forma tan secilla de colaborar con el gran proyecto del Software Libre y que en el blog dedicamos un artículo.

Más información: KDE Store

Here’s your latest Usability & Productivity report–and we’ve got all kinds of goodies to share!

New Features

Bugfixes

UI Polish & Improvement

Next week, your name could be in this list! Just check out https://community.kde.org/Get_Involved, and find out how you can help be a part of something that really matters. You don’t have to already be a programmer. I wasn’t when I got started. Try it, you’ll like it! We don’t bite!

If my efforts to perform, guide, and document this work seem useful and you’d like to see more of them, then consider becoming a patron on Patreon, LiberaPay, or PayPal. Also consider making a donation to the KDE e.V. foundation.

September 22, 2018

Procure seu colaborador favorito do KDE na Foto em grupo oficial do Akademy 2018

Estive em Viena para participar do Akademy 2018, o encontro anual do KDE. Este foi o meu quarto Akademy, sendo antecedido por Berlin’2012 (na verdade, Desktop Summit ), Brno’2014, e Berlin’2016 (junto com a QtCon). Interessante, vou ao Akademy a cada 2 anos – pretendo melhorar isso já no próximo. ��

Após uma viagem muito longa, pude finalmente encontrar “cabeças de engrenagem” de todas as partes do mundo, incluindo o próprio Brasil. Vi velhos e novos amigos trabalhando juntos para melhorar a experiência de utilizar um computador com software livre, cada qual contribuindo com pequenas (e alguns, realmente gigantes) partes para tornar isso realidade. Sempre que encontro esse pessoal me sinto reenergizado para seguir com esse trabalho.

Das palestras, gostei muito da feita por Volker sobre o KDE Itinerary, uma nova aplicação para gerenciar passbooks relacionados com viagens. Penso que um software para gerenciar todos os tipos de arquivos passbook (como entradas para shows, cinemas, e mais) como este seria uma interessante adição para a família de softwares do KDE, e um passo anterior à ideia perseguida pelo KDE Itinerary. De qualquer forma, estou na expectativa por novidades deste software.

A palestra sobre criação de transições utilizando o Kdenlive me fez pensar em quão interessante seria um plugin para executar scripts bash (ou python, talvez) de forma a automatizar vários passos realizados por editores nesse software. Inclusive, talves utilizando a KDE Store para compartilhar esses scripts… enfim, muitas ideias.

Conheci Camilo durante o evento. A palestra dele sobre o vvave me deu esperanças por uma nova e interessante aplicação de player multimídia, como uma vez tivemos no passado (saudades Amarok).

A última palestra que chamou minha atenção foi de Nate sobre algumas ideias para melhorar nosso ecossistema. Nate está fazendo um trabalho fabuloso sobre usabilidade, “polindo” nossos software de diversas formas. Recomendo o blog dele para quem quiser ficar acompanhar também. Apesar de eu concordar em geral com boa parte das ideias – por exemplo, é urgente a necessidade de melhorarmos nossa suíte de aplicações pessoais -, eu tive alguns desacordos em outras, em especial a ideia de que os desenvolvedores do KDE se dediquem a contribuir também para o LibreOffice. LibreOffice tem um código fonte completamente diferente, que utiliza tecnologias e práticas nada relacionadas com o que vemos no KDE, e há várias (e para muitos de nós, desconhecidas) influências das diferentes organizações que gerem a The Document Foundation, entidade responsável por desenvolver o LibreOffice. E por fim, nós ainda temos a suíte de escritório Calligra – a idea me soou como “vamos acabar com o Calligra”. De qualquer forma, isso foi apenas um desacordo com uma das sugestões, nada demais.

Após as seções de palestras o Akademy teve batantes sessões de BoF, que são mini-reuniões direcionadas sobre tópicos específicos. Pude participar de algumas, como a sobre o KDE e Qt (é sempre bom manter os olhos sobre esse tópico), KDE Phabricator (Phabricator é um conjunto muito bom de ferramentas para gerenciamento de projetos/repositórios/e afins, mas sofre por conta dos competidores (Gitlab) serem muito mais conhecidos e também por não ter das melhores usabilidades), e MyCroft (gosto da ideia de integração entre o MyCroft e o Plasma, especialmente para casos de uso especĩficos como auxiliar pessoas com deficiência – estou pensando nisso já há alguns meses).

Este ano, Aracele, Sandro e eu realizamos um BoF chamado “KDE in Americas”. A ideia foi apresentar algumas das nossas conquistas para o KDE na América Latina e discutir com o pessoal das demais américas sobre um evento “continental”, trazendo de volta o antigo CampKDE em uma nova edição junto com o LaKademy (o nome secreto é LaKamp :D). Esta ideia ainda precisa de alguma maturação para seguir em frente, mas estamos trabalhando.

Este ano eu tentei realizar o BoF sobre KDE na ciência e Cantor, mas infelizmente eu não tive o feedback necessário sobre potenciais participantes. Vamos ver se no futuro poderemos ter alguns deles acontecendo.

Akademy é um evento fantástico onde você encontra colaboradores do KDE de diferentes frentes e culturas, pode discutir com eles, pegar opiniões sobre projetos atuais e mesmo iniciar novos. Gostaria de agradecer ao KDE e.V. pelo patrocínio que me permitiu ir ao evento e espero ver todos vocês e mais alguns no próximo ano (vou tentar inserir um distúrbio naquela distribuição da minha sequência bianual de participações) no Akademy ou, em algumas semanas, no LaKademy!

Brasileiros no Akademy 2018: KDHelio, Caio, Sandro, Filipe (eu), Tomaz (abaixo), Eliakin, Aracele, e Lays

It’s exactly 20 years ago to the day, that on an equinox as well the first announcement of a KDevelop snapshot, the 0.1 Alpha, was made:

List: kde-announce
Subject: ANNOUNCE: kdevelop-0.1.tar.gz
From: konold () alpha ! tat ! physik ! uni-tuebingen ! de
Date: 1998-09-22 15:50:19

Dear KDE Enthusiast,

the KDE Team is pleased to announce the availability of:

kdevelop-0.1.tar.gz

It can be found at
ftp://ftp.kde.org/pub/kde/unstable/apps/ide/kdevelop-0.1.tar.gz

and at our U.S mirror site
ftp://ftp.us.kde.org/pub/kde/unstable/apps/ide/kdevelop-0.1.tar.gz.

it will probably appear firstly at
ftp://ftp.de.kde.org/pub/kde/unstable/apps/ide/kdevelop-0.1.tar.gz.

Here follows the LSM:

Begin3
Title: KDevelop
Version: 0.1 Alpha
Entered-date: 22 Sep 1998
Description: an IDE for X/Qt/KDE
Keywords: IDE, KDE, X11, Qt, development
Author: Sandy Meier, Stefan Heidrich, Stefan Bartel
Maintained-by: Sandy Meier
Primary-site: http​://www.cs.uni-potsdam.de/~smeier/kdevelop/kdevelop-0.1.tar.gz
Home-page: http​://www.cs.uni-potsdam.de/~smeier/kdevelop/index.html
Original-site: http​://www.cs.uni-potsdam.de/~smeier/kdevelop/kdevelop-0.1.tar.gz
Platform: Linux, needs Qt 1.4 and the kde libs
Copying-policy: GNU Public License
End

20 years of getting feature by feature, sometimes first of its kind, being partially rewritten, getting ported from Qt1 to Qt2 to Qt3 to Qt4 to now Qt5, being made run on non-Linux platforms, seeing hand-overs of maintainers.
At its 20th anniversary KDevelop, now to be called an extensible cross-platform IDE for C, C++, Python, PHP and other languages, continues to provide developers a very reliable and powerful environment to get their code work done. While being inviting to enhance their tool, KDevelop, itself, being a FLOSS software and with no company agenda attached.

I have been a happy user of KDevelop all the years, and currently am giving back to it by doing some development and feature additions.
Be a happy user as well, and then one giving back.
Looking forward to more 20 years, and then some.

KDevelop, ensuring development equity, by day and night. ��

As part of the research project on “The Interaction between Open Source Software and FRAND licensing in Standardisation”, a workshop was organised by the European Commission, Joint Research Centre (JRC) in collaboration with Directorate General Communications Networks, Content and Technology (CONNECT) to present and discuss the intermediate results to date. The workshop took place in Brussels on September 18, 2018. I presented a set of observations from the research on the case studies performed as part of the project that are outlined below. Other speakers where Catharina Maracke on the issue of legal compliance between Open Source and FRAND licenses, Bruce Perens on “Community Dynamics in Open Source”, and Andy Updegrove on “Dynamics in Standardisation”.

September 20, 2018

Maybe it’s all the QA we added but issues kept cropping up with Bionic.  All those people who had encrypted home folders in xenial soon found they had no files in bionic because support had been dropped so we had to add a quirk to keep access to the files.  Even yesterday a badly applied patch to the installer broke installs on already partitioned disks which it turns out we didn’t do QA for so we had to rejig our tests as well as fix the problem. Things are turning pleasingly green now so we should be ready to launch our Bionic update early next week. Do give the ISO images one last test and help us out by upgrading any existing installs and reporting back.  Hasta pronto.

 

Qt 5.11.2 is released today. As a patch release it does not add any new functionality, but provides important bug fixes, security updates and other improvements.

Compared to Qt 5.11.1, the Qt 5.11.2 release provides fixes for more than 250 bugs and it contains around 800 changes in total. For details of the most important changes, please check the Change files of Qt 5.11.2.

The recommended way for getting Qt 5.11.2 is using the maintenance tool of the online installer. For new installations, please download latest online installer from Qt Account portal (commercial license holders) or from qt.io Download page (open source).

Offline packages are also available for those who do not want to use the online installer.

The post Qt 5.11.2 Released appeared first on Qt Blog.

We’re about a week into the campaign, and almost 9000 euros along the path to bug fixing. So we decided to do some preliminary vote tallying! And share the results with you all, of course!

On top is Papercuts, with 84 votes. Is that because it’s the default choice? Or because you are telling us that Krita is fine, it just needs to be that little bit smoother that makes all the difference? If the latter, we won’t disagree, and yesterday Boudewijn fixed one of the things that must have annoyed everyone who wanted to create a custom image: now the channel depths are finally shown in a logical order!

Next, and that’s a  bit of a surprise, is Animation with 41 votes. When we first added animation to Krita, we were surprised  by the enthusiasm with which it was welcomed. We’ve actually seen, with our own eyes, at a Krita Sprint, work done in Krita for a very promising animated television series!

Coming third, there’s the Brush Engine bugs, with 39 votes. Until we decided that it was time to spend time on stability and polish, we thought that in 2018, we’d work on adding some cool new stuff for brushes. Well, with Digital Atelier, it’s clear that there is a lot more possible with brushes in Krita than we thought — but as you’re telling us, there’s also a lot that should be fixed. The brush engine code dates back to a rewrite in 2006, 2007, with a huge leap made when Lukáš Tvrdý wrote his thesis on Krita’s brush engines. Maybe we’ll have to do some deep work, maybe it really is all just surface bugs. We will find out!

Fourth, bugs with Layer handling. 23 votes. For instance, flickering when layers get updated. Well, Dmitry fixed one bug there on Wednesday already!

Vector Objects and Tools: with 20 votes, Text with 15 votes and Layer Styles, with 13 votes (4 less than there are bug reports for Layer Styles…): enough to show people are very much interested in these topics, but it looks like the priority is not that high.

The remaining topics, Color Management, Shortcuts and Canvas Input, Resource Management and Tagging, all get 8 votes. We did fix a shortcuts bug, though… Well, that fix fixed three of them! And resource management is being rewritten in any case — maybe that’s why people don’t need to vote for it!

September 19, 2018

DSC00064.JPG

I had the awesome opportunity to attend Akademy in Vienna this year. First off, a big thank you to the organising  team for pulling off this years Akademy without a hitch.

This Akademy was a bit more special, since it was decided to switch up the format, which in my opinion worked quite well. There were training’s that ran alongside the talk’s and BoF’s, which I think was a great idea. I signed up to the Public Speaking Training and the Non Violent Communication training, which I think were run exceptionally. I hope that these training sessions are run again next Akademy because I found them exceptionally valuable.

I also used this opportunity to sit down with TL Lim from Pine64 to discuss the needs of the Pine64 community and how KDE and Pine64 could work together to provide a great experience on Pine64 products such as Pinebook. This eventually led to the release of the KDE Neon image for the Pinebook in the past week, which everyone seems to be quite happy about ��

Overall, I’d say this was a very productive Akademy for me personally, and I thoroughly enjoyed it.

Since this blog is starting after the beginning of my contributions to KDE, the first few regular posts will be explaining my prior contributions, before moving into the present.

Continuity, right?

I’d also like to outline how I got involved in development, as an entry-level/non-programmer. I hope this will be helpful for those interested in helping, but unsure how to go about doing something useful.

Konqui_dev_close_cropped.pngI was introduced to the idea of developing for KDE by Nate Graham and his Usability & Productivity goal. I was immediately drawn to the idea of polishing the applications, like I stated in my first post. But how do I get started? I mean, besides the technical stuff. How do I find something easy to work on? I’m not a programmer by trade, so while we do have the Junior Jobs, a lot of those seemed out of my reach. So what to do?

One of the Usability & Productivity posts from Nate mentioned icons being added to the menus in an app. I looked at the linked code that was changed, and noticed how simple it was! I can do that! So I searched through the Junior Jobs, and Phabricator (KDE’s development and code review platform) for applications that needed some icons added to their menu. I found some tasks, and set to work:

Check out the screenshots in those links! Here is an example:

It really makes the app look nicer, right? If you scroll down in those pages and look at the code changes, you will see they are basically simple one-liners that are copy/pasted from elsewhere, with a different icon name. Easy!

You could help do easy tasks like this too!

Visit KDE’s Get Involved page for more information, or contact me!

Recently a KDE neon image for the Pinebook was announced. There is a new image, with a handful of fixes, which the KDE Plasma team has been working on over the past week and a half.

Photo of Pinebook

Pinebook running KDE neon

Here’s a picture of my Pinebook running KDE neon — watching Panic! At the Disco’s High Hopes — sitting in front of my monitor that’s hooked up to one of my openSUSE systems. There are still some errata, and watching video sucks up battery, but for hacking on documentation from my hammock in the garden, or doing IRC meetings it’s a really nice machine.

But one of the neat things about running KDE neon off of an SD card on the Pinebook is that it’s portable — that SD card can move around. So let’s talk about multiboot in the sense of “booting the same OS storage medium in different hardware units” rather than “booting different OS from a medium in a single hardware unit”. On these little ARM boards, u-boot does all the heavy lifting early in the boot process. So to re-use the KDE neon Pinebook image on another ARM board, the u-boot blocks need to be replaced.

I have the u-boot from a Pine64 image (I forget what) lying around, 1015 blocks of 1024 bytes, which I can dd over the u-boot blocks on the SD card, dd bs=1k conv=notrunc,sync if=uboot.img of=/dev/da0 seek=8, and then the same SD card, with the filesystem and data from the Pinebook, will boot on the Pine64 board. Of course, to move the SD card back again, I need to restore the Pinebook u-boot blocks.

Photo of a dusty circuit board

KDE neon Pinebook edition running on a Pine64, with console output

Here’s a picture of my Pineboard (the base is a piece of the garden fence, it’s Douglas pine, with 4mm threaded rods acting as the corner posts for my Pine64 mini-rack), with power and network and a serial console attached, along with the serial console output of the same.

The nice thing here is that the same software stack runs on the Pine64 but then has a wired network — which in turn means that if I switch on the other boards in that mini-rack, I’ve got a distcc-capable cluster for fast development, and vast NFS storage (served from ZFS on my FreeBSD machines) for source. I can develop in a high(er) powered environment, and then swap the card around into the Pinebook for testing-on-the-go.

So to sum up: you can multiboot the KDE neon Pinebook image on other Pine64 hardware (i.e. the Pine64 board). To do so, you need to swap around u-boot blocks. The blocks can be picked out of an image built for each board, and then a particular image (e.g. the latest KDE neon Pinebook) can be run on either board.

September 18, 2018

Today, on September 18th, 2018, the Russian-speaking KDE community launches its updated website on KDE.ru.

The new website serves as the main page for the Russian-speaking community. It provides localized information about the community, product download links and the list of social network pages we maintain. It is also meant to help new members get involved in KDE’s projects, particularly in our translation and promotion efforts.

The website was created by me and Alexander Potashev on top of Jonah Brüchert‘s work for plasma-mobile.org. It uses Jekyll and is now hosted on official KDE servers. It replaces the old forum that has significantly lost its users in the past years.

If you like our work, please share the website with your friends and subscribers! �� If you find mistakes, report them in VK group messages, contact me or open a Phabricator revision with a fix.

We would like to thank Ben Cooksley for his help with website deployment, all the users who participated in beta testing, and everyone who helped polish the content.

Krita’s 2018 fund raiser is all about fixing bugs! And we’re fixing bugs already. So, let’s take a non-technical look at a bug Dmitry fixed yesterday. This is the bug: “key sequence ctrl+w ambiguous with photoshop compatible bindings set” And this is the fix.

So, we actually both started looking at the bug at the same time, me being Boudewijn. The issue is, if you use a custom keyboard shortcut scheme that includes a shortcut definition for “close current image”, then a popup would show, saying that the shortcut is ambiguous:

The popup doesn’t tell where the ambiguous definition is… Only that there is an ambiguous definition. Hm… Almost everything that does something in Krita that is triggered by a shortcut is an action. And deep down, Qt keeps track of all actions, and all shortcuts, but we cannot access that list.

So we went through Krita’s source code. The action for closing an image was really created only once, inside Krita’s code. And, another bug, Krita doesn’t by default assign a shortcut to this action. The default shortcut should be CTRL+W on Linux and Windows, and COMMAND+W on macOS.

Curiously enough, the photoshop-compatible shortcut definitions did assign that shortcut. So, if you’d select that scheme, a shortcut would be set.

Even curiouser, if you don’t select one of those profiles, so Krita doesn’t set a shortcut, the default ctrl+w/command+w shortcut would still work.

Now, that can mean only one thing: Krita’s close-image action is a dummy. It never gets used. Somewhere else, another close-image action is created, but that doesn’t happen inside Krita.

So, Dmitry started digging into Qt’s source code. Parts of Qt are rather old, and the module that makes it possible to show multiple subwindows inside a big window is part of that old code.

/*!
    \internal
*/
void QMdiSubWindowPrivate::createSystemMenu()
{
...
    addToSystemMenu(CloseAction, QMdiSubWindow::tr("&Close"), SLOT(close()));
...
    actions[CloseAction]->setShortcuts(QKeySequence::Close);
....
}
#endif

Ah! That’s where another action is created, and a shortcut allocated. Completely outside our control. This bug, which was reported only two days ago, must have been in Krita since version 2.9! So, what we do now is to make sure that the Krita’s own close-image action’s shortcut gets triggered. We do that by making sure Qt’s action only can get triggered if the subwindow’s menu is open.

    /**
     * Qt has a weirdness, it has hardcoded shortcuts added to an action
     * in the window menu. We need to reset the shortcuts for that menu
     * to nothing, otherwise the shortcuts cannot be made configurable.
     *
     * See: https://bugs.kde.org/show_bug.cgi?id=352205
     *      https://bugs.kde.org/show_bug.cgi?id=375524
     *      https://bugs.kde.org/show_bug.cgi?id=398729
     */
    QMdiSubWindow *subWindow = d->mdiArea->currentSubWindow();
    if (subWindow) {
        QMenu *menu = subWindow->systemMenu();
        if (menu) {
            Q_FOREACH (QAction *action, menu->actions()) {
                action->setShortcut(QKeySequence());
            }
        }
    }

That means, for every subwindow we’ve got, we grab the menu. For every entry in the menu, we remove the shortcut. That means that our global Krita close-window shortcut always fires, and that people can select a different shortcut, if they want to.

Just because KDE4-era software has been deprecated by the KDE-FreeBSD team in the official ports-repository, doesn’t mean we don’t care for it while we still need to. KDE4 was released on January 11th, 2008 — I still have the T-shirt — which was a very different C++ world than what we now live in. Much of the code pre-dates the availability of C++11 — certainly the availability of compilers with C++11 support. The language has changed a great deal in those ten years since the original release.

The platforms we run KDE code on have, too — FreeBSD 12 is a long way from the FreeBSD 6 or 7 that were current at release (although at the time, I was more into OpenSolaris). In particular, since then the FreeBSD world has switched over to Clang, and FreeBSD current is experimenting with Clang 7. So we’re seeing KDE4-era code being built, and running, on FreeBSD 12 with Clang 7. That’s a platform with a very different idea of what constitutes correct code, than what the code was originally written for. (Not quite as big a difference as Helio’s KDE1 efforts, though)

So, while we’re counting down to removing KDE4 from the FreeBSD ports tree, we’re also going through and fixing it to work with Clang 7, which defaults to a newer C++ standard and which is quite picky about some things. Some time in the distant past, when pointers were integers and NULL was zero, there was some confusion about booleans. So there’s lots of code that does list.contains(element) > 0 .. this must have been a trick before booleans were a supported type in all our compilers. In any case it breaks with Clang 7, since contains() returns a QBool which converts to a nullptr (when false) which isn’t comparable to the integer 0. Suffice to say I’ve spent more time reading KDE4-era code this month, than in the past two years.

However, work is proceeding apace, so if you really really want to, you can still get your old-school kicks on a new platform. Because we care about packaging things right, even when we want to get rid of it.

September 17, 2018

An art school in Paris, France, is looking for a Krita teacher! This is pretty cool, isn’t it? If you’re interested, please mail foundation@krita.org and we’ll forward your mail to the school!


A freelance Krita teacher to teach basics to art school students, Paris 11e. November 2018.

The course has to be mainly in french (could be half in english).
That’s full-days session with differents students group (28 students x 5 classes).

  • The teacher has to have an “statut autoentrepreneur” (french freelance).
  • Price is around 50 euros per hour (6 hours days)
  •  The courses will be on : 5th, 8th, 9th,12th, 13th, 14th, 15th, 16th november 2018
  • It’s mainly about general tools of the software, and how to draw and paint with Krita
    using tablets
  • There are possibilities to work more than this first schedule, later in 2019

Profile: Game artist, Concept artist, digital painter, illustrator… please send your website if interested!


Cherche formateur auto-entrepreneur pour cours de Krita à des étudiants en Ecole d’Art, Paris 11. Novembre 2018.

Le cours doit être majoritairement donné en français, mais anglais partiel possible.
Jours pleins à l’école avec différents groupes d’étudiants (28 étudiants x 5 classes).

  • le formateur doit avoir un statut auto-entrepreneur
  • rémunération autour de 50 euros l’heure (journées de 6 heures)
  • les cours seront les : 5, 8, 9, 12, 13, 14, 15, 16 novembre 2018
  • il s’agit d’apprendre les outils de bases du logiciel, et surtout les outils de dessin et peinture avec tablette
  • Il y a des possibilités futures pour d’autres dates dans l’année 2019

Profil: Game artist, Concept artist, digital painter, illustrateur… merci d’envoyer votre site si intéressé !

KGraphViewer, your favourite visualiser of .dot files, has a new update.

  • Switch KgvPageLayout to QPageSize for page size handling
  • Avoid double top-level layout in KGVSimplePrintingPageSetup
  • Fix layout of page layout & size dialog
  • Remove unused dependency KIO
  • Fix minor typo
  • Update kgraphviewer docbook
  • Make sure the Graphviz library directories are known to the linker

Thanks to Pino, Michael, Yuri, Berkhard, Ben and translators for their continued gardening of this project.

Git tag v2.4.3a 4ff52f959f03291659db58554901d536356764e2

Tar https://download.kde.org/stable/kgraphviewer/2.4.3/kgraphviewer-2.4.3.tar.xz

GPG Signature https://download.kde.org/stable/kgraphviewer/2.4.3/kgraphviewer-2.4.3.tar.xz.sig

Signed by Jonathan Riddell GPG key fingerprint ‘2D1D 5B05 8835 7787 DE9E  E225 EC94 D18F 7F05 997E’

Facebooktwittergoogle_pluslinkedinby feather

Could you tell us something about yourself?

I’m a graduate of the Kansas City Art Institute, but I’ve since moved back to Northwest Arkansas. When I’m not painting or playing video games, I’m enjoying the great outdoors with my wonderful husband, adorable daughter, and our 8-year-old puppy.

Do you paint professionally, as a hobby artist, or both?

I do both! I do freelance work for clients, but I still paint for fun (and for prints).

What genre(s) do you work in?

Primarily fantasy because I love how much room for imagination there is. Nothing is off-limits! While that genre is my favorite, I also do portraiture (mostly pets) and have been dabbling a bit in children’s illustration recently.

Whose work inspires you most — who are your role models as an artist?

Dan dos Santos is my absolute favorite artist. His rendering is gorgeous. His color is masterful. There’s a lot that can be learned just by looking at the paintings he produces, but luckily for me and anyone else who looks up to his work, he even shares some of his techniques and professional experience with the world. He works mostly in traditional media, but the concepts that he discusses are pretty universal. As far as digital artists go, I’m very fond of the work of people like Marta Dahlig and Daarken.

How and when did you get to try digital painting for the first time?

I think college was the first time that I sat down with a tablet and computer and gave the digital painting thing a go. Before that, though, I had dabbled in some other digital image-making techniques, I was more interested in the traditional stuff like oil paints and charcoal.

What makes you choose digital over traditional painting?

Once I got over that initial transitional hump from traditional to digital I was hooked. There’s no cleanup. You can’t run out of blue paint at just the wrong moment. The undo function is absolute magic. More than anything, though, it’s the control that keeps me working in a digital space. Between layers, history states, and myriad manipulation options, I can experiment without worrying about destroying anything. It’s very freeing and really strips the blank canvas of any of its intimidating qualities.

How did you find out about Krita?

Reddit. It came up in a number of threads about digital painting software. People had a lot of positive things to say about it, so when I felt like it was time to start looking at some Photoshop alternatives to paint in, it was the first one that I tried.

What was your first impression?

I was pleasantly surprised when I launched Krita the first time. The UI was polished and supported high DPI displays. All of the functionality that I was looking to replace from Photoshop CS5 was there—and it had been tuned for painting specifically. I was even able to open up the PSDs I had been working on and transition over to Krita without losing a beat. All of my layers and blending modes were intact and ready rock. Hard to ask for a smoother switch than that!

What do you love about Krita?

Aside from the pricing and the whole thing being built from the ground up with painting in mind, I think my favorite feature is actually just the ability to configure what shows up in the toolbars as much as you can in Krita. I work on a Surface Pro 4, and being able to have all of the functions I need in the interface itself so that I don’t have to have a keyboard in between me and the painting to keep repetitive functions speedy is so great.

What do you think needs improvement in Krita? Is there anything that really annoys you?

Really, the brush system improvements in the last big update fixed up basically anything I could have hoped for! The only lingering thing for me probably comes down to a personal preference, but when I choose to save out a flat version of my document while working on a KRA, I’d rather the open document default to saving on the KRA on subsequent saves instead of that new JPEG/TIFF/whatever other format I selected for the un-layered copy.

What sets Krita apart from the other tools that you use?

I think the open source nature of it is a big component, but on a daily use basis, the biggest functional difference between Krita and other tools I use (like Photoshop and Illustrator) is that painting is the intended usage. The interface and toolsets are geared entirely toward painting and drawing by default, so doing that feels more natural most of the time.

If you had to pick one favourite of all your work done in Krita so far, what would it be, and why?

I think my favorite Krita painting so far is my most recent—Demon in the Dark. Out of my work produced start to finish in the program, that one had the most detail to play with and I had a lot more fun balancing the composition. Cloth, smoky details, and the female figure are some of the things I enjoy painting most, and that one included all of them!

What techniques and brushes did you use in it?

There weren’t any particularly fancy techniques or brushes used. I like to keep it simple and sketch out my composition, broadly block in color, then progressively refine, layering in and collapsing down chunks of painting until things are reasonably polished and cohesive. To pull it off, I used my staple brushes (hard round and standard blender) for the brunt of the painting, then some more specific texture build-up brushes for hair, clouds, particles, and the like. A time lapse of the whole process is up on my YouTube channel (https://youtu.be/phPrPgK5DYQ).

Where can people see more of your work?

People can check out my work on my website, www.artofalyssamay.com, or my Instagram, @artofalyssamay. They can also find time lapses of my paintings on my YouTube channel, www.youtube.com/c/AlyssaMay!

Anything else you’d like to share?

Just my thanks to the Krita team for making and sharing such a solid program!

There’s some discussion on D15383 about the use of editorconfig in our sources, I belive that we should have this little file in *all* of our projects (actually I would put this in *every single project that exists*. This is a small file that handles common code conventions per project, for instance the tab vs spaces thing.

Before adopting it in my company my life was not good: I had to manually change tabs vs spaces in the configuration of kate multiple times a day. Working with python? spaces. working with c++? tabs. And a few projects here have those two files at the same parent-project, after adopting it life is collorfull again.

The linked branch has a working editorconfig, I beg you fellow developer, this will help windows developers, mac developers, vim / emacs developers and visual developers as editorconfig has plugins or is directly integrated in many developer tools.

 

September 16, 2018

KDE Akademy 2018

Yeah I am not in the picture, but I was there! You can find me over on the left there, where several of us were cut off �� Akademy was held in the lovely city of Vienna, Austria this year. Hats off to the akademy team for a great job!

This year at akademy I spent much of my time catching up with the Blue Systems team and meeting with the KDE Sysadmin team. I am happy to report Ben Cooksley is real! Due to my flights, I missed the first and last day. It was still a productive akademy. I attended some good sysadmin and KDE Neon BoFs . I also did a bit of volunteering ��

Even though I am mostly packaging for Debian directly these days, KDE Neon is still near and dear to my heart. I hope to be able to merge debian packaging into Neon soon so that we can have better collaboration within the team.

I met with Ben in regards to getting back into sysadmin/CI work. I am working on Appimage tooling for KDE Binary factory to begin. I hope to utilize the craft tooling to make everyone’s lives easier. This of course is on my free time, but do keep an eye out!

https://binary-factory.kde.org/

Despite my shortened akademy, I still am happy with the results. It was great to see everyone! See you again next year!


Latte Dock v0.8.1   has been released containing important fixes and improvements!


Go get   v0.8.1  from, download.kde.orgor  store.kde.org*

-----
* archive has been signed with gpg key: 325E 97C3 2E60 1F5D 4EAD CF3A 5599 9050 A2D9 110E



Fixes/Improvements (v0.8.1)




Two Latte panels in Unity mode using properly the
Unity Ambiance plasma theme


  • Most important fix is the new implementation for multi-screen environments. Frustrated as I was from the previous one I decided to make it more robust. With new architecture onPrimary docks/panels have always higher priority that the explicit ones. That change creates a more consistent behavior with Plasma. 

    At the same time a highly sophiticated code that was messing things has been totally removed. Latte was trying to be too smart and never let you without a taskmanager in a multi-screen environment. That was creating more issues than it was solving. In the future when such case for the user occurs a dialog can appear to ask the user what it would prefer to do.
  • Fixes for plasma theme support:
    -
    draw properly plasma theme panel backgrounds based on the edge that the dock or panel is present, e.g. Unity Ambiance, Nilium
    -
    do not double paint plama theme background when the theme does not contain a shadow
  • Fix previews for grouped windows (follow plasma design for window previews)
  • do not move explicit dock on primary screen
  • consider "not show background" case as full transparency
  • consider preferredSize(s) only for >0 values (case of locked analog clock disappearing at a vertical panel)
  • if there is not any active window at all, dodge set docks should reappear
  • do not crash in wayland when right clicking with touchpad
  • identify maximized window screen differently
  • place correctly a new copied dock in a multi-screen environment
  • enable blur for solid theme panels
  • fix for missing global shortcuts '9' badge
  • support unified or not global shortcuts in case the user does not want to use the Latte unified system for its applets. In master version this can be set separately for every dock/panel from its Dock Settings but for v0.8 you should follow:
    https://github.com/psifidotos/Latte-Dock/wiki/Tips-&-Tricks#q-can-i-disable-unified-global-shortcuts-feature-introduced-with-v08

Greetings, KDE-loving humans! This week’s Usability & Productivity is a heavy one in terms of importance. We scored awesome fixes and improvements through the KDE software stack for subjects as varied as Libinput mouse and touchpad device handling, Task Manager icon sorting for LibreOffice, and a snazzy new unified mailbox in KMail. Have a look:

New Features

  • KMail can now display a unified inbox (Daniel Vrátil, KDE Applications 18.12.0):

Bugfixes

UI Polish & Improvement

Next week, your name could be in this list! Just check out https://community.kde.org/Get_Involved, and find out how you can help be a part of something that really matters.

If my efforts to perform, guide, and document this work seem useful and you’d like to see more of them, then consider becoming a patron on Patreon, LiberaPay, or PayPal. Also consider making a donation to the KDE e.V. foundation.

Let’s write a mail viewer with Rust and Qt. This is another blog about Rust Qt Binding Generator, the project that lets you add a Qt GUI to your Rust code, or if you will, add Rust to your Qt program.

Rust Qt Binding Generator (Logo by Alessandro Longo)Rust Qt Binding Generator (Logo by Alessandro Longo)

Previous blogs about Rust Qt Binding Generator covered the initial announcement, building a simple clock, and making a todo list. Now, I’ll show a bit of how to make a more complex application: an email reader.

But first: Rust Qt Binding Generator takes an unusual approach to bindings. It is not a complete binding from the Qt API to Rust because I think that that is impossible: the C++ Qt API does not have all the safety guarantees that Rust has. So the binding API would be full of unsafe negating a big advantage of using Rust.

Instead, Rust Qt Binding Generator generates a binding for just your code to make your Rust code available to a Qt GUI.

In the first tutorial, we showed a clock. The model shared between Rust and Qt had three simple properties: hour, minute and second. The second blog was about a todo application. There, the model was a list of todo items shared between Rust and Qt.

Getting the code

This time, we move on to a more complex object: a tree.

A mail viewer written with Rust and Qt A mail viewer written with Rust and Qt

We’re keeping with the theme of personal information management and are writing an email viewer. It can read mail from MailDir folders and IMAP servers. It is completely readonly and will not even change the state of your messages from unread to read. I feel comfortable using it on my own mails alongside my real mail programs.

The code is available in my personal KDE space. It requires Rust, Cargo, Qt, CMake, OpenSSL, and ninja (or make). You can retrieve and compile it with

The code is about 2200 lines of Rust and 550 lines of QML. Parsing mails and communicating over IMAP is done by three crates: mailparse, imap-proto and imap.

The shared data model

In an email application there are usually two prominent trees: one shows the email folders and the other shows the messages in the selected folder.

First we model the list of folders. Here is the JSON object from bindings.json that does this.

The type of MailFolders is Tree. Each node in the tree has two properties: name and delimiter. Rust Qt Binding Generator generates Qt and Rust code from this. The Qt code (Bindings.cpp and Bindings.h) defines an implementation of QAbstractItemModel. This is the same base class as in the todo example. This time, it holds a tree instead of a list.

There is also Rust code generated. The file interface.rs is the binding to the Qt code. It defines a trait MailFoldersTrait that the developer needs to implement in a struct called MailFolders.

We’ll discuss some parts of the Rust implementation file.

The implementation should be backed by a structure. There are two structures: MailFolder which represents a node in the tree and MailFolders which contains all the nodes in a Vec and interfaces for communicating with other parts of the program.

In the tree, each node has a unique index. The index is used by Qt to find out information about the node, like how many children (rows) it has or to get out data like the name.

These functions correspond to the C++ virtual functions in QAbstractItemModel.

Doing the work in a thread

The user interface should stay responsive. So intense and slow work like reading and parsing email is done in a separate thread. The user interface starts a thread to do the hard work and sends commands to it via a channel.

When new data is available, the UI needs to update. This must be done by the UI thread. When the processing thread has new data it emits a signal to the UI thread. The UI thread then aquires accesses the data via a mutex that is shared between the two threads.

Communication between GUI and processing threadsCommunication between GUI and processing threads

QML for the folders

The Rust-implemented model is used from the QML. The connection between the TreeView and the model is made by the line model: mailmodel.folders. Each node is rendered according to the Text delegate. When the user selects a different folder the model is notified of this by handling the onCurrentIndexChanged event.

TreeView {
    id: folders
    model: mailmodel.folders
    TableViewColumn {
        title: "Name"
        role: "name"
        width: folders.width - 20
        delegate: Text {
            text: icon(styleData.value) + " " + styleData.value
            verticalAlignment: Text.AlignVCenter
        }
    }
    onCurrentIndexChanged: {
        //...
        mailmodel.currentFolder = path;
    }
    style: TreeViewStyle {
        highlightedTextColor: palette.highlightedText
        backgroundColor: palette.base
        alternateBackgroundColor: palette.alternateBase
    }
    headerVisible: false
    frameVisible: false
}

Other parts

The list of folders is one of five object defined in the model. The others are the tree for the message threads in a folder (middle pane in the screenshot above), the current email (right pane), the list of attachments for the current email and an overall object that contains all the other ones. The latter, MailModel, is the initial entry point for the user interface. The user-initiated commands are sent to the processing thread from that overall object.

Trying it out

Create a configuration file for MailDir or IMAP.

The path for the MailDir configuration is the folder that contains .inbox.directory.

and run the code

Concluding

This GUI is built with QML via Qt Quick Controls. One might as well write one with Qt Quick Controls 2, QWidgets or Kirigami. The majority of the code, the Rust code, could stay the same. With the appropriate abstractions one might even use a different GUI framework and still keep the core application logic. Just imagine: KDE and GNOME joined together by Rust.

September 15, 2018

It’s time for a new Krita fundraiser! Our goal this year is to make it possible for the team to focus on one thing only: stability. Our previous fundraisers were all about features: adding new features, extending existing features. Thanks to your help, Krita has grown at breakneck speed!

Squash the bugs!

This year, we want to take a step back, look at we’ve achieved, and take stock of what got broken, what didn’t quite make the grade and what got forgotten. In short, we want to fix bugs, make Krita more stable and bring more polish and shine to all those features you all have made possible!

We’re not using Kickstarter this year. Already in 2016, Kickstarter felt like a tired formula. We’re also not going for a fixed amount of funding this year: every 3500 euros funds one month of work, and we’ll spend that time on fixing bugs, improving features and adding polish.

Polish Krita!

As an experiment, Dmitry has just spent about a month on area of Krita: selections. And now there are only a few issues left with selection handling: the whole area has been enormously improved. And now we want to ask you to make it possible for us to do the same with some other important areas in krita, ranging from papercuts to brush engines, from color management to resource management. We’ve dug through the bugs database, grouped some things together and arrived at a list of ten areas where we feel we can improve Krita a lot.

The list is order of number of reports, but if you support Krita in this fundraiser, you’ll be able to vote for what you think is important! Voting is fun, after all, and we love to hear from you all what you find  the most important things.

Practical Stuff

Practically speaking, we’ve kicked out Kickstarter, which means that from the start, you’ll be able to support our fundraiser with credit cards, paypal, bank transfers — even bitcoin! Everyone who donates from 15 September to 15 October will get a vote.

And everyone who donates 50 euros or more will get a free download of Ramon Miranda’s wonder new brush preset bundle, Digital Atelier. Over fifty of the highest-quality painterly brush presets (oils, pastel, water color) and more than that: 2 hours of tutorial video explaining the creation process in detail.

 

Go to the campaign page!

In the previous post on writing custom data extractors for the KItinerary framework, I mentioned we are augmenting extracted data with knowledge from Wikidata. This post will cover this aspect in more detail.

Static knowledge refers to information that with near certainty don’t change for the duration of your trip, or during a release cycle of our software. That’s things like name, location and timezone of an airport, or the country it belongs to, as opposed to dynamic knowledge like departure gates or platforms, delays, etc.

Use Cases

There’s two main use-cases for static knowledge here:

  • Detecting and translating human-readable identifiers of for example countries or airports into something more suited for machine use. As a human I know ‘Charles de Gaulle’ refers to the main airport of Paris, for the software the IATA airport code ‘CDG’ is much more useful. Similar, we want ISO 3166-1 codes for countries rather than possibly localized human-readable names, and so on.

  • Augmenting or completing partial information. Usually the booking confirmation data we extract doesn’t contain geo coordinates (useful for navigation to/from the airport/station), the timezone (essential for correctly converting arrival/departure times) or the country (needed for our power plug compatibility check), so we need to obtain that from elsewhere.

Data Sources

Currently we are basing this on the following free and open data sources:

Offline Data

One aspect that might be a bit counter-intuitive at first is that we don’t query this information online, but bake it into the program code. This has a number of advantages:

  • Privacy. Your email client would otherwise produce a predictable online access when opening an email containing a travel booking. Even with transport encryption this activity would still be observable on e.g. an open WiFi network, not ideal.
  • Speed. The data is encoded in the shared read-only data section of the KItinerary library, in a way that is directly usable without any parsing or additional memory allocations.
  • Offline support. That’s something quite handy when traveling, as you might be forced into flight mode or are outside of data roaming coverage.

Obviously there are some downsides to this approach as well, but they are comparatively small:

  • Outdated data. You’d need a software update to roll out data changes. This is however why we limit this to “static” data, ie. information that should be stable within one release cycle (3-4 month) with a very high certainty.
  • Size. Obviously this data needs space. It’s however surprisingly little, about 600kB for the localized country name to ISO 3166-1 mapping in KContacts, and about 400kB in KItinerary for the airport and train station databases.

Contribute

There’s an easy way to help in this area too, by improving the Wikidata content. Our code extracting the relevant knowledge from Wikidata is warning about some issues such as missing or conflicting data. These issues are usually easy to research and fix, so that might be a nice entry point into Wikidata editing (it definitely was for me).

Since the data quality is actually very good, the below is the complete list of remaining issues at this point, for the few ten thousand objects we are looking at.

The following airports have two geo coordinates assigned to them that differ by more than 20 kilometers. Few airports are that large, more commonly that’s a simple typo. A quick look on a map is often enough to determine which is the right coordinate.

Similarly, the following airports have no geo coordinate specified:

The list of train stations missing geo coordinates is a bit longer and therefore in a separate file.

A bit more elaborate are the following train stations with IBNR conflicts (an ideally unique station identifier). In the easiest case it’s just two duplicate objects that can be merged, in other cases this might require some understanding on which part of a larger station is actually addressed by the identifier.

And finally there is a more conceptual issue with Gares & connexions IDs for international destinations on SNCF tickets, as described in task T8830.


Older blog entries


Planet KDE is made from the blogs of KDE's contributors. The opinions it contains are those of the contributor. This site is powered by Rawdog and Rawdog RSS. Feed readers can read Planet KDE with RSS, FOAF or OPML.