February 22, 2019

El pasado martes 12 de febrero fue lanzado Plasma 5.15, el cual venía cargado de mejoras centradas en la usabilidad y la productividad. Es hora de ir repasando las novedades en la Preferencias del Sistema de Plasma 5.15, una de las herramientas más potentes para personalizar y configurar nuestro escritorio par ir sacarle el máximo provecho.

Novedades en la Preferencias del Sistema de Plasma 5.15

Aunque ya lo hemos comentado el día del lanzamiento y en el gran vídeo de elav, creo que es necesario detenerse en repasar todas los novedades reportadas por los desarrolladores. Quisiera destacar  que seguramente no serán en realidad todas las que se hayan realizado ya que si lo pensáis esto significa un trabajo extra que en ocasiones no se efectúa.

Así que, en el apartado de novedades en las herramientas de Plasma 5.15 nos encontramos con las siguientes novedades:

  • La página de escritorios virtuales se ha rediseñado y reescrito para permitir el Wayland, y ahora es más usable y tiene una coherencia visual con el resto de las preferencias.
  • Se han mejorado las páginas de configuración de la interfaz de usuario y la disposición del Reloj digital y la Vista de carpeta para adaptarse mejor al estilo común.

Novedades en la Preferencias del Sistema de Plasma 5.15

  • Se han retocado muchas páginas de las Preferencias del Sistema con el fin de estandarizar los iconos, el texto, y la situación de los botones inferiores, principalmente los botones «Obtener [algo] nuevo …».
  • Los efectos de escritorio nuevos instalados desde «store.kde.org» ahora aparecen en la lista de la página de efectos de escritorio del Preferencias del Sistema.
  • La resolución nativa de la pantalla ahora se indica con una estrella en la página de las pantallas.
  • La página de Pantalla de inicio de sesión de las Preferencias del sistema ha incorporado muchas mejoras visuales. +
  • La vista previa de la imagen del tema Brisa predeterminado ahora muestra la apariencia actual, el color de fondo de la vista previa coincide con el esquema activo de colores, y los tamaños y los márgenes se han ajustado para asegurar que todo encaja sin que hayan cortes.
  • La página de efectos de escritorio se ha adaptado al QtQuickControls 2. Esto soluciona varios problemas como una apariencia mala de escalado fraccional, las casillas de verificación mejoradas del menú desplegable, y el tamaño de la ventana que era demasiado pequeña cuando se abría como una aplicación autónoma.

Y hasta aquí las novedades en las Preferencias del Sistema de Plasma 5.15 que hacen que sea un entorno de trabajo vivo y dinámico que sigue mejorando con el objetivo de ser cada día más usable y productivo.

February 21, 2019

The KDE Community has just announced the wider integration of Matrix instant messaging into its communications infrastructure. There are instructions on the KDE Community Wiki as well.

So what’s the state of modern chat with KDE-FreeBSD?

The web client works pretty well in Falkon, the default browser in a KDE Plasma session on FreeBSD. I don’t like leaving browsers open for long periods of time, so I looked at the available desktop clients. Porting Quaternion to FreeBSD was dead simple. No compile warnings, nothing, just an hour of doing some boilerplate-ish things, figuring out which Qt components are needed, and doing a bunch of test builds. So that client is now available from official FreeBSD ports. The GTK-based client Fractal was already ported, so there’s choices available for native-desktop applications over the browser or Electron experience.

Screenshot of two Matrix IM clients

Fractal and Quaternion side-by-side

For about twenty years, irssi in screen, accessed via ssh, was my preferred chat method. (Well, irssi didn’t exist on SunOS in the mid-90s, so I must have used something else originally). Quassel has replaced it on my desktop, and has a nice phone client (QuasselDroid) too if I need to check IRC while on a train. But now there’s Matrix clients as well.

Here in the screenshot, Fractal (on the left, background) looks pretty slick, like a phone-based chat application would. Quaternion reminds me a lot more of .. well, of Quassel. It even has little brutalist buttons to pop up the raw JSON content of messages, I don’t know why. I haven’t gotten around to porting other Qt-based Matrix clients; it’s hard to tell what would be worthwhile to try. For now I’ll go back to plain IRC, because for me the lack of stickers is a feature, not a bug. #GetOffMyLawn

If you followed Kdenlive’s activity these last years, you know that we dedicated all our energy into a major code refactoring. During this period, which is not the most exciting since our first goal was to simply restore all the stable version’s features, we were extremely lucky to see new people joining the core team, and investing a lot of time in the project.

We are now considering to release the updated  version in April, with KDE Applications 19.04. There are still a few rough edges and missing features (with many new ones added as well), but we think it now reached the point where it is possible to start working with it.

Testing day tomorrow

This is why we are organizing a test day event tomorrow, 22nd of February 2019, from 17:00 to 22:00 CET, so you can try it, report the problems you encounter and help us shape the future.

How to join ?

  • Download the latest AppImage
  • Make it executable (in a terminal: chmod +x ) or from your file manager
  • Test it!

More tech-savy users can alternatively compile it with debug flags following this guide and send backtraces

Give us your feedback

During the event, some team members will be reachable on our #kdenlive channel on irc/freenode or via the kdenlive telegram group, and you can also leave your feedback in this Phabricator task.

Known issues

There are a couple of known problems that will be solved before release:

  • Audio thumbnails in timeline eat up lots of memory, and can cause a freeze if large audio files are used, you can disable them as a workaround in larger projects
  • Motion tracker not usable yet

 

El mejor gestor de imágenes de la Comunidad KDE sigue su desarrollo. De esta forma ya está disponible digiKam 6, una nueva versión que incluye jugosas e interesantes novedades como el soporte total a archivos de vídeo. Esto no para.

Disponible digiKam 6, ahora con soporte de vídeo

Disponible digiKam 6, ahora con soporte de vídeoEl pasado 10 de febrero fue lanzado digiKam 6.0.0, la nueva versión de uno de los gestores de imágenes más completo que puedes encontrar en el mundo GNU/Linux.

Este nuevo digiKam ha sido el fruto de meses de trabajo de desarrolladores y de los estudiantes que han participado en el Google Summer of Code, los cuales han invertido horas y horas de código para ofrecernos esta maravilla.
Más información: digiKam

Las novedades de digiKam 6

Como siempre, muchas serán las novedades de una actualización masiva. No obstante los desarrolladores quieren destacar las siguientes:

  • Compatibilidad total con la gestión de archivos de vídeo.
  • Integración de todas las herramientas de servicio web de importación/exportación en LightTable, Editor de imágenes y Showfoto.
  • Motor de decodificación de archivos sin formato compatible con nuevas cámaras.
  • Los datos de similitud ahora se almacenan en un archivo de base de datos separado.
  • Autenticación de servicios web simplificada utilizando el protocolo OAuth.
  • Nuevas herramientas para exportar a Pinterest, OneDrive y Box-services.
  • Capacidad de reorganizar los contenidos de la vista de iconos manualmente.
  • Soporte Exiv2 0.27, la nueva herramienta para el tratamiento de metadatos Exif, IPTC y XMP
  • Nueva herramienta para ajustar la fecha y la hora de mis imágenes.
  • Soporte para DrMinGw para Windows, ya que cada vez digiKam es más popular en el sistema privativo.

Lanzada la segunda beta de digiKam 6

Y, por supuesto, muchos errores solucionados, con lo que parece que tendremos la mejor versión de digiKam que puede tener vuestro ordenador.

¿Qué es digiKam?

La mejor forma de definir digiKam es buscar como se describe esta aplicación de userbase.kde.org y realizar una pequeña síntesis:

“DigiKam es una aplicación que te permite la importación de fotografías desde  cámaras, creación de álbumes, etiquetado con fechas, temas y otras propiedades, utilidades de búsqueda excelentes y modificación de imágenes en masa.”

En otras palabras, con digiKam podrás ver, administrar, editar, mejorar, organizar, etiquetar y compartir fotos de una forma profesional.

 

 

 

 

We are happy to announce the release of Qt Creator 4.9 Beta!

There are many improvements and fixes included in Qt Creator 4.9. I’ll just mention some highlights in this blog post. Please refer to our change log for a more thorough overview.

Generic Programming Language Support

In Qt Creator 4.8 we introduced experimental support for the language server protocol. This enables editing support for a wide range of programming languages through a common protocol. In 4.9 we add support for the document outline, find usages, and also for code actions, which allow the language server to suggest fixes or refactoring actions at a specified place in the code. If the language server of your favorite programming language supports these features, they are now available in Qt Creator as well. Enable the LanguageClient plugin in Help > About Plugins (Qt Creator > About Plugins on macOS) and configure your server in Tools > Options > Language Client to check it out.

Highlighting is still provided by the generic highlighter in these cases. We changed our highlighter to be based on the KSyntaxHighlighting library, which is the library used in KDE for this purpose. Many thanks to the maintainers of KSyntaxHighlighting for making it available to a wide range of uses.

C++ Support

The UI for diagnostics from the Clang analyzer tools got many improvements. They are grouped by file now. Diagnostics from the project’s headers files are now also included.
Fix-its show details on what they do when applied. We also added a guard against applying Fix-its to files that have changed in the meantime. In the Clazy configuration you can enable or disable individual checks.

If you enabled a diagnostic to be shown inline in the code editor, you can disable individual checks via a button in the diagnostic’s tool tip.

QML Support

We updated our QML parser to Qt 5.12, adding support for ECMAScript 7.

Profiling

Perf is a powerful performance profiling tool for software running on a Linux system. Profile your application via perf with Analyze > Performance Analyzer, after enabling the plugin in Help > About Plugins. The integration in Qt Creator is available for applications running on a local Linux system, and also for applications running on a remote Linux system from a Linux or Windows host.

Generic Projects

Similar to our support for deploying files to a remote system for CMake-based projects, you can now add a QtCreatorDeployment.txt file to your generic project, to specify the necessary information about where to deploy which files.

If your project needs some special compiler flags to be correctly handled by the code model, you can now specify these in a .cxxflags or .cflags file.

Other Improvements

For Windows, we added support for MSVC 2019. On macOS we added a Touch Bar if you run Qt Creator on a MacBook.

For remote Linux targets, we exchanged our Botan-based SSH backend by use of OpenSSH tools. You need to install the tools separately (if you have not already) to be able to benefit from a wide range of encryption and authentication features in Qt Creator. We also added a rsync-based deployment method, as well as support for Run in Terminal.

Version control support has also received many fixes and improvements. The Git Branches view has a new Push action and Git tracks detached HEADs.

Get Qt Creator 4.9 Beta

The opensource version is available on the Qt download page under “Pre-releases”, and you find commercially licensed packages on the Qt Account Portal. Qt Creator 4.9 Beta is also available under Preview > Qt Creator 4.9.0-beta1 in the online installer. Please post issues in our bug tracker. You can also find us on IRC on #qt-creator on chat.freenode.net, and on the Qt Creator mailing list.

The post Qt Creator 4.9 Beta released appeared first on Qt Blog.

QMacTouchBar has landed

Recent Apple MacBook Pro models contain an entirely new hardware feature, the touchbar. The touchbar is a touch-sensitive OLED strip sitting above the standard keyboard, where the function keys used to be. macOS uses it for some of the physical buttons that used to be located there, such as volume controls, but it is also possible to use the touchbar yourself, both as a graphical output device, and to trigger various activities.

Not a lot of packaged software makes use of it yet, but of course Apple’s own applications as well as recent versions of Microsoft Office and various Adobe packages use this to the fullest.

Support for Qt Developers

Qt developers were left out up until now, since there was no support in Qt for this. This has now changed, however, since KDAB just contributed QMacTouchBar, a widget in the QtMacExtras module that was written by KDABian Christoph Schleifenbaum, and that is already being used in some of KDAB’s own internal tools.

This is a welcome addition since Apple is not making interfacing with its system components from C++ particularly easy. This requires code written in Objective-C, one of Apple’s favorite programming languages, to interface with the built-in Cocoa libraries, as well as the necessary glue code written in C++ to make the touchbar appear as a perfectly ordinary Qt widget to Qt applications.

Currently supported are QTabBar, QMessageBox, QDialogButtonBox (Apple is using the touchbar a lot to show the buttons that close a dialog, such as “OK” and “Cancel”), and QWidgetAction, and it is possible to mark a QAction as the principal action as well as the escape action. Action icons are already supported, and further additions are planned.

Until QMacTouchBar has been merged upstream, you can find it here.

The post QMacTouchBar has landed appeared first on KDAB.

February 20, 2019

From February 4th until February 9th I attended a Plasma Mobile sprint in Berlin, Germany. I met a lot of people that share the vision of an open, privacy-friendly mobile platform. However, we all agree that such a platform can only succeed if there are enough people sharing that vision creating suitable apps for it. There already is a nice amount of mobile-friendly Linux apps, many of them created by the KDE Community, but of course we need more ��

One app that is essential for my use case is an app that allows me to check departures and routes for public transport. Since I’m not aware of any existing one I decided to do my own and share my road here. The purpose of this is to be educating for both me and you and to inspire you to create your own mobile-friendly Linux apps.

Like the other KDE mobile apps I’m going to use QML/QtQuick and Kirigami. QML is the declarative UI language from the Qt project. Unlike the older QWidgets it is designed with (embedded) touch systems in mind and thus is ideal for mobile apps. Kirigami is a set of QtQuick components designed for creating convergent mobile/desktop apps.

Unlike other KDE projects I’m not going to use C++ for the business logic. Instead I’m going to use Python, which is now officially supported by Qt. Since my Python skills are fairly basic this will be a fun challenge for me. Therefore take everything I write with a grain of salt and feel free to point out anything that is wrong or can be improved.

This won’t be a 100% complete reference for developing for Plasma Mobile, but I’ll try to cover as many different aspects as fit into the concept of this app. I’ll also try to focus on one aspect/feature/goal per post. Also most of this will not be specific to Plasma Mobile but will work on any desktop or mobile Linux.

So lets get started ��

Part 0: Basic application

Before getting started we need to install a few things. First of all we need Python (obviously) and Qt for Python. Qt for Python was formerly known as PySide2. You can install it via ‘pip install pyside2’. Next there is Kirigami. On Ubuntu you can install it via ‘sudo apt install qml-module-org-kde-kirigami2’.

After that we can start coding. The following main.py file is creating an app and loading the UI from a .qml file. The exact details are not too important at this point.

#!/usr/bin/env python3

from PySide2.QtGui import QGuiApplication
from PySide2.QtQml import QQmlApplicationEngine

if __name__ == "__main__":
    app = QGuiApplication()
    engine = QQmlApplicationEngine()

    context = engine.rootContext()
    engine.load("qml/main.qml")

    if len(engine.rootObjects()) == 0:
        quit()
    app.exec_()

Next we need to define our UI in a QML file. To keep things organized we are going to put our QML files in a qml/ subfolder. Our first main.qml is rather simple

import QtQuick 2.2
import QtQuick.Controls 2.4
import org.kde.kirigami 2.0 as Kirigami

Kirigami.ApplicationWindow
{
    width: 480
    height: 720

    Label {
        text: "Hello world!"
        anchors.centerIn: parent
    }
}

width and height are a bit arbitrary since the window will always be maximized on the phone, but this way we get a somewhat realistic window on the desktop. Executing the python file should result in something like this

In the next post we are going to fill this window with more life using QtQuick and Kirigami components. Stay tuned ��

The source code will be available at https://invent.kde.org/nicolasfella/kstraba

I've finally decided to delete my Facebook account. I've been pondering this decision for several years now; my previous choice on the matter was to just use it as little as possible, in write-only mode, just to spread political propaganda and generally make it a horrible place for everybody else too. My reasoning was the following: if I had a huge following, then I'd definitely leave and make a big noise (and impact); but since I'm mostly connected with real acquaintances only, my only way to make a (albeit minimal) impact is to stay there and “save” my friends by convincing them of my opinions and/or by being so annoying that they'd decide to leave first.

There's life out there, too

However, the more time passes, the more I start doubting this position. What I really want is for people to leave Facebook; but as long as I'm there, as everybody else is there, no matter how grumpy or destructive we might be, we are still part of Facebook's business and not challenging the status quo in any meaningful way. We are not going to convince anyone to migrate to alternative platforms (or just leave all social media for good) while we continue to maintain a presence in there. Also, I know too well that it's nearly impossible to change someone's mind via social media, and my plan to make the place horrible for everybody is not going to work either: if people get annoyed, they'll just mute me and that's it.

On the other hand, if I leave Facebook for good, there's still a high chance that nobody will care, but at least I've quit. I'll no longer be a resource for Facebook. On the grand scheme, this is very little, a tiny drop in the ocean, but I believe it's the best I can do. Will I suffer it? Personally, not at all: I've not been consuming Facebook for a couple of years by now. But certainly, it's possible that the number of visits to my blog or YouTube channel (we'll talk about this other monster some other time) will decrease; not many people know how to use browser bookmarks (let alone an RSS feed) nowadays but, honestly, there's not much I can do about it.

The tech giants of the internet are certainly making our lives easier: it has become easier to stay in touch, to find information, to consolidate a mainstream opinion. It's so convenient, that it is making us not only lazier, but also dumber, to the point that we'd feel lost and powerless without their services. We are not talking only about a psychological addiction anymore: they are becoming a practical necessity. This, in turn, makes us weak, easy to manipulate and, ultimately, slaves.

I believe in the internet as the inter net: a distributed, interconnected place, with no owner. My hosting provider decides to censor me and shuts down my site? Fine, I open a new one in another hosting. If Facebook kicks you out, you immediately lose access to your friends, the groups you followed, the marketplace, local events, your daily news, your identity, your history.

And me, I want to live in a world where I'm the owner of my life.

Nuevo evento a la vista, y en esta ocasión de nuevo casi ni llego a anunciarlo, como pasó en noviembre o en enero. El próximo 22 de febrero tendremos nuevo Meetup de GNU/Linux Valencia, una oportunidad única de conocer a gente extraordinaria que lucha por difundir el Software Libre. En esta ocasión los temas son los siguientes: asistente virtual, programación para móviles y privacidad

 

22 de febrero tendremos nuevo Meetup de GNU/Linux Valencia

18 de enero tendremos nuevo Meetup de GNU/Linux ValenciaDe nuevo me complace compartir con vosotros los eventos de un grupo de personas que en Valencia está impulsado el Software Libre gracias a sus reuniones.

Se trata un nuevo encuentro organizado del grupo de GNU/Linux Valencia que el próximo 22 de febrero de este 2019 donde se tratarán temas como asistente virtual, programación para móviles y privacidad.

Siendo más concretos, y rescatado directamente de la web de la Comunidad, para este viernes tendrás a tu alcance una:

  • demostración de Mycroft. Mycroft es el primer asistente open source del mundo. Este asistente, es capaz de correr en casi cualquier soporte, desde una Raspberry Pi, a un coche, y por supuesto en tu ordenador, ya sea de sobremesa o portátil. Al ser software libre, puede ser modificado, ampliado y mejorado, según tus propias necesidades. Pero no solo eso, sino que también se puede utilizar para cualquier cosa que te puedas imaginar, desde un proyecto de ciencias, hasta una aplicación de empresa.
  • introducción a la programación de aplicaciones para Ubuntu Touch. Pero, no solo te servirán para desarrollar aplicaciones para este plataforma, sino que se pueden aplicar a las aplicaciones de escritorio con algunas pequeñas modificaciones. Si tienes curiosidad o quieres ampliar los conocimientos puedes consultar el curso sobre programación de aplicaciones para Ubuntu Touch

22 de febrero tendremos nuevo Meetup de GNU/Linux Valencia

Si podéis asistir no os lo perdáis, seguro que no quedáis decepcionados.

Más información: GNU/Linux Valencia

 

We are pleased to announce that the 1st bugfix release of Plasma 5.15, 5.15.1, is now available in our backports PPA for Cosmic 18.10.

The release announcement detailing the new features and improvements in Plasma 5.15 can be found here, while the full 5.15.1 bugfix changelog can be found here.

Released along with this new version of Plasma is an update to KDE Frameworks 5.54. (5.55 is currently in testing in Disco 19.04 and may follow in the next few weeks.)

To upgrade:

Add the following repository to your software sources list:

ppa:kubuntu-ppa/backports

or if it is already added, the updates should become available via your preferred update method.

The PPA can be added manually in the Konsole terminal with the command:

sudo add-apt-repository ppa:kubuntu-ppa/backports

and packages then updated with

sudo apt update
sudo apt full-upgrade

IMPORTANT

Please note that more bugfix releases are scheduled by KDE for Plasma 5.15, so while we feel these backports will be beneficial to enthusiastic adopters, users wanting to use a Plasma release with more stabilisation/bugfixes ‘baked in’ may find it advisable to stay with Plasma 5.13.5 as included in the original 18.10 Cosmic release.

Should any issues occur, please provide feedback on our mailing list [1], IRC [2], and/or file a bug against our PPA packages [3].

1. Kubuntu-devel mailing list: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
2. Kubuntu IRC channels: #kubuntu & #kubuntu-devel on irc.freenode.net
3. Kubuntu ppa bugs: https://bugs.launchpad.net/kubuntu-ppa

KDE is adopting non-proprietary and decentralized instant messaging services and is now running its own community-managed instance of Matrix.

Matrix works fine on mobile as well.

KDE has been looking for a better way of chatting and live-sharing information for several years now. IRC has been a good solution for a long time, but our channels are currently on servers KDE cannot control. It also lacks features users have come to expect from more modern IM services. Other alternatives, such as Telegram, Slack and Discord, although feature-rich, are centralized and built around closed-source technologies and offer even less control than IRC. This flies in the face of KDE's principles that require we use and support technologies based on Free software.

However, our search for a better solution has finally come to an end: as of today we are officially using Matrix for collaboration within KDE! Matrix is an open protocol and network for decentralised communication, backed by an open standard and open source reference implementations for servers, clients, client SDKs, bridges, bots and more. It provides all the features you’d expect from a modern chat system: infinite scrollback, file transfer, typing notifications, read receipts, presence, search, push notifications, stickers, VoIP calling and conferencing, etc. It even provides end-to-end encryption (based on Signal’s double ratchet algorithm) for when you want some privacy.

All the existing rooms on Matrix (and their counterparts on IRC, Telegram and elsewhere) continue to exist. The new service provides a dedicated server for KDE users to access them using names like #kde:kde.org.

For more information go visit our wiki page which contains details and instructions on how to get started.

You can also try KDE's Matrix service right now by checking in to KDE's webchat or by installing a Matrix client like Riot and connecting to the kde.modular.im server!

February 19, 2019

Two months ago a small group of KDE enthusiasts, namely Adriaan, Roman, and me traveled to Berlin to attend Qt World Summit 2018.

Me posing at the KDE booth at Qt World Summit

At our little booth we showcased Plasma running on a variety of devices, ranging from a Nexus 5X running Plasma Mobile through two ARM laptops to the powerful KDE Slimbook. Plasma was praised for its performance and reliability and since the focus of the event was mostly on embedded systems, we could easily demonstrate with our selection of devices that Plasma and the KDE Frameworks are a viable option for an endeavor in this area, too.

It was very interesting to see the diverse set of people presenting their products and roaming the stalls, to see where Qt is in use today without you even realizing. We were approached by several companies evaluating using KDE Frameworks in their products and also tried to lay a foundation for an eventual partnership. And then there was Daimler who just parked an A-Class in the hallway, whose MBUX infotainment system is also powered by Qt.

Give Milian, author of hotspot (a profiler GUI we use a lot for Plasma), any device and he immediately starts profiling!
What’s inside? The large box isn’t a 5¼” HDD but the battery

The star of our stand, however, was the MNT Reform DIY Laptop which is a retro-style ARM laptop running Plasma with a mechanical keyboard and even a real trackball! Its case was 3D-printed just the day before, including a rubber band to hold the screen shut, and for educational purposes sported a transparent bottom cover so you could look inside. What got us very excited was the fact that it ran mainline Debian and a super recent kernel version, something that’s quite uncommon when it comes to ARM devices. Even better: its i.MX 6 SoC let Plasma fly and we didn’t even do any adjustments for the device. It really shows that our hard performance work and focus on polishing the stack over the past years is paying off.

We are happy to announce the release of Qt Design Studio 1.1 !

Qt Design Studio is a UI design and development tool that enables designers and developers to rapidly prototype and develop complex UIs. Both designers and developers use Qt Design Studio and this makes collaboration between the two a lot simpler and more streamlined. To get an impression, you should watch this video.

Since the Qt Design Studio 1.0 release last year we worked hard on bug fixes and new features.

The most notable addition to Qt Design Studio 1.1 is the availability of Linux packages and merging when using the Qt Photoshop Bridge.
To learn more about the improvements and fixes, you can check out the change log.

Qt Design Studio 1.1 is available for Linux

Qt Design Studio 1.1 is available for Linux

This means that developers using Linux e.g. for embedded development can use Qt Design Studio 1.1 directly on their development system.

Qt Photoshop Bridge and updating to Qt Design Studio 1.1

The Qt Photoshop bride allows sanitizing documents

The Qt Photoshop bridge allows sanitizing documents

We updated the Qt Photoshop Bridge for Qt Design Studio 1.1 and we fixed many issues.

Unfortunately, the format for the annotations by the Qt Photoshop Bridge in the PSD and the custom .metainfo file format have changed.

We will try to avoid such breakages in future, but we had to work around some limitations of Photoshop.

PSD files that already contain annotations from the Qt Photoshop Bridge 1.0, require to be sanitized.

Annotations are added whenever you export from a PSD file using the Qt Photoshop Bridge and when you explicitly use the UI of the Qt Photoshop Bridge to annotate a layer.

To remove such annotations you have to use Sanitize document in the Qt Photoshop Bridge.
After doing this you can export the PSD file and use it with Qt Design Studio 1.1.

 

Qt Photoshop Bridge and merging when importing

When re-importing from Photoshop to an existing Qt Design Studio project it is now possible to merge the existing QML files with the newly re-imported QML. This is very useful when the user made changes to the exported .ui.qml files using Design Studio.
Added StatesTimelinesMouseAreasAnchorsAlias Properties or Connections can now be preserved when re-importing from Photoshop and generating the new .ui.qml files.

By default, merging is not active and the importer will simply overwrite the .ui.qml file. You can enable merging using a checkbox in the import dialog.

You can find more information on the Qt Photoshop Bridge in the documentation.

The Photoshop bridge now supports merging when importing into Qt Design Studio

The Photoshop Bridge now supports merging when importing into Qt Design Studio

Update projects from Qt Design Studio 1.0 to Qt Design Studio 1.1

If you have used Qt Design Studio before, you should update projects that you created with the wizards of Qt Design Studio 1.0 since the custom controls like shapes and effects are part of the project.

You have to update the project itself, to get the latest controls and effects.
This is possible by copying the controls from a newly created Qt Design Studio 1.1 project into the existing project from Qt Design Studio 1.0.
The folder you have to replace is “imports/QtQuick”. Replacing this folder will update the Qt Design Studio specific components that are used in your project.

Download and try out Qt Design Studio 1.1

The commercially licensed packages are available on the Qt Account Portal. You can try out and evaluate Qt Design Studio by registering for an evaluation license. We are also working on an open source version of Qt Design Studio and our target is have it out with the 1.2 release (May 2019).

Qt Design Studio 1.1 comes with new examples and updated documentation

Qt Design Studio 1.1 comes with new examples and updated documentation

Getting Started

You can find the latest online documentation for Qt Design Studio 1.1 here. The documentation is also available from inside Qt Design Studio.

The welcome page of Qt Design Studio contains examples and links to video tutorials to help you get started.

Please post issues you find or suggestions you have in our bug tracker.

The post Qt Design Studio 1.1 released appeared first on Qt Blog.

Last year I wrote about Plasma Pass, a Plasma applet for the Pass password manager. Over the couple last months I got some emails from packagers from various distributions asking for a proper release so they can package it…so here it is, proudly announcing Plasma Pass 1.0.0.

Here’s a video of how it works:

Tarball:

https://download.kde.org/stable/plasma-pass/plasma-pass-1.0.0.tar.xz

Checksum:

SHA-256: 9821c5ad80e4370dce002855bd0300d234feec249258b01fafd9e3a9241cbc66
SHA-1:   8d877b4d4bbbbf12890ba77c03c5cdd62b8279d6
MD-5:    69928b6df32ba82d0436a6d0abf73a8a

Signature:

0ABDFA55A4E6BEA99A83EA974D69557AECB13683 Daniel Vrátil <dvratil@kde.org>

Feel free to report any issues or feature requests to KDE Bugzila.

There are only a few things more fun in this world than doing template meta-programming (TMP) and reading all those long poems that the compiler writes out when we make even the smallest mistake.

While we don’t usually welcome these messages, there are ways to make them useful.

One of the main causes of errors in TMP code are unexpected types – types that the compiler is deducing instead of the types that we expect it to deduce.

This results in error messages occurring in seemingly random places in our code.

printf debugging

Just like it is sometimes useful to printf values in our program while debugging a problem, it can be useful to print types while debugging the problems in TMP code.

For this, here is one of my favourite meta-functions for C++:

template <typename... Ts>
struct print_types;

It is a meta-function that takes several arguments, but has no implementation. Which means that every time we try to use it, the compiler will report an error along with some additional information like which Ts... we passed to the meta-function.

For example, if we wanted to know what are the exact types of std::vector<bool>::reference and friends, we could do this:

print_types<
    std::vector<bool>::reference,
    std::vector<bool>::value_type,
    std::vector<bool>::iterator
    >{};

And the compiler will print out an error message along these lines:

invalid use of incomplete type 'class print_types<
    std::_Bit_reference,
    bool,
    std::_Bit_iterator
    >'

The compiler printed out all three types that we requested it to print.

This can be used in conjunction with some compiler output post-processing – shortening some type names like std::basic_string<char> to string etc, replacing < and > with ( and ) and putting the output through clang-format to get a pretty readable and nice formatted output for complex types.

For example, this is the output generated for one expression template in my codebase:

expression(
    expression(
        void,
        expression(PRODUCER,
                   expression(PRODUCER, ping_process,
                              transform("(λ tests_multiprocess.cpp:91:26)")),
                   transform("(λ tests_multiprocess.cpp:82:38)"))),
    expression(
        TRAFO,
        expression(TRAFO,
                   expression(TRAFO,
                              expression(TRAFO, identity_fn,
                                         transform("(λ tests_multiprocess.cpp:99:26)")),

    …

Printing types several times

The problem with the previous approach is that you can call print_types only once – as soon as the compiler encounters it, it will report an error and stop.

Instead of triggering an error, we might want to try something else – something that the compiler reports without stopping the compilation – we could trigger a warning instead.

One of the easiest warnings to trigger is the deprecation warning – we just need to mark the print_types class as [[deprecated]].

template <typename... Ts>
struct [[deprecated]] print_types {};

This way, we can use it multiple times and the compiler will generate a warning for each of the usages. Now, this works well with clang because it reports the whole type that triggered the warning. Other compilers might not be that detailed when reporting warnings so your mileage might vary.

Assertions on types

When you write TMP code, it is useful to assert that the types you’re getting have some desired property.

For example, it is a sane default (just like const is a sane default for everything) to expect all template parameters to be value types. For this, you could create an assertion macro and sprinkle it all over your codebase:

#define assert_value_type(T)                            \
    static_assert(                                      \
        std::is_same_v<T, std::remove_cvref_t<T>>,      \
        "Not a value type")

Having the habit of adding assertions like these can make your life much easier down the road.

Tests on types

Just like the original print_types we defined stops the compilation when called, static_assert stops compilation as soon as the first one fails.

What if we wanted just to get notified that a test failed, without it stopping the compilation.

We can use the same trick we used to allow print_types to be called several times. We can use the [[deprecated]] annotation to get a warning instead of getting an error with static_assert.

This can be implemented in several ways. The main gist of all the solutions is to create a class template which is then specialized for false or std::false_type and that specialization is marked as deprecated.

Here is one of the more fun implementations:

template <typename T>
struct static_test {
    static_test(std::true_type) {}
};

template <>
struct [[deprecated]] static_test<std::false_type> {
    static_test(std::false_type) {}
};

template <typename T>
static_test(T x) -> static_test<T>;

And the usage is quite simple:

static_test int_is_int { std::is_same<int, int>::type{} };

Whenever a test returns std::false_type, we are going to get a deprecation warning.

Conclusion

Working with templates allows us to do awesome things but it can be quite tedious. Small tricks like these can make working with templates a breeze.


You can support my work on Patreon, or you can get my book Functional Programming in C++ at Manning if you're into that sort of thing.

February 18, 2019

Cutelyst a Qt/C++ Web Framework just got a new version. This time bringing back proper async support.

Perl Catalyst Framework was conceived as a sync/blocking framework, due that the Mojolicious framework was created, NodeJS and a few other web frameworks have pushed the async programming to the web. Performance wise being async doesn’t mean you get faster response times, rather the opposite, the need to unroll stack and make extra calls makes a CPU bound application slower.

But depending on the problem to solve it allows you to serve more users at the same time, using the same CPU cores. A typical modern application might receive a request from a Phone App then do a REST API call to an external API which might take 2ms or 200ms for the reply. While waiting for the response, typical sync/blocking applications can’t process more requests, or have to spawn more threads increasing RAM consumption and leveraging concurrency to the OS scheduler. On an Async web application, you can process another request while you wait for the previous request, thus possibly making the first request reply to be sent back to the user at a later time than if there was a dedicated process just waiting for his reply.

So, both ways have pros and cons and IMHO I’d like to support them both. When I started Cutelyst I thought that if I ever need async I could have a local QEventLoop to wait for the reply and would be able to deal with async requests, not recently I found out that supporting QEventLoop was causing stack overflow due it being used in pipelined scenarios, after that I removed it’s usage and performance improved in PlainText tests of TechEmpower, so I advised against using it and marked Cutelyst as not async.

Recently I got the need to call a few APIs from a REST API I did with Cutelyst, QNeworkAccessManager is an async only API, so either I create a thread for it to mimic sync behavior or allow Cutelyst to be used in async mode, of course I did the latter. The Context class has now detachAsync() and attachAsync() methods.

When you c->detachAsync(), you tell the engine to not send the headers and body immediately to the client, this will also break the action chain, meaning an end() method won’t be called, then when you get your async reply you call c->attachAsync().

Once c->attachAsync() is called the action chain is resumed so the end() method that possibly would render the HTML can perform it’s job.

It’s important to always be child ( QObject->setParent(…) ) of the Context pointer as if the client closes the connection it might be deleted.

This release was not only made of async:

  • A helper UserAgent singleton was added so that you have a thread_local QNetworkAccessManager with static methods to do more common REST tasks like sending a QJsonObject (yes, eventually I find time to write a patch for QNAM)
  • A new Sql::Transaction class gives you a scoped SQL transaction, preventing the mistake of not rolling back when you leave the scope in case of an error.
  • A few Headers helpers like ETag and If-Match comparison
  • Sebastian Held added support for dealing with Front-End Proxy Headers
  • Improved Stats precision using QElapsedTimer::nsecsElapsed()

And finally Cutelyst is not “half modern” CMake anymore, if that can even exist. The include directories of the exported Targets are now properly exported, so that you can remove:

include_directories(
    ${Cutelyst2Qt5_INCLUDE_DIR}
)

Have fun https://github.com/cutelyst/cutelyst/archive/v2.7.0.tar.gz

Could you tell us something about yourself?

Hi! I’m a European Krita user.

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

I’m kind of in-between. I finished art school not too long ago, and I’m hoping to find a job or commissions so I could keep painting and actually earn money from it. I also do 3D and programming, but I’d love to keep doing all three without having to abandon any.

What genre(s) do you work in?

I like to try out different things, but for my main style, I’d say… illustrative? One thing’s for sure, though: my favorite theme is animals.

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

I don’t really have one artist that I look up to, but more like a series of temporary stylistic crushes. Right now I’d say oddsbod, the video game Transistor by supergiant games, illustrator and video games 3D artist Heather Penn  I also read a lot of webcomics, and I admire the style of paranatural, vainglorious, inhibit (that are all three really expressive and energetic), stand still stay silent (beautiful), and barbarous (a bit of both).

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

That was more than ten years ago. I was something like ten, maybe twelve at most. A friend of mine had a photographer father, so I went to their house and could try his drawing tablet, and it was really cool; some time later my parents got me one (one of those small A6 ones), and my brother downloaded Gimp, probably for a birthday (he was -still is- really into open source).

What makes you choose digital over traditional painting?

At first it was the novelty, and the ease with which you could have really vivid colours; then, it was the lack of waste when you drew something you didn’t like and the immateriality of what you spent to draw: no heavy expensive paper wasted, no limited supply of colours – I never finished a gouache tube or a pastel stick, but I could see the point where there would be no more. No so with digital art. And now I’m just more used to it.

I haven’t left traditional forever though, I still go to the zoo to draw in a sketchbook, and every so often I include painted textures to my digital stuff. I’d like to experiment more with traditional techniques at some point.

How did you find out about Krita?

I didn’t actually need another drawing software, so I wasn’t looking, but then my brother told me “look at that awesome new (open source) drawing software, they actually ask their artists what they want/need”. I didn’t change right away (switching softwares is always a bit of an investment), but I did eventually try it out and I loved the brushes and I stayed. I remember it was the year of the sheep, probably around February (Chinese New Year), so the first drawing I ever made in Krita was a sheep head with one of the sketch brushes.

What was your first impression?

I loved the brushes. I didn’t use the sketch ones so much, though they definitely were a fun introduction to Krita, but I fell in love with the soft kind of blur of the wet ones. There actually was the same thing in TVPaint (an animation software), which I used in my animation school, but I felt like krita had more options painting-wise.

What do you love about Krita?

The brush engines, definitely. They have incredible diversity. Also I learnt how the assistant tool worked a few weeks ago (it was one of those  things you know exist but never got around to actually check), and it looks really cool (it can be used for drawing perspective, geometric patterns in your image, and more). And the animation system is nice, and way better than photoshop’s (which I deeply hate). It still needs some tweaks to actually be efficient in short films (most of all a way to colour that would be semi-automated over the timeline instead of by frame) but I’ve read somewhere it’s on the todo list. And I recently started doing repeating patterns, and the wrap-around mode is very useful, as instead of offsetting and copying the image every time you’re finished with one step you can just… draw… without worrying about seams.

The way people are always there to help, on reddit, the Ask Krita website, or the IRC channel (even developers!).

Also the fact that since it’s open source, if I want to I can just add the functionalities I need, and then if it’s a good addition it’ll get added to the software and made available to everybody.

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

Like I said, the animation system needs improvement. The bases are solid, but since it’s still very young, it has room to grow.

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

Well, I do use it as my main art program, so I use no other (2D) programs to compare it to.

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

This one [tern.jpg]. I did it as a birthday gift to someone I was missing, so I’m emotionally attached to it. I also like the format and the feeling of
space it gives.

What techniques and brushes did you use in it?

I used a round wet brush (it gives better gradients than the gradient tool if you’re going for a painted look and have large surfaces to fill), and the
shape tool as an eraser. For the mountains, and the sea, I drew them on separate layers, locked the alpha, and used wide brush sweeps over the opaque parts.

You’re a Krita contributor; how did you get into that?

Short version: stuff needed doing (to be used in my workflow), I was able to do it, and nobody else was currently doing it.

Long version: Something like one year ago, I was doing a pixel art animation in krita, and I needed to export an animation into a spritesheet for a game. At first I did it manually, then pretty quickly when I grew bored of it I looked on the internet and found a plugin that did it for gimp. So I exported all my images, imported them into gimp and exported them again, through this plugin, as a spritesheet. It was pretty unwieldy, plus the plugin only exported as a single line so I had to actually change the code every time I wanted to change the options, and every time I changed the animation I had to do it all over again. But I knew there was to be the python plugin interface for krita, so I waited.

Then a few weeks back I actually had some time, so I checked nobody had done it in the meantime and I made the export to spritesheet python plugin. Then there was one part of it that was actually already included in krita, but lacked a small option to be completely functional, so I built krita and changed it.

And now that I worked on this very small change of krita’s source code, I actually feel confident enough to imagine doing bigger contributions.

Where can people see more of your work?

I have stuff all over the place.

For a bit of everything I do, finished and sorted, go there: https://tarnoem.blogspot.com/
For finished art, sorted, go there: https://www.artstation.com/nolanfa
For art (including sketches and WIPS) posted on a semi-regular schedule: http://nolanfa.tumblr.com/
For (digital) art you can buy, and also games: https://fal.itch.io/
For tumblr-is-dying-and-instagram-is-more-fashionable-those-days: https://www.instagram.com/nolanfa_/

February 17, 2019

Week 58 for KDE’s Usability & Productivity initiative is here! Hot on the heels of last week’s update, we’ve got lots of nice goodies to share:

New Features

Bugfixes & Performance Improvements

User Interface Improvements

Next week, your name could be in this list! Not sure how? Just ask! I’ve helped mentor a number of new contributors recently and I’d love to help you, too! You can also 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 you find KDE software useful, consider making a donation to the KDE e.V. foundation.

February 16, 2019

https://phabricator.kde.org/source/latte-dock/


A few months ago while I was scratching Latte Dock limits an idea came and haunted my thoughts. How Latte could give the colors freedom for panels and windows that an Android phone already provides? Questions like this arose and solutions appeared suddenly in many different places, but an important and concrete dream prevail in the end.


“Lets have panels and docks that understand their environment and adjust their colors and settings accordingly”


- youtube presentation -


How far would we like this dream to go, what are the limits?

An initial effort was landed at v0.8 through the Dynamic Background options but of course it was very limited. Step by step with patience the following goals appeared after version 0.8

Panels that:
  • can understand the underlying background independent of screen
  • color themselves according to the underlying background in order to provide the best contrast when they are transparent
  • can understand busy backgrounds (elementary style) in order to provide enough contrast
  • solidify themselves at some circumstances
  • understand when a window is touching them and paint themselves based on that window colors
  • can choose to be light or dark but at the same time to be based on the current plasma theme
  • provide an easy and elegant way to support the above features

Someone could ask, What nice features to have in my system but how long do you think it will be needed to provide them? one, two years?  who knows maybe never…

Well the thing is that this article does not describe the future but rather the PRESENT… All the above are currently supported from Latte git version. With their limits of course that arose from the current technology but nonetheless they are here…



What is needed in my system?




Appearance
(advanced settings)
How can I enable these features in Latte git version?


After you install above requirements you can find these features at Latte Appearance settings. Latte Advanced settings has been reorganized and improved in order to provide you with a full screen height window at the edge of the screen. The new settings moto is:


“easy to find, simple to understand”


the settings work has not ended yet so more improvements will be presented in the future.












How can Latte understand which is the underlying background?


Latte tracks the plasma config files and discovers for each screen what is the current background used. It can understand only background image files or single colors. For each one it produces a brightness value for each different edge and at the same time if the background in that edge is busy. That means that a bottom dock can be light and a top panel can be dark in order for both to be presented correctly to the user. The same of course applies to different screens because screens can have backgrounds with different brightness.

In case you are using a gif animator or video playing for your background and the brightness is not identified correctly you could try the following. Make a representing screenshot from the mentioned video and assign that image as a background. You can afterwards reenable your background video because Latte will use that screenshot to identify the different brightness values for the edges.




Can a plasma theme choose to be dark or light dynamically?

Materia dark theme
in Latte Reversed Colors mode
Well the answer is by default it can not. Each plasma theme can be either light or dark and that is an important decision from its designer. Latte did not want to break the designer style so in order to solve this is trying the following.

Latte understands if a plasma theme is dark or light and independent of that it creates a reversed color palette. For example the background color will become the text color and the text color will become the background color. This way the colors used do not look too different.

At the same time in order for Latte to paint correctly a reversed colored background the plasma theme panel roundness needs to be known (how rounded are the panels in the corners). Latte already provides a file that describes the panels roundness for the most known plasma themes but if the theme does not exist in the file or the user just wants to bypass it he can adjust the plasma roundness in pixels through the Latte Preferences window.




How Latte can know what is the color scheme for each window?

The earlier mentioned KWin script sends through dbus the color schemes for windows that do not use the default applied color scheme. When these messages reach Latte are filed and thus Latte whenever needs to, can provide a proper color palette to be consumed by panels and applets.





What are the limits?


The new coloring mechanism needs to be supported from applets in order to be painted correctly at all cases. Currently there are four applets supporting it, Latte taskmanager, Window Title, Window AppMenu and Window Buttons . For the rest the user must choose whether the colorize effect should be applied or not. For example the plasma analog clock that is not monochromatic it should not be painted at all cases. The new option to disable the painting can be found at applet tooltip in edit mode.


left: analog clock with no painting / center: analog clock with painting / right: tooltip to disable painting



Epilogue

That is all for now, I hope you enjoy these new features, personally I love them...




Donations

You can find Latte at Liberapay if you want to support,     Donate using Liberapay


or you can split your donation between my active projects in kde store.

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


Go get  v0.8.6   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:
  • fix previews that broke after kde frameworks 5.55 update
  • fix shortcuts behavior from plasma applets when using "Multiple" layouts

Donations:

You can find Latte at Liberapay if you want to support,     Donate using Liberapay


or you can split your donation between my active projects in kde store.

After addressing Android support in KF5Notifications another fairly generic task that so far required Android specific code is next: opening files. Due to the security isolation of apps and the way the native “file dialog” works on Android this is quite different from other platforms, which makes application code a bit ugly. This can be fixed in Qt though.

Qt 5.12 and before

On most platforms, allowing the user to open a file in an application works like this:

  • Request the native file dialog via the corresponding widget or QML API, both of which go through the same internal platform integration plugin in Qt.
  • Retrieve a file path from the file dialog.
  • Open that path with QFile.

On Android so far we had to do the following:

  • Request the native “file dialog” (it’s essentially the file brower app) via an Intent.
  • Retrieve a content: URL from that Intent.
  • Use the Java ContentResolver API to open a file descriptor for that content: URL.
  • Pass that file descriptor to C++ and read it via QFile.

While the Intent details could be hidden behind the native file dialog abstraction in Qt, the problem then is still that the returned URL isn’t pointing to a local file that subsequent code might expect. There’s a good reason why Android does it that way though, as this allows applications to only access files that the user explicitly selected, without the need of full file system access permissions.

Qt 5.13 and beyond

A way to address this is a QAbstractFileEngine implementation to add support for content: URLs to QFile. This is the same approach taken already for e.g. asset: URLs. It’s actually not particularly complicated as all we need to do is obtain a file descriptor for a content: URL, and then hand over to the existing regualr file system backend, which implements everything else we need already.

KDE Itinerary is already using this approach as a testing ground, and this week this also landed upstream in Qt, to be included in the 5.13 release.

At the same time Nicolas added support for native file dialogs on Android, as well as content URL support in QML. With all that combined opening a file should (almost) work with identical code on all platforms.

One small caveat remains, the fact that you have to deal with URLs correctly throughout your file handling code. If you at some point convert to a local file path, this is going to break when encountering a content: URL.

February 15, 2019

If there is one thing you can learn from creative writing school, it is that you have to give your characters at least three good reasons before they should consider doing anything.

KDE Promo contributors recently completed drafting and editing a document that lays out the long-term goals for the Promo workgroup. This has proven a complex and tedious task, but we were compelled because we had those three good reasons:

  1. Having long-term goals laid out in front of us gives a clear direction in which to work.
  2. Concrete goals also help us differentiate between what is important and what is secondary; between what we can do with the resources we have, and what we may have to put on hold or even forget about completely.
  3. Goals help clarify to others why we do what we do. When our peers understand what we intend to achieve, it saves time because we don’t have to lay out every step of every process every single time to justify your actions.

But… what does “Long Term” mean to you?

After several back-and-forths on Phabricator, we ended up defining “long term” as “5 years”. We have also associated concrete numbers with each goal, things like “Promo intends to help increase the number of desktop end users by 2% over the next 5 years“, to provide specific baseline for each overarching action. This will help us assess the degree of success for each goal…

…or adjust our expectations to reality the next time we have to write something similar. Many of the numbers in the goals are dictated solely by what we currently feel is right. Since many of the goals have never been attempted, we can only speculate as to what they will take. Many of the baselines will probably have to change over time as we get more data that helps us make more realistic predictions.

How are you going to do it?

When you read through the list, you will see a pattern emerge: there is a lot of going to events, hoping to talk to head-honchos, sending emails into the void, getting in touch with people we have never met; lots of knocking on doors not knowing if we will have them slammed back in our faces.

Achieving goals through these means may sound like taking very long shots, but we do have a massive community on our side. For one, there’s the fact that, despite some exaggerated reports to the contrary, KDE is a force to be considered. I would not say that claiming you come on behalf of KDE will open every door, but it has helped us in the past, even when cold-calling, and it will continue to help us in the future.

Then there is the the friend-of-a-friend resource: in a community as large and with members in such far-flung places, from Korea to Kentucky, and from Norway to Nigeria, we want to be able to use members of our community as ambassadors to our cause. Thanks to our community, there will always be somebody who knows someone who can get us into meetings with the people we need to talk to.

And who are these people? Well, they are those who can help us reach ever larger audiences, while at the same time consolidating and helping us grow our community. We are talking about journalists, “influencers” (yes, I hate that word too), bloggers, vloggers, podcasters and so on. We also want to talk to businesses that may benefit from developing with our tools and frameworks.

The idea is to gradually expand our area of influence among users and companies beyond those that are already convinced of KDE’s virtues, even beyond those that are diehard Free software advocates and users. We want to reach more mainstream users, users and developers that may not even have heard of KDE.

This is where you can help: if you know a “celebrity”, influencer, or talented writer, a Youtuber, blogger, or good podcaster – introduce us! We want as much coverage as we can decently get, and content creators are often looking for topics they can talk about. We may be able to provide them with some juicy stories and get the word out to people we otherwise wouldn’t be able to reach. The same goes for journalists in mainstream or specialised publications, politicians, and decisions-makers in companies big, medium or small.

It may seem like the number of things we can do (tweeting, going to events, putting out press releases and blog posts, contacting journalists, talking to managers) is limited and very unexciting. This is true: there are no clever shortcuts or breakthrough techniques you can apply here. However, the fun is in the twists and turns you apply to these things.

You may have noticed we always try to a post an attractive picture with everything we send on to social media or publish on the Dot. We make meme jokes, jump on trending bandwagons, and often ask members from other workgroups and projects to let us look at what they want to submit to social media so we can give it a whirl. We believe you can always write and engineer a message in a way it can entice more people.

This sounds terribly conceited. How do you know you are right about this?

TL;DR: We don’t.

It is always hard to prove anything we do has a positive effect on KDE’s popularity and adoption. It stands to reason it be so, but there is no hard way to say for sure. The only thing we can do is look at the numbers over time and try to discover a correlation between actions and effects.

We monitor most social media platforms, regularly taking data from LinkedIn, Twitter, Mastodon, Facebook and so on. We also monitor Debian’s popcons (popularity contests) every week and store all the data in a folder on share.kde.org.

This is where you can help: a lot of the data collection and processing is done by hand. There are services that could help us, but very often they are proprietary, tie us to their online storage services, and/or don’t cover all the bases, leaving out things like Mastodon, PeerTube or Diaspora.

We are also aware of how inadequate the sources we mine are. We really don’t have a good way of knowing, for example, how many times KDE software gets installed in distributions, so it is nearly impossible to figure out how many silent users are out there.

Point us to solutions and tell us about sources we can mine. This helps us get a better idea of how things are going for us on a global scale. It will also contribute to figuring out if what we are doing is helping or not.

We also need to know where we stand within our own community. Because of this, we are creating a survey that will help us understand better who our peers are. While the survey may confirm things we already suspect, it will also tell us about the big absences.

A good way to grow a community is by looking further afield, into audiences different from what we already have. As different people respond to different things, knowing who we are missing can help us shape activities to attract them.

This is where you can help: please answer our surveys! All information is anonymised and you obviously can ignore questions that you don’t want to answer. But even incomplete information will help us learn what sort of people we click with, and put us on the road to answering the question of why some people just don’t get bitten by the KDE bu–… er… dragon.

Notwithstanding, market research is far from a hard science, and it is frustrating not being able to confirm without a shadow of a doubt that we are doing a good job.

That must be annoying…

Talking of annoying, it is important to remember that most things in business fall through. Most meetings lead to nothing, most agreements end up producing nothing useful, most promises are broken. This is not because businesspeople are unreliable. The problem is priorities shift, other more urgent or more auspicious things pop up, and businesspeople are obliged to implement a better strategy for their companies if the opportunity arises, even if it means ditching an agreement with certain Free software communities.

But even a 90% failure rate is nothing to be disillusioned about. Quite the contrary: if you give up after a couple of let-downs, you are guaranteed not to succeed ever. Promo casts its nets wide and latches onto as many plausible-sounding agreements it can. We try to follow through until it is either clear it is going nowhere, it is not going to work in our favour, or it is no longer our business and we need to pass it on to someone who can sign on the dotted line — Promo does not have a say in the conditions of final agreements.

In fact, Promo has very little say in anything. If you read through the list of goals and how we intend to carry them out, it should be clear that Promo doesn’t dictate or even want to dictate what the rest of the community should do. We won’t even tell you to re-design your project’s website to make it more attractive and useful to your visitors. We will probably tell you that you _should_ re-design your site, and even help you do it, but we won’t tell you you have to.

We work with the things we have. We try to tell the rest of the world how KDE and our projects are attractive. We try and improve our hand by advising on wording in announcements, layouts on web pages, and communication at events. In short, we aspire to be the community’s PR firm.

This where you can help… Or, more precisely: we can help you. Come and visit us in our IRC channel, Telegram group or mailing list, and we can start working together to improve your online presence, get your project into the media, and grow your userbase.

We are already working consistently with Krita, Kdenlive, Atelier, Kontact, Plasma, Plasma Mobile and many others. As it is difficult to keep track of all the projects within KDE and the people behind them (this community is big), we often need you to come and tell us.

The point is, we are here for you… even if we don’t know who you are yet!

So the best way to get a handle on Promo is to read through the goals. And if things are still not clear or you need more details, come and talk to us. We at KDE Promo are a welcoming lot!

February 14, 2019

No, this is not a tutorial, unfortunately. The main reason being that, while I strive to do my best, I don't consider myself to be an excellent member of the Free Software community, let alone be able to teach others about it. But this morning I got an email from the FSF about a campaign for St. Valentine's day, which reminded me of something I've been planning to do since a long time ago, but never got to it.

Love

I want to publicly send huge thanks to Robin Mills from the Exiv2 project, and not only because I've been fruitfully using his work in three (!) projects of mine (PhotoTeleport, Mappero Geotagger and Imaginario), but also, and especially, for being an extremely pleasant interlocutor. On the web, yes. Whereas most people tend to be more thorny and touchy in their interactions over the internet, Robin has always been friendly and coversational, trying to form a bond with some complete foreigner who just happened to report a bug on Exiv2.

Just adding some bits of information about one's personal events (such as travels) can make an enormous difference on how one's attitude is perceived. Mentioning that you visited the place that is familiar to the bug reporter almost makes one forget of being sitting in front of a computer on the internet, because your mind flies to that place. Considering that even on this personal blog of mine I'm kind of reticent about speaking of my private life, I cannot help appreciating the friendly attitude that Robin reserves for people writing on a bug tracker.

You are a wonderful netizen, Robin. A happy Valentine Day to you and your family. Thank you.

I was last week in Berlin at the Plasma Mobile sprint, graciously hosted by Endocode, almost exactly 9 years after the first Plasma Mobile sprint in which we first started to explore Plasma and other software by KDE on mobile phones, which at the time were just starting to become powerful enough to run a full Linux stack (Hi N900!)

Now the project got a wide breath of fresh air: the thing that impressed me the most was how many new faces came at the sprint and are now part of the project.

Compared to 9 years ago, we have a way saner and more robust ecosystem to play on. Instead of a single (and quite underpowered) phone, which was the N900, now we can hack on a wide variety of phones, thanks to ARM being slightly less painful to work with compared to back then (even tough still a long way to go to be considered an open hackable system from nay point of view) Some devices are starting to get upstream mainline kernel support, and for those (unfortunately, most) who don’t there is the Halium project to the rescue, which provides an abstraction layer between the Android kernel and the “proper Linux” userland, making possible to use its graphjics drivers to drive a Wayland session, access audio and connectivity and so on.

We have a Neon version which supports a reference device (the old Nexus-5x) which can be easily adapted to other devices, and PostmarketOS, which is a distribution which supports many different phones and several user interfaces, Plasma Mobile being one of the official ones. At the sprint there were also some people from the PostmarketOS project: one of the things i love most of open source is when different projects collaborate so closely.

We had also some new toys to play with: people from Purism were also present, bringing development kits for their upcoming Librem5 phone, which will support mainline kernel and no need for closed Android drivers. Even tough a lot of work is stil lto do, Plasma Mobile already boots on the device.

Plasma Mobile running on a Librem 5 devkit.

As for Plasma Mobile software in itself, we did many bugfixes on the main shell/homescreen to have a better first impact, and a significant improvement came in KWin about high DPI scaling when running on an Halium system.

Also, many improvoements were done in the Kirigami framework, which is the main toolkit recommended to be used to build applications for Plasma Mobile: as developers of several applications that use Kirigami were present there, we could do very fast feedback and debug sessions.

Google+ does rather killoff the notion I had of Google as a highly efficient company who always produce top quality work.  Even using the takeout website to download the content from Google+ I found a number of obvious bugs and poor features.  But I did get my photos in the end so for old times sakes here’s a random selection.

1a8a0n0gqj2mq
A marketing campaign that failed to take off

1bsc2o3kyhjlu.JPG
Sprints in Munich thanks to the city council’s KDE deployment were always fun.

1bogmkij7mzb6
Launching KDE neon with some pics of my office and local castle.

1bsmv13wngar6
One day I took a trip with Nim to Wales and woke up in somewhere suspiciously like the Shire from Lord of the Rings

1chq4qpaex94y.jpeg
KDE neon means business

1dde2jg4rwl2q
Time to go surfing. This ended up as a music video.

That’s about it.  Cheereo Google+, I’ve removed you from www.kde.org, one social media platform too many for this small world.

Facebooktwitterlinkedinby feather

Intro

Last Monday and Tuesday a few brave souls from both the Qt Company and KDAB gathered together in the KDAB Berlin office premises to work on the CMake build system for building Qt. There was Mikhail, Liang, Tobias, Kai, Simon (QtCompany) as well as Jean-Michaël, Albert, Volker and me (KDAB) sitting together in a tight room, focusing solely on the CMake port of Qt.

Excerpt of the top-level CMakeLists.txt in qtbase.git

All work done so far is out in public and can be checked out on Qt Gerrit.

About the CMake port

To put this a bit more into context, the Qt Project believes that building Qt with CMake is our best bet in Qt6 times and thus a group of people have started to build a CMake build system prototype. KDAB has a track record of helping out with the CMake support in Qt. For instance most of the “Modern CMake”-style support in Qt5 has been implemented by Stephen Kelly. As of today, we’re even largely responsible for maintaining the CMake support of Qt5. Since quite a few of our customers are actually heavily invested in CMake themselves, we’d also like to make sure Qt stays easy to use with it in future. Thus we’re continuing to invest in Qt’s CMake support and would like to help out with the early Qt6 build system exploration happening right now.

The central page where we’re currently collecting the progress made as well as the future roadmap is here: https://wiki.qt.io/CMake_Port

On that page you’ll also learn which branch to check out from Gerrit in order to start playing around with the current state of the Qt/CMake build. Please make sure to have the prerequisites for building the branch (i.e. a current CMake build!).

Workshop Summary

As Simon mentioned in his workshop summary, sent to the qt-development mailing list, we were able to make good progress on multiple fronts the last few days. Let me just outline his notes part of that mail, with some additional comments of my own:

Quoting Simon

  • We were able to fix the artifacts of “make install” in qtbase to allow for building an external module (qtsvg) and sample apps. The plan for allowing people to develop apps that work with Qt 5 and Qt 6 is quite simple API wise:
    1. In your application use either find_package(Qt5) or find_package(Qt6)
    2. Always use Qt::Core, Qt::Gui, etc. for linkage
    3. We want to add the “plain” Qt::Core, Qt::Gui, targets also to Qt5’s CMake support
  • The script to converting .pro files to CMakeLists.txt is becoming really good. The goal is to convert all scopes and (source) file names correctly. Right now the repo contains incremental conversions with hand-edits.
  • We’re working on installing the latest CMake (as required) in the provisioning setup, so that we can get a building CI as soon as possible.
  • We were able to verify that cross-compilation works well. The main challenge is ensuring that third-party libraries that used to be copied in src/3rdparty are either installed in the sysroot or can be found outside.
  • We discussed and experimented with different ways of making static builds robust. So static builds themselves work already, but what we’re looking into in particular is an automatic way of propagating Qt internal dependencies (such as double-conversion) correctly, to the build process of the application, that is not fragile.
  • We added a lot more plugins and platform support libraries to the build process and did many improvements to the finding of external libraries.

More than that

  • Additionally we’ve succeeded in generating CMake config files compatible with the current config files generated by the Qt/QMake build
    • For instance, we’ve been able to successfully compile KDAB’s GammaRay (which has a rather complex beast of a CMake build system) against the Qt/CMake build of qtbase
  • We were able to compile QMake using CMake in order to retain the support of using QMake to compile Qt projects for existing users of Qt/QMake

Outlook on the future

  • We’ll investigate ensuring a smooth Qt build process on macOS and Windows platforms for developers
  • We’ll add the CMake build system to other Qt modules (thinking of qtsvg (rather simple), qtdeclarative (rather complex))
  • We’ll add a super build which takes care of building multiple Qt modules in one go (cf. a top-level build off from qt5.git)
  • Test more cross-compilation configurations
  • Make sure static builds of Qt are not a pain to deal with for external users (like it is right now)
  • Make sure to continuously test the Qt/CMake build using basic CI build support.
  • QMake will likely still be around in future Qt6 times, as there’s still a lot of users out there. The difference will just be that QMake itself is built using CMake inside qtbase.git; and QMake’s module .pri files will get generated by CMake instead.
    • Obviously exactly the other way around to what it is right now in Qt5/QMake, where QMake generates the CMake config files for CMake!

If you have comments or if you want to help out, please ideally post feedback on the Qt Project infrastructure. Send a mail to the qt-development mailing list or comment on the wiki page dedicated for the CMake port. Or just join us in the IRC channel #qt-cmake on Freenode!

The post Qt on CMake Workshop Summary – Feb 2019 appeared first on KDAB.

@totte wrote:

Also available in French, Italian, Simplified Chinese, and Traditional Chinese.

The following updates have been tested, and are now available.

Name Version
Frameworks 5.55.0
Plasma 5.15.0
Applications 18.12.2

Most of our mirrors synchronize with the central repositories on the origin server within 24 hours. Use the mirror status web page to see when your mirror of choice last synchronized. Run sudo pacman -Syu to update and upgrade your system. If you have any issues updating or upgrading, reply to this topic with the complete input and output in English, i.e. run LC_ALL=C sudo pacman -Syu.


“The KDE dragons” by Tyson Tan, Creative Commons BY-SA, made with Krita.

Posts: 3

Participants: 2

Read full topic

February 13, 2019

KDE neon was rebased onto Ubuntu bionic/18.04 last year and upgrades have gone generally smooth. We have removed xenial/16.04 build from our machines (they only hang around for as long as they did because it took a while to move the Snap builds away from them) and the apt repo will remove soon. If you haven’t already upgrade now.

Snaps is a fancy new package format for Linux which allows applications to be shipped which run on pretty much any Linux distro. This nicely solves one of the headaches with shipping software for Linux, that you have to package it a dozen times using a dozen different methods to get anyone to be able to install it.

The format and host for Snaps is made using Ubuntu and developed by KDE patron Canonical.

We have been working on building Snaps from the KDE neon builders for some time and they’re now at a quality where we can move them into the stable channel. (Snap software gets hosted in channels depending on the risk you want to take, others being candidate, beta and edge.)

If you’re a Plasma user you can use Discover to install the Snaps, but of course they work equally well on other desktops with other package managers or using the snap command.

This month the Snap team are highlighting KDE’s stable Snaps on their Twitter and Facebook feeds. Here’s what we’ve seen so far:

There’s still plenty of KDE apps that need tweaks before they can go in the Snap stable channel. If you’re an app maintainer then come and talk to us (in #kde-neon probably) about how your app can be distributed. We plan on doing some automated QA so they don’t need manual review before publishing and before long hopefully we can move much of the build details into the app repo rather than the KDE neon repo.

February 12, 2019

Say hello to Plasma 5.15, the newest version of KDE's acclaimed desktop environment.

This February release of KDE Plasma comes with a wide range of new features and improvements. The main focus of developers has been stamping out all minor problems and papercuts of the desktop, aiming to make Plasma smoother and easier to use.

Plasma's configuration interfaces have been redesigned, expanded and clarified to cover more user cases and make it simpler to adapt Plasma to everybody's needs. Plasma has also improved the integration of non-native applications, so Firefox, for example, can now optionally use native KDE open/save dialogs. Likewise, GTK and GNOME apps now respect the global scale factor used by high-DPI screens.

Updating your system is now easier and more reliable with the new and improved Discover.

Developers have also been hard at work on Discover, Plasma's built-in software manager. Options for upgrading your distribution are now included in Discover's Update Notifier widget, which will also display a "Restart" button if a restart is recommended when updating is done. Talking of updates, it is now possible to uncheck and re-check all available updates to make it easier to pick and choose the ones you want to apply. Another improvement is that repository management in Discover is now more practical and usable, especially for Ubuntu-based distros.

We have also solved problems with text readability and icon clarity. KDE designers have improved a variety of Breeze device and preference icons, including the multimedia icons and all icons that depict a stylized version of a Plasma wallpaper. The Places, Vault and Python bytecode files all have redesigned icons to make them easier to identify.

There are literally hundreds more improvements and tweaks included in this release, all implemented to make your life as a Plasma user much more enjoyable. Read the official announcement and check out the Plasma 5.15 changelog for more details on this new version of the Plasma desktop.


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.