December 16, 2017

Como buen regalo pre-navideño, los desarrolladores de la Comunidad han lanzado KDE Aplicaciones 17.12, una gran actualización de sus aplicaciones que promete seguir mejorando algo que ya es bueno pero que siempre tiene margen de mejora. En esta ocasión nos encontramos múltiples mejoras en aplicaciones insignia como Dolphin o Kdenlive, en otras menos famosas como Ark y muchas migraciones. Como siempre decimos ¡KDE Rocks!

Lanzado KDE Aplicaciones 17.12, un regalo adelantado

Ayer fue el anuncio oficial, es decir, el 15 de diciembre fue el día elegido para anunciar lo que estaba programado y al final se hizo realidad. En otras palabras, ha sido lanzado KDE Aplicaciones 17.12.

Todo el trabajo que se inició tras el lanzamiento de KDE Aplicaciones 17.08 ha llegado a buen puerto y pronto las distribuciones más punteras lo pondrán en sus repositorios. Yo ya estoy impaciente en mi KDE Neon.

Sigue siendo un motivo de satisfacción comprobar que la Comunidad KDE sigue cumpliendo los plazos que ellos mismos se imponen, algo que se ha convertido en una constante y que demuestra el compromiso de los integrantes de este proyecto.

¡Enhorabuena a todos ellos!

Las novedades de KDE Aplicaciones 17.12

Como es habitual en los últimos tiempos, los lanzamientos de KDE Aplicaciones se centran en aportar nuevas funcionalidades y en portar más aplicaciones a KDE Frameworks 5 y a Qt5, además de ir solucionando los errores de anteriores versiones.

De esta forma, las novedades más destacadas de KDE Aplicaciones 15.12 son las siguientes:

Dolphin, el gestor de ficheros más funcional y cómodo que te puedes encontrar, ha recibido múltiples mejoras:

  • Activada la funcionalidad para guardar resultados de búsquedas de Baloo
  • Posibilidad de limitar la búsqueda solo a una carpeta
  • El renombrado de archivos es ahora más sencillo
  • Aumentada la información proporcionada por cada fichero
  • Añadidas columnas género, bitrate y año de lanzamiento en la “Vista por columnas”
Lanzado KDE Aplicaciones 17.12

Dolphin recibe muchas mejoras en KDE Aplicaciones 17.12

Okular, el visor universal de documentos, soporta ahora resoluciones HiDPI y el lenguaje  Markdown. Además, se ha optimizado la carga de documentos pesados y añadida la opción de compartir un documento vía correo electrónico.

Gwenview, el visor de imágenes básico de KDE, ahora puede abrir y destacar imágenes desde el gestor de ficheros. Además, se ha suavizado el zoom, se ha mejorado la navegación mediante teclado, se ha protegido el borrado accidental de imágenes y se ha añadido el soporte para los formatos FITS y Truevision TGA.

Kdenlive, el editor no-lineal de vídeo, ahora utiliza menos memoria en la gestión de los proyectos que incluyen muchas imágenes y se ha modificado la gestión del proxy. Además se ha solucionado un molesto error relacionado con el salto de un segundo hacía delante que se producía al reproducir un vídeo.

Kontact, el completo gestor de información personal, también ha recibido mucho amor por parte de su equipo de desarrollo. DE esta forma se ha trabajado duro para ir modernizando el código, lo que se traducirá en:

  • La visualización de los mensajes encriptados ha sido mejorada y se ha añadido el soporte para text/pgp y Apple® Wallet Pass.
  • Se ha añadido la opción “Seleccionar carpeta IMAP” en la cofiguración de vaciones
  • Tenemos un nuevo aviso en KMail para cuando el correo reabierto y la identidad/mailtransport no es el mismo.
  • Nuevo soporte para Microsoft® Exchange™
  • Soportor para  Nylas Mail
  • Mejoras en la importación Geary importen el asistente de importado de akonadi

Las aplicaciones de sistema, es decir, las pequeñas pero esenciales aplicaciones que elaboran tareas muy concretas, también han recibido mejoras. Así tenemos:

  • Ark, el gestor de archivos comprimidos, ha mejorado el soporte al conocido formato zip.
  • Kate, el sencillo pero potente libreta  de notas, tiene un nuevo plugin llamado vista previa que permite visualizar en tiempo real el aspecto que tu documento está tomando. Este plugin también está disponible para KDevelop.
Lanzado KDE Aplicaciones 17.12

Nuevo plugin “Vista Previa” para Kate

En el apartado de migraciones hay que destacar que:

Lanzado KDE Aplicaciones 17.12

Versíon Android de KTuberling

Finalizamos el repaso con otras informaciones sobre aplicaciones como:

  • KStars no seguirá ahora en ciclo de lanzamientos de KDE y estrena uno propio. Se aconseja seguir el blog del desarrollador  para seguir los anuncios.
  • Se ha publicado el listado de aplicaciones que no van a ser actualizadas más debido a que no han sido portadas a KF5, han sido reemplazadas por otras o que no tienen actualmente mantenedor: Entre ellas nos encontramos a Kopete, Blogilo o kscdare. Puedes consultar la  lista en este enlace.

Ayuda a la mejora de KDE Aplicaciones 17.12

Ahora queda ver si KDE Aplicaciones 17.12 es tan bueno como han querido dejarlo los desarrolladores y tiene el éxito que se merece, y para ello se necesita vuestra colaboración. No olvides nunca que KDE no es una empresa, sino una Comunidad de personas que busca un bien común.

Esta colaboración se puede concretar de dos formas:

  • En primero lugar no dejéis de ayudar al desarrollo cazando y reportando los errores que seguramente encontraréis en bugs.kde.org, Si no sabéis os invito a recordar cómo hacerlo en esta entrada del blog.
  • La segunda consiste en ayudar a la difusión de este lanzamiento, lo cual se puede hacer haciendo entradas similares a esta en vuestro blog (sentiros libres de utilizar lo que queráis de la misma), difundid la noticia en canales como Reddit, Facebook o Twitter, subid capturas de pantalla a servicios como Snapchat, Instagram o Google+ o cread vídeos de captures de pantalla y subirlos a YouTube, Blip.tv o Vimeo, ¡o transmitidlos en vivo por medios de Twitch!

Toda ayuda, por pequeña que sea  es bienvenida.

Resumiendo: nuevas funcionalidades en todo tipo de aplicaciones, más migraciones y un buen número de errores resueltos. Si queréis ver la lista completa de cambios seguid el siguiente enlace, no os dejéis intimidar por su extensión.

 

Más información: KDE.org

December 15, 2017

We are happy to announce the latest Kdenlive version, part of the KDE Applications 17.12 release, making it the last major release using the current code base. This is a maintenance release focused on stability, while feature development is going in next year’s 18.04 version. Proxy clips were given some attention and should give you better seeking experience as well as reduced memory usage for images. Other fixes include fixes in timeline preview, a crash when using a Library clip and smoother seeking on rewind playback.

Packaging
We have been pushing the AppImage packages lately because it allow us to put all required dependencies inside one file that can easily be downloaded and run on all linux distros. Today, we can also announce the immediate availability of the Kdenlive 17.12 AppImage, downloadable here :
https://files.kde.org/kdenlive/release/kdenlive-17.12-x86_64.AppImage.mirrorlist

AppImage related fixes:

  • Fix audio distortion affecting the 17.08.3 AppImage
  • Include Breeze style

Vincent Pinon is also continuing the support for the Windows version, and you can get Kdenlive 17.12 for Windows here: https://files.kde.org/kdenlive/release/Kdenlive-17.12.0-w64.7z.mirrorlist

Next
We are also making available the first usable “preview” AppImage of the refactoring branch which will receive all development focus from now and will be released as 18.04. It is not ready for production but allows you to have a look at Kdenlive’s future. You may follow the development progress here.

Kdenlive 18.04 alpha 2 release: https://files.kde.org/kdenlive/unstable/kdenlive-18.04-alpha2.AppImage.mirrorlist

Meet us:
Next Kdenlive Café is tonight on #kdenlive at 21PM (CET), so feel free to join us for some feedback!

 

Important

  • Packagers must take note that libsamplerate is now a dependency due to recent changes in FFMPEG.
  • It is recommended for Ubuntu (and derivatives) users to use the AppImage version until further notice.

 

Full list of changes

  • Remove useless audio bitrate on pcm proxy encoding. Commit.
  • Update proxy profiles. Commit.
  • Make sure playlist proxies have an even height. Commit.
  • Fix crash on playlists concurrent jobs using library clips. Commit. See bug #386616
  • Timeline preview fixes: Don’t invalidate on expand/collapse effect, invalidate on master clip edit. Commit.
  • Don’t restart clip if trying to play backwards from clip monitor end. Commit.
  • Use smaller size for image proxies. Commit. Fixes bug #353577
  • Fix playing backwards forwards one second. Commit. Fixes bug #375634
  • Fix extension in transcode file dialog. Commit.
  • Sort clip zones by position instead of name. Commit.
  • Set a proper desktop file name to fix an icon under Wayland. Commit.
  • FreeBSD does not have sys/asm.h — for what is this include needed on linux?. Commit.
  • Doc: fix option (qwindowtitle instead of caption). Commit.
  • Fix terminology: mimetype(s) -> MIME type(s). Commit.
  • Fix UI string: Control Center -> System Settings. Commit.
  • Const’ify code. Commit.
  • Fix import image sequence. Commit.

Tenía pendiente realizar una entrada donde hablara de las metas de KDE para el futuro, el resultado de unos meses de  análisis, votaciones, decisiones y anuncios. Ahora, gracias a la redacción de Adrián Chaves que ha adaptado los artículos originales, ya puedo ofrecer en el blog unas pinceladas del futuro de KDE que se verán ampliados en entradas venideras.

Las metas de KDE para el futuro

Tras la Akademy en Almería, la comunidad KDE inició un proceso de selección de metas en las que centrarse en los próximos años, unas metas que por fin han sido seleccionadas y que nos indican algunas cosas que podemos esperar de KDE a medio y largo plazo.

Precedentes: manifiesto, visión y misión

Visiones personales en Akademy 2015

Desde que Lydia Pintscher asumió la presidencia de KDE e.V. en 2014, entre otras cosas se planteó reto de ayudar a KDE y KDE e.V. a «entender mejor dónde estamos, dónde queremos ir y cómo llegar». Un reto que Lydia bautizó como Evolucionar KDE.

Con este objetivo, al Manifiesto KDE de 2012 que ya mencionamos en su momento y que definía los valores de KDE se han sumado la visión de KDE, que define lo que queremos lograr, y la misión de KDE, que define en términos generales lo que vamos a hacer para hacer realidad esa visión.

Selección de metas

Decididas las líneas generales sobre cómo lograr nuestra visión, tocaba definir metas concretas en las que centrar el trabajo de la comunidad de KDE para acercarnos a nuestra visión.

Tras la Akademy de 2017, celebrada en Almería, la comunidad KDE empezó un proceso de presentación de propuestas concretas de metas en las que trabajar en los próximos 3-4 años, apoyándolas de varias formas, como la financiación de encuentros de trabajo (sprints) o presentaciones en próximas Akademys.

Hasta principios de octubre se presentaron 10 propuestas, que se refinaron durante ese mes, y finalmente se ha realizado una votación entre todos los colaboradores de KDE (desarrolladores, artistas, traductores, etc.) con el objetivo de seleccionar 3 de las propuestas.

Las metas ganadoras

Dolphin, uno de los ganadores

De las 10 propuestas presentadas, las 684 personas que participaron en la votación eligieron las siguientes metas de las que hablaremos en más detalle en los próximos días:

Las metas de KDE para el futuro

Ahora les toca a los responsables de las propuestas concretarlas para poder organizar el trabajo a realizar. Si creéis que podéis aportar vuestro granito de arena en alguna, como por ejemplo escribiendo documentación para ayudar a nuevos colaboradores, haced seguimiento de las propuestas en Phabricator.

Las perdedoras

El plan es repetir el proceso de selección de metas cada año para seleccionar 1 o 2 metas que añadir. Por lo tando, y aunque no han sido seleccionadas este año, combiene tener en cuenta el resto de propuestas presentadas que podrían volver a presentarse el año que viene:

Además, no olvidemos que cada colaborador decide en qué trabaja, y que una propuesta no haya sido seleccionada no significa que no se vaya a trabajar en ella, simplemente que la comunidad en su conjunto no la considera una de sus prioridades este año.


¿Y tú? ¿Vas a colaborar en las propuestas seleccionadas? ¿Habrías preferido que ganasen otras propuestas? ¿Habrías hecho alguna propuesta distinta? ¿Presentarás una propuesta el año que viene?

KDE Partition Manager 3.3 is now ready. It includes some improvements for Btrfs, F2FS, NTFS file systems. I even landed the first bits of new LUKS2 on-disk format support, now KDE Partition Manager can display LUKS2 labels. More LUKS2 work will follow in KPM 3.4. There were changes in how LVM devices are detected. So now Calamares installer should be able to see LVM logical volumes. Once my pull request lands, Calamares should also support partitioning operations on LVM logical volumes (although Calamares would need more work before installation and booting from root file system on LVM works). KPMcore library now only depends on Tier 1 Frameworks instead of Tier 3 (although, we will later require Tier 2).

Most of the work is now done in sfdisk branch.  Currently, the only functional KDE Partition Manager backend uses libparted but sfdisk backend is now fully working (I would say RC quality). I would have merged in already but it requires util-linux 2.32 which is not yet released.

Yet another branch on top of sfdisk is KAuth branch which allows KPM to run as unprivileged user and uses Polkit when necessary to gain root rights. Everything except SMART support is working. To get SMART working too we would have to port away from (unmaintained) libatasmart to calling smartctl. Feel free to help! It should be fairly easy task but somebody has to do the work. Other than that you can already perform all partitioning operations using KAuth with one caveat. Right now KPM calls KAuth helper many times while performing partitioning operations. It can happen that KAuth authorization will expire in the meantime (KAuth remembers it for about 5 minutes) and KAuth will request a user to enter root password. If the user enters correct password, operation would finish. However, if authorization is not granted we may end up with half completed operation. And of course we don’t want to leave partition half moved, the data will almost surely be lost (half-resized partition is probably okay…). I suppose we can fix this by refactoring KPM operation runner, so that it calls KAuth helper just once with a list of all commands that have to be run. Unfortunately, this KPM Operation Runner refactoring might be bigger than what I would like, as significant changes would be necessary in partition data copying code. Maybe GSoC project then… Or ar there any better ideas on how to prevent KAuth authorization dialog in the middle of partitioning operations?

You can grab tarballs from standard locations on download.kde.org server.

December 14, 2017

Elisa is a music player designed to be simple and nice to use. It allows to browse music by album, artist or all tracks. You can build and play your own playlist. We aim to build a fluid interface that is easy to use.

Alexander has made yet another round of improvements to the UI and especially improved a lot the playlist by making it more fluid. It really feels much better now (at least for me).

I have added the possibility to load or save playlists. It is currently restricted to tracks already known to Elisa. More work is needed to support any audio files.

Screenshot_20171214_212504Current state of the interface.

The following things have been integrated in Elisa git repository:

  • delete outdated todo list by Alexander Stippich ;
  • fix player being stuck when same track is played in random mode by Matthieu Gallien ;
  • enhance content view navigation by Alexander Stippich:
    • The backspace key is now also accepted for back navigation in e.g. the artist album view ;
    • A mouse area is added to MediaBrowser to allow back navigation with the mouse backbutton ;
    • Focus is forced on the stackview when arist or album is opened. Without this, the back key navigation is only working when it is actively focused by the user, e.g. by a mouse click ;
  • deduplicate code for the content view and adjust visual appearance by Alexander Stippich ;
  • merge MediaPlayList and PlayListControler to reduce size of code by Matthieu Gallien ;
  • make margins consistent and remove horizontal separator in playlist by Alexander Stippich ;
  • show passive notification when a track fail to play by Matthieu Gallien ;
  • remove context menus by Alexander Stippich ;
  • overhaul RatingStar by Alexander Stippich ;
  • add possibility to load and save a playlist at format m3u from two buttons at bottom of playlist by Matthieu Gallien ;
  • fix problems with dependencies and make some optional ones be required. Require all tier1 dependencies if they are also supported on Windows and
    Android by Matthieu Gallien ;
  • more improvements to playlist by Alexander Stippich:
    • Some more improvements to the playlist. First of all, adds more animations and fixes T6295.
    • Fixes some scaling issues and makes Show Current Track also select the item to highlight it better.
    • Converts actions to use signals
  • shorten the play now and replace play list button text by Alexander Stippich;
  • add a readme for packagers following some feedback in #kde-devel by Matthieu Gallien ;

ElementaryIcons.png

Two months ago I start to finalize the existing Elementary icon theme for LibreOffice. It’s about 2.000 icons and now they are available in LibreOffice 6.0 beta. In addition all icons are available as svg file so it can be used and edit in an easy way.

Please download and test LibreOffice 6.0 beta to give feedback. You switch the icon theme with Tools -> Options -> View -> Icon Style. We talk about a lot icons not all are perfect. Feedback is always welcome.

Test LibreOffice 6.0 beta

Mary Christmas and an shiny new year with LibreOffice 6.0.

 

 


En realidad hay muchas más, pero hoy quiero compartir las 7 trucos para el escritorio Plasma de KDE que ha recopilado Average Linux User en su canal de Youtube y que seguro que mejoran la experiencia de uso de nuestro PC.

7 trucos para el escritorio Plasma de KDE

A lo largo de casi 8 minutos nos presentan algunas de las muchas bondades del escritorio Plasma de KDE, así cómo solucionar algunos detalles que cualquier usuario pueda querer adaptar más a sus necesidades.

De esta forma sus 7 trucos para el escritorio Plasma de KDE son los siguientes:

  1. 7 trucos para el escritorio Plasma de KDELa utilización del simple click, doble click y como cambiar su comportamiento.
  2. Modificar el aspecto de los mensajes emergentes de las aplicaciones GTK en Plasma, algo de lo que ya hablamos hace un tiempo en el blog.
  3. Personalización de dónde se abren las nuevas: aleatoriamente, en el centro, de forma inteligente, bajo en ratón, etc.
  4. Mejora de la velocidad al realizar el scroll en las aplicaciones Qt.
  5. Añadir enlaces directos a la ventana de Lugares de Dolphin.
  6. Cambiar el conmutador de ventanas a cambio en rueda, iconos o cualquier otro.
  7. Posibilidad de restaurar la sesión anterior para seguir trabajando aunque reinicies el ordenador o dejarla en blanco, recomendado para aquellos Plasma que se utilicen en sitios públicos.

¿Los conocías todos? ¿Tienes otros que utilices para adaptar tu sistema? No te cortes y ponlo en los comentarios, seguro que le vendrán bien a alguno de los lectores del blog y te lo agradecerá.

Además, aprovecho la ocasión para comentar que Average Linux User tiene una magnífica lista de reproducción en la que nos está explicando como afinar mejor la experiencia de uso ya que nos explica como configurar mejor Dolphin o utilizar los increíbles  service menu, así como utilizar imágenes personalizadas en cada cuenta de usuario.

 

 

 

December 13, 2017

Introduction

In the previous article we gave an overview of the process for creating a custom aspect and showed how to create (most of) the front end functionality. In this article we shall continue building our custom aspect by implementing the corresponding backend types, registering the types and setting up communication from the frontend to the backend objects. This will get us most of the way there. The next article will wrap up by showing how to implement jobs to process our aspect's components.

As a reminder of what we are dealing with, here's the architecture diagram from part 1:

Creating the Backend

One of the nice things about Qt 3D is that it is capable of very high throughput. This is achieved by way of using jobs executed on a threadpool in the backend. To be able to do this without introducing a tangled web of synchronisation points (which would limit the parallelism), we make a classic computer science trade-off and sacrifice memory for the benefit of speed. By having each aspect work on its own copy of the data, it can schedule jobs safe in the knowledge that nothing else will be trampling all over its data.

This is not as costly as it sounds. The backend nodes are not derived from QObject. The base class for backend nodes is Qt3DCore::QBackendNode, which is a pretty lightweight class. Also, note that aspects only store the data that they specifically care about in the backend. For example, the animation aspect does not care about which Material component an Entity has, so no need to store any data from it. Conversely, the render aspect doesn't care about Animation clips or Animator components.

In our little custom aspect, we only have one type of frontend component, FpsMonitor. Logically, we will only have a single corresponding backend type, which we will imaginatively call FpsMonitorBackend:

[sourcecode lang="cpp" title="fpsmonitorbackend.h"]
class FpsMonitorBackend : public Qt3DCore::QBackendNode
{
public:
FpsMonitorBackend()
: Qt3DCore::QBackendNode(Qt3DCore::QBackendNode::ReadWrite)
, m_rollingMeanFrameCount(5)
{}

private:
void initializeFromPeer(const Qt3DCore::QNodeCreatedChangeBasePtr &change) override
{
// TODO: Implement me!
}

int m_rollingMeanFrameCount;
};
[/sourcecode]

The class declaration is very simple. We subclass Qt3DCore::QBackendNode as you would expect; add a data member to mirror the information from the frontend FpsMonitor component; and override the initializeFromPeer() virtual function. This function will be called just after Qt 3D creates an instance of our backend type. The argument allows us to get at the data sent from the corresponding frontend object as we will see shortly.

Registering the Types

We now have simple implementations of the frontend and backend components. The next step is to register these with the aspect so that it knows to instantiate the backend node whenever a frontend node is created. Similarly for destruction. We do this by way of an intermediary helper known as a node mapper.

To create a node mapper, just subclass Qt3DCore::QNodeMapper and override the virtuals to create, lookup and destroy the backend objects on demand. The manner in which you create, store, lookup and destroy the objects is entirely up to you as a developer. Qt 3D does not impose any particular management scheme upon you. The render aspect does some fairly fancy things with bucketed memory managers and aligning memory for SIMD types, but here we can do something much simpler.

We will store pointers to the backend nodes in a QHash within the CustomAspect and index them by the node's Qt3DCore::QNodeId. The node id is used to uniquely identify a given node, even between the frontend and all available aspect backends. On Qt3DCore::QNode the id is available via the id() function, whereas for QBackendNode you access it via the peerId() function. For the two corresponding objects representing the component, the id() and peerId() functions return the same QNodeId value.

Let's get to it and add some storage for the backend nodes to the CustomAspect along with some helper functions:

[sourcecode lang="cpp" title="customaspect.h"]
class CustomAspect : public Qt3DCore::QAbstractAspect
{
Q_OBJECT
public:
...
void addFpsMonitor(Qt3DCore::QNodeId id, FpsMonitorBackend *fpsMonitor)
{
m_fpsMonitors.insert(id, fpsMonitor);
}

FpsMonitorBackend *fpsMonitor(Qt3DCore::QNodeId id)
{
return m_fpsMonitors.value(id, nullptr);
}

FpsMonitorBackend *takeFpsMonitor(Qt3DCore::QNodeId id)
{
return m_fpsMonitors.take(id);
}
...

private:
QHash<Qt3DCore::QNodeId, FpsMonitorBackend *> m_fpsMonitors;
};
[/sourcecode]

Now we can implement a simple node mapper as:

[sourcecode lang="cpp" title="fpsmonitorbackend.h"]
class FpsMonitorMapper : public Qt3DCore::QBackendNodeMapper
{
public:
explicit FpsMonitorMapper(CustomAspect *aspect);

Qt3DCore::QBackendNode *create(const Qt3DCore::QNodeCreatedChangeBasePtr &change) const override
{
auto fpsMonitor = new FpsMonitorBackend;
m_aspect->addFpsMonitor(change->subjectId(), fpsMonitor);
return fpsMonitor;
}

Qt3DCore::QBackendNode *get(Qt3DCore::QNodeId id) const override
{
return m_aspect->fpsMonitor(id);
}

void destroy(Qt3DCore::QNodeId id) const override
{
auto fpsMonitor = m_aspect->takeFpsMonitor(id);
delete fpsMonitor;
}

private:
CustomAspect *m_aspect;
};
[/sourcecode]

To finish this piece of the puzzle, we now need to tell the aspect about how these types and the mapper relate to each other. We do this by calling QAbstractAspect::registerBackendType() template function, passing in a shared pointer to the mapper that will create, find, and destroy the corresponding backend nodes. The template argument is the type of the frontend node for which this mapper should be called. A convenient place to do this is in the constructor of the CustomAspect. In our case it looks like this:

[sourcecode lang="cpp" title="customaspect.cpp"]
CustomAspect::CustomAspect(QObject *parent)
: Qt3DCore::QAbstractAspect(parent)
{
// Register the mapper to handle creation, lookup, and destruction of backend nodes
auto mapper = QSharedPointer<FpsMonitorMapper>::create(this);
registerBackendType<FpsMonitor>(mapper);
}
[/sourcecode]

And that's it! With that registration in place, any time an FpsMonitor component is added to the frontend object tree (the scene), the aspect will lookup the node mapper for that type of object. Here, it will find our registered FpsMonitorMapper object and it will call its create() function to create the backend node and manage its storage. A similar story holds for the destruction (technically, it's the removal from the scene) of the frontend node. The mapper's get() function is used internally to be able to call virtuals on the backend node at appropriate points in time (e.g. when properties notify that they have been changed).

The Frontend-Backend Communications

Now that we are able to create, access and destroy the backend node for any frontend node, let's see how we can let them talk to each other. There are 3 main times the frontend and backend nodes communicate with each other:

  1. Initialisation — When our backend node is first created we get an opportunity to initialise it with data sent from the frontend node.
  2. Frontend to Backend — Typically when properties on the frontend node get changed we want to send the new property value to the backend node so that it is operating on up to date information.
  3. Backend to Frontend — When our jobs process the data stored in the backend nodes, sometimes this will result in updated values that should be sent to the frontend node.

Here we will cover the first two cases. The third case will be deferred until the next article when we introduce jobs.

Backend Node Initialisation

All communication between frontend and backend objects operates by sending sub-classed Qt3DCore::QSceneChanges. These are similar in nature and concept to QEvent but the change arbiter that processes the changes has the opportunity to manipulate them in the case of conflicts from multiple aspects, re-order them into priority, or any other manipulations that may be needed in the future.

For the purpose of initialising the backend node upon creation, we use a Qt3DCore::QNodeCreatedChange which is a templated type that we can use to wrap up our type-specific data. When Qt 3D wants to notify the backend about your frontend node's initial state, it calls the private virtual function QNode::createNodeCreationChange(). This function returns a node created change containing any information that we wish to access in the backend node. We have to do it by copying the data rather than just dereferencing a pointer to the frontend object because by the time the backend processes the request, the frontend object may have been deleted - i.e. a classic data race. For our simple component our implementation looks like this:

[sourcecode lang="cpp" title="fpsmonitor.h"]
struct FpsMonitorData
{
int rollingMeanFrameCount;
};
[/sourcecode]

[sourcecode lang="cpp" title="fpsmonitor.cpp"]
Qt3DCore::QNodeCreatedChangeBasePtr FpsMonitor::createNodeCreationChange() const
{
auto creationChange = Qt3DCore::QNodeCreatedChangePtr<FpsMonitorData>::create(this);
auto &data = creationChange->data;
data.rollingMeanFrameCount = m_rollingMeanFrameCount;
return creationChange;
}
[/sourcecode]

The change created by our frontend node is passed to the backend node (via the change arbiter) and gets processed by the initializeFromPeer()
virtual function
:

[sourcecode lang="cpp" title="fpsmonitorbackend.cpp"]
void FpsMonitorBackend::initializeFromPeer(const Qt3DCore::QNodeCreatedChangeBasePtr &change)
{
const auto typedChange = qSharedPointerCast<Qt3DCore::QNodeCreatedChange<FpsMonitorData>>(change);
const auto &data = typedChange->data;
m_rollingMeanFrameCount = data.rollingMeanFrameCount;
}
[/sourcecode]

Frontend to Backend Communication

At this point, the backend node mirrors the initial state of the frontend node. But what if the user changes a property on the frontend node? When that happens, our backend node will hold stale data.

The good news is that this is easy to handle. The implementation of Qt3DCore::QNode takes care of the first half of the problem for us. Internally it listens to the Q_PROPERTY notification signals and when it sees that a property has changed, it creates a QPropertyUpdatedChange for us and dispatches it to the change arbiter which in turn delivers it to the backend node's sceneChangeEvent() function.

So all we need to do as authors of the backend node is to override this function, extract the data from the change object and update our internal state. Often you will then want to mark the backend node as dirty in some way so that the aspect knows it needs to be processed next frame. Here though,
we will just update the state to reflect the latest value from the frontend:

[sourcecode lang="cpp" title="fpsmonitorbackend.cpp"]
void FpsMonitorBackend::sceneChangeEvent(const Qt3DCore::QSceneChangePtr &e)
{
if (e->type() == Qt3DCore::PropertyUpdated) {
const auto change = qSharedPointerCast<Qt3DCore::QPropertyUpdatedChange>(e);
if (change->propertyName() == QByteArrayLiteral("rollingMeanFrameCount")) {
const auto newValue = change->value().toInt();
if (newValue != m_rollingMeanFrameCount) {
m_rollingMeanFrameCount = newValue;
// TODO: Update fps calculations
}
return;
}
}
QBackendNode::sceneChangeEvent(e);
}
[/sourcecode]

If you don't want to use the built in automatic property change dispatch of Qt3DCore::QNode then you can disable it by wrapping the property notification signal emission in a call to QNode::blockNotifications(). This works in exactly the same manner as QObject::blockSignals() except that it only blocks sending the notifications to the backend node, not the signal itself. This means that other connections or property bindings that rely upon your signals will still work.

If you block the default notifications in this way, then you need to send your own to ensure that the backend node has up to date information. Feel free to subclass any class in the Qt3DCore::QSceneChange hierarchy and bend it to your needs. A common approach is to subclass Qt3DCore::QStaticPropertyUpdatedChangeBase,
which handles the property name and in the subclass add a strongly typed member for the property value payload. The advantage of this over the built-in mechanism is that it avoids using QVariant which does suffer a little in highly threaded contexts in terms of performance. Usually though, the frontend properties don't change too frequently and the default is fine.

Summary

In this article we have shown how to implement most of the backend node; how to register the node mapper with the aspect to create, lookup and destroy backend nodes; how to initialise the backend node from the frontend node in a safe way and also how to keep its data in sync with the frontend.

In the next article we will finally make our custom aspect actually do some real (if simple) work, and learn how to get the backend node to send updates to the frontend node (the mean fps value). We will ensure that the heavy lifting parts get executed in the context of the Qt 3D threadpool so that you get an idea of how it can scale. Until next time. continue reading

The post Writing a Custom Qt 3D Aspect – part 2 appeared first on KDAB.

December 12, 2017

This is a little blog post from India. I’ve been invited to give not one, but two talks at Swatantra 2017, the triennial conference organised by ICFOSS in Thiruvananthapuram (also known by its shorter old name, Trivandrum), Kerala.

I’ll have the pleasure to give a talk about GCompris, and another one about Synfig studio. It’s been a long time since I didn’t talk about the latter, but since Konstantin Dmitriev and the Morevna team were not available, I’ll do my best to represent Synfig there.





(little teaser animation of the event banner, done with Synfig studio)

I’ll also meet some friends from Krita, David Revoy and Raghavendra Kamath, so even if there is no talk dedicated to Krita, it should be well represented.

The event will happen the 20th and 21st of December, and my talks will be on the second day. Until then, I’m spending a week visiting and enjoying the south of India.

You can find more info on the official website of the event: swatantra.net.in. Many thanks again to the nice organization team at ICFOSS for the invitation !

December 11, 2017

Two months ago I attended to KDE Edu Sprint 2017 at Berlin. It was my first KDE sprint (really, I send code to KDE software since 2010 and never went to a sprint!) so I was really excited for the event.

KDE Edu is the an umbrella for specific educational software of KDE. There are a lot of them and it is the main educational software suite in free software world. Despite it, KDE Edu has received little attention in organization side, for instance the previous KDE Edu sprint occurred several years ago, our website has some problems, and more.

Therefore, this sprint was an opportunity not only for developers work in software development, but for works in organization side as well.

In organization work side, we discuss about the rebranding of some software more related to university work than for “education” itself, like Cantor and Labplot. There was a wish to create something like a KDE Research/Science in order to put software like them and others like Kile and KBibTex in a same umbrella. There is a discussion about this theme.

Other topic in this point was the discussions about a new website, more oriented to teach how to use KDE software in educational context than present a set of software. In fact, I think we need to do it and strengthen the “KDE Edu brand” in order to have a specific icon+link in KDE products page.

Follow, the developers in the sprint agreed with the multi operating system policy for KDE Edu. KDE software can be built and distributed to users of several OS, not only Linux. During the sprint some developers worked to bring installers for Windows, Mac OS, porting applications to Android, and creating independent installers for Linux distributions using flatpak.

Besides the discussions in this point, I worked to bring a rule to send e-mail to KDE Edu mailing list for each new Differential Revisions of KDE Edu software in Phabricator. Sorry devs, our mailboxes are full of e-mails because me.

Now in development work side, my focus was work hard on Cantor. First, I made some task triage in our workboard, closing, opening, and putting more information in some tasks. Secondly, I reviewed some works made by Rishabh Gupta, my student during GSoC 2017. He ported the Lua and R backend to QProcess and it will be available soon.

After it I worked to port Python 3 backend to Python/C API. This work is in progress and I expect to finish it to release in 18.04.

Of course, besides this amount of work we have fun with some beers and German food (and some American food and Chinese food and Arab food and Italian food as well)! I was happy because my 31 years birthday was in the first day of the sprint, so thank you KDE for coming to my birthday party full of code and good beers and pork dishes. ��

To finish, it is always a pleasure to meet the gearheads like my Spanish friends Albert and Aleix, the only other Mageia user I found personally in my life Timothée, my GSoC student Rishabh, my irmão brasileiro Sandro, and the new friends Sanjiban and David.

Thank you KDE e.V for provide resources to the sprint and thank you Endocode for hosting the sprint.

A software developer's life can get lonely. Developers spend a lot of time immersed in their code, and often don't get to see the direct impact of their work on the users. That is why events like Randa Meetings are necessary. They help build bonds within the community and show the developers that their work is appreciated.

Randa Meetings are crucial to the KDE community for developer interaction, brainstorming, and bringing great new things to KDE. --- Scarlett Clark

Randa Meetings are a yearly collection of KDE Community contributor sprints that take place in Randa, Switzerland. With origins dating back to a Plasma meeting in 2009, Randa is one of the most important developer-related events in the community.


View from Randa. Photo by Gilles Caulier, CC BY 2.0

This year, Randa Meetings were held from September 10 to September 16, and were centered around a meaningful theme - accessibility.

Accessibility in Free and Open Source Software

Accessibility is incredibly important, yet so often neglected in the process of software development, and implemented almost as an afterthought. Users with disabilities and impairments often find themselves excluded from using the software, and prevented from participating in activities that the rest of us take for granted. Essentially, the software makes them feel as if they don't matter.

To remedy this, many governments enforce laws requiring software to be accessible. There are also accessibility standards, guidelines, and checklists to help developers make their software accessible to all.

FOSS communities and projects have the potential to play a major role in driving software accessibility efforts because of their open nature. People with disabilities can communicate directly with developers, report issues, and request features that they need. Proprietary products are rarely this open to feedback, not to mention the fact they are often very expensive.


Accessibility Settings module in Plasma 5

Assistive technology covers a wide range of products and solutions: from screen magnifiers, screen readers, and text prediction methods to text-to-speech interfaces, speech recognition software, and simplified computer interfaces. There are also advanced solutions like 3D-printed prosthetic limbs, and those that allow controlling the mouse by moving the head or just the eyes.

The best thing about all this technology is that it benefits everyone. Although people usually associate the word "accessibility" with hearing or visually impaired people, assistive technology can make life easier for many other groups: dyslexic or illiterate people, cognitively disabled people, the elderly, anyone with limited mobility or just bad eyesight.

The analogy is clear with wheelchair-accessible spaces, which are useful to parents with baby strollers, people with bicycles and shopping carts, and delivery drivers. Likewise, improving keyboard navigation, image and color contrast, and text-to-speech tools results in satisfaction among non-disabled users. Making software accessible means making software better.

Making KDE Software More Accessible

Generally speaking, there are two ways to make software accessible: either by building special accessibility-focused tools from scratch, or by implementing accessibility features and improvements into existing applications. The latter is what the Randa Meetings 2017 were all about.


digiKam with David Edmundson from Plasma in the background.
Photo by Gilles Caulier, CC BY 2.0

The developers created a useful KWin plugin that can simulate different types of color blindness. This will help in all future accessibility efforts, as it helps developers understand what their color schemes will look like to visually impaired users.

KMyMoney was made more accessible via improvements to keyboard navigation. New keyboard shortcuts were added, and others simplified to make them easier to use.

Randa Meetings 2017 were made special by Manuel, a visitor from Italy who stayed at the Randa house during the sprint. Manuel is a deaf user, and he took the time to explain the problems that hearing-impaired users encounter with KDE software, and software in general. His feedback was extremely valuable in the context of the sprint's theme, and helped developers come up with accessibility-oriented solutions.

Meeting in Randa with other participants makes you aware of deficiencies, possibilities, and needs. For a newcomer, like myself, it was also a chance to meet some community members, see what kind of people build KDE software, and take a look behind the scenes. --- Lukasz Wojnilowicz

Apart from fixing individual applications, a lot of work was done on the Plasma desktop environment itself. Accessibility-related improvements include the ability to navigate the Plasma panel using voice feedback and the keyboard. The following video demonstrates this feature in action:

KRunner was made completely accessible, and this change is visible in Plasma 5.11. The Orca Screen Reader works well with KRunner, and can read the entered query, as well as let the user know which element of the interface is currently focused.

There was also a round of discussions on best practices for accessibility in KDE software. When testing software, the developers should try to use it only with their keyboard, and then only with the mouse. Too much customization is not a good idea, so it should be avoided, especially when it comes to colors, fonts, and focus handling.

Another good practice is to test the application with a screen reader. This experience should highlight potential issues for disabled users. In the end, it all comes down to empathy - being able to put yourself in the user's shoes, and the willingness to make your software available to as many people as possible, without excluding anyone.

More Plans and Achievements from the Randa Meetings 2017

Of course, the developers worked on so much more than just accessibility. The KDE PIM team discussed the results of their KMail User Survey, and tackled the most pressing issue reported by the uses - broken and unreliable search. They also ported the entire Kontact codebase away from the obsolete KDateTime component.


Lukasz Wojnilowicz from KMyMoney and Volker Krause
from KDE PIM. Photo by Gilles Caulier, CC BY 2.0

KMyMoney saw some important changes. All plugin KCM modules were ported to KF5. The backup feature is, well, back up and available to use, and database loading was improved so as to prevent the incompatibility between new and old KMyMoney files.

After successfully participating in Google Summer of Code, the digiKam team gathered in Randa to further polish the new code contributed by students. They also worked on the media server functionality, which allows users to share their photo collections across different devices (smartphones, tablets, TVs...) using DLNA.


Scarlett Clark (KDE CI), Emmanuel LePage (Ring), Simon Frei
(digiKam) and David Edmundson discussing Plasma Accessibility.
Photo by Gilles Caulier, CC BY 2.0

Marble Maps now has a new splash screen, and the entire interface of the Bookmarks dialog is responsive to touch. There are plans to implement a better text-to-speech module for navigation.

The Public Transport Plasma applet has been completely rewritten as a Kirigami application. The applet's UI is now much more flexible and easier to adapt to mobile devices.

The developers of Kube worked on resolving an annoying issue with live queries which slows down email synchronization, especially when there are thousands of emails. They also discussed the possibility of implementing an HTML composer to edit emails in Kube, and made plans for GPG implementation. In collaboration with developers from other KDE projects, they explored the options for making Kube cross-platform, and looked for the best way to build Kube on macOS and Windows. Finally, they implemented a visualization in the configuration dialog which indicates when the user input is invalid in configuration fields.

Last but not least, Kdenlive received color correction improvements, and the developers worked on bringing back the popular TypeWriter effect. They also fixed the import of image sequences, worked on porting Kdenlive to Windows and macOS, and removed the warning about missing DVD tools that used to appear when starting Kdenlive for the first time.

Looking Forward to the Next Randa Meetings

With another successful Randa Meetings behind us, we can start planning for the next session.

If you like the work our developers are doing, you can directly support it by donating to KDE. You can also contribute to KDE and make an impact on the users by joining our mentored project called Season of KDE.

Who knows, maybe in the future you too will attend the Randa Meetings!

Could you tell us something about yourself?

I’m Rytelier, a digital artist. I’ve had an interest in creating art for a few years, I mainly want to visualize my original world.

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

Currently I do only personal work, but I will look for some freelance job in the future.

What genre(s) do you work in?

I work mainly in science fiction – I’m creating an original world. I like to try various things, from creatures to landscapes and architecture. There are so many things to design in this world.

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

It’s hard to point out certain artists, there are so many. Mainly I get inspired by fantasy art from the internet, I explore various websites to find interesting art.

I recommend looking at my favourites gallery, there are many works that inspire me.

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

It was years ago, I’ve got interested in the subject after I saw other people’s work. It was obviously confusing, how to place strokes, how to mix colors, and I had to get used to not looking at my hand when doing something on the tablet.

What makes you choose digital over traditional painting?

I like the freedom and flexibility that digital art gives. I can create a variety of textures, find colors more easily and fix mistakes.

How did you find out about Krita?

I saw a news item about Krita on some website related to digital art and decided to try it.

What was your first impression?

I liked how many interesting brushes there were. As time went on I discovered more useful features. It was surprising to find out that some functions aren’t available in Photoshop.

What do you love about Krita?

It has many useful functions and very high user convenience. I love the brush editor – it’s clean and simple to understand, but powerful. The dynamics curve adjustment is useful, the size dependent brush with sunken curve allows me to paint fur and grass more easily.

Also different functional brush engines. Color smudge is nice for more traditional work, like mixing wet paint. Shape brush is like a lasso, but better because it shows the shape instantly, without having to use the fill tool. Filter brush is nice too, I mainly use it as sharpen and customizable burn/dodge. There are also ways to color line art quickly. For a free program that functionality is amazing — it would be amazing even for a paid program! I like this software much more than Photoshop.

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

The performance is the thing I most want to see improved for painting and filters. I’m happy to see multi-threaded brushes in the 4.0 version. Also I would like more dynamic preview on applying filters like the gradient map, where it updates instantly when moving the color on the color wheel. It annoys me that large brush files (brushes with big textures) don’t load, I
have to optimize my textures by reducing the size so the brush can load.

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

The amount of convenience is very high compared to other programs. The amount of “this one should be designed in a better way, it annoys me” things is the smallest of all the programs I use, and if something is broken, then most of these functions are announced to improve in 4.0.

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

It’s hard to pick a favourite. I think this, because I challenged myself in this picture and they are my original character, which I like a lot.

What techniques and brushes did you use in it?

I use brushes that I’ve created myself from resources found on the internet and pictures scanned by myself. I like to use slightly different ways of painting in every artwork, still looking for techniques that suit me best. Generally I start from sketch, then paint splatter going all over the canvas, then adding blurry forms, then adding details. Starting from soft edges allows me to find good colors more easily.

Where can people see more of your work?

https://rytelierart.deviantart.com/
I will open galleries in other sites in the future.

Anything else you’d like to share?

I hope that Krita will get more exposure and more people, including professionals, will use it and will donate to its development team instead of buying expensive digital art programs. Open source software is having a great time, more and more tools are being created that replace these expensive ones in various categories.

December 10, 2017

Today’s daily ISO for Bionic Beaver 18.04 sees an experimental switch to the Breeze-Dark Plasma theme by default.

Users running 18.04 development version who have not deliberately opted to use Breeze/Breeze-Light in their systemsettings will also see the change after upgrading packages.

Users can easily revert back to the Breeze/Breeze-Light Plasma themes by changing this in systemsettings.

Feedback on this change will be very welcome:

You can reach us on the Kubuntu IRC channel or Telegram group, on our user mailing list, or post feedback on the (unofficial) Kubuntu web forums

Thank you to Michael Tunnell from TuxDigital.com for kindly suggesting this change.

December 09, 2017

The Elisa team is happy to release the first alpha release of a future 0.1 version of the Elisa music player.

Screenshot_20171207_231959

Elisa is a music player designed to be simple and nice to use.

Elisa allows to browse music by album, artist or all tracks. The music is indexed using either a private indexer or an indexer using Baloo. The private one can be configured to scan music on chosen paths. The Baloo one is much faster because Baloo is providing all needed data from its own database. You can build and play your own playlist.

It is available in source form only at https://download.kde.org/unstable/elisa/0.0.80/elisa-0.0.80.tar.xz. KDE also provides regular flatpak and windows builds. The windows builds are provided by binary-factory.kde.org and are using Craft. Thanks to the people in the flatpak and windows teams. A binary package is provided for Fedora thanks to Robert-André Mauchin. Other Linux distributions may provide binary packages from the git repository (as far as I know, there is an AUR package and a package for Neon).

The development is still continuing and we will regularly release an alpha version until we have completed review by other KDE developers. We plan to move to kdereview as soon as we have finished a few missing features.

For the curious reader, the phabricator workboard of Elisa is a good way to know what is happening (https://phabricator.kde.org/project/board/193/).

Any help is very much welcome. We have open tasks for code but also for design.


December 08, 2017

Another month passed, just like that. I spent last week holed up with some KDE people in the hills, watching the snow come down. While they did impressive things to the KDE codebase, I hacked on Calamares. Since my last post on the topic, I’ve been running a roughly every-other-week release schedule for the Calamares 3.1-stable branch. We’ve just reached 3.1.10. The reason for these stable releases is small bugfixes, minor polishing, and occasional non-interfering features.

Each release is announced on the Calamares site, and can be found on the Calamares GitHub page.

Calamares isn’t a KDE project, and aims to support whatever Linux distro wants to use it, and to configure the stuff that is needed for that distro. But when feature requests show up for KDE integration, there’s no special reason for me to reject them — as long as things can remain modular, the SKIP_MODULES mechanism in Calamares can avoid unwanted KDE Frameworks dependencies.

One new module in development is called “Plasma Look-and-Feel” (plasmalnf) and the purpose there is to configure the look-and-feel of Plasma. No surprise there, but ther point is that this can be done during installation, before Plasma is started by the (new) user on the target system. So kind of like the Look-and-Feel KCM, but entirely outside of the target environment. The UI is more primitive, more limited, but that’s the use-case that was asked for. I’d like to thank the Plasma developers for helping out with tooling and guiding me through some of the Plasma code, and deployers of Calamares (that is, distro’s) can look forward to this feature in the 3.2 series.

Speaking of Calamares 3.2, I’m intending to put out an RC fairly soon, with the features as developed so far. There will probably be a few RCs each of which integrates a new feature branch (e.g. a giant requirements-checking rewrite) with 3.2.0 showing up for real in the new year.

December 07, 2017

We’re now running a Kube program with Kolab Now where you can get a basic Kolab Now account now, and see it’s features grow together with Kube, while the price remains the same. To take advantage of that offer, install the Kolab Now flatpak and signup through Kube.

  • Fixed a problem where emails with a header larger than 8kb would not be parsed correctly.
  • Added a Kolab Now signup capability to the Kolab Now settings.
  • Added merging of log entries of the same type so you don’t end up with multiple errors.
  • Added a dedicated error view for some classes of errors: Blogpost
  • Added support for PGP encryption: Blogpost
  • Fixed opening of attachments in the flatpak(s) (/tmp needed to be shared with the host system).
  • Added a dockercontainer to the kube repository that is used for CI and can be used for development.
  • Added ASAN and LSAN checkers (LLVM based memory/leak checkers) to sink and fixed various related issues.
  • Created a stresstest for sink which allows to continously run synchronizations and queries. This is used to trigger hard to find crashes.

Kube Commits, Sink Commits

Previous updates

More information on the Kolab Now blog!

“Kube is a modern communication and collaboration client built with QtQuick on top of a high performance, low resource usage core. It provides online and offline access to all your mail, contacts, calendars, notes, todo’s and more. With a strong focus on usability, the team works with designers and UX experts from the ground up, to build a product that is not only visually appealing but also a joy to use.”

For more info, head over to: kube.kde.org


December 05, 2017

We are happy to release a new SDDM with a few improvements.

SDDM is a Qt based graphical login manager developed in a collaborative fashion by people from Liri, KDE and LXQt.

This new version include the following changes:

* Added possibility to change border width of ComboBox widget.
* Added missing utmp/wtmp/btmp handling.
* Make greeter see icons set by AccountsServices.
* Fix sddm.conf man page syntax error and update.
* Fix ComboBox widget.
* Fix connection of PropertiesChanged event for LogindSeat.
* Avoid race conditions with Xsetup.
* Update de translation.
* Update lt translation.
* Update zh_TW translation.
* Adjust order of components in the default PATH.
* Set default input method to qtvirtualkeyboard.


Download it here.

While it is possible to draw scenes with almost unlimited numbers of lights using deferred rendering in Qt 3D, the default materials in Qt 3D Extras have been limited to eight lights because they are tied to forward rendering. Although we apply a few tricks that allow you to define more than eight lights in the scene, we only select the eight closest lights when rendering.

In the scene below, we have defined 100 lights that float around, but because only 8 of them are in use at the time and you can see how they pop in and out:

Although it’s possible to support more lights in other pipelines (this is for instance the case with the Qt 3D Studio Runtime), we also want the default materials in Qt 3D Extras to be able to use a larger number of lights, even when used with forward rendering.

The reason behind the current limit is that we need to support a range of OpenGL architectures, including some which are quite limited in terms of how much uniform data can be passed to the shader. We therefore need to pass a small array of light structs to the shader and loop over the lights in the fragment shader. Unfortunately, such loops are also very expensive on hardware with limited resources because they compile to a large number of shader program instructions. Sometimes so many that the resulting shader program won’t compile at all.

We have therefore started work on a solution that will both allow us to increase the number of lights on beefy hardware and at the same time reduce the number of shader program instructions on weaker hardware. It is based on Qt 3D’s new internal shader graph, which was recently introduced by Kevin Ottens from KDAB.

The shader graph is a game changer for Qt 3D. It allows us to build shaders dynamically with a structure similar to the material graphs you find in many modern 3D modeling applications. Each node in the graph can be thought of as a function – it is defined as a computation, takes a set of input values, and produces output values. For instance, a surface node can take the incoming and outgoing angles of light, the light color, and the surface color, and compute the resulting light contribution. By connecting nodes in the graph, you define the flow of computations in the shader program, which is translated to instructions in a programming language. Because all the computations are abstract, they can easily be translated to many different shader languages (or dialects), making it trivial to produce the same material definitions for different architectures.

In terms of increasing the number of lights, the great thing about the shader graph is that we can easily define a shader node for each of the lights in the scene. The graph then results in the right number of light calculations when converted to shader code. Instead of having a for loop inside the shader itself, we loop over the lights when the shader is generated. This is basically unrolling the old loop, which is way more efficient and allows us to have a much higher number of lights.

I am currently working on a prototype where we have moved the lighting system on top of the shader graph. While this work is still highly experimental, it is already producing some promising results. Here’s the same scene as above, but this time we are actually seeing 100 lights in use at the same time:

Before this becomes part of the default materials in Qt 3D Extras, we also want to change how lights are gathered in a scene and passed on to the shaders. Currently, the light gathering is tightly coupled with the rendering code, but we want to reduce the number of assumptions we make and give you more control over how light information is passed to your shaders. In turn, this will also make it easier to create applications that can switch between rendering modes, for instance if you want to support both forward and deferred rendering of the same scene

If this sounds interesting for your applications, feel free to share thoughts on how you would like to work with lights in your code.

The post Increasing the number of lights in Qt 3D appeared first on Qt Blog.

December 03, 2017

The KTextEditor Framework uses the syntax highlighting files provided by the KSyntaxHighlighting Framework since the  KDE Frameworks release 5.28.

The KSyntaxHighlighting Framework implements Kate’s highlighting system and meanwhile is used in quite some applications (e.g. LabPlot, KDE PIM). What is quite nice is that the KSyntaxHighlighting framework is nicely unit tested. And while we do not have tests for all highlighting files, we still provide some quality assurance through a compile time checker.

How does it work? Well – in former times, Kate loaded all highlighting .xml files from disk (through the KTextEditor framework). This lead to a slow startup over time, since there are >250 .xml files that needed a stat system call at startup.

With the KSyntaxHighlighting Framework, all these xml files are compiled into a Qt resource (qrc file), that then is included into the KSyntaxHighlighting library.

In order to create the Qt resource file, we need to iterate over all available xml files anyways. So what happens is that we take this opportunity and also scan the highlighting files for common mistakes.

As of today, we are checking the following:

  1. RegExpr: A warning is raised, if a regular expression has syntax errors.
  2. DetectChars: A warning is raised, if the char=”x” attribute contains more or less than one character, e.g. when char=”xyz”, or char=”\\” (no escaping required), or similar.
  3. Detect2Chars: Same as DetectChars, just for char=”x” and char1=”y”.
  4. Keyword lists: A warning is raised, if a keyword entry contains leading or trailing spaces. Additional trimming just takes time.
  5. Keyword lists: A warning is raised if a keyword list is unused.
  6. Keyword lists: A warning is raised if multiple keyword lists use the same me (=identifier).
  7. Keyword lists: A warning is raised if a non-existing keyword list is used.
  8. Contexts: A warning is raised, if a non-existing context is referenced.
  9. Contexts: A warning is raised, if a context is unused.
  10. Contexts: A warning is raised, if multiple contexts have the same name (identifier clash).
  11. Attributes: A warning is raised, if non-existing itemData is used.
  12. Attributes: A warning is raised, if multiple itemDatas use the same name (identifier clash).
  13. Attributes: A warning is raised, if an itemData is unused.

This list helps us nicely to catch many mistakes at compile time even before running unit tests.

However, there is still work to do, since some of the files still contain one or more of the above issues. The current todo-list looks as follows (updated on 2017-12-04):

Reference of non-existing keyword list:
- "asp.xml": QSet("Others")
- "template-toolkit.xml": QSet("Others")

Duplicate contexts:
- "diff.xml": "File"
- "objectivecpp.xml": "Preprocessor"

Reference of non-existing itemData attributes:
- "haml.xml": QSet("Array", "Escaped Text", "Ruby embedded in haml")
- "lilypond.xml": QSet("Tremolo")
- "metafont.xml": QSet("Verbatim", "Tex", "Bullet")
- "relaxng.xml": QSet("Entity Reference")
- "rhtml.xml": QSet("RUBY RAILS ERB Text")
- "rmarkdown.xml": QSet("Markdown", "Document Headers")
- "stata.xml": QSet("String2")

Incorrect DetectChar and Detect2Chars:
- "xmldebug.xml" line 130 'char' must contain exactly one char: "\"(\\s+|$)"
- "xmldebug.xml" line 135 'char' must contain exactly one char: "'(\\s+|$)"
- "xmldebug.xml" line 373 'char' must contain exactly one char: "\"(\\s+|$)"
- "xmldebug.xml" line 378 'char' must contain exactly one char: "'(\\s+|$)"
- "xmldebug.xml" line 415 'char' must contain exactly one char: "\"(\\s+|$)"
- "xmldebug.xml" line 420 'char' must contain exactly one char: "'(\\s+|$)"
- "xmldebug.xml" line 467 'char' must contain exactly one char: "\"(\\s+|$)"
- "xmldebug.xml" line 472 'char' must contain exactly one char: "'(\\s+|$)"

Unused contexts:
- "ample.xml": QSet("Preprocessor", "Define")
- "gcc.xml": QSet("GNUMacros")
- "ruby.xml": QSet("RDoc Label")
- "tcsh.xml": QSet("HereDocIQ", "HereDocNQ", "HereDocINQ", "HereDocQ", "FindCommentsParen")
- "xmldebug.xml": QSet("44:Enumeration")

Unused keyword lists:
- "ample.xml": QSet("dvafct", "icprops", "sgfct")
- "ansforth94.xml": QSet("attention")
- "css.xml": QSet("mediatypes_op")
- "dosbat.xml": QSet("not", "else")
- "euphoria.xml": QSet("constants")
- "freebasic.xml": QSet("Assembly Operators")
- "fsharp.xml": QSet("symbols")
- "ilerpg.xml": QSet("pkeywords", "evalopcodes8")
- "metafont.xml": QSet("EnvDelimiters", "notDefined")
- "pango.xml": QSet("int_attributes", "plain_attributes", "endtags", "color_attributes", "tags")
- "pony.xml": QSet("types", "literal")
- "powershell.xml": QSet("operators", "attributes")
- "scss.xml": QSet("mediatypes_op")
- "vhdl.xml": QSet("forOrWhile", "directions")
- "xonotic-console.xml": QSet("Aliases")
- "build/frameworks/syntax-highlighting/data/css-php.xml": QSet("mediatypes_op")
- "prolog.xml": QSet("list+is_list non-ISO", "lists ISO", "listing non-ISO", "directives non-ISO", "lists non-ISO", "terms non-ISO", "streams deprecated")

Fixing these issues is quite some work and sometimes even a bit tricky. So if you want to get your hands dirty, help is always welcome. Please send your patches to us using the syntax-highlighting repository on Phabricator ��

December 01, 2017

It‘s a common usecase to share Files or Content from native Android or iOS Apps with other Apps on your phone. So I thought this would be an easy task to add sharing to my mobile Apps built with QtQuickControls2.

Found the Blog from Eskil Abrahamsen Blomfeld about Intents with Qt for Android, part 1. Please read that Blog to learn about Android Intents, Qt Android Extras, JNI and HowTo use it from Qt. All of this was new to me – never did JNI before. Also I‘m not an experienced native developer for Android or iOS – that‘s the reason why I‘m using Qt for mobile App development.

I also found Share on iOS and Android using QML, where I learned HowTo share Text and a URL and HowTo structure a QtCreator project for Android and iOS with native code integration.

Unfortunately all of this didn‘t help me to share Files on Android or iOS from Qt mobile Apps.

For a DropBox-like project at customer site I needed sharing:

  • download Files from cloud
  • store Files in App sandbox data
  • view or edit Files in other Apps
  • print Files to local Printer

It took me some time and thanks to much help from other developers at Qt Forum and Slack (QtMob) I found ways to solve my use-cases.

The hardest part was the ugly JNI and Obj-C syntax ��

Hopefully my experiences will make it easier for others to integrate Sharing-functionality into their Android or iOS Apps.

Here‘s my Example App at Github.

The Example App demonstrates:

  • Share Text and URL
  • View File
  • Edit File
  • Send File as Stream to …

To easy understand the complex structure please take a look at this Overview:

share_overview

UI: SwipeView with some Tabs. Each Tab contains a Page with some Buttons to test features.

01_tab_bar

Share Text and URL is the easiest one:

02_android_share_text_url

ShareUtils is registered as „shareUtils“:

void ApplicationUI::addContextProperty(QQmlContext *context)
{
    context->setContextProperty("shareUtils", mShareUtils);
}

Click on the Button to share Text and URL:

Button {
    text: qsTr("Share Text and Url")
    onClicked: {
        shareUtils.share("Qt","http://qt.io")
    }
}

Here‘s the share() method:

Q_INVOKABLE void share(const QString &text, const QUrl &url);
void ShareUtils::share(const QString &text, const QUrl &url)
{
    mPlatformShareUtils->share(text, url);
}

ShareUtils delegates this to PlatformShareUtils:

  • AndroidShareUtils on Android
  • IosShareUtils on iOS

The magic to detect the right class can be found in ShareUtils:

#if defined(Q_OS_IOS)
    mPlatformShareUtils = new IosShareUtils(this);
#elif defined(Q_OS_ANDROID)
    mPlatformShareUtils = new AndroidShareUtils(this);
#else
    mPlatformShareUtils = new PlatformShareUtils(this);
#endif

The Compiler knows the Platform you‘re running on and instantiates the matching platform specificClass.

Android:

void AndroidShareUtils::share(const QString &text, const QUrl &url)
{
    QAndroidJniObject jsText = QAndroidJniObject::fromString(text);
    QAndroidJniObject jsUrl = QAndroidJniObject::fromString(url.toString());
    jboolean ok = QAndroidJniObject::callStaticMethod("org/ekkescorner/utils/QShareUtils",
                                              "share",
                                              "(Ljava/lang/String;Ljava/lang/String;)Z",
                                              jsText.object(), jsUrl.object());
    if(!ok) {
        emit shareNoAppAvailable(0);
    }
}

QAndroidJniObjects are created for text and url and a Method from QShareUtils.java will be called:

    public static boolean share(String text, String url) {
        if (QtNative.activity() == null)
            return false;
        Intent sendIntent = new Intent();
        sendIntent.setAction(Intent.ACTION_SEND);
        sendIntent.putExtra(Intent.EXTRA_TEXT, text + " " + url);
        sendIntent.setType("text/plain");
        // Verify that the intent will resolve to an activity
        if (sendIntent.resolveActivity(QtNative.activity().getPackageManager()) != null) {
            QtNative.activity().startActivity(sendIntent);
            return true;
        } else {
            Log.d("ekkescorner share", "Intent not resolved");
        }
        return false;
    }

In our QShareUtils.java we create the Intent with ACTION_SEND and EXTRA_TEXT and start the Activity using QtNative.activity().

It‘s important to test if the Intent can be resolved – otherwise your App will crash.

Here‘s the iOS implementation:

void IosShareUtils::share(const QString &text, const QUrl &url) {
    NSMutableArray *sharingItems = [NSMutableArray new];
    if (!text.isEmpty()) {
        [sharingItems addObject:text.toNSString()];
    }
    if (url.isValid()) {
        [sharingItems addObject:url.toNSURL()];
    }
    // get the main window rootViewController
    UIViewController *qtUIViewController = [[UIApplication sharedApplication].keyWindow rootViewController];
    UIActivityViewController *activityController = [[UIActivityViewController alloc] initWithActivityItems:sharingItems applicationActivities:nil];
    if ( [activityController respondsToSelector:@selector(popoverPresentationController)] ) { // iOS8
        activityController.popoverPresentationController.sourceView = qtUIViewController.view;
    }
    [qtUIViewController presentViewController:activityController animated:YES completion:nil];
}

In this case we‘re using UIActivityViewController to get the share options displayed.

Let‘s take a look HowTo view or edit Files. My Example App contains an Image and a PDF File in assets:

03_assets

At first start of the Example App we copy these files from Assets to (QstandardPaths::AppDataLocation)/my_share_files. This simulates that you have downloaded the Files from your Cloud or WebService.

See all the details in the sources.

Now we want to view or edit these Files in another App. I learned that it‘s not possible to share Files from your AppData Location (Sandbox) – you must copy the Files from APP Data to USER Data – per ex. Documents Location. I create a app specific working directory at DocumentsLocation.

Attention: I‘m not checking if Permissions are set – this isn‘t the goal of this App. To access Files at DocumentLocation you have to set WRITE_EXTERNAL_STORAGE.

<uses-permission android:name=”android.permission.WRITE_EXTERNAL_STORAGE” />

Using Files from DocumentsLocation sounds easy but makes things more complicated. We don‘t want to leave those Files at DocumentsLocation when sharing the File finished. Then we must delete them. And if the User edited the File we must know if the File was changed and saved or canceled. If the File was modified we must replace the origin File inside our AppData before deleting the File from DocumentsLocation.

Also after sending the File as a Stream per ex. to a Printer we must delete the copied File as soon as printing was done.

The workflows are different for Android and iOS.

Android needs

  • FilePath URI
  • a specific Action: ACTION_VIEW, ACTION_EDIT, ACTION_SEND
  • MimeType

to find matching Apps.

iOS needs

  • FilePath as NSURL

On iOS there‘s no way to limit the Apps for View or Edit capabilities.

Android does an in-place-Editing of the File, where iOS copies the File over to the other App. To get the modified File back a second manual step is required by the user.

file_flow

The interesting question now is „HowTo know when sharing is finished and if Edit mode was canceled or saved“ ?

Android gives us the startActivityForResult() to get a Result Code back.

Unfortunately I didn‘t found a way to get this Result Code back from the Java Code in QShareUtils.java.

Using Java code on the other side is much easier to read and write as JNI code.

There‘s a workaround: as soon as the Intent Activity is started, our Qt App changes ApplicationState to Suspended and when the Intent Activity closes, the ApplicationState goes back to Active. You can watch the ApplicationState to know when sharing was finished and you also can compare modified Timestamp of the File to recognize changes from Edit mode.

This workflow is marked ‚A‘ in the Overview at the beginning of this article.

More coding, but much more flexible is to use JNI to construct the complete Intent Activity and to go with QAndroidActivityResultReceiver To get the Result back.

Here‘s the method to construct the Edit Intent:

    QAndroidJniObject jniPath = QAndroidJniObject::fromString("file://"+filePath);
    if(!jniPath.isValid()) {
        emit shareError(requestId, tr("Share: an Error occured\nFilePath not valid"));
        return;
    }
    // next step: convert filePath Java String into Java Uri
    QAndroidJniObject jniUri = QAndroidJniObject::callStaticObjectMethod("android/net/Uri", "parse", "(Ljava/lang/String;)Landroid/net/Uri;", jniPath.object());
    if(!jniUri.isValid()) {
        emit shareError(requestId, tr("Share: an Error occured\nURI not valid"));
        return;
    }
    // THE INTENT ACTION
    // create a Java String for the ACTION
    QAndroidJniObject jniParam = QAndroidJniObject::getStaticObjectField("android/content/Intent", "ACTION_EDIT");
    if(!jniParam.isValid()) {
        emit shareError(requestId, tr("Share: an Error occured"));
        return;
    }
    // then create the Intent Object for this Action
    QAndroidJniObject jniIntent("android/content/Intent","(Ljava/lang/String;)V",jniParam.object());
    if(!jniIntent.isValid()) {
        emit shareError(requestId, tr("Share: an Error occured"));
        return;
    }
    // THE FILE TYPE
    if(mimeType.isEmpty()) {
        emit shareError(requestId, tr("Share: an Error occured\nMimeType is empty"));
        return;
    }
    // create a Java String for the File Type (Mime Type)
    QAndroidJniObject jniType = QAndroidJniObject::fromString(mimeType);
    if(!jniType.isValid()) {
        emit shareError(requestId, tr("Share: an Error occured\nMimeType not valid"));
        return;
    }
    // set Data (the URI) and Type (MimeType)
    QAndroidJniObject jniResult = jniIntent.callObjectMethod("setDataAndType", "(Landroid/net/Uri;Ljava/lang/String;)Landroid/content/Intent;", jniUri.object(), jniType.object());
    if(!jniResult.isValid()) {
        emit shareError(requestId, tr("Share: an Error occured"));
        return;
    }
    QAndroidJniObject activity = QtAndroid::androidActivity();
    QAndroidJniObject packageManager = activity.callObjectMethod("getPackageManager",
                                                                 "()Landroid/content/pm/PackageManager;");
    QAndroidJniObject componentName = jniIntent.callObjectMethod("resolveActivity",
                                                              "(Landroid/content/pm/PackageManager;)Landroid/content/ComponentName;",
                                                              packageManager.object());
    if (!componentName.isValid()) {
        emit shareNoAppAvailable(requestId);
        return;
    }
    // now all is ready to start the Activity:
    // we have the JNI Object, know the requestId
    // and want the Result back into 'this' handleActivityResult(...)
    QtAndroid::startActivity(jniIntent, requestId, this);

Thanks to QAndroidActivityResultReceiver we‘ll get the Result back into:

void AndroidShareUtils::handleActivityResult(int receiverRequestCode, int resultCode, const QAndroidJniObject &data)
{
    Q_UNUSED(data);
    // we're getting RESULT_OK only if edit is done
    if(resultCode == RESULT_OK) {
        emit shareEditDone(receiverRequestCode);
    } else if(resultCode == RESULT_CANCELED) {
        emit shareFinished(receiverRequestCode);
    } else {
        emit shareError(receiverRequestCode, tr("Share: an Error occured"));
    }
}

Now it‘s easy to connect to the SIGNAL (shareEditDone, shareFinished, shareError) from QML.This workflow is marked as ‚B‘ in the Overview above.

Please note: the JNI code is different for VIEW/EDIT and SEND – please take a look at all the details in the sources.

Was not so easy to figure out all the details but now it‘s really easy for you: just copy the code into your app ��

On iOS we‘re using a UIDocumentInteractionController:

    NSString* nsFilePath = filePath.toNSString();
    NSURL *nsFileUrl = [NSURL fileURLWithPath:nsFilePath];
    static DocViewController* docViewController = nil;
    if(docViewController!=nil)
    {
        [docViewController removeFromParentViewController];
        [docViewController release];
    }
    UIDocumentInteractionController* documentInteractionController = nil;
    documentInteractionController = [UIDocumentInteractionController interactionControllerWithURL:nsFileUrl];
    UIViewController* qtUIViewController = [[[[UIApplication sharedApplication]windows] firstObject]rootViewController];
    if(qtUIViewController!=nil)
    {
        docViewController = [[DocViewController alloc] init];
        docViewController.requestId = requestId;
        // we need this to be able to execute handleDocumentPreviewDone() method,
        // when preview was finished
        docViewController.mIosShareUtils = this;
        [qtUIViewController addChildViewController:docViewController];
        documentInteractionController.delegate = docViewController;
        [documentInteractionController presentPreviewAnimated:YES];
    }

Know when Preview is done from DocViewController:

-
(void)documentInteractionControllerDidEndPreview:(UIDocumentInteractionController *)controller
{
#pragma unused (controller)
    self.mIosShareUtils->handleDocumentPreviewDone(self.requestId);
    [self removeFromParentViewController];
}

We detect the end of preview and call documentPreviewDone() in IosShareUtils:

void IosShareUtils::handleDocumentPreviewDone(const int &requestId)
{
    emit shareFinished(requestId);
}

Now from QML we can connect to the SIGNAL and know when sharing was done.

The good thing: the workflow now is similar for Android and iOS and easier to handle from common QML code.

Please take a look at .pro – there are some Android and iOS specific sections. Also dont forget to add AndroidExtras.

Now it‘s time to download from Github, build and run the Sharing Example App.

Some Screenshots

Open in… Dialog on Android. Select the App you want to use for View or Edit mode:

04_android_share_chooser

Edit the Image and cancel or save:

05_android_share_edit_image

ACTION_SEND enables you to print Text, Images or PDF Files.

Choose the Printer Plugin:

06_android_share_send_chooser

Then select your Printer, configure the Printer and print:

07_android_share_print

On iOS the UIDocumentInteractionController gives you a preview of the File and provides the iOS Share Button at bottom left:

08_ios_preview

The Share Button presents the available Apps:

09_ios_share

Conclusion: you can share Files on Android and iOS and integrate into your specific workflows. SIGNALS are mitted to let you know what the User has done.

There‘s even a call to check if for a given MimeType and Action Type any matching Apps are available on Android.

Call this check before downloading a File from Cloud, to provide a better UX: instead of downloading and then telling users that there‘s no App available you can inform in advance.

One question is open for now: HowTo suppress the Preview on iOS and only show what you get from clicking on the Share Button. Thanks to any tips from Qt / Obj-C experts.

I‘ll continue work on this app and add some more Intent Actions for Android.Also will add functionality to open the App from outside by providing a File URI or MimeType.

Now have fun!

The post Sharing Files on Android or iOS from your Qt App appeared first on Qt Blog.

November 30, 2017

Elisa is a music player designed to be simple and nice to use.

Elisa project has now an official mailing list hosted by kde (Elisa mailing list). Alexander Stippich is now a regular KDE developer and we felt a list was good to coordinate work on Elisa. I am also very happy, to nine years after I joined KDE, to have the honor to recommend somebody. I still remember how excited I was at that time.

Following blog post from Kevin Funk on binary-factory service (KDE binary factory), Elisa windows installers are regularly built. Thanks a lot to the KDE windows contributors. They do a lot of work to help projects like mine.

2017-11-30 14_28_43-Snapshot of Elisa on Windows 10

The following things have been integrated in Elisa git repository:

  • Fix the case of albums with same title but different cover images by Matthieu Gallien ;
  • Do not duplicate albums when a track is missing album artist metadata by Matthieu Gallien ;
  • Hopefully fix compilation for neon distribution by Matthieu Gallien ;
  • By default tracks are from disc 1 now: fix some tracks being from disc 0 by Matthieu Gallien ;
  • Fix play list save and restore when exiting and launching the application by Matthieu Gallien ;
  • Rename default license file to match documentation on community KDE wiki by Matthieu Gallien ;
  • Add a reference to a snapshot for Elisa appstream metadata by Matthieu Gallien ;
  • Rename Qml import to org.kde.elisa by Matthieu Gallien ;
  • Give credit to astippich by Matthieu Gallien ;
  • Lower requirement for frameworks except for kdoctools. This is needed to built on binary-factory.kde.org by Matthieu Gallien ;
  • Print a warning if KFileMEtaData version is older than 5.39.0 that can crash when used the way Elisa code is using it by Matthieu Gallien ;
  • Add a test for MediaPlayList persistence by Matthieu Gallien ;
  • Make text vertically aligned to center for NavigationActionBar by Alexander Stippich ;
  • Alexander Stippich changed icons in playlist entry such that :
    • Playing indicator and remove button now share the position. indicator becomes invisible when entry is hovered or selected ;
    • Play button is transformed into a play pause button, allowing pause in the playlist entry. this is also a nice way to indicate the playing status when hovered or selected ;
  • Add automatic tests for MediaPlayList by Matthieu Gallien ;
  • Remove extra rowsInserted signals in MediaPlayList when adding tracks from an artist by Matthieu Gallien ;
  • When reselecting e.g. the all albums view with the view selector, the stackview shows a previously opened album. Reset to the initial item when the view selector is used by Alexander Stippich ;
  • Add a test for tracks removal via TracksListener and fix some bugs by Matthieu Gallien ;
  • Fix XML in copyright text for about dialog by Alexander Potashev ;
  • Allow to display all albums from an artist directly from the view of one of its albums by Matthieu Gallien ;
  • Do not extract i18n messages from localFileConfiguration/ to elisa.pot by Alexander Potashev.

The KDE community has spoken and it has chosen the proposals which will define the general direction of the KDE project over the next three or four years.

How does the KDE community decide where it wants to take the project? Well, every once in a while, we hold a Request for Proposals, if you will. All members of the community are encouraged to submit their grand ideas which will lay out long-term targets. Proposals are voted on democratically, again, by the community. This ensures it is truly the community that guides the KDE project to wherever the community wants it to go.

This year, the three most voted proposals have been:

Top-notch Usability and Productivity for Basic Software

Nate Graham proposes improving the usability of KDE's software and making it more accessible and user-friendly for a wider variety of users. Nate argues that, although KDE apps and environments in general boast a "long list of features that are genuinely useful for normal people's typical use cases", small but noticeable inconsistencies and niggling usability issues sometimes mar KDE's semblance of maturity with casual users.

Nate reasons that focusing on irksome details of the most common and commonly used of KDE's software, such as Plasma, Dolphin, Okular and Discover, would be the first step towards polishing the whole. He mentions, for example, the annoying bug that makes Plasma require the Wifi password twice; or enhancements that can be made to Dolphin to support column view or colourised files and directories, like MacOS X's file browser sports; or improving Okular's stamp feature to make it suitable for digitally signing documents.

KDE's environments and applications are mature and usable to a great extent, but by getting small incremental improvements, we can nearly subliminally improve the overall feel of the project and increase its uptake with the general public.

Privacy Software

In synch with KDE's vision, Sebastian Kugler says that "KDE is in a unique position to offer users a complete software environment that helps them to protect their privacy". Being in that position, Sebastian explains, KDE as a FLOSS community is morally obliged to do its utmost to provide the most privacy-protecting environment for users.


KDE will bring privacy to all
your devices, including your
mobile.

This is especially true since KDE has been developing not only for desktop devices, but also for mobile - an area where the respect for users' privacy is nearly non-existent. Sebastian thinks that the intrusion on users’ personal lives is very dangerous. Users can have their livelihood and even personal safety put at risk when their confidential data makes its way into the hands of unscrupulous companies or hostile government agencies.

To make sure KDE environment and apps protect users’ privacy, Sebastian lists several measures that developers can implement. He proposes that applications not expose private data by default, asking the user for explicit consent before sending data to third parties. Other measures would involve apps using privacy-protecting protocols when communicating with the outside world; say, a widget should use Tor to collect weather information. Applications should also only require the bare minimum user information to operate and only when it is essential.

Finally, the proposal explains that KDE must provide the right tools to further safeguard users' privacy. These tools include email clients that offer easy ways of encrypting messages, privacy-protecting chat and instant messaging protocols and clients, and support for online services that can be implemented on personal servers.

Streamlined Onboarding of New Contributors


Getting more people involved with the project
is crucial for the survival of KDE.
Photo CC By-SA by Teia

Although we have made many improvements to KDE's development infrastructure and tools over the years, there are still several things we can do to streamline the access for contributors, says Neofytos Kolokotronis. Thinking of ways to get more people involved in the development, Neofytos proposes measures to simplify newcomer participation within KDE.

KDE is a living community and, as such, it is threatened if new users do not become contributors and therefore do not join its ranks, bringing in new blood and fresh ideas. To solve this potential problem, Neofytos wants the community to look at methods of incrementing user involvement. This will require analysing the available resources, especially the people and time that they can invest in this effort.

He also proposes KDE improve and standardise protocols for accepting and mentoring new users, as well as correcting issues with documentation and tools used to receive new contributions, such as KDE's bug tracking system.


The KDE community will start implementing the proposals into concrete actions and policies. The proposals will shape how the KDE community creates software and works with its members, as well as with outside users. In view of the winning ideas, we can expect a more polished KDE experience, enhanced privacy protection and a more accessible and welcoming community for years to come.

To make sure all KDE's goals are met, we need your support. Head over to the End of Year fundraiser (coming soon!) and help us meet our yearly funding target. You can contribute to the success of KDE and we will also show appreciation with karma and gifts!

November 29, 2017

This Saturday ( December 2nd ) the second Kubuntu Kafe Live, our online video cafe will be taking place from 21:00 UTC.
Join the Kubuntu development community, and guests as our intrepid hosts.

  • Aaron Honeycut
  • Ovidiu-Florin Bogdan
  • Rick Timmis

Discuss a cornucopia of topics in this free format, magazine style show.

This show includes Technical Design and Planning for a Kubuntu CI Rebuild, a Live Testing workshop in the Kubuntu Dojo, Kubuntu product development and more.

We will be attempting to run a live stream into our YouTube Channel although we encourage you to come and join us in our Big Blue Button conference server, use your name and welcome to join room 1 and come and interact with us and be part of the show.

See you there

Cutelyst the Qt Web framework got a new release, this is likely to be the last of the year and will be one of lasts releases of the 1.x.x series. I’d like to add HTTP/2 support before branching 1.x.x and having master as 2.0 but I’m not yet sure I’ll do that yet.

For the next year I’d like to have Cutelyst 2 packaged on most distros soon due Ubuntu’s LTS being released in April, and H2 might delay this or I delay it since it can be done using a front-end server like Nginx.

The 1.11.0 version includes three new plugins written by Matthias Fehring, a Memcached plugin that simplifies talking to a memcached server, a memcached based session store, that stores session information on the memcached server, and a static compressed plugin to serve compressed versions of static files.

Besides that I extended the EngineRequest class to serve as a base class for Engine’s requests allowing to get rid of some ugly casts and void pointers that carry the real request/connection. This doesn’t affect user code as long as they don’t implement their own engine.

Setting a Json reply is now a bit simpler now that two overloads directly accepting QJsonObject and QJsonArray were added.

Cutelyst license preamble on files was fixed to state it’s LGPLv2.1+, and finally pkg-config is now fully supported.

Go get/break/package/.* it!

https://github.com/cutelyst/cutelyst/archive/v1.11.0.tar.gz


November 28, 2017

by Banksyby Banksy
At Akademy 2016, the KDE community started a long-term project to invigorate its development (both, technically and organizationally) with more focus. This process of soul-searching has already yielded some very useful results, the most important one so far being agreement of a common community-wide vision:

A world in which everyone has control over their digital life and enjoys freedom and privacy.

This presents a very high-level vision, so a logical follow-up question has been how this influences KDE’s activities and actions in practice. KDE, being a fairly loose community with many separate sub-communities and products, is not an easy target to align to a common goal. A common goal may have very different on each of KDE’s products, for an email and groupware client, that may be very straight-forward (e.g. support high-end crypto, work very well with privacy-respecting and/or self-hosted services), for others, it may be mostly irrelevant (a natural painting app such as Krita simply doesn’t have a lot of privacy exposure), yet for a product such as Plasma, the implications may be fundamental and varied.
So in the pursuit of the common ground and a common goal, we had to concentrate on what unites us. There’s of course Software Freedom, but that is somewhat vague as well, and also it’s already entrenched in KDE’s DNA. It’s not a very useful goal since it doesn’t give us something to strive for, but something we maintain anyway. A “good goal” has to be more specific, yet it should have a clear connection to Free Software, since that is probably the single most important thing that unites us. Almost two years ago, I posed that privacy is Free Software’s new milestone, trying to set a new goal post for us to head for. Now the point where these streams join has come, and KDE has chosen privacy as one of its primary goals for the next 3 to 4 years. The full proposal can be read here.
“In 5 years, KDE software enables and promotes privacy”

Privacy, being a vague concept, especially given the diversity in the KDE community needs some explanation, some operationalization to make it specific and to know how we can create software that enables privacy. There are three general focus areas we will concentrate on: Security, privacy-respecting defaults and offering the right tools in the first place.

Security

Improving security means improving our processes to make it easier to spot and fix security problems and avoiding single points of failure in both software and development processes. This entails code review, quick turnaround times for security fixes.

Privacy-respecting defaults

Defaulting to encrypted connections where possible and storing sensible data in a secure way. The user should be able to expect the KDE software Does The Right Thing and protect his or her data in the best possible way. Surprises should be avoided as much as possible, and reasonable expectations should be met with best effort.

Offering the right tools

KDE prides itself for providing a very wide range of useful software. From a privacy point of view, some functions are more important than others, of course. We want to offer the tools that most users need in a way that allows them to lead their life privately, so the toolset needs to be comprehensive and cover as many needs as possible. The tools itself should make it easy and straight-forward to achieve privacy. Some examples:

  • An email client allowing encrypted communication
  • Chat and instant messenging with state-of-the art protocol security
  • Support for online services that can be operated as private instance, not depending on a 3rd party provider

Of course, this is only a small part, and the needs of our userbase varies wildly.

Onwards from here…

In the past, KDE software has come a long way in providing privacy tools, but the tool-set is neither comprehensive, nor is privacy its implications widely seen as critical to our success in this area. Setting privacy as a central goal for KDE means that we will put more focus on this topic and lead to improved tools that allow users to increase their level of privacy. Moreover, it will set an example for others to follow and hopefully increase standards across the whole software ecosystem. There is much work to do, and we’re excited to put our shoulder under it and work on it.

Why?

One of the interesting things about QML is that it leverages OOP property semantics of QObject to drive its declarative workflow.

How?

We attach into any QObject the developer requests and monitor it (and optionally all it’s children).

To gather the information we need, we will collect information for every property and connect to the property’s notification signal to see when it changes.

What?

This is the repository:https://phabricator.kde.org/source/kobjecttracking/.

This allows us to see:

  • Spurious property change notifications
  • Property changing bursts (i.e. same property changing values repeatedly in a short amount of time)
  • How a change in a value can have an effect on other properties

At the moment we have two ways of inspecting an application:
On one hand we have warnings that allow us know specific things and even add breakpoints to the sore points. The warnings at the moment look like this:
repeated value ScrollView_QMLTYPE_43(0x5648c6d97b50) width QVariant(double, 320) 8 times
repeated value Kirigami::BasicTheme(0x5648c6986ac0) backgroundColor QVariant(QColor, QColor(ARGB 1, 0.988235, 0.988235, 0.988235)) 11 times

Additionally, we have a timeline view output from tracking. You can see an example of plasmashell run here.

Future

An idea would be to integrate automatically ModelTest, so if a QAbstractItemModel is found, a ModelTest instance is attached that makes sure the model is true to its promises.

Another thing that bothers me is that we are forced to compile it into the application. If we could make it possible to have processes attached or start the application somewhat automatically (like GammaRay does, wink-wink) we would ease the adoption of these tools.

What do you think? Do you think it’s useful?
Feedback very welcome.

Linux perf is an immensely useful and powerful tool suite for profiling of C/C++ applications.
I have used it extensively and successfully on various customer projects, both for desktop applications as well as automotive or industrial projects targeting low-end embedded Linux targets running on ARM hardware.

The biggest problem with perf really is its usability, or lack thereof. Over the years I have tried my best in educating people on how to use the tool suite, both in form of conference talks as well as during KDABs Linux profiling trainings and workshops and, most recently, by creating hotspot.

Additionally, I have started contributing upstream to the Linux kernel repository to alleviate some of the problems. A short time ago, one important patch series of mine got merged and will be part of Linux 4.15, which drastically improves Linux perf usability when dealing with common C++ workloads.

The patch series completely reworked the representation and handling of inlined frames in perf report.

Up until recently, inlined frames were not shown at all in the report. This made the interpretation of reports from C++ applications very hard, since the compiler will inline a lot of templates.

continue reading

The post Update to Linux perf report appeared first on KDAB.

https://youtu.be/Y0TgaevFKx0?rel=0&showinfo=0

KDAB has unique experience in porting the code base for toolkits like Qt 3, Qt 4, Motif, Java, Tcl, GTK, .NET, MFC, and Photon to Qt 5. Porting legacy GUI toolkits to Qt 5 is a job where proven experience saves a lot of time.

In this presentation we highlight the main problems facing developers using legacy toolkits, what migrations are and which approaches to migrations are possible. We give you a short overview of common guidelines in starting migrations including common pitfalls and also discuss how KDAB can assist in porting your legacy code base to a modern Qt-based system using our tooling for automatic conversions.

View the slides.


For detailed information on migration, read our whitepaper: Modernizing Legacy Systems continue reading

The post Porting Applications to Qt appeared first on KDAB.

November 27, 2017

Since Akademy in Almería we have been going through the process of defining goals for KDE for the next 3 to 4 years. Different ideas were proposed and refined. 10 of them made it into the community-wide vote to select 3 of them. Today I am proud to announce the result based on the 684 submitted votes.

The 3 goals KDE will be focusing on over the next 3 to 4 years are:

  • Top-notch usability and productivity for basic software: We want our users to love our software and enable them to do their day-to-day work hassle-free. As part of this goal we will focus on polishing our basic software so everyone will be delighted to use it. For more details see the proposal.
  • Privacy Software: A central part of KDE’s vision for the future is privacy. As part of this goal we will work on improving privacy-related features, settings and applications all over KDE’s software. Once done KDE software enables and promotes privacy, which is crucial for a free and open society and protecting our users from harm. For more details see the proposal.
  • Streamlined onboarding of new contributors: KDE can only achieve its vision if we enable many people to join our community and support us with their specific knowledge and skills – be it programming, artwork, promotion, translation, event organizing or any of the other hundreds of areas needed to make KDE successful. As part of this goal we will identify and remove barriers to entry in our documentation, infrastructure and processes. For more details see the proposal.

I am excited about what this will bring for the next years of KDE and how it will help bring great software to our users.

What will happen next? I am helping the proposers of the goals come up with a plan. There will be sprints related to the topics in 2018 as well as a progress report at Akademy. None of these goals is going to be achieved without help. It’ll need all hands on deck – including yours! If you are able to help with one of them please add your name to the proposal on Phabricator linked above so you can be contacted once the plan for each of them becomes more clear.

Thanks to everyone who submitted one of the great proposal, Ben for providing the list of voters and Kevin for his help in making sense of the votes.


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.