January 24, 2017

While we’re still working on Vector, Text and Python Scripting, we’ve already decided: This year, we want to spend on stabilizing and polishing Krita!

Now, one of the important elements in making Krita stable is bug reports. And we’ve got a lot of those! But with some bug reports, we’re kind of stuck. We cannot figure out what type of hardware or drivers it is that is causing these bugs, so we’re asking for you help.

We’ve made a Krita user survey.

In it, we ask things like what type of hardware you have, and whether you have trouble with certain hardware. That way we can figure out which drivers and hardware are problematic and maybe get workarounds. There’s also some other questions, like what you make with Krita and how you get your Krita news.

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 novena entrevista nos encontramos con uno de los miembros de KDE España con más solera aunque en la actualidad está un poco retirado de la primera línea de la programación: Àlex Fiestas.

20 entrevistas para 20 años de KDE (X): Àlex Fiestas

Hola, en primer lugar quisiera agradecerte tu tiempo. Seguro que tus palabras serán fuente de inspiración para otros muchos.

Los inicios

De nuevo es Mandrake la primera distro de un integrante de la Comunidad KDE.

¿Recuerdas como conociste KDE?

20 entrevistas para 20 años de KDE (X)Mi primer contacto con KDE fue jugando con una instalación de Mandrake allá por el 2001 en el ordenador de mi hermano mayor. Por entonces no tenía mucho interés por la informática y mi contacto con KDE no fue más que un accidente debido al aburrimiento que sufría en aquellos ratos previos a las 18:00 cuando empezaba la tarifa plana de nuestro flamante modem de 56k.

Durante el 2003 empezó mi interés por la informática y motivado por la incomodidad que me ofrecía Windows XP fui a probar otras experiencias y ahí fue dónde conocí a Debian.

Saltamos al 2007, después de trabajar un verano pude por fin comprarme mi primer portátil un Sony Vario VGN-FS315S de lo mejorcito en el mercado en aquel momento. Lo desembalé, arranqué el sistema operativo que venia por defecto, comprobé que todo funcionaba, le puse un cd de Debian sarge y nunca mas un Windows volvió a pisar aquel portátil.

El entorno que utilizaba era Fluxbox y recuerdo que me recomendaban huir de KDE por que era un entorno pesado y inestable. A los meses me di cuenta que estaba utilizando más software de KDE que de cualquier otro entorno (Konqueror, Kopete, k3b…). Así que pensé tan mal no puede estar… Lo probé y hasta hoy.
¿Qué es lo que te gustó de KDE? ¿Y lo que menos?
Cómo he comentado antes las aplicaciones me convencieron de ignorar la mala fama que KDE tenía en mi entorno. Una vez en KDE 3 me encantó lo cohesionado que estaba todo, las aplicaciones ofrecían una experiencia unificada e integrada.

¿Por qué decidiste empezar a colaborar KDE?
Es muy largo de explicar, quizá mejor escuches la charla que realicé en Akademy-es de Bilbao de 2013.

El resumen es que parecía un sitio divertido dónde colaborar, se estaba innovando mucho a las puertas de KDE4 y creí que sería un lugar dónde encontrar personas interesantes y retos técnicos.
¿Cual es tu motivación para hacerlo y qué te aportó o te aporta?
Lo mejor de KDE es la gente que lo compone. Ahora tengo una familia esparcida por todo el mundo y eso no tiene precio.

El momento actual

En la actualidad, ¿Colaboras con el Software Libre en general y KDE en particular?
Software libre en general, ya apenas colaboro con KDE.

¿Qué aplicaciones o partes de KDE has colaborado?
Kamoso, BlueDevil, Powerdevil, frameworks, KSCreen, KWallet, user-manager…

Me has convencido, me gustaría echar una mano ¿cómo crees que es la mejor manera de empezar?
Localiza a contribuidores activos cercanos a ti y habla con ellos.

La Comunidad KDE

Define KDE en 3 palabras: Entretenido, personas, inclusivo

Siempre se dice que KDE es una Comunidad ¿Tú qué opinas?
Es correcto. Podré utilizar software hecho por KDE o no pero siempre seré parte de KDE.
Te gusta asistir a los eventos ¿por qué? Cuéntanos alguna anécdota.

Me encanta ver a mis amigos y pasarlo bien.
Mi primer proyecto en solitario dentro de KDE fue el de mejorar el soporte Bluetooth y lo decidí en una loca noche en La Palma.

Era el http://www.grancanariadesktopsummit.org el evento que pasará a la historia por la cantidad de fiestas patrocinadas, básicamente teníamos barra libre casi cada día.

Una de esas noches cuando volvíamos al hotel pensamos que era una buena idea ir a la playa a dar volteretas en ropa interior y un compañero
grabó todo el suceso con su teléfono móvil.

Al día siguiente le pedí a Víctor el vídeo, me lo pasó vía bluetooth y por algún motivo KDE decidió guardarlo en un directorio oculto.
El estrés que me generó el hecho de que el hardware de mi portátil aparentemente no funcionase hizo que me decidiese a arreglar la situación y
así comencé a arreglar KDE Bluetooth.

 

Preguntas rápidas:

¿KDE 4 o Plasma 5?
KDE 4.9 en adelante teníamos un escritorio que cubría todos los requerimientos del momento. Plasma 5 aún no.
 Aplicación que más te gusta de KDE
KDevelop y KDE Connect

La persona

Un libro: A song of Ice and fire. Me encanta el mundo que ha creado el autor, la política, la complejidad de los personajes, etc..
Una película: La vida es Bella

Un artista musical:  Aquí no me puedo mojar creo que no tengo ningún artista favorito. Me gusta casi toda la música.

Tu canción favorita: Uff… “Show must go on”, “Ara que tinc vint anys”, y seguiría con otras 200.

 


Cuando estoy solo me gusta comer:   Soy bastante “foodie”, me gusta mucho comer y comer rico. Uno de mis mayores placeres es un café, una tostada con “Pa amb tomaquet” y zumo de naranja recién exprimido.

Ahora tu minuto de oro, cuenta lo que quieras para los lectores de KDE Blog.
En unos meses me haré mi primer tattoo y sin ninguna duda será algo relacionado con KDE. No penséis y ayudad es un gran sitio donde hacerlo.
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.

January 23, 2017

Recently, the KSyntaxHighlighting framework was added to the KDE Frameworks 5.29 release. And starting with KDE Frameworks 5.29, KTextEditor depends on KSyntaxHighlighting. This also means that KTextEditor now queries KSyntaxHighlighting for available xml highlighting files. As such, the location for syntax highlighting files changed from $HOME/.local/share/katepart5/syntax to

$HOME/.local/share/org.kde.syntax-highlighting/syntax

So if you want to add your own syntax highlighting files to Kate/KDevelop, then you have to use the new location.

By the way, in former times, all syntax highlighting files were located somewhere in /usr/share/. However, since some time, there are no xml highlighting files anymore, since all xml files are compiled into the KSyntaxHighlighting library by default. This leads to much faster startup times for KTextEditor-based applications.

Running Unit Tests

If you build Kate (or KTextEditor, or KSyntaxHighlighting) from sources and run the unit tests (`make test`), then the location typically is /$HOME/.qttest/share/org.kde.syntax-highlighting/syntax.

Qt has provided support for state machine based development since introduction of Qt State Machine Framework in Qt 4.6. With the new functionality introduced in Qt 5.8 and Qt Creator 4.2 state machine based development is now easier than ever before.

Qt 5.8 introduces fully supported Qt SCXML module that makes it easy to integrate SCXML based state machines into Qt. Previously SCXML has been imported to Qt from external tools, which is still possible. Now Qt Creator 4.2 introduces a new experimental visual state chart editor that allows creation and modification of state charts directly with Qt Creator IDE. Together with the new editor and other improvements in Qt Creator, state machine based development can be done completely within Qt Creator.

Here is a short screen cast that shows these new features in action. For demonstration purposes, the simple state machine driven example application with Qt Quick user interface Traffic Light is being recreated from scratch.

Note that the the editor is still experimental with Qt Creator 4.2 and the plugin is not loaded by default. Turn it on in Help > About Plugins (Qt Creator > About Plugins on macOS) to try it.

The post Qt SCXML and State Chart Support in Qt Creator appeared first on Qt Blog.

Could you tell us something about yourself?

Good day. My name is Adam and I am a 26-year-old person who is trying to learn how to draw…

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

Hobby ��

What genre(s) do you work in?

I try to draw everything, I don’t want to get stuck in drawing only one thing over and over again and leave behind everything else.

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

People who inspired me when i was younger … much younger … were Satoshi Urushihara, Masamune Shirow and DragonBall artists.

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

My first adventure with digital painting was about 4-5 years ago, when I bought my first small Wacom Bamboo tablet that I am still using.

How did you find out about Krita?

A friend of mine mentioned it.

What was your first impression?

I uninstalled it and then came back after a while ��

What do you love about Krita?

Everything!

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

Maybe make it less laggy, but that can be the fault of my laptop.

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

The featured image. Not really my favourite, but I don’t have anything else worth showing!

What techniques and brushes did you use in it?

It was all random without any technique! I used Pencil 2B and pencil texture, nothing more or less.

Anything else you’d like to share?

Have a nice day everyone and let the Krita grow ��

Tras el análisis exhaustivo de la sección Aspecto, seguimos con la segunda sección de las Preferencias del Sistema con las referidas al Espacio de Trabajo. Y para seguir el orden que aparece si tenemos configurado nuestro Plasma en español, nos toca hablar del Comportamiento de la ventana en Plasma 5 una subsección también compleja donde aparecerán casi todas las acciones que pueden realizarse sobre las ventanas.

Comportamiento de la ventana en Plasma 5

Para llegar a la gestión de Comportamiento de ventanas en Plasma 5 primero debemos acceder a las Preferencias del Sistema, y lo haremos iniciando el Lanzador de aplicaciones (del icono que tenemos en la parte inferior izquierda de nuestra pantalla) y buscar la aplicación Preferencias del Sistema.

Nos aparecerá una ventana como la siguiente y que nos divide en diferentes secciones las opciones de configuración y personalización:

Preferencias del Sistema de Plasma 5

Ahora simplemente debemos pinchar en el icono de “Gestión de ventanas” para encontramos ante una subsección bastante compleja.

Comportamiento de la ventana

La primera sub-sección de la Gestión de Ventanas se centra en como se comportarán las ventanas. Lo cierto es que tenemos decenas de parámetros para configurar.

Para empezar nos encontramos con 5 pestañas. El primero de ellos es Foco y nos permite seleccionar la forma que el sistema selecciona la ventana activa. En una barra de desplazamiento las distintas formas que tenemos para pasar el foco de una ventana a otras, desde haciendo click hasta simplemente pasando por encima. También nos encontramos los parámetros para controlar el tiempo de captura de foco o la prevención de robo del mismo.

Comportamiento de la ventana en Plasma 5

La segunda de las pestañas nos permite controlar las acciones de la barra de las ventanas, es decir,  qué acción se realiza al hacer doble click, utilizar la rueda del ratón, el botón derecho, el izquierdo, etc.

La tercera se encarga de las acciones tanto de las ventanas inactivas como de sus componentes: barras de título, marco, desplazadores, etc.

La penúltima nos permitirá configurar las acciones al mover las ventanas, como por ejemplo, mostrar las dimensiones de las ventanas al mover o redimensionar las ventanas. También nos permite afinar definir las tamaños de las zonas ajustables.

Para finalizar, la quinta pestaña nos permite ajustar algunos detalles avanzados como sombreados, agrupaciones de las ventanas o su posición.

Cambiador de tareas

El segundo módulo nos permite personalizar la conmutación entre ventanas tanto el tipo de animación como todos los modificadores posibles: atajos de teclado, ordenación, si solo se aplica para un escritorio o una actividad o para todos, etc.

Este módulo también tiene una pestaña que tiene exactamente los mismo parámetros pero para un conmutador alternativo. ¡¡Si!! ¡¡Puedes tener dos conmutadores de ventanas activados a la vez!!!!

Guiones de KWin

Este módulo nos permite vitaminar las posibilidades de KWin con nuevas acciones como “Forzar la decoración de las ventanas en las ventanas GTK+” o “Minimizar Todo”.

Además, permite añadir nuevas funcionalidades desde internet.

Reglas de la ventana

El último módulo demuestra el poder de personalización de Plasma ya que nos permite crear una serie de reglas únicas para las ventanas que deseemos. Las opciones son casi infinitas y se merece un artículo independiente.

Además, se puede tanto crear tanto desde cero o importar, modificar, exportar o eliminar.

En resumen, comportamiento de la ventana en Plasma 5 es uno de los módulos más completos que tenemos en las Preferencias del Sistema. Tanto es así que en un futuro dedicaré alguna entrada especial para algunos de sus módulos.

 

January 22, 2017

This announcement is also available in Spanish and Taiwanese Mandarin.

The latest updates for KDE's Applications and Frameworks series are now available to all Chakra users, together with some other package upgrades.

Applications 16.12.1 include more than 40 recorded bugfixes and improvements, including a data loss bug in iCal resource for kdepim-runtime. kdelibs got updated to 4.14.28.

Frameworks 5.30.0 ship with the usual bugfixes and improvements, mostly found in breeze icons, kio and plasma-framework.

Other notable package upgrades and changes:

[core]
laptop-mode-tools 1.71
libinput 1.5.3
libvncserver 0.9.11
mariadb 10.1.20
ruby 2.4.0
xf86-input-libinput 0.23.0

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.

Instalar una distribución GNU/Linux se ha vuelto un juego de niños, siendo la instalación del gestor de arranque (maldito uefi) y la creación de particiones los único posibles problemas que nos podemos encontrar. Los instaladores actuales son muy buenos pero siguen evolucionando para mejorar su uso. Así que es una buena noticia que la “no-distribución” KDE neon utilizará Calamares como instalador oficial en breve.

KDE neon utilizará Calamares como instalador

Como se puede leer en el blog de Jonathan Riddell, la versión para desarrolladores de KDE neon utilizará Calamares como instalador oficial con lo que se suma al carro de las muchas distribuciones que lo están utilizando o lo van a utilizar en un futuro.

Por si alguien no lo sabe Calamares es un instalador de distribuciones independiente que es utilizado en proyectos como Netrunner o Tanglu. Está escrito en Qt y KDE Frameworks con módulos en C++ y Python.

Este cambio de del instalador Ubiquity a Calamares se ha producido por demanda popular y, de momento, está siendo utilizado en la versión para desarrolladores para afinarla y dejarla lista respecto a detalles como codecs restringidos, encriptación de discos duros mediante LUKS, encriptación de la carpeta home, la actualización a los ultimos paquetes, etc.

Todo este trabajo se implementará pronto y estará listo para la User Edition. De momento podemos conformarnos con las capturas de pantalla de la instalación en la versión para developers:

¿Qué es KDE Neon?

El proyecto KDE Neon es uno de los más ambiciosos de la Comunidad KDE ya que quiere ofrecer a todos los usuarios En realidad se parece mucho a Kubuntu o a KaOS, pero en esta iniciativa proviene desde dentro la Comunidad KDE, con la finalidad de simplificar el proceso de creación y distribución de Plasma y el software de KDE en general.

KDE neon utilizará Calamares como instalador

De momento ofrece varias versiones:

  • User Edition para personas que son aficionados a KDE o para quienes tienen curiosidad de probar el KDE más puro. Incluye una con Plasma 5.8 LTS.
  • Versión Developer Editions pensada para personas quien quieren ayudar KDE.  Posiblemente manteniendo una aplicación de KDE y quiere el Frameworks más nuevo para trabajar. O posiblemente has encontrado error del programa y necesitas probar en una versión de Git Unstable.

January 21, 2017

When you download a KDE neon ISO you get transparently redirected to one of the mirrors that KDE uses. Recently the Polish mirror was marked as unsafe in Google Safebrowsing which is an extremely popular service used by most web browsers and anti-virus software to check if a site is problematic. I expect there was a problem elsewhere on this mirror but it certainly wasn’t KDE neon. KDE sysadmins have tried to contact the mirror and Google.

You can verify any KDE neon installable image by checking the gpg signature against the KDE neon ISO Signing Key.  This is the .sig file which is alongside all the .iso files.

gpg2 --recv-key '348C 8651 2066 33FD 983A 8FC4 DEAC EA00 075E 1D76'

wget http://files.kde.org/neon/images/neon-useredition/current/neon-useredition-current.iso.sig

gpg2 --verify neon-useredition-current.iso.sig
gpg: Signature made Thu 19 Jan 2017 11:18:13 GMT using RSA key ID 075E1D76
gpg: Good signature from "KDE neon ISO Signing Key <neon@kde.org>" [full]

Adding a sensible GUI to do this is future work and fairly tricky to do in a secure way but hopefully soon.

Facebooktwittergoogle_pluslinkedinby feather

January 20, 2017

You voted for change and today we’re bringing change. Today we give back the installer to the people. Today Calamares 3 was released.

It’s been a long standing wish of KDE neon to switch to the Calamares installer.  Calamares is a distro independent installer used by various projects such as Netrunner and Tanglu.  It’s written in Qt and KDE Frameworks and has modules in C++ or Python.

Today I’ve switched the Developer Unstable edition to Calamares and it looks to work pretty nicely.

However there’s a few features missing compared to the previous Ubiquity installer.  OEM mode might be in there but needs me to add some integration for it.  Restricted codecs install should be easy to add.  LUKS encrypted hard disk are there but also needs some integration from me.  Encrypted home holders isn’t there and should be added.  Updating to latest packages on install should also be added.  It does seem to work with UEFI computers, but not with secure boot yet. Let me know if you spot any others.

I’ve only tested this on a simple virtual machine, so give it a try and see what breaks. Or if you want to switch back run apt install ubiquity-frontend-kde ubiquity-slideshow-neon''.

Screenshot_generic_2017-01-20_18:05:56
Screenshot_generic_2017-01-20_18:06:07
Screenshot_generic_2017-01-20_18:06:25
Screenshot_generic_2017-01-20_18:06:57
Screenshot_generic_2017-01-20_18:07:12
Screenshot_generic_2017-01-20_18:07:29
Screenshot_generic_2017-01-20_18:07:34
Screenshot_generic_2017-01-20_18:09:50
Screenshot_generic_2017-01-20_18:11:24

Facebooktwittergoogle_pluslinkedinby feather

For the past couple of months I’ve been working on getting KDE applications into the binary bundle format snap.

With the release of snapd 2.20 last month it gained a much-needed feature to enable easy bundling of applications that register a DBus service name. The all new dbus interface makes this super easy.

Being able to easily register a DBus service matters a great deal because an extraordinary amount of KDE’s applications are doing just that. The use cases range from actual inter-process communication to spin-offs from this functionality, such as single-instance behavior and clean application termination via the kquitapp command-line utility.

There’s barely any application that gets by without also claiming its own space on the session bus, so it is a good thing that enabling this is now super easy when building snap bundles.

One simply adds a suitable slot to the snapcraft.yaml and that’s it:

slots:
    session-dbus-interface:
        interface: dbus
        name: org.kde.kmplot
        bus: session

An obvious caveat is that the application needs to claim a well-known name on the bus. For most of KDE’s applications this will happen automatically as the KDBusAddons framework will claim the correct name assuming the QCoreApplication properties were set with the relevant data to deduce the organization+app reverse-domain-name.

As an additional bonus, in KDE we tend to codify the used service name in the desktop files via the X-DBUS-ServiceName entry already. When writing a snapcraft.yaml it is easy to figure out if DBus should be used and what the service name is by simply checking the desktop file.

The introduction of this feature moves a really big roadblock out of the way for enabling KDE’s applications to be easily snapped and published.

As some of you might know I’ve been involved in the foss-gbg group for a long while (more than 3 years now). Last year I helped starting the foss-north conference, which is really about taking what foss-gbg is and turning it into something bigger. We had a great turn-up – over 100 guests and ten great speakers.

This week, I finally got time to start pushing forward with this year’s edition of foss-north. It will be held on April 26 in Gothenburg and it is a great opportunity to visit Sweden and Gothenburg and mingle with the FOSS community. We’ve already confirmed Lydia Pintscher and Lennart Poettering as speakers. If you want to speak the call for paper has just opened and will run until March 12. Tickets sales will open shortly too, as well as the call for sponsors.

By a random chance I got involved in the organization of yet another group this week. The C++ meetup community in Gothenburg has been inactive for almost a year, so a group of people decided to pick up the ball and try to get something running. We’ve renamed the group to gbgcpp and the next (our first) meeting will be held January 26, and then we will take it from there. Hopefully this can turn into something fun!

QImage is the most common container for image data in Qt applications.

Getting a QImage that contains the pixel data of an image loaded from a file is fairly self-explanatory:

QImage img;
img.load("some_image.png");

This can then be used with QPainter, can be passed to widgets, and can also be utilized in Qt Quick scenes via custom image provider implementations. (although the latter would obviously be a massive overkill for image data coming from a file since that’s what the Image element provides out of the box anyway).

So far so good. Now, what if the image data is coming from somewhere else? For example a custom drawing made via QPainter, or an image that comes from some external engine, like a camera, scanner or computer vision framework?

The answer lies in some of the 9 constructors. The interesting ones for our purposes are the following:

QImage(int width, int height, Format format);
QImage(uchar *data, int width, int height, Format format, ...);
QImage(uchar *data, int width, int height, int bytesPerLine, Format format, …);
QImage(const uchar *data, int width, int height, ...);
QImage(const uchar *data, int width, int height, int bytesPerLine, Format format, …);

Let’s now take a look at some of the common use cases and how these constructors serve the specific needs of each case.

Case #1: Image data owned by the QImage

The common case when generating images on-the-fly, is using QPainter and its raster paint engine to draw into a QImage:

QImage img(640, 480, QImage::Format_ARGB32_Premultiplied);
img.fill(Qt::transparent);
QPainter p(&img);
p.fillRect(10, 10, 50, 50, Qt::red);
p.end();
...

Here the underlying image data is allocated and owned by img itself.

When it comes to the format for images that will be passed to Qt Quick, the basic recommendations (as of Qt 5.8) are the following:

  • In general, the first choice should be Format_ARGB32_Premultiplied. This is good because it is one of the preferred, fast formats for the raster paint engine, which QPainter uses under the hood when targeting a QImage, and the premultiplied format fits Qt Quick well since the scenegraph renderer and its materials rely on premultiplied alpha for blending. When creating textures for our image, the default, OpenGL-based Qt Quick scenegraph will avoid any potentially expensive QImage format conversion for ARGB32_Premultiplied images.
  • When there is no need for an alpha channel at all, due to our image being completely opaque, Format_RGB32 is a good alternative. This comes with the same benefit: no format conversion when creating an OpenGL scenegraph texture from such a QImage.

Other formats will lead to a convertToFormat() call at some point, which is not necessarily ideal. It is better to get the format right from the start.

It is worth noting that in order to get a proper no-conversion-by-Qt-on-CPU path, the OpenGL implementation must support GL_EXT_bgra, GL_EXT_texture_format_BGRA8888, or some of the vendor-specific variants. This can be relevant on older, OpenGL ES 2.0 only systems where BGRA support is not mandated by the GLES spec. In the absence of these (A)RGB32 image data will internally need either an additional swizzle step (this is what Quick and pretty much all old Qt 4 code does) or a conversion to a byte ordered QImage format (preferred by some of the newer code in QtGui and elsewhere), because the (A)RGB32 formats are not byte ordered.

What are byte ordered however are the Format_RGB(A|X)8888[_Premultiplied] formats introduced in Qt 5.2. These are nice because when read as bytes, the order is R, G, B, A on both little and big endian systems, meaning the image data can be passed to a glTex(Sub)Image2D call using a GL_RGBA format with a GL_UNSIGNED_BYTE data type as-is.

  • When targeting older OpenGL ES 2.0 systems is a must, custom OpenGL rendering code (for example, inside a QOpenGLWindow, QOpenGLWidget, QQuickFramebufferObject, etc.) can benefit from using QImages with a byte ordered format like Format_RGBA8888, simply because there is less code to write. (no manual swizzling or extra QImage format conversion is needed when BGRA support is missing)
  • Some of QtGui’s OpenGL helpers that may be used by such code, most notably QOpenGLTexture, also prefer Format_RGBA8888 when working with QImage, and will kick off a conversion for other formats.

Therefore, the older default recommendation of using Format_ARGB32_Premultiplied or Format_RGB32 is not necessarily valid always. In the context of Qt Quick however, sticking with these formats will typically still be the right choice.

Case #2: Wrapping external, read-only image data

Now, what if the image data is readily available from an external engine? The common solution here is to use the QImage constructor taking a const uchar pointer.

void *data = ...
QImage wrapper(static_cast<const uchar *>(data), 640, 480, QImage::Format_RGB32);
// 'wrapper' does not own the data.
// 'data' must stay valid until 'wrapper' is alive.

There are no memory allocations and copies made here. It is up to the application to ensure the width, height, format, and optionally the bytes per line reflect the raw image data received from the other framework or engine.

Like many other container classes in Qt, QImage is using implicit sharing. This is handy because this way a QImage can be passed or returned by value without having to worry avoid expensive copies of the actual image data.

Instances created from a const uchar * are special in the sense that any attempt to modify the QImage (via a non-const function) detaches (makes a copy) regardless of the reference count. Hence attempts to modify to original, external data are futile:

const uchar *data = ...
QImage wrapper(data, ...);
wrapper.setPixelColor(5, 5, Qt::green);
// 'wrapper' is not a wrapper anymore,
// it made a full copy and got detached

Note that while this is all nice in theory, and the zero-copy approach is great in some cases, in practice making copies of the data is often unavoidable due to the need for format conversions in order to match the needs of the various frameworks. For example when interfacing with OpenCV, the code (taken from here) to convert a CV_8UC4 image into a QImage could look like this:

QImage mat8ToImage(const cv::Mat &mat)
{
    switch (mat.type()) {
    ...
    case CV_8UC4: {
        QImage wrapper(static_cast<const uchar *>(mat.data), mat.cols, mat.rows, int(mat.step), QImage::Format_RGB32);
        return wrapper.rgbSwapped();
    }
    ...

(NB! It does not matter if we use the const or non-const pointer variant of the constructor here. A copy will be made either way due to the semantics of rgbSwapped())

Case #3: Wrapping and modifying external image data

What about the constructor taking an uchar pointer? As the non-const argument suggests, this allows modifying the external, non-owned data via a wrapping QImage, without making copies of the image data. Modification often means opening a QPainter on the QImage:

void *data = ...
QImage img(static_cast<uchar *>(data), 640, 480, QImage::Format_RGB32);
QPainter p(&img);
p.fillRect(10, 10, 50, 50, Qt::red);
p.end();
... // 'data' must stay valid as long as 'img' is alive

Here we paint a red rectangle on top of the existing content.

This is made possible by a perhaps at first confusing feature of QImage: with non-owned, non-read-only data modification attempts will not detach when the reference count is 1 (i.e. the image data is not shared between multiple QImage instances).

Compare this behavior with something like QString::fromRawData() which explicitly says: Any attempts to modify the QString or copies of it will cause it to create a deep copy of the data, ensuring that the raw data isn’t modified.

There a container associated with external data always makes a copy, and does not support modifying the external data. With QImage this is not acceptable, since the ability to change the pixels of an image from an arbitrary source without making a copy is a must have.

See this little example project for a demonstration of painting into a manually allocated image. It also demonstrates one potential issue one may run into when getting started with such a QImage:

void drawStuff_Wrong(QImage image)
{
    QPainter p(&image); // oops
    p.fillRect(10, 10, 50, 50, Qt::red);
}

QImage wrapper(data, 640, 480, QImage::Format_RGB32);
drawStuff_Wrong(wrapper);

This is clearly broken. The red rectangle will not appear in the original image pointed to by ‘data’. Due to passing to the function by value the image gets its refcount increased to 2, and so the modification attempt when opening the QPainter has to detach with a full copy. The solution here is to pass by pointer or reference. (or yet better do not pass at all; QImage instances referencing external data should ideally be isolated as much as possible, in order to avoid issues like the one above)

Accessing the image data

And last but not least, let’s talk about accessing the bytes of a QImage.

For read access, something like QImage::pixel() clearly does not scale when having to examining a larger part of the image. Instead, use constBits() or constScanLine().

QImage img(640, 480, QImage::Format_ARGB32_Premultiplied);
const uchar *p = img.constBits();
...
// 'p' is valid as long as 'img' is alive

Read-write access is done via bits() and scanLine(). These exist in both const and non-const version. The const version are in effect same as constBits() and constScanLine(). In practice it is strongly recommended to use constBits() and constScanLine() whenever read-only access is desired, in order to avoid accidentally invoking the non-const bits() or scanLine(), and making expensive and totally unnecessary copies of the image data.

QImage img1(640, 480, QImage::Format_RGB32);
QImage img2 = img1;
const uchar *p = img1.bits();
// ouch! that's the non-const bits(). img1 detaches.
// we only wanted read access and yet wasted time with a copy.

Due to img1 not being const this should have been:

QImage img1(640, 480, QImage::Format_RGB32);
QImage img2 = img1;
const uchar *p = img1.constBits();
// no copy, img1 and img2 still share the same data

The non-const versions detach when multiple instances share the same data or when the image wraps read-only, external data (via the const uchar * constructor).

That is all for now. Hope this clears up some of the uncertainties that may arise when looking at the QImage API for the first time, and helps to avoid some of the pitfalls when working with external image data. Happy hacking with QImage!

The post Inside QImage (with a touch of Qt Quick and OpenGL) appeared first on Qt Blog.

January 19, 2017

I’m happy that with Qt 5.8.0 we’ll have Qt Speech added as a new tech preview module. It took a while to get it in shape since the poor thing sometimes did not get the attention it deserved. We had trouble with some Android builds before that backend received proper care. Luckily there’s always the great Qt community to help out.
Example application show Qt Text to Speech
What’s in the package? Text to speech, that’s about it. The module is rather small, it abstracts away different platform backends to let you (or rather your apps) say smart things. In the screen shot you see that speech dispatcher on Linux does not care much about gender, that’s platform dependent and we do our best to give you access to the different voices and information about them.

Making the common things as simple as possible with a clear API is the prime goal. How simple?
You can optionally select an engine (some platforms have several). Set a locale and voice, but by default, just create an instance of QTextToSpeech and connect a signal or two. Then call say().

m_speech = new QTextToSpeech(this);
connect(m_speech, &QTextToSpeech::stateChanged,
        this, &Window::stateChanged);
m_speech->say("Hello World!");

And that’s about it. Give it a spin. It’s a tech preview, so if there’s feedback that the API is incomplete or we got it all wrong, let us know so we can fix it ASAP. Here’s the documentation.

I’d like to thank everyone who contributed, Maurice and Richard at The Qt Company, but especially our community contributors who were there from day one. Jeremy Whiting for general improvements and encouragement along the way (I bet he almost gave up on this project). Samuel Nevala and Michael Dippold did implement most of the Android backend, finally getting things into shape. Thanks!

You may wonder about future development of Qt Speech. There are some small issues in the Text to Speech part (saving voices and the current state in general should be easier, for example). When it comes to speech recognition, I realized that that’s a big project, which deserves proper focus. There are many exciting things that can and should be done, currently I feel we need proper research of all the different options. From a simple command/picker mode to dictation, from offline options and native backends to the various cloud APIs. I’d rather end up with a good API that can wrap all of these in a way that makes sense (so probably a bunch of classes, but I don’t have a clear picture in my mind yet) than rushing it. I hope we’ll get there eventually, because it’s certainly an area that is important and becoming more and more relevant, but I assume it will take some time until we have completed the offering.

The post Qt Speech (Text to Speech) is here appeared first on Qt Blog.

There was a time when the Qt Graphics View Framework was seen as the solution to create modern user interfaces with Qt. Now that Qt Quick 2 has matured does the Graphics View Framework still have a place in Qt?

At the Qt World Summit 2016 I gave a presentation entitled “The Curse of Choice.” It gives an overview of the various GUI technologies available in Qt 5 as well as descriptions of which you should use for different use cases. I would recommend you watch the recording of the presentation, unfortunately there was a technical issue with the recording and while the talk is available for viewing online, it is incomplete.  I did give the same talk in webinar format though which you can view here.

After each time giving the talk, I got many questions about the Graphics View framework, which I was quite harsh on. My conclusion was that users should avoid QGraphicsView for new applications and instead use Qt Quick. This proved to be a controversial claim because Graphics View is used in many applications shipping today. So in the interest of answering the question “Should you still be using QGraphicsView in 2017?” This post will give the longer form of the answer.

Prophetic comment on a post about Qt Scene Graph

Prophetic comment on a post about Qt Scene Graph

Does Qt Quick really replace Graphics View?

Yes and No.

Qt Quick 1 (QDeclarative* API) was built on top of Graphics View, so comparing Graphics View to Qt Quick 2 is like comparing apples to oranges.

The better question is: “Does the Qt Quick Scenegraph replace Graphics View?” The lessons learned from using Graphics View for Qt Quick 1 were applied to create its successor. An API optimized for rendering Qt Quick scenes on devices with a Graphical Processor Unit. That API is the Qt Quick Scenegraph.

Qt Quick and its Scenegraph API can do most of what Graphics View could do and much more, but there are still features that got left behind:

Graphics View enables Multiple Views of the same scene

This powerful feature was shamelessly flaunted in the 40000 Chips demo:

40000 Chips Demo

The Power of Qt Graphics View!

Because all items in Graphics View can live in a shared QGraphicsScene, it is possible to have more than one QGraphicsView widget each of which could display different views of the shared scene. This is quite difficult to replicate in Qt Quick 2 because each view would need to create its own copy of the scene.

A cool as the feature seems, in practice it was not used so much by customers. The feature was also less practical on mobile and embedded platforms where only one view would be used per screen. This proved to be an unfortunate design decision because it also limited opportunities for optimization.

It makes the code really complex and optimization hard. — Alexis Menard ( Qt DevDays 2010 )

If you need to show the same scene multiple ways when migrating to Qt Quick, then you will need to separate the data you would like to visualize from the scene defined in QML. Populate each Qt Quick scene with only the data present in the view of your logical scene. This is more complicated but does provide more flexibility in how you store the state of your shared scene. I concede that it was easier to do in QGraphicsView.

Graphics View depends on QPainter

This is both a blessing and a curse. One of the reasons that Graphics View lived on so long through Qt Quick 1 in Qt 5 is because of its use of QPainter. When Qt Quick 2 was released with Qt 5.0 it came with the requirement that it could only be rendered with OpenGL(ES) 2 or higher. This minimum requirement did not fit everyone’s needs, and the solution was to keep Qt Quick 1 around for those customers.

In Qt 4 QPainter had a couple of different graphics systems (backends) that could be used. This meant that if you were rendering with QPainter you could either choose to do so in software (raster), or with the GPU (opengl). In the case of QGraphicsView if you wanted to render your scene with the OpenGL paint engine you just needed to set the viewport of QGraphicsView to be backed by a QGLWidget.

In general this would improve the rendering performance of Graphics View. However, under the hood QPainter is generating loads of state changes and rendering the scene back to front leading to a poor use of the GPU. This is a large reason why the Qt Quick Scenegraph exists. In Qt Quick the renderer can, depending on the scene’s content, determine the best way to arrange the scene for rendering on the GPU.

Qt Quick as of 5.8 no longer requires the use of OpenGL 2 thanks to the Software rendering adaption.

Graphics View has collision detection

What! Are you making a game now?

Angry Birds

They use Box2D, and so should you.

Graphics View supports embedding QWidgets

This is a neat feature and became a customer favorite shortly after its debut. The intention was to enable users to reuse controls that already existed. For simple widgets like QPushButton and QSlider the cost in extra memory usage and proxying was worth it for the convenience gained. However users did not stop there and would place complex widget hierarchies into their scenes like their entire QMainWindow or QDialog.

What was convenient for customers was also problematic for performance. QWidgets can not be embedded into a Graphics View scene directly. Instead they must be proxied. Each time an item in the scene that represents a QWidget requires an update, it has to request a full update of the QWidget via QWidget::render(…). The contents of the QWidget would then be rendered and copied into Graphics View. With Graphics View there is a shared QPainter between all items which renders to a single target QPaintDevice. QWidgets however are themselves QPaintDevices which require their own QPainter instances.

The key to the high performance of Graphics View is reducing how much is painted each frame. QGraphicsWidget and QGraphicsProxyWidget together are huge performance killers because they can not be rendered in a efficient way.

If you still choose to use Graphics View today, do yourself a favor and avoid embedding QWidgets into your scene.

QGraphicsProxyWidget: Not even once

Seriously

Graphics View has Shape Items

Graphics View Items

As of Qt 5.8, Qt Quick still only has one built in shape, the Rectangle. The Rectangle Item can also be used to create circles, but that is little comfort to anyone porting Qt Graphics View shapes to Qt Quick.

You can create lines in Qt Quick with a thin and long Rectangle. Line segments become a series of Rectangles. If you wanted more exotic shapes or paths, then you have a couple of options:

Canvas Item: With the Canvas Item you can use the imperative Context2D Javascript API to render whatever shape or content you want.

QQuickPaintedItem: This is a custom C++ item that has a virtual paint method much like a custom QGraphicsViewItem. Here you can render whatever content you want but via QPainter making a very easy porting path from QGraphicsItem. Both this and the Canvas Item create an offscreen rendering surface the size of the area you want to render to. This can either be a QImage or an QOpenGLFramebufferObject.

Keep in mind that if you are drawing a large shape, there is also a large area of memory behind the scenes being used that will be the size of your shapes bounding rectangle.

Custom QSGGeometryNode: This is likely the most optimal method performance-wise, but also the most difficult. Rather than drawing the shape you desire though an imperative painting API, you would embrace the Qt Quick Scenegraph and generate custom geometry for your item. This however means turning the shape you want to render into geometrical primitives like triangles. The details of this are a bit much for this article, and likely best left to a future post. For more details check out this example.

There may be several ways to render arbitrary shapes in Qt Quick scenes, but none as convenient as QGraphicsPathItem.

Laszlo Agocs is currently researching this topic though, so as soon as Qt 5.10 there could be an easy way to use shapes and paths in Qt Quick. Stay tuned.

But I don’t want to write QML or Javascript!

Time to address the gorilla in the room.

Its very easy to breeze over the detail that not everything has a public C++ API in Qt Quick. If you are porting an application using Graphics View to Qt Quick, you will very soon realize that you have to write QML code. While you can (and should) use C++ APIs as much as possible with Qt Quick as well, you will find that creating sub-classes of existing components via C++ is not possible.

Lets consider the TextEdit QML component. If you wanted to create an item that extended the existing functionality of TextEdit you would have to do so from QML. The TextEdit QML component is implemented in C++, but that class is not public API, so you can’t use that class in your custom C++ item via aggregation nor composition.

Much of the Qt Quick QML APIs are like this. Even if you start with the approach of: “Code only in C++”, in practice this is challenging. We hope to address this in future releases of Qt. The original reason given to keep these classes private was to keep our options open, and not lock down these APIs too soon. As we are now releasing Qt 5.8 and looking towards Qt 6, its time to reconsider this policy.

That said, QML is awesome, and in practice extending items in QML is super easy. QML stands for the Qt Meta-object Language and should be looked at as an easy way to automate the process of setting up a hierarchy of QObjects and their signal/slot connections. If you’re holding out on Qt Quick because of QML, I understand, but recommend you still give it a chance. Check out the free online QML Book for more details on getting started.

Is Graphics View deprecated?

The short answer is no, not officially. The real answer is more nuanced. And it starts with the fact that Qt Quick 1 is now deprecated. This is important because it was Qt Quick 1 that drove forward the development of Graphics View. Much like the rest of the Widgets module, Graphics View is considered “done” and isn’t being given new features. You can see this if you check out the commit log for those classes.

There is some maintenance, but much of those commits are from various refactoring that covers all of the QtBase module.

Because of the larger than not overlap between Qt Quick 2 and Graphics View, I would expect to see Graphics View moved into a “Compatibility” module for Qt 6.

Conclusion

I am not so naive to believe that this answers all the questions you have about the future of Graphics View. I would like to continue the discussion because if there is a reason you still can not migrate from Graphics View, then we still have work to do.

If you want me to write more articles about porting from Graphics View to Qt Quick, please let me know in the comments.  Also if you recall seeing this post elsewhere, it also appeared on my own blog.  In the interest of making the Dev Loop of the Qt Blog more awesome, I’ll be posting all future blog articles here. So stay tuned!

The post Should you still be using QGraphicsView? appeared first on Qt Blog.




Google Code In ( Gcompris )  2106-2017


Our Experience -:

This year's Google Code In was awesome as before . There were instances of tasks successfully completed by the students . Out of 12 unique tasks 11 tasks were successfully attempted . The students were enthusiastic till the very end of the program. Most of the students solved multiple tasks that provided us with varied ideas .

Some of the students bonded with the community during their  tasks over the irc. All the mentors did a great job . At first the program seemed a bit monotonous but as we reached halfway through the timeline students showed their interest and made it a success.

Students seemed to be interested in contributing to opensource softwares and getting exposure to new technologies like (Qt , git). We did hit a road bump with some tasks that involved building the software or coding in general. But this was supposed to happened as we encountered very young talents.

What we learnt ( Mentors ) -:

We will try to improve the quality and type of tasks that are published for further GCI's to get more students interested in contributing to opensource softwares.


Type of tasks  -: 

Open Bugs -:

Blog Posts -:

Videos -:

T-Shirts -:


Icons -:  ( All the icons have been commited in the main repository )

  1.     Babymatch
  2.     Babyshapes
  3.     details
  4.     Drawletters
  5.     Explore_monuments
  6.     Explore_world_music
  7.     Explore_world_animals
  8.     Geo-country
  9.     Graph-coloring
  10.     Guesscount
  11.     Hanoi
  12.     Hanoi_real
  13.     Imagename
  14.     Letter-in-word
  15.     Melody
  16.     Missing-letter
  17.     Number_sequence
  18.     Paintings
  19.     Photo_hunter
  20.     Roman_numerals
  21.     Tangram
  22.     Water cycle






Code -: 

  1.   2 new levels in explore_world_animals
  2.   dataset update in guesscount activity


Reviews from the students :-

  • Ilya Bizyaev said -: "For me, Google Code-In was a wonderful opportunity to improve various skills, meet new friends and become part of an amazing community that shares my values."

  • Sergey said -: "GCI is an amazing adventure through the world of Opensource, allowing you not only to improve skills and meet new friends from all around the world, but also help you dive right into the development of real projects. I'd say, tagline of GCI should be "Learn by making the world a better place"."



Mentor's Review :-


  •  Rahul yadav ( My Self )  :- The contest was full of energetic students. The students were active on irc as well . Students were exited to contribute to Gcompris. Some of the students work was continuously being commited to our main repository which increased their interest in the project . I had a great learning experience of being a mentor as well .

  •  Johnny Jazeix said -: "really great surprises and amazing job done by some students. I though we would advance more on code tasks but the graphics have been improved a lot."

  • Pulkit Gupta

Special Thanks to :-
(they were not official GCI mentors but helped the students all along the way)
  • Timothée  said -: "that was a great experience: it was cool to can share some knowledge, the students were nice and the result was helpful."

  • Wxl



Codethink is steadily growing for some time now. I have been working for 18 months in the company and it is about time for me to tell you that this is an outstanding place to work if you:

  • Love Open Source and work upstream.
  • Prefer to work in a startup kind of environment than in a corporate one.
  • Love to solve complex problem for first class customers instead of living peacefully in your comfort zone.
  • Like to travel to customers and conferences once in a while.
  • Understand that being challenged every day is the best way to improve.
  • Like international and multicultural environments with a British touch.
  • Think that Manchester, UK, is not a bad place to live or to visit once in a while. Hey, I am from the Canaries and too old to party night and day when I am not working, ut that might not be your case ;-)
  • Like IRC, git, vim/emacs, RSS and some other technologies that newcomers to Open Source consider... old school.
  • Are not scared of sending patches by mail.
But above all, you are willing to learn no matter how senior you are!

Codethink is an independent consultancy company based in Manchester, UK, although it has some people like myself working remotely. Our customers are also spread around the world. We are around 75-80 people now, most of them, engineers.

Most of our work is related with Linux kernel, low level system activities, compilers, delivery of linux systems, distro and SoC work.

Let me know if you could be interested in working at Codethink or send directly your CV to jobs@codethink.co.uk

I am trying to get into the habit of blogging more often, also about topics that may not warrant a white paper worth of text, but that may be interesting to some of you. For those of you who don’t know me, I am the maintainer of the text and font code in Qt, and recently I came across a curious customer case where the optimization mechanisms in the Qt Quick scene graph ended up doing more harm than good. I thought I would share the case with you, along with the work-around I ended up giving to the customer.

Consider an application of considerable complexity: Lots of dials and lists and buttons and functionality crammed into a single screen. On this screen there are obviously also labels. Thousands of static labels, just to describe what all the complex dials and buttons do. All the labels share the same font and style.

Narrowing the example down to just the labels, here is an illustration:

import QtQuick 2.5
import QtQuick.Window 2.2

Window {
    id: window
    visible: true
    title: qsTr("Hello World")
    visibility: Window.Maximized

    Flow {
        anchors.fill: parent
        Repeater {
            model: 1000
            Text {
                text: "Hello World"
            }
        }
    }
}

Now, the way the scene graph was designed, it will make an effort to bundle together as much of a single primitive as possible, in order to minimize the number of draw calls and state changes needed to render a scene (batching). Next, it will try to keep as much as possible of the data in graphics memory between frames to avoid unnecessary uploads (retention). So if you have a set of text labels that never change and are always visible, using the same font, essentially Qt will merge them into a single list of vertices, upload this to the GPU in one go and retain the data in graphics memory for the duration of the application.

Example screenshot

Artist’s impression of a complex Qt application

We can see this in action by setting the environment variable QSG_RENDERER_DEBUG=render before running the application above. In the first frame, all the data will be uploaded, but if we cause the scene graph to re-render (for instance by changing the window size), we see output like this:

Renderer::render() QSGAbstractRenderer(0x2a392d67640) "rebuild: none"
Rendering:
 -> Opaque: 0 nodes in 0 batches...
 -> Alpha: 1000 nodes in 1 batches...
 - 0x2a39351fcb0 [retained] [noclip] [ alpha] [  merged]  Nodes: 1000  Vertices: 40000  Indices: 60000  root: 0x0 opacity: 1
 -> times: build: 0, prepare(opaque/alpha): 0/0, sorting: 0, upload(opaque/alpha): 0/0, render: 0

From this we can read the following: The application has one batch of alpha-blended material, containing 1000 nodes. The full 40000 vertices are retained in graphics memory between the frames, so we can repaint everything without uploading the data again.

So far so good.

But then this happens: Someone adds another label to our UI, somewhere in the depths of this complex graph of buttons, dials and labels. This label is not static, however, but shows a millisecond counter which is updated for every single frame.

While the scene graph does the correct and performant thing for most common use cases, the introduction of this single counter item in our scene breaks the preconditions. Since the counter label will be batched together with the static text, we will invalidate all the geometry in the graph every time it is changed.

To see what I mean, lets change our example and run it again.

import QtQuick 2.5
import QtQuick.Window 2.2

Window {
    id: window
    visible: true
    title: qsTr("Hello World")
    visibility: Window.Maximized
    property int number: 0

    Flow {
        anchors.fill: parent
        Repeater {
            model: 1000
            Text {
                text: index === 500 ? number : "Hello World"
            }
        }
    }

    NumberAnimation on number {
        duration: 200
        from: 0
        to: 9
        loops: Animation.Infinite
    }
}

The example looks the same, except that the 501st Text item is now a counter, looping from 0 to 9 continuously. For every render pass, we now get output like this:

Renderer::render() QSGAbstractRenderer(0x1e671914460) "rebuild: full"
Rendering:
 -> Opaque: 0 nodes in 0 batches...
 -> Alpha: 1000 nodes in 1 batches...
 - 0x1e672111f60 [  upload] [noclip] [ alpha] [  merged]  Nodes: 1000  Vertices: 39964  Indices: 59946  root: 0x0 opacity: 1
 -> times: build: 0, prepare(opaque/alpha): 0/0, sorting: 0, upload(opaque/alpha): 0/1, render: 0

As we can see, we still have a single batch with 1000 nodes, but the data is not retained, causing us to upload almost 40000 vertices per frame. In a more complex application, this may also invalidate other parts of the graph. We could even end up redoing everything for every frame if we are especially unlucky.

So, presented with this case and after analyzing what was actually going on, my first goal was to find a work-around for the customer. I needed to come up with a way to separate out the counter label into its own batch, without changing how anything looked on screen. There may be more ways of doing this, but what I ended up suggesting to the customer was to set clip to true for all the counter labels. Giving the counters a clip node parent in the graph will force them out of the main batch, and the updates will thus be isolated to the clipped part of the scene graph.

import QtQuick 2.5
import QtQuick.Window 2.2

Window {
    id: window
    visible: true
    title: qsTr("Hello World")
    visibility: Window.Maximized
    property int number: 0

    Flow {
        anchors.fill: parent
        Repeater {
            model: 1000
            Text {
                text: index === 500 ? number : "Hello World"
                clip: index === 500
            }
        }
    }

    NumberAnimation on number {
        duration: 200
        from: 0
        to: 9
        loops: Animation.Infinite
    }
}

Still the same code, except that the clip property of the 501st Text item is now set to true. If we run this updated form of the application with the same debug output, we get the following:

Renderer::render() QSGAbstractRenderer(0x143890afa10) "rebuild: partial"
Rendering:
 -> Opaque: 0 nodes in 0 batches...
 -> Alpha: 1000 nodes in 3 batches...
 - 0x143898ee6d0 [retained] [noclip] [ alpha] [  merged]  Nodes:  500  Vertices: 20000  Indices: 30000  root: 0x0 opacity: 1
 - 0x143898ec7e0 [  upload] [  clip] [ alpha] [  merged]  Nodes:    1  Vertices:     4  Indices:     6  root: 0x14389a3a840 opacity: 1
 - 0x143898edb90 [retained] [noclip] [ alpha] [  merged]  Nodes:  499  Vertices: 19960  Indices: 29940  root: 0x0 opacity: 1
 -> times: build: 0, prepare(opaque/alpha): 0/0, sorting: 0, upload(opaque/alpha): 0/0, render: 0

As you can see from the output, the text is now divided into three batches instead of one. The first and last are retained between frames, causing the full upload for each frame to be an insignificant 4 vertices. Since the clip rect contains the bounding rect of the text, we will not actually clip away any pixels, so the application will still look the same as before.

So all is well that ends well: The customer was happy with the solution and their performance problems were fixed.

Also, I gained some ideas on how we can improve the Qt Quick API to make it easier for users to avoid these problems in the future. Since we want performance to be stable from the first frame, I don’t think there is any way to get around the need for users to manually identify which parts of the graph should be isolated from the rest, but I would like to have a more obvious way of doing so than clipping. My current idea is to introduce a set of optimization flags to the Qt Quick Text element, one of which is Text.StaticText, sister to the QStaticText class we have for QPainter-based applications.

In the first iteration of this, the only effect of the flag will be to ensure that no label marked as StaticText will ever be batched together with non-static text. But down the road, maybe there are other optimizations we can do when we know a text label never (or rarely) changes. And this is just one of a few optimization APIs I want to add to Qt Quick Text in the near future, so stay tuned! ��

The post How to shoot yourself in the foot using only a scene graph (neat optimization trick inside) appeared first on Qt Blog.

January 18, 2017

Android Things is Google’s answer to creating an environment for IoT devices. Take a slimmed down Android build, add some sensor-specific APIs, and provide it on a number of powerful pre-integrated micro-boards and you have a ready-made platform for building a host of upcoming IoT devices. Android Things can take advantage of many existing Android libraries, toolkits, and APIs, making it easier and quicker for developers to turn ideas into product. What’s not to like?

We decided to test this theory by checking out the Android Things Developer Preview on a Raspberry Pi 3. We were looking to assess the overall experience, to understand what types of products it is targeting and to try to determine how well it can support Qt.

Raspberry Pi 3 (Model B)

One of my very first observations is that Google does not provide the source, just a pre-built image. This makes it difficult to customize the image and puts us at the mercy of Google for updates to any of the contained components or packages like the kernel or SSL library. Let’s hope that this will change once we’re beyond the Developer Preview stage.

Once you have the image loaded onto a board, it’s time to boot it and take it for a spin. This is an appropriate time to get a coffee — and you’ve got the time to drive to Starbucks — because booting Android Things takes a very long time. Linux builds for Yocto or Debian on the same hardware boot significantly faster than Android Things, so we can probably assume the boot process hasn’t yet been fine-tuned. Without knowing the final boot speed of an Android Things product, you may want to plan use cases around a system that’s always on and rarely needs a reboot, or that isn’t real-time and can afford a boot process that takes minutes.

The Android Things Preview on the Raspberry Pi 3 doesn’t provide OpenGL ES support or a virtual keyboard, which severely limits what type of Android Java apps will run. (Unfortunately, that also means it cannot support Qt QML either.) It’s pretty safe to say that if your device plans to have a full smartphone-like display, you might not want to use Android Things anyway. Although it does support frame buffer graphics, without hardware acceleration the graphics are quite pokey. Our guess is that even if Android Things will eventually support OpenGL ES, its best application will be for a headless configuration or one where your display needs aren’t too sophisticated.

Unfortunately, boot speed and graphics aren’t the only things that are sluggish. Running and installing apps are quite slow: first time loads for a Java app are around 20 seconds, and for a Qt app around 25 seconds. This delay is likely due to the AOT compiler, because things speed up dramatically to a boot in just 2-3 seconds on subsequent loads. While this is a pain for developers who will suffer these load times for each new build, the AOT compiling means that customers would only notice a slow experience first time out-of-the-box.

Now for the good news. Qt developers will be happy to know that Qt Creator works very well with Android Things — running and debugging apps just works. And not only will QWidget-based applications run on Android Things, they’re even faster than the platform’s native Android Java widgets. This may not be saying much without GPU-accelerated graphics but any speed improvement is a bonus.

Also good news is the device’s security. Android Things uses the Android security/permissions model across the board, letting you have complete security control of your IoT device access, and placing all apps in isolated containers by default. With IoT security being a primary concern, built-in security from the ground up is most welcome.

Finally, Android Things is Apache 2 licensed. People who are building an IoT device to be sold as a product will appreciate that they don’t have to open up their source code to the world. It is a disadvantage to those who are tinkering but this choice (and the Google source ownership) pretty clearly point to a commercial product bias.

Conclusion

Android Things

If you’re an Android fan, you’ll like where Android Things is going. It’s a bit on the slow side, as it’s clearly designed with certain use cases in mind — like little (or no) display and infrequent reboots — but the benefits of Android development may outweigh the disadvantage of carrying around a massive Android runtime. It will definitely suffer on low-end devices but we can hope that optimizations will be made as more programmers get their hands on it. We’ll certainly be keeping our eyes on it and, as running C++ can do nothing but help the overall speed, we’ll be trying to make sure that it supports Qt as best as possible.

The post “Unboxing” the Android Things Developer Preview appeared first on KDAB.

Qt Quick-based user interfaces have traditionally been requiring OpenGL, quite unsurprisingly, since the foundation of it all, the Qt Quick 2 scenegraph, is designed exclusively with OpenGL ES 2.0 (the top of the line for mobile/embedded at the time) in mind. As you may have heard, the graphics API story is a bit more inclusive in recent Qt versions, however the default OpenGL-based rendering path is, and is going to be, the number one choice for many applications and devices in the future. This raises the interesting question of OpenGL implementations.

Wait, there is more than one? Isn’t there one for my graphics card, and that’s it?

Kind of, but not quite.

The vendor-provided OpenGL implementation is one thing, but is is not always there to begin with (anyone who attempted to deploy Quick apps on a wide range of older machines running e.g. Windows 7 with no graphics driver installed could likely talk a lot about this…), while in some cases there are alternative options, for instance an open-source stack like Mesa. Some of these stacks can then provide multiple ways of operation (think software rasterizers like Mesa llvmpipe or Direct3D WARP).

As an example, let’s take a look at Windows. The Windows-specific area of the Qt documentation describes the options pretty well. To summarize, one may be using OpenGL proper (a vendor-provided ICD behind opengl32.dll), ANGLE in D3D9 mode, ANGLE in D3D11 mode, ANGLE with the D3D11 WARP software rasterizer, an OpenGL software rasterizer provided by Mesa llvmpipe. That is no fewer than 5 options, and the choice can be made based on the built-in GPU card/driver blacklist or environment variables or hard-coded application preferences. All this is not exactly rocket science, but it does require a certain level of awareness from the developer during development, possibly when reporting bugs and support requests, and naturally also when planning deployment.

Why does this matter?

  • It is not always obvious what is going on. Just starting a Qt Quick application and getting some output does not mean rendering is happening on the optimal path. When the application does not render at the expected speed, the very first thing to verify is if the graphics stack is the expected one. There can always be an unexpected environment variable or blacklist rule present, or the application may pick the wrong graphics stack when there are multiple ones present in the system.
  • Some of the options come with a set of drawbacks and affect the runtime behavior (most importantly, the choice of the Qt Quick render loop used behind the scenes), which in turn can affect performance and can even disable features. (No threaded render loop? No render thread Animators for you.)
  • When reporting issues to the Qt Project bug tracker or Qt Support, it is essential to provide the necessary information about the runtime environment. A mere “OpenGL on Windows” or “Qt Quick on an ARM device” is never sufficient.

QSG_INFO=1 is your friend

When in doubt about graphics performance or before attempting to troubleshoot any sort of graphics issues, do set the QSG_INFO environment variable to 1 and rerun your Qt Quick application.

An alternative in modern Qt versions is to enable the qt.scenegraph.general logging category.

This will print something like the following either on the console or the debug output: (on Windows you can use DebugView for non-console apps when not launching from Qt Creator)

qt.scenegraph.general: threaded render loop
qt.scenegraph.general: Using sg animation driver
qt.scenegraph.general: Animation Driver: using vsync: 16.95 ms
qt.scenegraph.general: texture atlas dimensions: 2048x2048
qt.scenegraph.general: R/G/B/A Buffers:    8 8 8 0
qt.scenegraph.general: Depth Buffer:       24
qt.scenegraph.general: Stencil Buffer:     8
qt.scenegraph.general: Samples:            0
qt.scenegraph.general: GL_VENDOR:          NVIDIA Corporation
qt.scenegraph.general: GL_RENDERER:        GP10B (nvgpu)/integrated
qt.scenegraph.general: GL_VERSION:         OpenGL ES 3.2 NVIDIA 367.00
qt.scenegraph.general: GL_EXTENSIONS:      ...
qt.scenegraph.general: Max Texture Size:  32768
qt.scenegraph.general: Debug context:     false

What does this tell us?

The OpenGL vendor, renderer and version strings. In the example above we see Qt Quick is using an OpenGL ES 3.2 context on some NVIDIA embedded platform, using the vendor’s driver. This look good.

Now, if there happen to be references to llvmpipe, like in the below example, then that should immediately raise a flag: your application is rendering via a software rasterizer. If this is expected, fine. If not, then you should figure out why, because performance is seriously affected (you are not using the GPU at all).

GL_VENDOR: VMware, Inc.
GL_RENDERER: Gallium 0.4 on llvmpipe (LLVM 3.6, 128 bits)
GL_VERSION: 3.0 Mesa 11.2.2

Let’s take another example, this time with ANGLE. Here I just forced the usage of ANGLE by setting QT_OPENGL=angle on an otherwise fully OpenGL capable system:

qt.scenegraph.general: windows render loop
qt.scenegraph.general: Using sg animation driver
t.scenegraph.general: Animation Driver: using vsync: 16.67 ms
qt.scenegraph.general: texture atlas dimensions: 512x512
qt.scenegraph.general: R/G/B/A Buffers:    8 8 8 8
qt.scenegraph.general: Depth Buffer:       24
qt.scenegraph.general: Stencil Buffer:     8
qt.scenegraph.general: Samples:            0
qt.scenegraph.general: GL_VENDOR:          Google Inc.
qt.scenegraph.general: GL_RENDERER:        ANGLE (NVIDIA GeForce GTX 960 Direct3D11 vs_5_0 ps_5_0)
qt.scenegraph.general: GL_VERSION:         OpenGL ES 2.0 (ANGLE 2.1.0.8613f4946861)
qt.scenegraph.general: GL_EXTENSIONS:      ...
qt.scenegraph.general: Max Texture Size:  16384
qt.scenegraph.general: Debug context:     false

The key points are that (1) we are using ANGLE, (2) it is using its D3D11 backend, and (3) the Qt Quick scenegraph is using the (somewhat ill-named) ‘windows’ render loop, meaning no dedicated render thread is present. The usage of D3D9 or D3D11 WARP can be recognized from the renderer string in the same way.

Then there is the Qt Quick scenegraph’s active render loop. This can be threaded, basic or windows. In recent Qt versions the scenegraph documentation describes all of these quite well, including the logic for choosing the loop to use. For experimenting or troubleshooting one can always override by setting the environment variable QSG_RENDER_LOOP to one of the three render loop names.

One common problem, mainly on embedded systems, is sometimes the bizarre speed up of animations. If you find that QML animations are running a lot faster than they should be and that the threaded render loop is in use, there is a good chance the issue is caused by the missing or incorrect vertical sync throttling. Solving this will be platform specific (e.g. in some cases one will need to force making a dedicated FBIO_WAITFORVSYNC ioctl, see QT_QPA_EGLFS_FORCEVSYNC), but armed with the logs from the application at least the root cause can be uncovered quickly and painlessly. (NB as a temporary workaround one can force the basic render loop via QSG_RENDER_LOOP=basic; this will provide more or less correct timing regardless of vsync at the expense of losing smooth animation)

Your other friends: qtdiag and contextinfo

Note that the scenegraph’s log only provides limited system information. It is great for strictly graphics and Quick-related issues, but when making bug reports, especially for Windows, it is strongly recommended to post the output of the qtdiag utility as well. This will provide a lot wider set of system information.

Additionally, the contextinfo example in examples/opengl/contextinfo is a good tool to troubleshoot basic OpenGL bringup problems. Launch it normally, click Create Context, see what happens: does the triangle show up? Does it rotate smoothly? Are the vendor and renderer strings as expected? Then set QT_OPENGL=angle and re-run. Then set QT_ANGLE_PLATFORM=d3d9 and re-run. Then set QT_OPENGL=software and, assuming the opengl32sw.dll shipped with the pre-built Qt packages is accessible, re-run. Or on Linux with Mesa, set LIBGL_ALWAYS_SOFTWARE=1 and see what happens. And so on.

Why am I not getting the right GL implementation?

Now, let’s say the logs reveal we are stuck with a software rasterizer and our beautiful Qt Quick UI runs sluggishly in a maximized full HD window. What can we do to figure out why?

On Windows, enable the logging category qt.qpa.gl. (e.g. set QT_LOGGING_RULES=qt.qpa.gl=true) This will tell why exactly the OpenGL implementation in question was chosen. The typical reasons are:

  • opengl32.dll not providing OpenGL 2.0
  • the card PCI ID or driver vendor/version matching a built-in GPU blacklist rule
  • having the QT_OPENGL or QT_ANGLE_PLATFORM environment variables set
  • having a hard-coded request like Qt::AA_UseSoftwareOpenGL via QCoreApplication::setAttribute().

On Linux, there are typically three reasons:

  • With Mesa, the environment variable LIBGL_ALWAYS_SOFTWARE forces a software rasterizer. Check if it is set, and if it is, investigate why.
  • In some environments no hardware acceleration is available. In some virtual machines for example, you will be stuck with a Mesa llvmpipe based rendering path.
  • Multiple graphics stacks. This can happen on any kind of Linux systems, but is more likely to happen on some embedded device oriented distros. Running ldd on the application and the relevant Qt libraries, and looking for libGLESv2.so may help to figure out what is going on.

A cautionary tale

The Raspberry Pi has at least three OpenGL solutions as of today: the Broadcom graphics stack, Mesa with llvmpipe (software rasterizer), and the upcoming Mesa with proper GPU acceleration (VC4) path.

Unfortunately this can lead to an unholy mess due to some distros prefering to ship Mesa llvmpipe in order to provide some sort of OpenGL under X11 (which the Broadcom stack does not support): Qt applications may unexpectedly pick up Mesa when they should use Broadcom (for Dispmanx without X11), while they may end up with disastrous performance under X11 due to overdriving the poor CPU with software GL rasterization.

While it is easy to blame Qt, JavaScript VMs, scripting languages, C++, and everything but the kitchen sink when one’s Quick application runs slowly, the solution to figure out the root cause is often even easier: QSG_INFO=1.

That’s all for now. Take care, and make sure to check the output from QSG_INFO=1 next time.

The post Which OpenGL implementation is my Qt Quick app using today? appeared first on Qt Blog.

I guess you all have heard about Flatpak, Snappy and sandboxing in general. Flatpak is a new way of distributing applications. With Flatpak applications are running in sandbox, which means they are isolated from the rest of your system. With that in mind you need a way how to access some stuff outside the sandbox, like your files or have access to your hardware. To solve this problem the Flatpak developers came up with portals. Portals are high-level session bus APIs that provide access to resources to sandboxed applications. Idea is that there is one DBus service available and visible for the sandboxed application which is supposed to communicate with it to get access outside the sandbox. Then this one service communicates with backend implementations which may be different per desktop so you have in example a Gnome implementation or in my case KDE implementation. The backend then provides dialogs so users can access files or hardware outside the sandbox. To add portal support you need to add your backend implementation, which is quite easy part and if you don’t have any then one from other available ones will be used. Complicated part is to alter the framework the application is using to use the portal DBus service instead of doing what it usually do (e.g. when opening a file dialog you want to send a request over DBus instead of actually displaying the dialog). I’ve been playing with this for some time and I tried to cover the most common or required portals. Let’s go through all of this:

File chooser portal

I think this is the most common and needed portal from all of them. I’ve added a backend implementation as well as support for this to Qt in form of my own Qt platform plugin. Given you can modify Qt’s behaviour using your own Qt platform plugin then I didn’t have to modify Qt at all. The platform plugin alters FileDialog to talk around DBus instead of showing the dialog. The dialog is then shown thanks to the backend implementation and user running app in sandbox shouldn’t notice any difference. The file chooser portal supports both opening and saving files with possibilities to set properties like filters, accept label text etc. which are all already implemented in both like in the platform plugin and the backend.

App chooser portal

This portal allows the user to select an application outside the sandbox which should be used for opening a document, a file or whatever. It is also used when opening an url. On the backend side this is just a simple dialog with list of possible applications associated with given file/document type. On Qt side I added my own implementation of OpenUrl() again into the platform plugin to make it transparent the same way the file dialog works.

Print portal

I guess the most complicated and also quite important portal. I’ve been able to add just backend implementation so far which will be used for printing from gtk applications as gtk already supports printing from sandbox. The idea behind this portal is that when app requests to print a document, it calls PreparePrint() method and the backend presents classic print dialog to the user where he can configure printer, setup the page and paper and so on. This configuration is then passed back to the application where the framework is supposed to create a pdf or ps file already pre-formatted and ready for printing. This file is then passed as file descriptor again to the backend using Print() method and printed. This all works with Qt backend and gtk app, or Gnome backend and gtk app, but unfortunately not yet with Qt apps as I still don’t know how to do this without touching Qt code as this cannot be done on platform plugin level, at least from what I can see. A simple solution can be to don’t touch Qt at all and let the app print the document to file and have a simple utility sending this file through the portal to print it. As you can set application name which should be used for printing in QPrinter, then we maybe can just set this automatically when the app is running in sandbox to make this work automatically. I’m definitely open to your ideas or any help :).

Notification portal

Again very useful portal and not that complicated. I have full backend implementation presenting a notification outside the sandbox when someone calls AddNotification() method. To make this work for KDE applications automatically I had to modify KNotifications framework and implement my own flatpak plugin which replaces NotifyByPopup plugin. All this plugin does instead displaying a popup it calls the portal DBus service which then calls AddNotification() in my backend and presents notification outside the sandbox. Both the plugin and backend supports also sending back information about triggered action so you can also get feedback back to the sandboxed application.

Those are all the portals I have fully or partially covered so far. There are of course more portals designed in Flatpak portal API, like screenshot portal, inhibit portal, but for some of them we don’t have any framework/API or they are not that important so they will be added later. I also have a test application which you can run in sandbox and test all the portals.

How to use flatpak portals

In order to use flatpak portals, either my implementation or the Gnome one, you need to install xdg-desktop-portal which is the main portal DBus service visible to sandboxed applications and which calls backend implementation. For gtk implementation you need xdg-desktop-portal-gtk and for KDE/Qt implementation you need xdg-desktop-portal-kde. This is required to be installed outside the sandbox to present dialogs for file and hardware access. To add support for portals to your sandboxed application you should be fine already with gtk, with Qt and KDE you need my Qt platform plugin and my modifications made to KNotifications. To use those you need to modify flatpak manifest to include them during build so they are available in the sandbox. You can get inspiration in my test app manifest. And finally to use my platform plugin as KNotifications will be used automatically you need to start your app using flatpak run your_app -platform flatpak.

I guess that’s all from me today. Patches and improvements are warmly welcomed as well as any reported issue. If you want some information about Flatpak and KDE in general, we have setup a wiki page where you can find information about KDE runtimes and applications packaged for Flatpak. There will be also a talk at FOSDEM this year about Flatpak and KDE from Aleix Pol.

Google Code-in has just finished where school pupils do tasks to introduce themselves to open development.  I had one to update the screenshots on www.kde.org.  The KDE website is out of date in many ways but here’s a wee way to fix one part of it.  Despite me having about half a dozen students work on it there’s still some old screenshots there so if anyone wants the satisfaction of contributing to www.kde.org’s front page here’s an easy way.

www.kde.org has screenshots of all our apps but many still use the old KDE 4 Oxygen widget theme and icons.

For 10 screenshots which is using the old theme take a new screenshot using the new theme.

They can be checked out from Subversion here https://websvn.kde.org/trunk/www/sites/www/images/screenshots/ also provide one the resized screenshot which is 400 pixels wide exactly.

Keep the filenames the same and in lower case.

Upload as a single .zip or .tar.gz containing the screenshots with the right file name and a folder resized/ with the 400px screenshots

For bonus points you could go through the index file to make sure it’s current with KDE applications https://www.kde.org/applications/index.json
Facebooktwittergoogle_pluslinkedinby feather

January 17, 2017

Seven years ago at Camp KDE in San Diego, Frank announced a project to help people protect their privacy, building an alternative to Dropbox: ownCloud.

I was there, sharing a room with Frank at the infamous Banana Bungalow. Epic times, I can tell you that - there was lots of rum, lots of rain and loads of good conversations and making new friends.





Since then, a lot has changed. But the people who started building a self-hosted, privacy protecting alternative in 2010 and 2011 are still on it! In 2011, a first meetup was held, and the 5 participants at that meetup recently got on stage at the Nextcloud conference to recall some good memories:



Of course, today we continue the work at Nextcloud, that just yesterday published its latest bugfix- and security update. It is great to see so many people have stuck with us for all these years - just this month, the KDE sysadmins migrated their ownCloud instance to Nextcloud!

We'll keep up the good work and you're welcome to join, either if you're looking for a job or just want to code. In both cases I can promise you: working with such a motivated, dedicated, professional team is just plain amazing.

I also published a blog on our Nextcloud blog about this milestone.

EDIT: By the way - there's a meetup tonight in C-Base, B'lin, 19:00 - would be fun to drink a beer on ownCloud's birthday and talk about the future! Join! It will be at least until 10 or so, so if you can't be there before then - still come! ;-)

Update: Both Flipkart and Amazon Extractor (Python) with fine, expect for the fore-mentioned issue.

The purpose for which i made the python extractors, give quite accurate results. Parsing the email, to find the appropriate data was quite fun, but what worries me is the longevity of the semi-sketchy methods to extract the data.

Scrapely worked beautifully, but there were some unironed kinks which need attention while parsing the information.

{   "id" : "OE1004125T3442...",
    "total": "Rs. 310",
    ...
    ...
    "name":"<div><span><b><a href="http:// .../../..">ProductName</a></b></span></div>"
}

We can see here that the value of  “name”  is messed up a bit.
The desired result that was needed was:

{"name" : "ProductName"}

Yeah well, for now there was only way which came into my mind to parse this, was some sketchy method �� . But rest assured, everything else works fine.

January 16, 2017

Next month is FOSDEM, the largest gathering of free software developers anywhere in Europe. FOSDEM 2017 is being held at the ULB Campus Solbosch on Saturday 4th and Sunday 5th of February. Thousands of coders, designers, maintainers and managers from projects as popular as Linux and as obscure as Tcl/Tk will descend on the European capital Brussels to talk, present, show off and drink beer.


You won't believe what the KDE community's next weird collaboration is about. Find out at FOSDEM.

KDE will have a stall in building K where we will demonstrate our latest software including KDE neon running on Docker, the newest build of Plasma Mobile using Android Open Source Project, and a very exciting mystery announcement.

Our Saturday parties have become legendary and this year's party has a new location at Le Magic Rubens in the city centre. Sign up on the wiki page if you'd like to come.

We will be taking part in the Desktop devroom on Sunday where several presenters will give talks about KDE.

Bundling KDE - Where does KDE land in the Snap and Flatpak world? by Aleix Pol Gonzalez (apol)

How we are integrating the Snap and Flatpak packaging systems into Plasma and what steps we've had to take to get KDE applications packaged and working on Flatpak and Snap.

KDE is present on different platforms, but most notably on GNU/Linux and it's here where we're seeing the most changes lately. In this presentation I'll explain how we are integrating the Snap and Flatpak packaging systems into Plasma and then what steps we've had to take to get KDE applications packaged and working on Flatpak and Snap.

From Gtk to Qt: An 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.

by Tomaz Canabrava

As subsurface evolved from a Gtk Application to a Qt one, cutting a quarter of the codebase while still gaining new functionalities, a new question arose: "How do we get this desktop based application and run it on mobile, on a unified codebase?"

How do we take a kernel developer application writen in kernel-style code for the desktop and make it universal, able to run in any operating system be it mobile or desktop?

In this talk I'll present you piece-by-piece history on what we had when Subsurface started, the challenges that kernel hackers faced when creating a desktop application and why the choice was made to port away from Gtk into Qt - even though the main developer of subsurface back then loathed C++.

After the initial port to desktop a new era began, the era of mobile applications, and Qt had launched it's new QML language that promised good integration on mobile and even desktop with minimal effort. We wanted to give it a try. At the same time the KDE hackers launched a new project "Kirigami", a library build on QML to simplify development of QML based software. Since we were already on the bleeding edge of things, why not give it a try?

This is the tale of Subsurface, From Gtk to Qt to Mobile, from one of it's main hackers.


Last year's KDE @ FOSDEM party to launch KDE neon, what will this year's party
launch?

Kube - The next generation communication and collaboration client by Christian Mollekopf

Kube is a beautiful, modern communication in a reliable, high-performance native groupware application for your desktop, laptop and mobile devices.

Kube is a next-gen communication and collaboration client built with QtQuick on a high performance, low resource usage core. It provides online and offline access to all your mail, contacts, calendars, notes, todos 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.

While the initial focus is on the Linux desktop, the platform is built to run on all desktop systems as well as on mobile devices.

This talk is giving an overview of what Kube is and strives to be, along with some history why this effort has been started in the first place. The talk will go into some technical detail, but is suitable for anyone interested in an alternative to the currently existing groupware clients.

With over 8000 hackers attending to particulate in hundreds of lectures FOSDEM is one of the premier conferences to collaborate with other developers and be informed about the latest developments in the free software community. We look forward to seeing you there!

After quite some delay, I finally assembled a second release candidate for KBibTeX 0.6.1. Version 0.6.1 will be the last release in the 0.6.x series.

The following changes were applied since the release of 0.6:

Read more to learn which changes were applied )

comment count unavailable comments

January 15, 2017

A new wonderful era for the Calligra Suite has begun with the release of version 3.0.

We have chosen to cut back on the number of applications. Krita has left us to be independent and although it was emotional it was also done with complete support from both sides. We are saying goodbye to Author, which never differentiated itself from Words. We also removed Braindump the purpose of which will be better fitted by a new application (nothing planned from our side). Flow and Stage has gone in this release but we intend to bring them back in the future. And Kexi has own release schedule but is still part of the Calligra community.

What’s New?

The 3.x series is built on top of KDE frameworks 5 and Qt5 which in and of itself doesn’t bring much new but it ensures that we stay current. It took a lot of effort which means we haven’t made many other new features.

Hi,

in the recent months, I didn’t find much time to spend on Kate/KTextEditor development. But at least I was now able to spend a bit more time on OpenSource & Qt things even during work time in our company. Normally I am stuck there with low level binary or source analysis work.

For our products, we were in the need of some online help. As our documentation is delivered as PDFs generated by the tools of the TeX Live distro, a natural idea was to use some PDF viewer and integrate it more tightly in our software than just “open the manual at page 1”.

We did review PDF viewers out there, but most (like Okular) have too many dependencies to be just bundled with our product (or a license not permitting that).

Without bundling, we can’t ensure that the tight coupling is working, without starting to test the integration with X different viewers which more or less all need other kinds of command line arguments to open the right page or even lack that feature or will not reuse an already running instance, ….

Therefore, as our GUIs are developed with Qt anyways, we did take a look at libpoppler (and its Qt 5 bindings), which is the base of Okular, too.

Easy enough, taking the small demo program shipped with the library and adding a small stdin based interface to tell it “goto <named reference>” we arrived at some small PDF viewer that is fit enough for our use case.

We named the thing “FirstAid”, the sources can be grabbed at github.com/AbsInt/FirstAid. Like libpoppler and the demo, its licensed as GPLv2+.

As already the README states, the aim of this small project is not to replace some full fledged viewer like Okular, the design goal is to have a small viewer that is auto-started by some host application and will jump to the requested labels for a tightly coupled online help. It can be used as a pure standalone PDF viewer, too, but that is more intended for testing it e.g. on the documents that should later be shown as online help.

FirstAid

I already annoyed Albert with some small issue I had with libpoppler, perhaps I will provide more useful fixes in the future if more things come up during FirstAid development. In any case, already THANKS A LOT for the Qt 5 bindings around libpoppler, they work nicely for us!

I really think this small project shows the benefit of OpenSource: We needed a PDF viewer, we were able to create a small one in less than a month based on OpenSource libraries and we can give back the results to the community (if it is useful for others is a different story, but perhaps other people have the same itch to scratch, if not, ignore it). I hope more possibilities for such things come up at work in the future.

For building: It should build out of the box if you have some recent Qt and libpoppler-qt5-dev installed, at least the Travis CI is able to build it out of the box with the given config. For me, it shows some small bugs if used with Qt 5.6/7 compared to the Qt 5.8 Beta I used here for testing.

KDE's Google Code-in party is ending once again. Student work submitted deadline is January 16, 2017 at 09:00 (PST). 

Mentors, you have until January 18, 2017 at 09:00 (PST) to evaluate your student's work. Please get that done before the deadline, so that admins don't have to judge the student work.

Then it will be time to choose winners. We need to have our choices in by January 23, 2017 at 09:00 (PST). Winners and Finalists will be announced January 30, 2017 at 09:00 (PST).

To me, this contest has been lovely. Because there are more organizations participating now, there are more tasks for students, and less pressure on each org. It seems that the students have enjoyed themselves as well.

Spencerb said, in #kde-soc, This was my first (and final) gci, so I don't have much of a point of comparison, but it's been awesome. I've been an opportunity to meet new people and just get involved with KDE, which I've wanted to do for a long time. I've also learned a lot about serious software development that I wouldn't have otherwise.

"I'll turn 18 this Monday, which is why this is my last year :(  I'm so glad to have had the chance to participate at least once.

As a task, Harpreet filed a GCi review: http://aboutgci2016.blogspot.in/

So far, we've had 121 students. The top ten have 103 completed tasks so far! And 160 tasks completed so far. Most exciting for me is that Beginner tasks completed: 45. Getting kids acquainted with Free and Open Source Software communities, which is why every organization must have beginner tasks. I'm glad 45 kids got to know KDE a bit.


January 14, 2017

On FreeBSD, Qt4 is still a thing — for instance, for the KDE4 desktop that is still the latest full-KDE experience you can get from the official packages. And although that software is pretty old, the base system still evolves. FreeBSD 9 has been put to rest, and with it all the GCC-based FreeBSD systems. That frees us from having to deal with GCC and Clang at the same time, and we can generally patch things in just one way (usually towards more-modern C++). But the base system also evolves “out from under” older software. There’s an effort to update the base system compiler (for FreeBSD 12) to Clang 4.0 (sometime soon-ish), and that means that our older C++ code is being exposed to a newer, pickier, compiler.

Seems like I’ve been doing “fix KDE stuff relative to pickier compilers” since, like, forever (on Solaris, and then FreeBSD, and then Solaris again, and OpenSolaris, and then FreeBSD).
Anyway, today’s little fix comes from Qt4 Linguist (devel/qt4-linguist in the ports tree), where we find this code:
if (c->findMessage(m->text(), m->comment()) >= 0)
Here findMessage() returns a MessageItem*, so that’s a nonsensical comparison that should be != 0 instead (or idiomatically, just leave out the comparison but Qt4 sources are somewhat inconsistent in their formulation of null-pointer checks).
So there’s — for me — a brief interlude of messing with old codebases in preparation for new things, while the rest of the KDE-FreeBSD team deals with newer things like the latest KDE Frameworks and Plasma Desktop releases (which, as I’ve said many times, may be had from the area51 repository and work fine, but are waiting on various dependencies in the official ports tree).


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.