March 01, 2017

Once upon a time, the Qt people joked about switching Qt to snake_case in one of the April Fools posts.

But even if it was a joke, it did trigger me and Vishesh to talk (argue?) about it during one of aKademies.

One of the strange things I’ve noticed is that when I’m writing code that is Qt-based, I tend to use camelCase most of the time, but at the same time (in the same project) I tend to use snake_case when I’m creating generic functions. For example, a for-each algorithm that works on associative containers would be called for_each_assoc instead of forEachAssoc. This is the place where Vishesh did not agree with me.

You might ask me why I’m bringing this up now, quite a few years after the discussion.

I’ve been digging through Qt code, and I’ve encountered this:

    inline QModelIndex create_index(
            int row, int column,
            QHash<QModelIndex, Mapping*>::const_iterator it) const
    {
        return q_func()->createIndex(row, column, *it);
    }

    void _q_sourceDataChanged(const QModelIndex &source_top_left,
                              const QModelIndex &source_bottom_right,
                              const QVector<int> &roles);

    void _q_sourceHeaderDataChanged(
            Qt::Orientation orientation, int start, int end);

    void _q_sourceLayoutAboutToBeChanged(
            const QList<QPersistentModelIndex> &sourceParents,
            QAbstractItemModel::LayoutChangeHint hint);
    void _q_sourceLayoutChanged(
            const QList<QPersistentModelIndex> &sourceParents,
            QAbstractItemModel::LayoutChangeHint hint);

    void _q_sourceRowsAboutToBeInserted(const QModelIndex &source_parent,
                                        int start, int end);
    void _q_sourceRowsInserted(const QModelIndex &source_parent,
                               int start, int end);

I’d say that Qt is a true framework for the new age of political correctness – it does not discriminate against any of the naming styles. :)

p.s. I’ve posted this just for fun, please do not post comments about which naming convention is better etc. No reason to start a flamewar here.


Read more...

Tras un mes desde su lanzamiento y ya tenemos la tercera actualización de Plasma 5.9. Y es que alguna cosa no se le puede reprochar al equipo de desarrollo de KDE es su capacidad de trabajo y mejora constante.

Tercera actualización de Plasma 5.9 actualización de Plasma 5.9

El 31 de enero de 2017, la Comunidad KDE se complacióe en presentar su escritorio para entornos GNU/Linux Plasma 5.9. Esta nueva versión fue el fruto de un intenso trabajo por parte de los desarrolladores y probadores que siguen dos líneas básicas de acción: añadir nuevas funcionalidades y mejorar el funcionamiento de Plasma eliminando bugs y optimizando el consumo de recursos.

Primera actualización de Plasma 5.9

Un mes más tarde, ayer 28 de febrero de 2017, se anunció en la página oficial de la Comunidad el lanzamiento de la tercera actualización de Plasma 5.9, la cual conlleva un buen número de errores resueltos, mejoras en las traducciones y pequeños cambios realizados por parte de los desarrolladores.

Como es habitual, este tipo de actualizaciones son muy recomendables.

Más información: kde.org

Las novedades de Plasma 5.9

De esta forma, y como la forma más sencilla de conocer todas las novedades, os aconsejo a ver el siguiente vídeo con las novedades más destacadas de Plasma 5.9, muchas de las cuales comento en el siguiente apartado del artículo:

 

Además del regalo que es tener un nuevo fondo de escritorio de la mano de Ken Vermette del que ya hablamos en el blog, Plasma 5.9 nos traerá nuevas funcionalidades:

Tercera actualización de Plasma 5.9

  • Retorno de la barra de menús globales para el escritorio y para las ventanas. Con ello podemos tener el menú de opciones principales bien en la parte superior del escritorio o bien como un botón en la barra de la ventana de la aplicación.
  • Posibilidad de conmutar entre ventanas con el Gestor detareas utilizando Meta + número ventana.
  • Posibilidad de añadir nuevos temas globales para Plasma (los llamado Look-and-Feel Packs) descargados directamente desde internet con la posibilidad de editarlos.
  • Nuevo diseño de la barra de desplazamiento de Breeze, mucho más fina y elegante ya que se integra mejor con el tema Plasma seleccionado.
  • El Quick Launch applet ahora soporta listas de acciones, con lo que podremos seleccionar qué hacer con el elemento seleccionado.

  • Las ventanas emergentes de las barras de tareas mostrarán información más detallada.
  • Notificaciones interactivas en las previsualizaciones: A partir de ahora, las notificaciones no solo nos informan sino que también podemos realiza acciones con ellas como capturar una imagen y arrastrarla al visor de imágenes.
  • Mejoras en el plasmoide icono de escritorio con el retorno de las opciones de configuración: general, permisos y opciones de la aplicación.
  • Posibilidad de agrupar plasmoides en uno solo mediante pestañas.
  • Mejoras en el gestor de tareas que ahora añade el control multimedia. De esta forma podemos incluso silenciar directamente una aplicación.
  • Las Preferencias del Sistemas mejoran la gestión de redes.

En definitiva, muchas novedades para Plasma 5.9 que hará que nuestro escritorio funcione mejor y sea más funcional. No puedo a esperar a probarlo en mis distribuciones favoritas.

You can see it in https://www.youtube.com/watch?v=fCLFkpaW3Ug

As the description of the YouTube video says:

Form 14 updates from Form 13 values as defined by the PDF file.
There's a few bugs left:
* To make the page contents update i need to edit another form in the page of the form that is being auto updated
* The contents of the "editable" Form are not updated. (The form is actually not editable since it's readonly)

And also a pile of uncommited and unreviewed patches, and probably only works for very simple files like this one, but it's a start :)

February 28, 2017

Con motivo de los 20 años de KDE la Comunidad de KDE España ha decidido mostrar su lado más humano y mostrar un poco el lado más personal de sus integrantes. Por ello muchos de ellos han participado en la serie de entrada que he titulado “20 entrevistas para 20 años de KDE” en las que no solo hablarán de su relación con el proyecto sino que también nos mostrarán su lado más personal. Para la décimotercera entrevista nos encontramos con uno de los miembros de KDE España que más tiempo ha permanecido en la Junta Directiva realizando una fabulosa labor de tesorero. Con todos ustedes José Millán Soto.

20 entrevistas para 20 años de KDE (XIII):José Millán Soto

Hola, en primer lugar quisiera agradecerte tu tiempo. Seguro que tus palabras serán fuente de inspiración para otros muchos. Para empezar me gustaría que te presentaras tu mismo

Soy José Millán Soto, estudié Ingeniería en Informática en la Facultad de Informática de la UDC, donde participo muy activamente en la asociación GPUL, y actualmente trabajo como desarrollador de software en la empresa Opentia.

¿Recuerdas como conociste KDE?

KDE lo conocí en el 1999 aproximadamente. Acababa de instalar mi primera distribución GNU/Linux, que era una RedHat 6.0 y probé todos los entornos de escritorio que traía, decidiéndome finalmente por KDE.

¿Qué es lo que te gustó de KDE? ¿Y lo que menos?
En el momento en el que lo probé la mayoría de los entornos tenían un conjunto de funcionalidad bastante reducida. Una de las cosas que más me gustó por aquel momento era kfm (predecesor de Koqueror y Dolphin).
¿Por qué decidiste empezar a colaborar KDE?
Cuando comencé a colaborar con KDE llevaba unos años colaborando con una asociación llamada GPUL, surgió la posibilidad de organizar una reunión de colaboradores en entornos de escritorio libres (GUADEMY 2007), y esa fue la primera vez que me puse en contacto con la comunidad KDE.
¿Cual es tu motivación para hacerlo y qué te aportó o te aporta?
En un principio dado que me encantaba KDE fue para mí un gran incentivo el tener a los desarrolladores de dicho proyecto en una actividad organizada por mi LUG, y luego una vez los conocí me dí cuenta de lo simple que era comenzar a colaborar en el proyecto.

El momento actual

En la actualidad, ¿Colaboras con el Software Libre en general y KDE en particular?
Sí, aunque en este momento por lo general no colaboro en el desarrollo de KDE a nivel técnico

¿Qué aplicaciones o partes de KDE has colaborado?

La mayoría de las colaboraciones a nivel técnico que he realizado había sido en el área de accesibilidad. Además de eso y de mi participación en la Junta Directiva de KDE España he colaborado también en algunas ediciones de Akademy, por ejemplo coordinando el equipo local en 2015.
  20 entrevistas para 20 años de KDE (XIII)
Me has convencido, me gustaría echar una mano ¿cómo crees que es la mejor manera de empezar?

Si es una colaboración a nivel de código pero nunca has colaborado previamente en un proyecto de Software Libre, busca un Junior Job en bugs.kde.org. Los Junior Jobs son tareas muy sencillas que tienen como objetivo el aprender a trabajar con las herramientas y a comunicarse con la comunidad.
Si quieres colaborar en temas de difusión de KDE, puede ser buena idea ponerse en contacto con la asociación KDE España ya que contamos con un equipo de comunicación.
En el caso de que sea otro tipo de colaboración (Visual Design, traducciones, etc), cada grupo suele tener en la página de información de dicho grupo una sección “Get involved”.
Por último, independientemente de cómo decidas colaborar, si se va a celebrar algún evento (Akademy, Akademy-es, BcnFS, etc) cerca de tu localidad te aconsejo que intentes asistir.

La Comunidad KDE

Define KDE en 3 palabras:
KDE, Molón, Softwarelibre.
Siempre se dice que KDE es una Comunidad ¿Tú qué opinas?
Creo que es la decisión de modificar la referencia de KDE desde un proyecto software hasta una comunidad ha sido correcta. Actualmente se puede ver como KDE se compone de varios proyectos en ocasiones muy dispares (por ejemplo: Plasma, Frameworks, Wikitolearn, Kirigami,, Plasma mobile, Krita, etc.) pero todos los colaboradores os vemos como que formamos parte del mismo equipo.

Te gusta asistir a los eventos ¿por qué? Cuéntanos alguna anécdota.

Siempre es interesante encontrarse en persona y escuchar a la gente.

Sí, por supuesto. Cuando comienzas a moverte en este entorno, al principio como usuario, es una oportunidad el poder conocer y hablar con la gente que hace el software que te gusta, y si eres desarrollador, a la gente que trabaja contigo.
Como anécdota reciente, en la QtCon/Akademy de Berlín había un estudiante que había venido con la idea únicamente de asistir a las ponencias del fin de semana y finalmente decidió quedarse la semana completa y participar en los BOFs y en el FOSDEM de este año lo volví a ver y me comentó que ya estaba colaborando en KDE (en concreto en minuet y haciendo algunas cosas de la comunidad francesa de KDE).

Y para finalizar, me gustaría que nos diéses tu visión de la Comunidad KDE en un futuro.

Creo que el pack Frameworks + Plasma + KDE Applications seguirán siendo nuestros “flagship projects”, por otra parte hay otros proyectos que son muy interesantes tales como wikitolearn, KDE Connect o versiones para Android de nuestras aplicaciones que a medio plazo podrían conseguir un éxito mayor en usuarios y colaboradores que nuestros proyectos principales. Será una oportunidad clave para KDE el conseguir integrar en la comunidad a dichos usuarios y desarrolladores.

 

Preguntas rápidas:

¿KDE 4 o Plasma 5?
Creo que con Plasma 4 habíamos conseguido en las últimas versiones un gran producto a pesar de su inicio claramente inestable. Con Plasma 5 hemos obtenido un producto muy estable desde el principio y versión a versión está incluyendo más funcionalidades sin perder este buen funcionamiento, por lo que si ya ahora es un producto de muy buena calidad no me puedo ni imaginar como será dentro de unos años.

 Aplicación que más te gusta de KDE
Una de mis preferidas es Dolphin, y también KDevelop.

Aplicación que te gustaría tener nativa en KDE
Sigo con mucho interés el desarrollo de Kube, creo que cuando se publique la primera versión estable será un gran éxito.

 

Ahora tu minuto de oro, cuenta lo que quieras para los lectores de KDE Blog.
Me gustaría en primer lugar agradeceros a todos que leáis KDE Blog y así estáis al día de las novedades de KDE. Me gustaría también invitaros a que os comuniques con nosotros ya sea a través del grupo de Telegram KDE Cañas y Bravas, de nuestras cuentas en las redes sociales, de nuestras listas de correo, en los foros KDE o reportando un bug si detectan cualquier problema o tienen cualquier sugerencia sobre alguno de nuestros productos.
Muchas gracias por tu tiempo y por tus palabras, estoy seguro que los lectores del blog habrán disfrutado tanto de la entrevista como yo y…

A small new feature that was added to Qt 5.8 is the ability for moc (Qt’s meta-object compiler) to extract meta-object information at the namespace level. This means, for instance, that you can have introspection support for enumerations defined in a namespace (not just in QObject subclasses, or classes tagged with Q_GADGET), and use such enumerations in QtScript, QtDBus and QML.

Introducing Q_NAMESPACE

The support for all of this involves a few new macros. The most important one is …

The post New in Qt 5.8: meta-object support for namespaces appeared first on KDAB.

I’m extremely happy to finally announce the first stable release of heaptrack, the FOSS heap memory profiler for C/C++ Linux applications. You can download the source tarball from the KDE mirrors: https://download.kde.org/stable/heaptrack/1.0.0/src/

Heaptrack is a fast heap memory profiler that runs on Linux. It allows you to track all heap memory allocations at run-time. Afterwards, the accompanying GUI tool can be used to find optimization opportunities in your code by analyzing the recorded profiling data. It allows you to:

  • Inspect

The post Heaptrack v1.0.0 Release appeared first on KDAB.

I'm very excited to announce the release of KStars 2.7.5 for MacOS and Windows!

This is the first official KStars release for MacOS 10.11+, and while we made sure to test it thoroughly, please treat it as a beta release and report any bugs to the KDE bug tracking website.



KStars for MacOS supports all the features of the Linux KStars release, including Ekos and INDI. It comes ready with astrometry.net support, xplanet, and ability to download and install General Star Catalog (GSC) data used for CCD Simulator stars.

Most INDI drivers are imported with the exception of few Linux-specific drivers; we are investigating different approaches to improve INDI 3rd party drivers support under OSX. This release would not have been possible if not for the tireless efforts of KStars developers and INDI forums members.

Specifically, I'd like to thank the following volunteers for their significant contribution to the MacOS release:

  • Robert Lancaster: KStars latest developer and chief driver of the MacOS release. Robert greatly improved the usability and cross-platform capabilities of KStars while adding several very exciting and useful features to both KStars and Ekos.
  • Stephane Lucas: Initiated the longest (110+ pages) INDI thread Ekos for OS X that resulted in this release. Stephane carried out extensive testing and suggestions for Ekos Scheduler and aided in the KStars OSX Port.
  • Jamie Smith: Developed script to automate building of KStars using Craft, CMake, and XCode methods in addition to automating DMG builds.
Many INDI forums users also helped in testing this release, so I'd like to extend my thanks to all our users.

Along with the Mac OS release, a new KStars for Windows 64bit release is also available for download. You can download both release from KStars website.


Qt 5.8 has just been released! Another great release of Qt, made possible by thousands of commits by over a hundred different contributors:

Commit percentages to Qt in the last 16 weeks, grouped by employer

And here we are again, with the usual showcase of the most outstanding contributions to Qt 5.8 developed by KDAB engineers.

In no particular order:

Qt 3D

Qt 3D continues to receive lots of improvements and bugfixes, thanks to the hard work of …

The post KDAB contributions to Qt 5.8 appeared first on KDAB.

We have released version 2.7 of our Qt application introspection tool GammaRay. GammaRay allows you to observe the behavior and data structures of Qt code inside your program live at runtime.

Here are a few of the highlights of this release:

  • The new Qt 3D geometry inspector allows you to look at a wireframe rendering of entity geometries, as well as the raw OpenGL buffer data. Visualizations of normal vectors and backface culling help to identify common problems in geometry

The post GammaRay 2.7.0 Released appeared first on KDAB.

Knowing what tools are at your disposal when looking to make a program faster or keep it operating smoothly is critical to your success as a programmer. We recently solved a performance problem using Linux Kernel Tracepoints so we thought we’d share the process with you so that you can see for yourself if this tool makes sense in your toolkit.

Our challenge: the database writes in a customer’s application normally took under 5ms but occasionally spiked to over 150ms, …

The post Slaying Latency with Linux Kernel Tracepoints appeared first on KDAB.

February 27, 2017

Hi there,

TL;DR

If you don’t know, go there first: https://community.kde.org/Guidelines_and_HOWTOs/Documentation_in_wikis

Some documentation issues

I’ve been asked a lot lately about some directions to document new projects in KDE.
I’ve seen as well an awesome tutorial being published on Planet KDE, with a very wrong address.

To counter that I wrote a page [1] that explains everything in details. If it’s not enough, just ping me and let me know.

A recap of previous episodes

During the sprint at CERN, we worked at a logical organization of our wikis [2].

On the Community wiki (https://community.kde.org), you’ll find a Guides and HOWTOs page, in which we try to centralize all the generic tutorials for KDE newcomers (and old ones as well :D). Go there whenever you have questions, take the time to read the pages, correct them if needed, add new ones if you think something is missing.

Even Specially if you’re new to KDE, write tutorial about what you find unclear, and ask us for review. You are the ones who know what information is missing!!

Cheers and have fun !
Olivier

Links

[1] https://community.kde.org/Guidelines_and_HOWTOs/Documentation_in_wikis
[2] https://blogs.churlaud.com/somefoobar/2016/03/17/we-reorganized-most-of-the-wikis-we-need-you/

Could you tell us something about yourself?

I flow between the frugal pal who can still find a creative way of making art even when the limitations get worse; And the bon vivant of me and my father at art supplies stores like they were literally our home sweet home. My current notebook is a shabby 32GB onboard flash-disk that barely allows me to draw in a screen sized canvas with Krita Gemini. Yes, I’m using a touch screen pen because my notebook ignores and treats my Intuos 2 as a mouse. So I’m having a much better experience with my tiny android phone with its drawing apps. One of those apps, Autodesk Sketchbook, under my circumstances now, is my only choice for 2D Digital Painting. Good stuff, bought it and am making comics with it!!! Hahahaha.

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

I’m an artist drawing professionally since 1994, had my first watercolors exposition in 2001, india ink illustrations for an Irish literature book in 2007, and acrylics paintings expositions between 2008 and 2016.

What genre(s) do you work in?

Among other genres, as in visual storytelling, storyboarding and zines, I work in comedy (though making someone laugh is so hard they could totally mistake it for serious/not kidding.)

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

The hard-work of Peleng, and so natural of Kim Jung Gi inspires me the most, though I wish Gi was ambidextrous — but the Italian designer Bruno Munari is my role model as an artist. Among many of Munari’s professional values, I’m talking about his separation between purely commercial artifacts or artifacts of complete accessibility.

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

Worst experience of my entire teeenager all nighters! Heheh. I didn’t know how to ask the right questions of the right people, and because my example of digital art came from a mag filled with some nice and detailed 2D Digital Illustrations, I, instead of understanding that all that cool DOOM game sprites were what I was supposed to draw, I tried to do the big illustrations, very similar to traditional, that I saw in the digital art magazine I had.

What makes you choose digital over traditional painting?

I don’t, it is binary, I can choose to paint either traditional or digital.

I’ve been working on my art in three very different ways: the first one aims for beauty, perfection, even if impossible to reach. The closest I’ve got was on two pieces, Find the Sacred in Humanity (the featured image) – traditional painting of singer Julie Wein, and a 2D Digital Portrait of a Civilian Baby. The second way is pure entertainment, that’s the one all done on Krita, where I give life to Character Design Model Sheets producing industry material, which then can be adapted and shared in games and movies as long as for non-commercial uses. And the third is Underground Zine Publishing (this one is under the WTFPL, a very permissive license for artistic works that offers a great degree of freedom).

How did you find out about Krita?

Fernando Michelotti told me I would work better on something totally developed artist-centered (instead of any open source image manipulation program or proprietary raster graphics editor).

What was your first impression?

“I know Kung-Fu”

What do you love about Krita?

My first impression only gets stronger.

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

Improvement: ideally what for more than a decade only IllustStudio (a software that you need to have an address in Japan to be eligible to pay monthly subscription) has, the surface coating feature: http://herionz.deviantart.com/art/Illuststudio-Surface-Coating-tool-tips-290615045, but at least the al.chemy.org Create > Pull Shapes. Annoys me: It’s ok that it isn’t the de facto standard for 2D digital painting on all Linux distros, but that fact annoys me. It is like a childhood without Metroid, which is my case.

I bought other softwares, one for comics and another for vector art. But for concept art I’ve chosen Krita, beyond any other competitor. And if Krita had all the features of http://al.chemy.org/ I wouldn’t need to work on my silhouettes with al.chemy. And if Krita Gemini was an app for android I’d pay any fair price, hell, I’d pay a monthly subscription. I love mobility and tiny A-6 paper books and sketchbooks, so an android phone with krita app would be one of my biggest dreams come true, especially when I get an iPad Pro I’ll probably receive mid 2017.

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

Let me stretch this a little bit. Imagine a world where almost more than half of the population is way too poor to pay not only for the de facto industry standard in raster graphics editing but anything, Then picture that somewhere nearby each group of people there is a very slow computer, and in one of the seldom hours the very slow Internet works they download Krita. Okay, we don’t need to go to that level under misery to understand Krita, see the possibility of way more artists, even paid professional. Simply imagine what happens when people whose only property is lifetime finally control the means of production. But that’s just text, very fantastic or a fantasy, because I don’t know if what I just wrote has any example in our societies. But anything close to what I wrote definitely sets Krita apart from other tools that I use.

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


“Catman” (face closeup). Because I did it all with only one brush, and only kept using two features: the X key to switch fore to background brush color and the hold Ctrl + click to sample colors, witch makes the Block_brush preset kick ass.

Where can people see more of your work?

http://www.edli.work

Anything else you’d like to share?

I’d like to acknowledge my friend Fernando Michelotti without whom I’d might never heard of Krita, again, like my childhood without Metroid — thx NES emulators for fixing that childhood bug — and acknowledge Fernando for knowing so much about the Krita staff and always saying cool stuff about you guys. The digital world is very warm only when you’re not simply in front of a painting software screen but also feeling connected to a whole community that makes digital painting accessible almost to everyone.

 

Some days of the week, I work on Free Software projects that aren’t ready to see the light yet; they live in my own git repo’s, or wherever. While I have the intention of publishing eventually, I usually want to get things somewhat working before throwing code out there.

Part of checking if things work is packaging, and installing the stuff on more than one system. Sure, I can build everywhere, or copy around executables, but it struck me that it’d be cool to have packages — you know, installable with the system package manager — for the stuff I make. O yeah, I know flatpak is the new orange, but I’m not that hip. I’ll stick with Debian and FreeBSD packages, thanks.

And so my thoughts turned to CPack, for the reasons (well, because it’s there anyway and I use cmake as meta-buildsystem for almost everything).

So I spent two days messing with CPack internals and exercising libpkg (from pkg(8)) and writing code and then throwing it away (because can replace a half day of me trying to be clever quite easily).

At this point I’m happy to report that I’ve got a working CPack FreeBSD package generator. Like any package, it needs some metadata to be set before it can actually produce an installable package: things like who is the package maintainer, package description, etc.

I’m taking the position that this way of producing packages is auxiliary to the official packaging mechanisms (in FreeBSD, that would be via ports). So for these unofficial packages, the metadata is of less importance; they’re for unofficial, or for testing, purposes. With that in mind I decided to re-use as many of the package-metadata settings from Debian as I could find, and put bogus (e.g. example.com) defaults in the rest. That way, you can get away with very little metadata setting in CMakeLists.txt before CPack’s FreeBSD package generator is happy.

Here’s a minimal CMakeLists.txt which will successfully be packaged using the CPack FreeBSD generator:

set(CPACK_PACKAGE_CONTACT "groot@kde.org")
set(CPACK_PACKAGE_LICENSE "GPLv2")

include(CPack)

add_executable(hw hw.c)
install(TARGETS hw DESTINATION bin)

Notice that there’s nothing FreeBSD-specific in there. For testing purposes, or maybe also for proprietary software, it’s reasonable to have just one contact address, so the packaging falls back to using the generic CPACK_PACKAGE_CONTACT. Of course there’s also CPACK_FREEBSD_MAINTAINER, just like there’s CPACK_DEBIAN_PACKAGE_MAINTAINER, for setting specific maintainers for different packaging if you want to do that. Similarly, there’s a generic license setting, but in the unlikely chance that the license identifier specified generically isn’t recognized by the packaging system, you can override it. The default for project-homepage is example.com, but if CPACK_DEBIAN_PACKAGE_HOMEPAGE is set, that gets used; CPACK_FREEBSD_PACKAGE_WWW can also be used — but that only makes sense if the homepage of the upstream project is different for FreeBSD than for Debian, which seems unlikely. The rest of the variables that influence CPack FreeBSD package generation are described in the CPack script for it. The only thing specific to FreeBSD packaging that you might really need to set manually is CPACK_FREEBSD_PACKAGE_DEPS, which is a list of ports-origins on which the package depends. I may try to generate this automatically, even — libpkg knows about shared-libs dependencies, and could query the package database as well to get whatprovides information — but not right now.

Anyway, I’m going to add this to FreeBSD’s cmake package, so that we can experiment with it downstream. In the medium term I’m going to try to merge it upstream. It surprises me a little that there’s no Flatpak generator: surely that can’t be too difficult to wrangle up (or maybe there’s no point — the intro-to-Flatpak workshop given in Randa was a long time ago). And now, having spent two days messing around on infrastructure for my other projects, I can get back to those.

A pesar de que la atención del equipo de desarrolladores de KDE tiene un nuevo foco de interés con Plasma 5.9 no ha dejado de lado su anterior escritorio. Por ello me congratula anunciar la sexta actualización de Plasma 5.8 LTS, la cual es bienvenida y recomendada para todos los usuarios que estén utilizando la versión de soporte extendido.

Sexta actualización de Plasma 5.8 LTS

El pasado 4 de octubre de 2016 fue lanzado Plasma 5.8 LTS, tal y como estaba previsto en su calendario como es habitual en el proyecto KDE. Hay que recordar que esta rama es muy especial porque es el símbolo de la madurez de este escritorio por el gran tiempo de soporte de esta versión.

Casi cinco meses más tarde, el pasado 21 de febrero de 2017, fue lanzada la sexta actualización de Plasma 5.8. Y como es habitual el equipo de desarrolladores recomiendan su actualización ya que aunque no ofrece novedades si corrige errores molestos y mejoras en las traducciones.

Cuarta actualización de Plasma 5.8

Las novedades, claro está son nulas, simplemente se trata de ir arreglando pequeños errores aquí y allá. Si queréis ver toda la lista de cambios os recomiendo leer el changelog,

Más información: KDE.org

Las novedades de Plasma 5.8

Los desarrolladores han trabajado muy duro para que este Plasma 5.8 sea el más rápido y fluido de todos los lanzados hasta la fecha. Por ello han dedicado mucho tiempo a optimizar su funcionamiento. Es notable la optimización de los recursos del sistema y la fluidez que presenta toda la interfaz.

Podemos ver algunas de las novedades mirando el siguiente vídeo:

Y, como complemento del vídeo, os redacto algunas de ellas:

  • Aspecto visual unificado para las pantallas de bienvenida y cierre del sistema.
  • Soporte mejorado para idiomas que escriben de derecha a izquierda.

Sexta actualización de Plasma 5.8 LTS

  • Mejoras en widgets como el paginador o el gestor de tareas
  • Grandes mejoras en los atajos de teclado globales.
  • Mejoras en el soporte de multimonitores
  • Discover ha sido portado a Kirigami
  • Soporte para Wayland, incluso para aplicaciones GTK

En definitiva, otro paso en la evolución de Plasma, un escritorio que sigue sumando adeptos y mejorando versión tras versión.

February 26, 2017

During the last foss-gbg meeting I tried filming the entire event. The idea is to produce videos of each talk and publish them on YouTube. Since I’m lazy, I simply put up a camera on a tripod and recorder the whole event, some 3h and 16 minutes and a few seconds. A few seconds that would cause me quite some pain, it turns out.

All started with me realizing that I can hear the humming sound of the AC system in the video. No problem, simply use ffmpeg to separate the audio from the video and use the noise reduction filter in Audacity. However, when putting it all together I recognized a sound sync drift (after 6h+ of rendering videos, that is).

ffprobe told me that the video is 03:16:07.58 long, while the extracted audio is 03:16:04.03. This means that the video of the last speaker drifts more than 3s – unwatchable. So, googling for a solution, I realized that I will have to try to stretch the audio to the same duration as the video. Audacity has a tempo effect to do this, but I could not get the UI to accept my very small adjustment in tempo (or my insane number of seconds in the clip). Instead, I had to turn to ffmpeg and the atempo filter.

ffmpeg -i filtered.ac3 -filter:a "atempo=0.9996983236995207" -vn slower.ac3

This resulted in an audio clip of the correct length. (By the way, the factor is the difference in length of the audio and video).

Back to kdenlive – I imported the video clip, put it on the time line, separated the audio and video (just a right click away), ungrouped them, removed the audio, added the filtered, slowed down audio, grouped it with the video and everything seems nice. I about 1h43 I will know when the first clip has been properly rendered :-)

 The “Plasma tricks” series continues, I have a list of ~10 cool tricks but not the time to post them regularly. Today I decided to share this one because with Plasma 5.9 you can pin apps in task manager by Activity:

Pin app to current activity
But what if you don’t like to pin apps in the task manager, but want a menu with different apps for each Activity? Now I will explain how to get the result in the video below:
(direct link in case it’s not shown: https://streamable.com/eqdxr)
 
  1. Copy the app launchers you want from /usr/share/applications/ or ~/.local/share/applications/ to somewhere in your home or manually write them
  2. Right click on them > Activities > Link to the Activities you want to show them
  3. On your panel add a Folder View plasmoid and set it as follow:

Show files from current Activity

(Location > Show files linked to the current activity)

Filter desktop files

(Filter > Show Files Matching and select ONLY application/x-desktop)

Now play with other options like icon, title, view etc as you want. The wallpapers are available on my profile on KDE Store as part of the “Plasma Activities series” and so you can download them directly from Plasma’s get new wallpapers dialog.

I hope you find this useful, ciao!

February 25, 2017

The KDE-FreeBSD team bumped Qt to 5.7.1 and KDE Frameworks to 5.31.0 in official ports last week, so we’re fairly up-to-date in that department. On FreeBSD, we still fully support Qt4 next to Qt5, so some of the delay in getting this stuff in is due to some shuffling of install locations. In particular, we’ve added qt-chooser in this round of updates, so that qmake is qmake — and no longer qmake-qt4 or some other suffixed binary. We use qt-chooser to switch out one or the other. Checking that this doesn’t break anything else — or at least making sure that everything still compiles — is what took the most time this round of updates.

So we’re edging closer to getting Plasma 5 Desktop; TCBerner intends to import it together with all the KDE Frameworks-based KDE Applications. That makes it a grand shuffling of ports — and that again takes lots of time.

I’m about to embark on an examination of kcheckpass — we still have two of them, even, one kdelibs4-based and one kf5-based — because the Plasma maintainers would like to clean up the code, and have asked distro’s to double-check what actually gets used on each platform. (And kcheckpass is tricksy, like the time in 2003 or so I locked out all the sysadmins at the university by updating the KDE packages, but forgot to setuid it ..)

Anyway, the usual applies: Plasma 5 and KDE Applications are fine to use on FreeBSD, from the area51 repository, and official ports just keep getting closer, bit-by-bit.

During last year's Summer of Code I had the honor of mentoring Nanduni Indeewaree Nimalsiri. She worked on Inqlude, the comprehensive archive of third party Qt libraries, improving the tooling to create a better structured web site with additional features such as categorization by topic. She did an excellent job with it and all of her code ended up on the master branch. But we hadn't yet made the switch to change the default layout of the web site to fully take advantage of all her work. As part of SUSE's 15th Hack Week, which is taking place this week, I took some time to change that, put up some finishing touches, and switch the Inqlude web site to the new layout. So here we are. I proudly present the new improved home page of Inqlude.


All libraries have additional meta data now to group them by a number of curated topics. You can see the topics in the navigation bar on the left and use them to navigate Inqlude by categories. The listing shows more information on first view, such as the supported platforms, to make it easier to find libraries according to your criteria without having to navigate between different pages. The presentation in general is cleaner now, and some usability testing has shown that the page works better now than before. In addition to the visible changes, Nanduni has also done quite a bit of improvements under the hood, including better automated testing. I'm proud of what we have achieved there.

It always has been a privilege for me to act as mentor as part of Google's Summer of Code or other programs. This is one of the most rewarding parts of working in free software communities, to see how new people learn and grow, especially if they decide to stay involved after the program has ended and become valuable members of the community for the long term. Being able to help with that I feel is one of the most satisfying investments of your time in the community.

February 24, 2017

Let’s say you got a 64-bit ARM device running Android. For instance, the Tegra X1-based NVIDIA Shield TV. Now, let’s say you are also interested in the latest greatest content from the dev branch, for example to try out some upcoming Vulkan enablers from here and here, and want to see all this running on the big screen with Android TV. How do we get Qt, or at least the basic modules like QtGui, QtQuick, etc. up and running on there?

nv_shield_2017 Our test device.

In this little guide we are going to build qtbase for Android targeting AArch64 and will deploy some examples to the Android TV device. To make it more interesting, we will do this from Windows.

Pre-requisites

The Qt documentation and wiki pages document the process fairly well. One thing to note is that a sufficient MinGW toolchain is easily obtainable by installing the official 32-bit MinGW package from Qt 5.8. Visual Studio is not sufficient as of today.

Once MinGW, Perl, git, Java, Ant, the Android SDK, and the 32-bit Android NDK are installed, open a Qt MinGW command prompt and set some environment variables:

set PATH=c:\android\tools;c:\android\platform-tools;
  c:\android\android-ndk-r13b;c:\android\qtbase\bin;
  C:\Program Files\Java\jdk1.8.0_121\bin;
  c:\android\ant\bin;%PATH%
set ANDROID_API_VERSION=android-24
set ANDROID_SDK_ROOT=c:\android
set ANDROID_BUILD_TOOLS_REVISION=25.0.2

Adapt the paths as necessary. Here we assume that the Android SDK is in c:\android, the NDK in android-ndk-r13b, qtbase/dev is checked out to c:\android\qtbase, etc.

The Shield TV has Android 7.0 and the API level is 24. This is great for trying out Vulkan in particular since the level 24 NDK comes with the Vulkan headers, unlike level 23.

Build qtbase

Now the fun part: configure. Note that architecture.

configure -developer-build -release -platform win32-g++
  -xplatform android-g++ -android-arch arm64-v8a
  -android-ndk c:/android/android-ndk-r13b -android-sdk c:/android
  -android-ndk-host windows -android-ndk-platform android-24
  -android-toolchain-version 4.9 -opensource -confirm-license
  -nomake tests -nomake examples -v

Once this succeeds, check the output to see if the necessary features (Vulkan in this case) are enabled.

Then build with mingw32-make -j8 or similar.

Deploying

To get androiddeployqt, check out the qttools repo, go to src/androiddeployqt and do qmake and mingw32-make. The result is a host (x86) build of the tool in qtbase/bin.

For general information on androiddeployqt usage, check the documentation.

Here we will also rely on Ant. This means that Ant must either be in the PATH, as shown above, or the location must be provided to androiddeployqt via the –ant parameter.

Now, Qt 5.8.0 and earlier have a small issue with AArch64 Android deployments. Therefore, grab the patch from Gerrit and apply on top of your qtbase tree if it is not there already. (it may or may not have made its way to the dev branch via merges yet)

After this one can simply go to a Qt application, for instance qtbase/examples/opengl/qopenglwidget and do:

qmake
mingw32-make install INSTALL_ROOT=bld
androiddeployqt --output bld
adb install -r bld/bin/QtApp-debug.apk

Launching

Now that a Qt application is installed, let’s launch it.

Except that it does not show up in the Android TV launcher.

One easy workaround could be to adb shell and do something like the following:

am start -n org.qtproject.example.qopenglwidget/org.qtproject.qt5.android.bindings.QtActivity

Then again, it would be nice to get something like this:

nv_shield_qopenglwidget_launcher

Therefore, let’s edit bld/AndroidManifest.xml:

<intent-filter>
  <action android:name="android.intent.action.MAIN"/>
  <!--<category android:name="android.intent.category.LAUNCHER"/>-->
  <category android:name="android.intent.category.LEANBACK_LAUNCHER" />
</intent-filter>

and reinstall by running ant debug install. Changing the category name does the trick.

Note that rerunning androiddeployqt overwrites the manifest file. A more reusable alternative would be to make a copy of the template, change it, and use ANDROID_PACKAGE_SOURCE_DIR.

The result

Widget applications, including OpenGL, run fairly well:

nv_shield_qopenglwidget

Or something more exciting:

qqvk_shield_1

No, really. That clear to green is actually done via Vulkan.

qt_vk_android_texture

And finally, the hellovulkantexture example using QVulkanWindow! (yeah, colors are a bit bad on these photos)

adb logcat is your friend, as usual. Let’s get some proof that our textured quad is indeed drawn via Vulkan:

qt.vulkan: Vulkan init (libvulkan.so)         
vulkan  : searching for layers in '/data/app/org.qtproject.example.hellovulkantexture-2/lib/arm64'     
...
qt.vulkan: Supported Vulkan instance layers: QVector()              
qt.vulkan: Supported Vulkan instance extensions: QVector(QVulkanExtension("VK_KHR_surface" 25), QVulkanExtension("VK_KHR_android_surface" 6), QVulkanExtension("VK_EXT_debug_report" 2))    
qt.vulkan: Enabling Vulkan instance layers: ()                                                                                            
qt.vulkan: Enabling Vulkan instance extensions: ("VK_EXT_debug_report", "VK_KHR_surface", "VK_KHR_android_surface")                     
qt.vulkan: QVulkanWindow init                                                                                                        
qt.vulkan: 1 physical devices                                                                                                              
qt.vulkan: Physical device [0]: name 'NVIDIA Tegra X1' version 361.0.0                                                                     
qt.vulkan: Using physical device [0]                                                                                                      
qt.vulkan: queue family 0: flags=0xf count=16                                                                                                               
qt.vulkan: Supported device layers: QVector()                                                                                      
qt.vulkan: Enabling device layers: QVector()                                                                                       
qt.vulkan: Supported device extensions: QVector(QVulkanExtension("VK_KHR_swapchain" 68), QVulkanExtension("VK_KHR_sampler_mirror_clamp_to_edge" 1), QVulkanExtension("VK_NV_dedicated_allocation" 1), QVulkanExtension("VK_NV_glsl_shader" 1))                                                                                
qt.vulkan: Enabling device extensions: QVector(VK_KHR_swapchain)                                                     
qt.vulkan: memtype 0: flags=0x1                                                 
qt.vulkan: memtype 1: flags=0x1                           
qt.vulkan: memtype 2: flags=0x7                             
qt.vulkan: memtype 3: flags=0xb                               
qt.vulkan: Picked memtype 2 for host visible memory             
qt.vulkan: Picked memtype 0 for device local memory     
initResources            
uniform buffer offset alignment is 256        
qt.vulkan: Creating new swap chain of 2 buffers, size 1920x1080       
qt.vulkan: Actual swap chain buffer count: 2                
qt.vulkan: Allocating 8847360 bytes for depth-stencil        
initSwapChainResources              
...

Should you need validation layers, follow the instructions from the Android Vulkan docs and rebuild and redeploy the package after copying the libVkLayer* to the right location.

That’s all for now. Have fun experimenting. The basic Vulkan enablers, including QVulkanWindow are currently scheduled for Qt 5.10, with support for Windows, Linux/X11, and Android. (the list may grow later on)

The post Building the latest greatest for Android AArch64 (with Vulkan teaser) appeared first on Qt Blog.

After much preparation, the tickets for foss-north 2017 is available at foss-north.se – grab them while they are hot!

The call for papers is still open (do you want to talk – register!) so we do not have a final schedule, but you will find our confirmed speakers on the web site as we grow the list. Right now, we know that have the pleasure to introduce:

  • Lydia Pintscher, the product manager of Wikidata, Wikimedia’s knowledge base, as well as the president of KDE e.V.
  • Lennart Poettering, from Red Hat known for systemd, PulseAudio, Avahi and more.
  • Jos Poortvliet, with a background from SUSE and KDE, he now heads marketing at Nextcloud.

The conference covering both software and hardware from the technical perspective. The event is held on April 26 in central Gothenburg located between Copenhagen, Oslo and Stockholm with an international airport.

This is a great excuse to visit a really nice part of Sweden while attending a nice conference – welcome!

Today the Kubuntu team is happy to announce that Kubuntu Zesty Zapus (17.04) Beta 1 is released . With this Beta 1 pre-release, you can see and test what we are preparing for 17.04, which we will be releasing in April.

NOTE: This is Beta 1 Release. Kubuntu Beta Releases are NOT recommended for:

* Regular users who are not aware of pre-release issues
* Anyone who needs a stable system
* Anyone uncomfortable running a possibly frequently broken system
* Anyone in a production environment with data or work-flows that need to be reliable

Getting Kubuntu 17.04 Beta 1:
* Upgrade from 16.10: run `do-release-upgrade -d` from a command line.
* Download a bootable image (ISO) and put it onto a DVD or USB Drive : http://cdimage.ubuntu.com/kubuntu/releases/zesty/beta-1/

Release notes: https://wiki.ubuntu.com/ZestyZapus/Beta1/Kubuntu

February 23, 2017

Some time ago I posted a blog post about how I packed telegram desktop client for flatpak. I’ve been updating it since then in some reasonable intervals as I don’t have time to update it more often and mostly because the telegram client’s build system breaks my build quite oftenly. Recently I discovered that someone managed to patch telegram to use system Qt libraries instead of building own patched Qt and building linking it statically. After some time I managed to adjust those patches and make them work with my build which allows me to use Qt from KDE runtimes. Here are new instructions how to get this work:

Add KDE runtimes repository and install runtimes
$ flatpak remote-add kde --from https://distribute.kde.org/kderuntime.flatpakrepo
$ flatpak install kde org.kde.Platform

And then you can install and run the telegram desktop client:
$ wget https://jgrulich.fedorapeople.org/telegram/keys/telegram.gpg
$ flatpak remote-add --gpg-import=telegram.gpg telegram-desktop https://jgrulich.fedorapeople.org/telegram/repo/
$ flatpak install telegram-desktop org.telegram.TelegramDesktopDevel
$ flatpak run org.telegram.TelegramDesktopDevel

Or install it from bundle
$ wget https://jgrulich.fedorapeople.org/telegram/telegram.flatpak
$ flatpak install --bundle telegram.flatpak

The reason I did the hard work to build it with Qt from KDE runtimes is that now you can use telegram with portals support if you run it with “-platform flatpak” parameter. Unfortunately this only makes openURI portal to work as telegram has some internal hacks or whatever to use gtk filedialog so for that reason I still allow to access user’s home directory. There is also a bug if you use telegram under KDE where it tries to use QSystemTrayIcon instead of libappindicator and unfortunately telegram’s system tray icon (the one using QSystemTrayIcon) works only with Qt 5.6.2 and in KDE runtimes we have Qt 5.7.1. The system tray icon is visible, but its context menu doesn’t work so if you want to have fully working system tray icon you have to use “–env=XDG_CURRENT_DESKTOP=gnome” flatpak parameter to force it to use libappindicator.

And that’s it. Sorry you had telegram broken for couple of days while I was fighting with it, but hopefully it will work perfectly now.

I am happy to inform you that Qt 5.9 Alpha has been released today.

Qt 5.9 Alpha is an important milestone on our way to the final Qt 5.9.0 release, which is targeted to be released by the end of May 2017.

The Alpha release is available only as source packages. Binary installers will be available via the online installer in conjunction with the Beta release as well as development snapshots during the coming weeks.

To learn about the features in Qt 5.9, please read the Qt 5.9 new features page. For more detailed overview of some Qt 5.9 key features, check the Qt Roadmap for 2017 blog post.

If you want to try Qt 5.9, please download the Qt 5.9 Alpha source packages from your Qt Account or from download.qt.io.

Please remember to give us feedback by writing to the mailing lists and reporting bugs.

The post Qt 5.9 Alpha Released appeared first on Qt Blog.

February 22, 2017

WebGL Streaming is optimized for Qt Quick and allows you to run remote Qt Quick applications in a browser.

I’m working on a platform plugin to run remote applications in your browser, using OpenGL command streaming.

When the remote application runs using this new platform plugin, the application will create a lightweight web server. When a user connects to the application, a web socket connection is opened between the server and the client, using QWebSocketServer.
The application running on a remote computer will serialize all GL calls to binary data and sends it using the web socket connection.

The local browser will send the event (mouse, touch or keyboard) to the remote application, so user interaction is allowed. Even multi-touch support! (up to 6 fingers):

And some Qt Quick demos running in the browser:

The “calqlatr” example:

“clocks” example:

“emitters” (particles) example:

“samegame” example:

Desktop browsers are also supported:
webgldemo

It allows multiple connections to the same application.

screenshot_20170222_183836

New windows are shown in a different canvas in the browser.screenshot_20170222_184419

To improve the performance, I’m also working to support web sockets compression. To be able to use the permessage-deflate extension. It’s actually working but needs more testing.

This feature is going to be introduced in Qt 5.10 as appears in the 2017 roadmap.

The post Qt Quick WebGL Streaming appeared first on Qt Blog.

KDE had 4 talks at this year's FOSDEM conference. Here's the recordings.

From Gtk to Qt: A Strange Journey, part 2

The continuation of the original talk from Dirk Hohndel and Linus Torvalds about the port of Subsurface from Gtk to Qt, now with mobile in mind.

Kube

The next generation communication and collaboration client

Bundling KDE

Where does KDE land in the Snap and Flatpak world?

KDE SlimBook Q&A

February 21, 2017

One of the interesting things about working with Qt is seeing all the unexpected ways our users use the APIs we create.  Last year I got a bug report requesting an API to set a custom frame rate for QML animations when using QQuickRenderControl.  The reason was that the user was using QQuickRenderControl as an engine to render video output from Qt Quick, and if your target was say 24 frames per second, the animations were not smooth because of how the default animation driver behaves.  So inspired by this use case I decided to take a stab at creating such an example myself.

screen-shot-2017-02-21-at-12-46-27

This may not be the most professional looking User Interface, but what it does is still pretty neat.  The objective is to feed it an animated QML scene and it should output an image file for each frame of the animation.  These images can then be converted into a video or animated image using an external tool.  The challenge is that Qt Quick is a UI tool, not a movie generator.

The naive approach to this would be to create a QQuickWindow, set the window size to the output target size, and then grab the frame by calling QQuickWindow::grabWindow() each time the frameSwapped() signal is emitted.  There are a couple of issues with this approach though.  First is that the video would need to render in realtime.  If you wanted to render an animation that was 5 minutes long, it would take 5 minutes because it would just be like recording your application for 5 minutes.  The second issue is that under the best case scenario you would be rendering video at the refresh rate of your monitor. This would even require a reasonably powerful machine, because the QQuickWindow::grabWindow() call involves a glReadPixels call which is quite expensive.  It is also problematic if you need to render at a different frame rate than your monitor refresh (which is what the user that inspired me was complaining about).  So here is how I addressed both of these issues.

QQuickRenderControl

QQuickRenderControl is a magical class that lets you do all kinds of crazy things with Qt Quick content.  For our purposes we will use it to render Qt Quick content to an offscreen surface as fast as we can.  Rather than creating an on-screen QQuickWindow, we can create a dummy QQuickWindow and via render control we can render content to an QOpenGLFramebufferObject instead.

    // Setup Format
    QSurfaceFormat format;
    format.setDepthBufferSize(16);
    format.setStencilBufferSize(8);

    // Setup OpenGL Context
    m_context = new QOpenGLContext;
    m_context->setFormat(format);
    m_context->create();

    // Setup dummy Surface (to create FBO with)
    m_offscreenSurface = new QOffscreenSurface;
    m_offscreenSurface->setFormat(m_context->format());
    m_offscreenSurface->create();

    // Setup Render Control and dummy window 
    m_renderControl = new QQuickRenderControl(this);
    m_quickWindow = new QQuickWindow(m_renderControl);

    // Setup QML Engine
    m_qmlEngine = new QQmlEngine;
    if (!m_qmlEngine->incubationController())
        m_qmlEngine->setIncubationController(m_quickWindow->incubationController());

    // Finish it all off
    m_context->makeCurrent(m_offscreenSurface);
    m_renderControl->initialize(m_context);

The above gets QQuickRenderControl setup, then when the size is know and you can actually create the QOpenGLFramebuffer object and tell the dummy QQuickWindow thats where it will be rendering.

void MovieRenderer::createFbo()
{
    m_fbo = new QOpenGLFramebufferObject(m_size * m_dpr, QOpenGLFramebufferObject::CombinedDepthStencil);
    m_quickWindow->setRenderTarget(m_fbo);
}

And once that is done it’s just a matter of loading up the QML content and rendering it.  Unlike with QQuickWindow, QQuickRenderControl allows you to control when the steps of the rendering process occurs.  In our case we want to render as fast as possible so this is what our rendering setup looks like:

void MovieRenderer::renderNext()
{

    // Polish, synchronize and render the next frame (into our fbo).
    m_renderControl->polishItems();
    m_renderControl->sync();
    m_renderControl->render();
    m_context->functions()->glFlush();

    m_currentFrame++;
 
    // Grab the contents of the FBO here ...

    if (m_currentFrame < m_frames) { 
        // Schedule the next update 
        QEvent *updateRequest = new QEvent(QEvent::UpdateRequest); 
        QCoreApplication::postEvent(this, updateRequest);
    } else { 
        //Finished cleanup();
    } 
} 
bool MovieRenderer::event(QEvent *event) { 
    if (event->type() == QEvent::UpdateRequest) {
        renderNext();
        return true;
    }
    return QObject::event(event);
}

The above sets up an event driven loop that will render as fast as possible while still handling events between frames, which is needed for progressing animations with Qt Quick.

Custom QAnimationDriver

The second issue we need to address is that the animation behavior is wrong.  To remedy this we need a custom QAnimationDriver that enables us to advance animations at our own frame rate.  The default behavior is to try and advance the animation’s in steps as close as possible to the refresh rate of the monitor your application is running on.  Since we never present the content we render to the screen that behavior doesn’t make sense for us.  Instead we can install our own QAnimationDriver which can be manually advanced each frame we generate based on a pre-determined frame rate.  Here is the whole implementation of my custom Animation driver:

class AnimationDriver : public QAnimationDriver
{
public:
    AnimationDriver(int msPerStep)
        : m_step(msPerStep)
        , m_elapsed(0)
    {}

    void advance() override
    {
        m_elapsed += m_step;
        advanceAnimation();
    }
    qint64 elapsed() const override
    {
        return m_elapsed;
    }
private:
    int m_step;
    qint64 m_elapsed;
};

Now to use this you just need to install the new QAnimationDriver.  When you call QAnimationDriver::install() it will replace the current one, so Qt Quick will then behave like we need it to.  When we start the movie renderer we also install the custom AnimationDriver:

    m_frames = m_duration / 1000 * m_fps;
    m_animationDriver = new AnimationDriver(1000 / m_fps);
    m_animationDriver->install();

    // Start the renderer
    renderNext();

And finally since we control the render loop, we need to manually advance the animation driver.  So before the end of the renderNext() method make sure to call:

m_animationDriver->advance();

And that is it.  Now we can render as fast as possible, and our animation engine will step perfectly for the frame rate we are generate frames for.  It is important to remember that you must process events after calling advance() on your animations though, because these are handled through the Qt Event and Signal and Slots system.  If you don’t do this, then you will generate the same frame many times.

Results

Once you run the MovieRenderer you end up with a folder full of images representing each frame.  To prepare video files from the generated output I used ffmpeg:

ffmpeg -r 24 -f image2 -s 1280x720 -i output_%d.jpg -vcodec libx264 -crf 25 -pix_fmt yuv420p hello_world_24.mp4

In the above command it will generate a 720p video at 24 fps from a series of files called output_*.jpg.  It would also be possible to create an example that either called this tool for you via QProcess, or even included an encoder library to generate the video directly.  I went for the simplest approach using only what Qt had built-in for this example.  Here are a few example movies I generated:

This first video is rendered at 60 FPS and the second is at 24 FPS.  Notice how they animate at the same speed but one is smoother than the other.  This is the intended behavior in action.

Well thats all I have to show, the rest is up to you.  I’ve published the code for the QML Movie Renderer here so go check it out now!  I hope this example inspires you as well to make other cool projects, and I look forward to seeing what new unexpected ways you’ll be using Qt in the future.

The post Making Movies with QML appeared first on Qt Blog.

This is the first in a series of blog posts on QStringView, the std::u16string_view equivalent for Qt. You can read about QStringView in my original post to the Qt development mailing-list, follow its status by tracking the “qstringview” topic on Gerrit and learn about string views in general in Marshall Clow’s CppCon 2015 talk, aptly named “string_view”.

But this post is not about QStringView — yet. It’s about QStringLiteral and its upcoming sister QStringViewLiteral.

continue reading

The post QStringView Diaries: Advances in QStringLiteral appeared first on KDAB.

…why not!

Shortly before FOSDEM, Aleix Pol asked if I had ever put Plasma in a Snap. While I was a bit perplexed by the notion itself, I also found this a rather interesting idea.

So, the past couple of weeks I spent a bit of time here and there on trying to see if it is possible.

img_20170220_154814

It is!

But let’s start in the beginning. Snap is one of the Linux bundle formats that are currently very much en-vogue. Basically, whatever is necessary to run an application is put into a self-contained archive from which the application then gets run. The motivation is to isolate application building and delivery from the operating system building and delivery. Or in short, you do not depend on your Linux distribution to provide a package, as long as the distribution can run the middleware for the specific bundle format you can get a bundle from the source author and it will run. As an added bonus these bundles usually also get confined. That means that whatever is inside can’t access system files or other programs unless permission for this was given in some form or fashion.

Putting Plasma, KDE’s award-winning desktop workspace, in a snap is interesting for all the same reasons it is interesting for applications. Distributing binary builds would be less of a hassle, testing is more accessible and confinement in various ways can lessen the impact of security issues in the confined software.

With the snap format specifically Plasma has two challenges:

  1. The snapped software is mounted in a changing path that is different from the installation directory.
  2. Confining Plasma is a bit tricky because of how many actors are involved in a Plasma session and some of them needing far-reaching access to system services.

As it turns out problem 1, in particular, is biting Plasma fairly hard. Not exactly a great surprise, after all, relocating (i.e. changing paths of) an installed Plasma isn’t exactly something we’ve done in the past. In fact, it goes further than that as ultimately Plasma’s dependencies need to be relocatable as well, which for example Xwayland is not.

But let’s talk about the snapping itself first. For the purposes of this proof of concept, I simply recycled KDE neon‘s deb builds. Snapcraft, the build tool for snaps, has built-in support for installing debs into a snap, so that is a great timesaver to get things off the ground as it were. Additionally, I used the Plasma Wayland stack instead of the X11 stack. Confinement makes lots more sense with Wayland compared to X11.

Relocatability

Relocatability is a tricky topic. A lot of times one compiles fixed paths into the binary because it is easy to do and it is somewhat secure. Notably, depending on the specific environment at the time of invocation one could be tricked into executing a malicious binary in $PATH instead of the desired one. Explicitly specifying the path is a well-understood safeguard against this sort of problem. Unfortunately, it also means that you cannot move your installed tree anywhere but where it was installed. The relocatable and safe solution is slightly more involved in terms of code as you need to resolve what you want to invoke relative from your location, it being more code and also not exactly trivial to get right is why often times one opts to simply hard-compile paths. This is a problem in terms of packing things into a relocatable snap though. I had to apply a whole bunch of hacks to either resolve binaries from PATH or resolve their location relative. None of these are particularly useful patches but here ya go.

Session

Once all relocatability issues were out of the way I finally had an actual Plasma session. Weeeh!

Confinement

Confining Plasma as a whole is fairly straightforward, albeit a bit of a drag since it’s basically a matter of figuring out what is or isn’t required to make things fly. A lot of logouts and logins is what it takes. Fortunately, snaps have a built-in mechanism to expose DBus session services offered by them. A full blown Plasma session has an enormous amount of services it offers on DBus, from the general purpose notification service to the special interest Plasma Activity service. Being able to expose them efficiently is a great help in tweaking confinement.

Not everything is about DBus though! Sometimes a snap needs to talk with a system service, and obviously, a workspace as powerful as Plasma would need to talk to a bunch of them. Doing advanced access control needs to be done in snapd (the thing that manages installed snaps). Snapd’s interfaces control what is and is not allowed for a snap. To get Plasma to start and work with confinement a bunch of holes need to be poked in the confinement that are outside the scope of existing interface. KWin, in particular, is taking the role of a fairly central service in the Plasma Wayland world, so it needs far-reaching access so it can do its job. Unfortunately, interfaces currently can only be built with snapd’s source tree itself. I made an example interface which covers most of the relevant core services but unless you build a snapd this won’t be particularly easy to try ��

Summary

All in all, Plasma is easily bundled up once one gets relocatability problems out of the way. And thanks to the confinement control snap and snapd offer, it is also perfectly possible to restrict the workspace through confinement.

I did not at all touch on integration issues however. Running the workspace from a confined bundle is all nice and dandy but not very useful since Plasma won’t have any applications it can launch as they either live on the system or in other snaps. A confined Plasma would know about neither right now.

There is also the lingering question of whether confining like this makes sense at all. Putting all of Plasma into the same snap means this one snap will need lots of permissions and interaction with the host system. At the same time it also means that keeping confinement profiles up to date would be a continuous feat as there are so many things offered and used by this one snap.

One day perhaps we’ll see this in production quality. Certainly not today ��

mascot_konqi-app-dev

This announcement is also available in Spanish and Taiwanese Mandarin.

The latest updates for KDE's Plasma, Applications and Frameworks series are now available to all Chakra users.

Included with this update, is an update of the ncurses, readline and gnutls related group of packages, as well as many other important updates in our core repository. Be aware that during this update, your screen might turn black. If that is the case and it does not automatically restore after some time, then please switch to tty3 with Ctrl+Alt+F3 and then switch back to the Plasma session with Ctrl+Alt+F7. If that does not work, please give enough time for the upgrade to complete before shutting down. You can check your cpu usage using 'top' after logging in within tty3. You can reboot within tty3 using 'shutdown --reboot'.

The Plasma 5.9.2 release provides additional bugfixes to the many new features and changes that were introduced in 5.9.0 aimed at enhancing users' experience:



Applications 16.12.2 include more than 20 recorded bugfixes and improvements to 'kdepim, dolphin, kate, kdenlive, ktouch, okular, among others.'.

Frameworks 5.31.0 include python bindings to many modules in addition to the usual bugfixes and improvements.

Other notable package upgrades and changes:

[core]
alsa-utils 1.1.3
bash 4.4.005
binutils 2.27
dhcpcd 6.11.5
dnsutils 9.11.1
ffmpeg 2.8.11
gawk 4.1.4
gdb 7.12
gnutls 3.5.8: If you have local or CCR packages that require it, they might need a rebuild
gstreamer 1.10.3
gutenprint 5.2.12
hunspell 1.6.0
jack 0.125.0
kdelibs 4.14.29
make 4.2.1
mariadb 10.1.21
mplayer 37916
ncurses 6.0+20170204: If you have local or CCR packages that require it, they might need a rebuild
php 7.0.15
postgresql 9.6.1
python2 2.7.13
readline 7.0.001: If you have local or CCR packages that require it, they might need a rebuild
samba 4.5.3
sqlite3 3.16.0
texinfo 6.3
util-linux 2.29
vim 8.0.0142
wpa_supplicant 2.6

[desktop]
fcitx-qt 5 1.1.0
libreoffice 5.2.5
nano 2.7.4
wireshark 2.2.4
qemu 2.8.0
screen 4.5.0

[gtk]
filezilla 3.24.0
thunderbird-kde 45.7.1

[lib32]
wine 2.2

It should be safe to answer yes to any replacement question by Pacman. If in doubt or if you face another issue in relation to this update, please ask or report it on the related forum section.

Most of our mirrors take 12-24h to synchronize, after which it should be safe to upgrade. To be sure, please use the mirror status page to check that your mirror synchronized with our main server after this announcement.


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.