May 30, 2017

1 month of GSoC is already over and the coding period has officially begun. Here’s a highlight of what I did and what I plan to do for this week

Most of the time of community bonding period was spent giving college exams. By the time my exams got over,  I only had a week left to make something useful of the community bonding period time.

The last week started with a discussion with my mentor , where we decided which API to use to port the back ends.  We had to  decide between QProcess and KProcess. Just a brief of what these APIs do:

QProcess is used to start external programs and to communicate with them. The communication between QProcess and the external program happens through channels. The three standard channels used for communication are
Standard output(stdout): supplies regular console output
Standard error(stderr): supplies the errors that are printed by the process
Standard input(stdin): provides input to the process

KProcess is no different from QProcess. It inherits QProcess and extends it by by some extra and useful functionality

Since a few of the back ends of cantor were already using KProcess, we had to decide whether we actually need KProcess or whether QProcess will suffice our needs. The best  way to  decide this  was to port a back end which makes use of KProcess to QProcess.

Port of Scilab to QProcess

The port process was pretty simple and did not take more than an hour to port and test. The test was performed  on various inputs including plot commands.
You can have a look at the commit that actually does the port
Since Everything worked fine, we decided to move forward with QProcess and use it for other back ends

Plan for this week

The very first back end I have decided to work on is Qalculate. Qalculate at the moment uses libqalculate library for all the calculations.
To get rid of libcalulate, we will be making use of qalc which is the command line interface for Qalculate
This week  I’ll be concentrating on setting up basic communication  between Cantor and  Qalculate using  qalc

Let the hacking begin!

May 29, 2017

The KDE/FreeBSD website has been around for a long time. It has been the repository of much (well, maybe some) wisdom around KDE-on-FreeBSD. But as a repository of knowledge, it has been rather limited in recent years: it lives in KDE’s source-code repositories, and as such has a pretty high barrier to entry. You need a KDE developer account to edit it, for one. And then, editing PHP files in git is not fun, if you’re trying to contribute documentation, howto’s, or screenshots.

So the content has almost entirely migrated to the KDE Community wiki.

The community wiki is described as: is the working area for the KDE community. It provides a place for sharing information within the community, including policies, guidelines and coordination.

That’s most of what f.k.o does, so putting it somewhere more accessible, and easier to edit, makes sense.

There’s only two things really left in git: the team page, describing who is on the team, and the in-memoriam page for Alan Eldridge. Neither of those is, in my opinion, up for community-editing-debate.

So now’s the time for FreeBSD-using KDEsta’s, and KDE-using FreeBSDudes, to get the content together!

Ha sido lanzado KIO GDrive 1.2, un servicio para aplicaciones Plasma con el que tendremos todas la facilidades para trabajar con nuestros documentos en línea y cuya nueva versión incluye integración con Plasma/KAccounts. Una opción más para trabajar con documentos sincronizados en la nube al estilo de NextoCloud o Dropbox pero utilizando servidores de la gran G.

Lanzado KIO GDrive 1.2, ahora con integración con Plasma/KAccounts

Ya hablé y expliqué detenidamente qué era KIO Gdrive cuando se lanzó su primera versión estable. Ahora es el momento de ir supervisando su desarrollo e ir anunciando nuevas versiones, destacando su novedades.

Pues bien, el pasado 26 de mayo fue lanzado KIO GDrive 1.2 cuya principal novedad es su integración con los KAccounts de Plasma, con lo que su uso se hará casi estándard para los ususarios de Plasma que lo deseen, y que se viasualiza el espacio libre disponible en el Google Drive.

Una gran mejora y una pequeñita que demuestra que el proyecto sigue vivo.

Un gran servicio que se va a convertir un imprescindible para aquellos que tenemos que utilizar servicios de la gran G.

Más información: aelog

Cómo instalar KIO GDrive

Los detalles de KIO GDrive los podéis encontrar en la Wiki de la Comunidad pero a modo de resumen, y según distribución, la instalación de KIO Gdrive se realiza abriendo una consola. y escribiendo:

KDE neon

$ sudo apt install kio-gdrive


$ pacman -S kio-gdrive


$ cave resolve kio-gdrive


$ emerge kde-misc/kio-gdrive


Para Tumbleweed:

$ zypper install kio-gdrive

Para Leap debemos instalar el siguiente repositorio: y ejecutar igual que para Tumbleweed.

Lanzado KIO GDrive

Participa en el desarrollo de KIO GDrive

Si estás interesado en saber más del proyecto o echar una mano te comento los canales de comunicación:

Y si quieres tener acceso al código fuente o reportar bugs:


Few hours to go for the start of the coding period of GSoC, and here are my plans for the first week.

As mentioned in my proposal, I will be starting off with the Pilot a Submarine activity. In this week, I will be focusing on the tutorials and the basic structure of the levels of the activity as follows (may be subject to change, depending on feedbacks):

  • There will be 10 levels approximately in the activity, in 3,4,3 format (first 3 = beginner level, next 4 = intermediate and last 3 = challenging)
  • The initial levels will be tutorial levels. It will be mostly used to explain the various components of the submarine: the enigne, rudders and the air tanks. This will take up the 3 basic levels, with each of the components being explaned in each of the first three levels.
  • The intermediate level will mostly contain items like obstacles and jewels in the form of pickups to increase the difficulty curve of the levels
  • The final challenging levels (the number of levels of this types may be reduced to one, depending on the difficulty) will require the player to react a bit faster, the “gate” (from the original “Pilot a Submarine” activity) will be closing instead of opening and the player will need to complete the level before the gate closes, thus require the player to act faster compared to that of the previous intermediate levels.
  • If time permits me, I will move on to implement the functionalities of the submarine using box2d. Also, I will be looking forward to improving the controls of the submarine to make it more intuitive for the children to understand. Any suggestions regarding it is always welcome!

More in depth on the progress of the implementation and mockups of the levels will be posted in the blog, as the work progresses.

For any feedbacks related to the plans, feel free to contact me regarding it:

  • Email:
  • Freenode IRC nick: rudra / rudra_

Following blog post from Patrick Griffis about new themes support in Flatpak, we started working on supporting this new feature too. Currently wherever you start a Qt application, it would always look like a KDE application or something would be missing, like icons so you would end up with bad experience and mixed feelings. This is going to change now as we now support Gnome in form of icons, widget style and Qt platform theme and with this, when you run a Qt application in Gnome, it will look definitely better and more natively than before. We packaged regular adwaita icons which are used by default in Gnome as extension of freedesktop runtime. For widget style we use adwaita-qt style, which is a Qt style attempting to look like Gtk’s adwaita and the most important part putting this all together is QGnomePlatform, a Qt platform theme which reads your Gnome configuration and applies it to running Qt applications. QGnomePlatform also enforces Qt apps to use adwaita icons and adwaita-qt style by default so that’s another reason why it is important. Both adwaita-qt and QGnomePlatform projects are by the way authored by Martin Bříza, a collegue of mine from Red Hat so if you meet him in person somewhere buy him a beer for that he cares about Qt integration in Gnome :). Now coming to a question how to install this and make it work. Basically all you need to do is install following extensions and you shold be done:

flatpak install kderuntime org.freedesktop.Platform.Icontheme.Adwaita
flatpak install kderuntime org.kde.KStyle.Adwaita
flatpak install kderuntime org.kde.PlatformTheme.QGnomePlatform

Your Qt apps running in flatpak should then automatically pick up all of these extensions without any further modification, same way it does automatically when you run it outside the sandbox. Simply done!. I’m also aware that there are more Gtk themes, like adwaita-dark or high-contrast, both are also available in form of Qt style and we will probably package them later, but at this point it is mostly proof of concept that this can be done and works nicely. You can follow our wiki page if you want more information about runtimes, repository with applications and so on and from me it’s all for now.

Btw. below you can see okular running in flatpak and using adwaita-qt style with adwaita icons.

Hi everyone, is everything ok? I hope so.

Today, I will talk about my week working on Krita during this community bonding period that ends this Wednesday.

I will try to be more concise this week and I will explain what I've made in a short list.

1. Unit tests to Python scripting API

I made previously, the integration of python tests with cmake. Now, I implemented tests to all classes that don’t need a GUI to work, at least partially. I wrote tests to classes below:

  • Action
  • Filter
  • InfoObject
  • Extension

When you implement tests, you naturally find errors. I found some inconsistencies that I fix, but I need to understand others behaviors, like setConfiguration method in the Filter class.

Reviews(D5967 and D5982) created and commits pushed to my remote branch.

2. Improve Scripter plugin

As I told in my introduction for GSOC, I'm intending to use the Scripter to execute and edit scripts.

When I started to work in this plugin, we was using the exec function(python 3) in python to run all the code from the editor, but it's really more complex to implement and maintain the scripter using exec, mainly when using files where we can create classes and all.

Now the implementation creates a python module to refer to files, but the Scripter still using exec when the code is executed without saving files. You can see a peace of code below:

if document:
    spec = importlib.util.spec_from_file_location("users_script", document.filePath)
    users_module = importlib.util.module_from_spec(spec)
    code = compile(script, '<string>', 'exec')
    empty_scope = {}
    exec(script, {})

If you need more details about my reasons to take this decision please read this comment in the task thread.

3. Krita community

  • I’m following other tasks in the Krita to know what people have made.

  • Talking with my mentors to understand some important implementations.

  • Reading documentation to libkiss. Thanks, Wolthera :).

That’s it for now, until the next week. See ya!!

May 28, 2017

The KDE Continuous Integration system builds KDE software from scratch, straight from the git repositories, and usually from master (or whatever is considered the development branch). It’s been building for Linux for a long time, and has recently been expanded with FreeBSD servers as well. KDE sysadmin has been kind enough to provide two more VMs (with some more compiling “oomph”) so that we can keep up better, and the CI has just been expanded with all of the Plasma products. That means we’re now building KDE Frameworks, and the Plasma desktop.

Results are still in the sandbox, but will eventually end up in the maiin CI.

Frameworks are all blue (good) or yellow (not-quite-good .. but I can’t really tell what Jenkins’ criteria are for making something yellow). Plasma is now in-progress: what we’re trying to do is merge as much as we can from FreeBSD ports to upstream, so that code only needs maintainence once. Today’s small fix is dealing with PAM, where Linux has pam_syslog() defined in the library, and FreeBSD does not.

El pasado 26 de mayo fue lanzado Krita 3.1.4, la mejor aplicación para dibujo artístico que existe y que vuelve locos a los artistas gráficos que la llegan a conocer. Y es que cuando se unen artistas y programadores los productos que se desarrollan son asombrosos, no hay más que ver algunos de los juegos de nintendo.

Lanzado Krita 3.1.4, solucionando errores

Ya hace un tiempo desde el lanzamiento de Krita 3.0, el cual supuso el salto a KF5 y Qt5, lo cual significa su integración total con el escritorio Plasma de la Comunidad KDE.

Así desde junio del 2016 se ha ido incluyendo diversas mejoras en Krita. De esta forma, en Krita 3.1 se introdujo la capacidad de generar amimaciones, así que en versiones posteriores toca ir limando la aplicación.

Lanzado Krita 3.1.4

De esta forma me complace anunciar que ha sido lanzado Krita 3.1.4, una nueva versión que simplemente se limita a solucionar errores, que no es poco.

Así nos encontramos, entre otros que:

  • La aplicación no se rompe cuando se intenta realizar una animación y OpenGL no está activado.
  • No aparecerá el diálogo de resolución de conflictos en multiples ocasiones al cambiar de resolución
  • Mejorada la carga de documentos de Gimp 2.9, aunque oficialmente este tipo de documentos no están soportados em Krita.
  • Solucionado el problema al cargar la última vista en el último documentos mientras el documento está siendo modificado.

Las novedades de Krita 3.1

Aprovecho este lanzamiento para compartir con vosotros un vídeo donde se muestra las novedades de Krita 3.1 que nos llega de la mano de GDquest y que en menos 5 minutos  nos cuentan que esta versión incluye soporte oficial para Mac, posibilidad de exportar gif animados y vídeos, nuevo editor gráfico, máscaras animadas, etiquetas coloreadas para mejorar la gestión de etiquetas, nuevo selector de colores, pinceles rápidos, nuevo gradiente de color, etc.

Más información: Krita

May 27, 2017

A pesar de que los desarrolladores de KDE han creado uno de los sistemas de ventanas más completos que existen siempre hay alguien en la Comunidad que le da una vuelta de tuerca y añade una nueva funcionalidad que puede ser de gran utilidad. Es el caso de “Maximize To New Virtual Desktop”, un script de Kwin que nos permite maximizar una ventana en un escritorio virtual diferente al que estamos. Espero que os guste.

Maximize To New Virtual Desktop, un útil script para Plasma 5

De la mano de AETF nos llega un script para Kwin que dota de nuevas funcionalidades a las ventanas de Plasma 5. Se trata de Maximize To New Virtual Desktop gracias al cual podemos maximizar una ventana en cualquier otro escritorio virtual diferente al que nos encontremos. Una funcionalidad que existe en sistemas Mac OS y que nos puede resultar útil en nuestro escritorio Plasma. Además, al minimizar la ventana ésta volverá al escritorio original.

Para verlo en funcionamiento os aconsejo ver el gif animado que nos lo muestra en la tienda de aplicaciones de KDE (KDE Store).

Maximize To New Virtual Desktop


Por cierto, si os ha gustado y lo utilizáis no estaría de más agradecer el trabajo a Flupp con comentarios, votos positivos y compartiéndolo, ya que como comenté en una entrada en el blog: Un simple gracias también ayuda.

Más información: KDE Store – Maximize To New Virtual Desktop

Cómo instalar Maximize To New Virtual Desktop

La instalación de este Script es muy sencilla ya que se realiza directamente desde las Preferencias del Sistema. Los pasos exactos son los siguientes:

  • Iniciamos el Lanzador de aplicaciones o Kickoff
  • Clicamos en la Preferencias del sistema.
  • Ahora pinchamos en Gestión de Ventanas.
  • Nos dirigimos a la sección de Guiones de KWin.
  • Ahora pinchamos en Obtener nuevos guiones.
  • Buscamos Maximize To New Virtual Desktop  y pinchamos en Instalar.
  • Ahora activamos el guión y pulsamos en Aplicar.

Sencillo y, a partir de ahora, imprescindible en todos mis escritorios Plasma de mis ordenadores.

KDevelop 5.1.1 released

We are happy to announce the release of KDevelop 5.1.1, the first bugfix and stabilization release for KDevelop 5.1!

Get it

Together with the source code, we again provide a prebuilt one-file-executable for 64-bit Linux (AppImage), as well as binary installers for 32- and 64-bit Microsoft Windows. You can find them on our download page.

The 5.1.1 source code and signatures can be downloaded from here.

Please give this version a try and as always let us know about any issues you find via our bug tracker.


Prebuilt binaries

  • Windows installer: Fix missing icons on Windows installers.
  • AppImage: Ship Breeze widget style. T3538
  • AppImage: Ship Sonnet plugins (based on aspell, hunspell, hspell). T4100
  • AppImage: Ship some default colour schemes (to be used with Settings -> Colour Scheme) with AppImage.
  • AppImage: Built with KF5SysGuard support: Enables "Attach to process" in the AppImage. T5878


  • Do not extract all template preview images, load from archives on demand. Commit. Phabricator Code review D5701
  • Use instead of in google selection external script. Commit. Phabricator Code review D5719
  • Use consistent icon names for build stuff, remove left-over legacy icons. Commit. Phabricator Code review D5651
  • Appwizard: fix broken disconnect in ProjectVcsPage. Commit. Phabricator Code review D5536
  • Stop unused & broken exposure of Project object on D-Bus. Commit. Phabricator Code review D5607
  • Appwizard: store chosen vcsPlugin in developer .kdev4 file. Commit. Phabricator Code review D5513
  • Backgroundparser: Relax assert a bit. Commit. See bug #378933
  • Work-around issue in Path(QString) ctor. Commit. See bug #378933
  • Fix preview file wrongly added on project generation from app template. Commit. Phabricator Code review D5314
  • Fix support for multiple files and relative paths in ShowFilesAfterGeneration. Commit. Phabricator Code review D5316
  • Load Template From File dialogs: fix wrong filter strings usage. Commit. Fixes bug #376040. Phabricator Code review D5155
  • Find/Replace in files: Do not wrap content of tooltip for an output line. Commit. Phabricator Code review D5135


  • Install xdg mimetype definition for OpenCL C. Commit. Phabricator Code review D5621
  • Move print from int to unsigned int. Commit. Phabricator Code review D5654
  • Fix build for MinGW. Commit. Fixes bug #379454
  • Look for Cppcheck as RUNTIME dependencies. Commit. Phabricator Code review D5632
  • The OpenCL language is actually called OpenCL C. Commit. Phabricator Code review D5485
  • Remove unneeded mimetype for *.kdevinternal files. Commit. Phabricator Code review D5624
  • Create KAboutData object only after QApp instance, for working translations. Commit. Phabricator Code review D5598
  • CMake - fix bug with dropping changed settings for existing build directory. Commit. Phabricator Code review D5609
  • Drop explicit %{PROJECTDIR}/ from templates' ShowFilesAfterGeneration. Commit. Phabricator Code review D5531
  • Remove unused "VersionControl" entries from kdev4 samples/templates. Commit. Phabricator Code review D5512
  • Fix ShowFilesAfterGeneration to match generated files. Commit. Fixes bug #378499
  • Update Qt logo image. Commit. Phabricator Code review D5278


  • Fix crash in syntax fix-up code. Commit. Partially fixes bug #378827.
  • Pep8: Make pep8 warnings less annoying. Commit. Phabricator Code review D5397


  • Fix duchain unit tests. Commit. Phabricator Code review D5817
kfunk Sat, 05/27/2017 - 10:00

May 26, 2017

A new stable release for KIO GDrive is now available, version is 1.2.0. The main change is the integration with Plasma/KAccounts. Have a look at my previous post for more details.

You can find the link to the source code in the wiki page:


Today we’re releasing Krita 3.1.4. This strictly a bug-fix release, but everyone is encouraged to update.

  • Fix a crash when trying to play an animation when OpenGL is disabled in Krita
  • Fix rendering animation frames if the directory you’re trying to render to doesn’t exist
  • Don’t open the tablet/screen resolution conflict dialog multiple times
  • Don’t scale down previews that are too small in the transform tool: this fixes a rare crash with the transform tool
  • Don’t crash when trying to close the last view on the last document while the document is modified.
  • Fix a crash when cycling quickly through layers that have a color tag
  • Fix loading some Gimp 2.9 files: note that Gimp 2.9’s file format is not officially supported in Krita
  • Fully remove the macro recorder plugin: in 3.1.4, only the menu entries had stayed around.
  • Make it impossible to hide the template selector in the new image dialog; hiding the template selector would also hide the cancel button in the dialog.


The KDE download site has been updated to support https now.


Note for Windows users: if you encounter crashes, please follow these instructions to use the debug symbols so we can figure out where Krita crashes.


(For some reason, Firefox thinks it needs to load this as text: to download, right-click on the link.)

A snap image for the Ubuntu App Store will be available from the Ubuntu application store. When it is updated, you can also use the Krita Lime PPA to install Krita 3.1.4 on Ubuntu and derivatives.


Source code


For all downloads:


The Linux appimage and the source tarball are signed. You can retrieve the public key over https here:
. The signatures are here.

Support Krita

Krita is a free and open source project. Please consider supporting the project with donations or by buying training videos or the artbook! With your support, we can keep the core team working on Krita full-time.

In the beginning there was …


That’s how things start, right? And in the beginning there were punch cards. The UI was rudimentary direct machine language, so we could say there was no UI. So let there be light!

In very simplistic terms that was a screen where one could type text (using a keyboard) and see the same text on the screen … maybe get some feedback on the results of a command. And let the animation begin!

The post What makes for good animation? appeared first on KDAB.

Last year, GDQuest’s Nathan Lovato ran a succesful kickstarter: “Create Professional 2D Game Art: Krita Video Training”. Over the past year, he has produced a great number of videos for Krita, and has helped the Krita team out with release videos as well.

This year, he’s going to teach you how to use your art in a real game. Learn how to use Godot to create games with GDQuest, on Kickstarter now to bring you the first premium course for the engine, with the support of the Godot developers.

During the campaign, you get a free game creation tutorial on YouTube, every day!

Please check it out now, and spread the word: Make Professional 2d Games: Godot Engine Online Course

GDQuest reached the goal in less than 12 hours. Everything above it means more
content for the backers, but also for everyone! GDQuest will also contribute to
Godot 3.0’s demos and documentation. All the money will go to the
course’s production and official free educational resources.

Check out the Free daily tutorials on Youtube!.

May 25, 2017

Qt for Device Creation provides ready disk images for a variety of devices. When you flash it to a device, start enterprise Qt Creator and plug the device in via USB, it will be detected automatically. You are ready to run, debug and profile your applications right on the device. From a user’s point of view the green marker for a ready device just appears.


But how do we actually see the device? There have been changes here for 5.9 and in this post I’ll discuss what we ended up doing and why.

How things used to be

Previous versions of Qt for Device Creation use Android Debug Bridge (ADB) for the device discovery. As you can guess from the name, it’s the same component that is used in the development of Android applications. It was a natural choice early in the development of the Boot2Qt when Android was a supported platform along with embedded Linux. But nowadays we focus on embedded Linux only. (In Device Creation with the device images, Qt can of course still be used to build applications on Android.)

Due to requiring Google’s USB drivers, ADB has made installing more complicated than desired for our users on Windows. And when they jumped through the hoops, they could end up with a different version than we tested against. There’s also the risk of mixups with Android development environments, who may include their own versions of ADB. There were also some things missing, which required working around inside our Qt Creator integration.

Recognizing USB devices

So to avoid those issues we decided to decided to write our own debug bridge, which we without extraneous imagination called QDB. It looks for Boot2Qt devices in a similar way as the purpose of other USB devices is discovered. When a device is enumerated in the universal serial bus, it describes its class, subclass and protocol. For example for my mouse the command lsusb -v reveals:

      bInterfaceClass         3 Human Interface Device
      bInterfaceSubClass      1 Boot Interface Subclass
      bInterfaceProtocol      2 Mouse

There is a vendor-defined class 255. We have picked a subclass and protocol inside that which our devices use, thus allowing QDB to find them. Finding them is of course not enough, since there needs to a way to transfer data between the host computer and the device.

Network over USB

ADB implements file transfers and port forwards. It transfers the data over the USB connection using its own protocol. One obvious option would have been to do the same thing. That would have been reinventing the wheel, as was quickly pointed out by many. There was also a second place where duplication of effort to accomplish the same thing was happening. The Boot2Qt plugin for Qt Creator was implementing support for running, debugging and profiling applications with ADB. But Qt Creator also supports these things with any Linux device over SSH through the RemoteLinux plugin. If we were able to use SSH, all of that duplication could be gotten rid of (after the support window for older Qt for Device Creation releases runs out).

Linux allows a device to present itself as an USB Ethernet adapter with the kernel module usb_f_rndis. The device then shows up as a network card in both Linux and Windows. This way we can have a network connection between the host computer and the device, which allows the use of SSH and thus the desired reuse. And apart from Qt Creator activity, the user can also use regular SSH to connect to the device. It has a properly resizing terminal, unlike adb shell! All the other things you might do over the network also become possible, even if the embedded device has no Ethernet socket.

But there’s something we glossed over. Networks don’t configure themselves. If the user would need to set the right IP address and subnet mask on both the computer and the device, then we certainly wouldn’t meet the bar of just plugging in the device and being ready to go.

Configuring the network

Now despite what I just said there actually are efforts for networks to configure themselves. Under the umbrella term zeroconf there are two things of interest in particular: link-local IPv4 addresses as specified in RFC 3927 and mDNS/DNS-SD, which allows finding out the addresses of devices in the network. For a while we tried to use these to accomplish the configuration of the network. However, getting the host computer to actually use link-local addresses for our network adapter proved fiddly and even if it worked there was a bit too long delay. The connection only works after both the host computer and device have gotten their IP which wasn’t predictable. I hope we will be able to revisit mDNS/DNS-SD at some point, because it might allow us to provide device discovery when devices are connected over Ethernet instead of USB, but for now zeroconf required too much configuration.

Another thing which we looked at was using IPv6 link-local addresses. Unlike their IPv4 cousin they are part of the protocol and always available, which would eliminate the delays and configuration burden. Here the downside is that they are a bit more local to the link. An IPv4 link-local IP is from the block and you can just connect to it regularly. IPv6 versions use the prefix fe80::/10, but they also require a “scope ID” to describe the network adapter to use. I’d rather not write

ssh user@fe80::2864:3dff:fe98:9b3a%enp0s20f0u4u4u3

That’s superficial, but there was also a more important issue: All the tools would need to support IPv6 addresses and giving these scope IDs. GDB – which we use for debugging – didn’t.

Back to the drawing board. The simplest approach would be picking up a fixed IP address for the devices. That has two issues. First, you can’t connect more than one device. Second, the fixed IP address might already be in use on the host computer. We ended up using the following approach to circumvent these problems: The same process that recognizes the USB devices knows a list of candidate network configurations in the private use IPv4 ranges. When a new device is connected, it looks at the networks the host computer currently has and then picks a candidate that doesn’t conflict. The device is told the configuration, sets its own IP address accordingly and then acts as a DHCP server that provides an IP for the host computer.

After this process is done, the host computer and device have matching network configurations, Qt Creator knows the IP of the device and everything is ready. If you connect a second device, a different candidate configuration is picked, since the first one is already in use. The DHCP server is disabled when the device is disconnected, because otherwise host computer could get an IP from a previous configuration when it is connected again.

The post Device detection in Qt for Device Creation 5.9 appeared first on Qt Blog.

May 24, 2017

LaKademy 2017 group photo

Some weeks ago we had the fifth edition of the KDE Latin-America summit, LaKademy. Since the first edition, KDE community in Latin-America has grown up and now we has several developers, translators, artists, promoters, and more people from here involved in KDE activities.

This time LaKademy was held in Belo Horizonte, a nice city known for the amazing cachaça, cheese, home made beers, cheese, hills, and of course, cheese. The city is very cosmopolitan, with several options of activities and gastronomy, while the people is gentle. I would like to back to Belo Horizonte, maybe in my next vacation.

LaKademy activites were held in CEFET, an educational technological institute. During the days of LaKademy there were political demonstrations and a general strike in the country, consequence of the current political crisis here in Brazil. Despite I support the demonstrations, I was in Belo Horizonte for event. So I focused in the tasks while in my mind I was side-by-side with the workers on the streets.

Like in past editions I worked a lot with Cantor, the mathematical software I am the maintainer. This time the main tasks performed were an extensive set of reviews: revisions in pending patches, in the bug management system in order to close very old (and invalid) reports, and in the task management workboard, specially to ping developers with old tasks without any comment in the last year.

There were some work to implement new features as well. I finished a backends refactoring in order to provide a recommended version of the programming language for each backend in Cantor. How each programming language has its own planning and scheduling, it is common some programming language version not be correctly supported in a Cantor backend (Sage, I am thinking you). This feature presents a “recommended” version of the programming language supported for the Cantor backend, meaning that version was tested and it will work correctly with Cantor. It is more like a workaround in order to maintain the sanity of the developer while he try to support 11 different programming languages.

Other feature I worked but it is not finished is a option to select different LaTeX processors in Cantor. Currently there are several LaTeX processors available (like pdflatex, pdftex, luatex, xetex, …), some of them with several additional features. This option will increased the versatility of Cantor and will allow the use of moderns processors and their features in the software.

I addition to these tasks I fixed some bugs and helped Fernando Telles, my past SoK student, with some tasks in Cantor.

(Like in past editions)², in LaKademy 2017 I also worked in other set of tasks related to the management and promotion of KDE Brazil. I investigated how to bring back our unified feed with Brazilian blogs posts as in the old Planet KDE Português, utilized to send updates about KDE in Brazil to our social networks. Fred implemented the solution. So I updated this feed in social networks, updated our e-mail contact utilized in this networks, and started a bootstrap version of LaKademy website (but the team is migrating to WordPress, I think it will not be used). I also did a large revision in the tasks of KDE Brazil workboard, migrated past year from the TODO website. Besides all this we had the promo meeting to discuss our actions in Latin-America – all the tasks were documented in the workboard.

Of course, just as we worked intensely in those days, we also had a lot of fun between a push and other. LaKademy is also a opportunity to find old friends and make new ones. It is amazing see again the KDE fellows, and I invite the newcomers to stay with us and go to next LaKademy editions!

This year we had a problem that we must to address in next edition – all the participants were Brazilians. We need to think about how to integrate people from other Latin-America countries in LaKademy. It would be bad if the event become only an Akademy-BR.

Filipe and Chicão

So, I give my greetings to the community and put myself in the mission to continue to work in order to grown the Latin-America as an important player to the development and future of KDE.

Its been some time since I’ve posted any progress for AtCore. Some may wonder what we have been up to ..

  • Implimented a Comand Queue

We would like to get some info from the printer while printing we need to have some method of flow control. AtCore now uses a command queue to send all commands. With the command Queue in place we have to handle stop and Emergency stop differently . For example Emergency Stop should skip the queue and be sent as soon as the button is pressed.

  • Requesting Temperatue from the printer

After you connect to a FW plugin every 5 seconds a m105 will be send to the printer and the temperature results are put onto a pretty graph that Patrick made. In order to make the graph work we need read the M105 return and extract the data from it. While our current methods of parsing this info work its very specific to each firmwares return . Since these string can be differnt between fw versions it can crash so we are working on a way to do this better.

  • Cleaned up the test Client Gui

The test clients GUI needed some love. All the widgets now live within a dock and the docks can be arranged how ever the user likes. I’ve also added a status bar to show the status of AtCore. We’ve also added a print job timer and remaining print time estimate. A Seperate axis control for relative was asked for by a user and I’ve added one that Lays wrote some time ago . It works well and allows for movements on 1, 10 or 25 units

  • Fixed the windows build so that It builds and deploys correctly via craft

Lays has been working hard to get atcore buildable via craft. Now we can build and deploy AtCore (and testgui) from craft. After building we had a problem of not finding the plugins on windows and them not deploying to the correct path.I added some instructions for deploy and tweaked plugin detection on window. Everything is now working well.

Foto em grupo do LaKademy 2017

E chegamos à 5ª edição do encontro latino-americano do KDE, o LaKademy. Nesse tempo todo foi perceptível o crescimento da comunidade na região, em especial no Brasil, ainda que mantendo o fluxo típico dos trabalhos voluntários onde participantes vem e vão de acordo com suas demandas.

Dessa vez o evento saiu das praias cariocas e adentrou um pouco mais para o interior do país, subindo o morro urbano de Belo Horizonte. Cidade aprazível conhecida pelas cachaças, queijos, cervejas artesanais, queijos, ladeiras e queijos, Belo Horizonte combina um ar cosmopolita, com diversas opções de lazer, culinária e mais, com um jeito cordial e solícito típico de seus moradores. Adorei a cidade e espero um dia agendar uma viagem que não seja a trabalho para lá.

As atividades do LaKademy ocorreram nas dependências do CEFET, do final de abril ao início de maio, em pleno feriadão do dia do trabalhador combinado a uma greve geral dias antes. Muitos que participaram do evento (eu incluso) defendiam as pautas da greve, mas não podíamos abandonar o evento após todo o investimento feito pelo KDE. Portanto, fica aqui meu mea culpa sobre esse tema. 🙂

A exemplo das demais edições do evento trabalhei bastante no Cantor, software matemático o qual sou mantenedor. Dessa vez as principais tarefas que desenvolvi podem ser resumidas em um grande esforço de triagem: revisões de patches pendentes, uma extensa revisão para fechar todos os bugs antigos e inválidos existentes, deixando abertos apenas aqueles que importam, e outra revisão nas tarefas pendentes, em especial naquelas que estavam abertas há quase um ano mas cujo os desenvolvedores responsáveis não haviam realizado qualquer movimentação durante o referido tempo.

No campo das funcionalidades, finalizei uma refatoração nos backends para apresentar a versão recomendada da linguagem de programação no Cantor. Como cada linguagem tem seu próprio planejamento, é comum que de uma versão para outra o backend do Cantor comece a se comportar de maneira inesperada ou mesmo deixe de funcionar (Sage, estou pensando em você). Essa funcionalidade apresenta a versão “recomendada” da linguagem para o backend do Cantor, significando que essa versão descrita foi testada e sabemos que funcionará bem com a ferramenta. Isso serve como um workaround para manter a sanidade do desenvolvedor enquanto suporta 11 backends diferentes.

Outra funcionalidade que trabalhei mas ainda não finalizei foi a adição de um seletor de backends LaTeX para usar no Cantor. Atualmente existem muitas opções de processadores LaTeX (pdflatex, pdftex, luatex, xetex, …), alguns deles com muitas opções adicionais. Isso aumentaria a versatilidade do Cantor e permitira que processadores modernos possam ser utilizados no software.

Além dessas funcionalidades houveram correções de bugs e auxílio ao Fernando Telles em algumas tarefas sobre esse software.

Outras tarefas que desenvolvi nessa edição, também a exemplo das demais, foram as relacionadas com o gerenciamento e promoção do KDE Brasil. Nelas, pesquisei como trazer de volta o feed do Planet KDE Português (que o Fred acabou desenvolvendo), atualização dos feeds automáticos nas nossas redes sociais, atualização da conta de e-mail que utilizamos para gerenciar nossas redes, port do site do LaKademy para bootstrap (que acho q o pessoal não vai utilizar pois estão migrando para WordPress) e uma pesada triagem das tarefas no workboard do KDE Brasil. Além de tudo isso, ainda tivemos a famosa reunião de promo onde discutimos ações de promoção para o país e região – tudo também documentado no workboard.

E claro, assim como trabalhamos muito e de forma muito intensa esses dias todos, o LaKademy também é um momento de reencontrar amigos e afetos e se divertir bastante entre um push e outro. É sempre reconfortante encontrar a galera inteira, e fica o convite para que os calouros apareçam sempre.

Uma falta da edição desse ano foi a ausência de não brasileiros – precisamos pensar em estratégias de termos latino-americanos de outros países participando do LaKademy. Seria ruim que o evento passasse a ser tão somente um Akademy-BR.

Filipe e Chicão

Para finalizar, deixo meu agradecimento à comunidade e minha disposição para continuar trabalhando para tornar a América Latina uma região cada vez mais importante para o desenvolvimento e futuro do KDE.

The OpenStreetMap plugin in QtLocation 5.8 has received a new Plugin Parameter,, to specify a indexable location from which to source offline tiles. Since this new feature seems to have generated some confusion, here is an attempt to clarify how it works.

Until now, when a tile became visible on the map, the QtLocation engine would first attempt to source it from the tile cache. If not present, it would attempt to fetch it from the provider.

With QtLocation 5.8 it is possible to pass an additional offline directory to the OSM plugin. When this parameter is present, tiles will be sourced from the specified directory before being searched in the tile cache, and, after that, being requested to the provider.

The content of such an offline directory is read only, for QtLocation, meaning that the engine will not add, delete or update tiles present therein. Tile filenames have to follow the osm plugin filename pattern, meaning osm_100-<l|h>-<map_id>-<z>-<x>-<y>.<extension>.

The field map_id goes from 1 to 7 (or 8, if a custom map type is specified), referring to the map types street, satellite, cycle, transit, night-transit, terrain and hiking, in this order.
The field before has to contain an l or an h, which stands low-dpi and high-dpi tiles, respectively.

The intended use cases that this feature aims to address are mainly:
– shipping custom maps for limited regions with the application.
– shipping tiles for low zoom levels with the application so to prevent blank maps when the application is run for the first time without internet connection.

To exemplify the usage of this feature, OsmOffline is an example application that uses tiles from the Natural Earth project, which are licensed under very permissive TOS, to address the second scenario.
This example embeds tiles for one map type at zoom levels 0, 1 and 2 using the Qt Resource system, and sources them from the qrc path :/offline_tiles/.

The post QtLocation: using offline map tiles with the OpenStreetMap plugin appeared first on Qt Blog.

May 23, 2017

On my last blog post I discussed about how some assumptions such as the platform developed on can affect our development. We need to minimize it by empowering the developers with good tools so that they can develop properly. To that end, I introduced runtimes in our IDE to abstract platforms (much like on Gnome’s Builder or Qt Creator).

There are different platforms that we’ll be developing for and they need to be easily reachable when coding and testing. Both switching and interacting transparently with the different platforms.

To that end I implemented 4 approaches that integrate different runtimes:

  • Docker, allows you to develop directly against virtually any system. This is especially interesting because it enables to reproduce the environment our users are having: behavior on execution and project information (i.e. the imports are the ones from the target rather the ones on our local system). Docker is a wide-spread technology in the cloud, I hope many developers will see the value in integrating the deployed environment into the IDE while they are coding.
  • Flatpak, is a solution that targets specifically desktop Linux applications. We are talking about distributing bundled applications to users, there we have the opportunity to integrate the tooling specifically to that end: from fetching dependencies to testing on other devices (see videos below).
  • Android, as you know it’s something I’ve been pushing for years. Finally we are getting to a space where the IDE can help get some set up troubles out of the way.
  • The local host, i.e. what we have now.

And remember KDevelop is extensible. Do you want snapcraft?, vagrant?, mock? Contributions are very welcome!

If there’s something better than a list of technologies and buzzwords, that’s videos. Let’s see why this could change how you develop your software.

One development, any platform

We get to develop an application and switch back and forth the target platform we are developing for.

Here I put together a short video that tests Blinken on different platforms:

One development, any device

Using the right SDK is not enough proof that the application will work as expected on every device, especially those our users will be using. Being able to easily send our application to another device to test and play around with is something I had needed for longtime. Especially important when we need to test different form factors or input devices.

In this video we can see how we can easily test an application locally and when it works just switch to Android and send to the device for proper test on the smaller touch screen.

Here we can see how we can just test an application by executing it remotely on another device. This is done by creating a bundle of the application, sending it to the device where we want to test it and executing it there.

Hassle-free contributions

You can’t deny it. You’ve wanted to fix things in the past, but you couldn’t be bothered with setting up the development environment. Both Flatpak and Docker offer the possibility to maintainers to distribute recipes to set up development platforms that can and should be integrated so that we can dedicate this 1 hour in the week-end to fixing that bug that’s been annoying us rather than reading a couple of wikis and – oh, well, never mind, gotta make dinner.

We can do this either by providing the flatpak-builder json manifest (disclaimer: the video is quite slow).

Or a Dockerfile.

You can try this today by building kdevelop git master branch, feedback is welcome. Or wait for KDevelop 5.2 later this year. ��

Happy hacking!

Once again a lot has been going on behind the scenes since the last release. The HTML gallery tool is back, database shrinking (e.g. purging stale thumbnails) is also supported on MySQL, grouping has been improved and additional sidecars can now be specified. Therefore the release of 5.6.0 will be (is already) delayed, as we would like to invite you to test all these features. As usual they are available in the pre-release bundles or obviously directly from the git repository. Please report any dysfunctions, unexpected behaviour or suggestions for improvement to our bug tracker.

The HTML gallery is accessible through the tools menu in the main bar of both digiKam and showFoto. It allows you to export pictures to a gallery that you can then open in any browser. There are many themes to select and you can create your own as well.

Already in 5.5.0 tests for database integrity and obsolete information have been introduced. Besides obvious data safety improvements this can free up quite a lot of space in the digiKam databases. For technical reasons only SQLite database were shrunk to this smaller size in 5.5.0. Now this is also possible for MySQL databases.

Earlier changes to the grouping behaviour proved that digiKam users have quite diverse workflows - so with the current change we try to represent that diversity.

Originally grouped items were basically hidden away. Due to requests to include grouped items in certain operations, this was changed entirely to include grouped items in (almost) all operations. Needless to say, this wasn’t such a good idea either. So now you can choose which operations should be performed on all images in a group or just the first one.
The corresponding settings lives in the configuration wizard under Miscellaneous in the Grouping tab. By default all operations are set to Ask, which will open a dialog whenever you perform this operation and grouped items are involved.

Another new capability is to recognise additional sidecars. Under the new Sidecars tab in the Metadata part of the configuration wizard you can specify any additional extension that you want digiKam to recognise as a sidecar. These files will neither be read from nor written to, but they will be moved/rename/deleted/… together with the item that they belong to.

Finally, the last important change done for the next version is to restore the geolocation bookmarks feature which do not work with bundle versions of digiKam (AppImage, MacOS, and Windows). The new bookmarker was been fully re-written and still compatible with previous geolocation bookmarks settings. It now able to display the bookmark GPS information over a map for a better usability while editing your collection.

Thanks in advance to everyone testing this new release and in general everyone using digiKam - we hope you keep enjoying this tool and spread the word!

May 22, 2017

After a month of dread and panicking about the fact that Google Summer of Code results are announced in the middle of exam season... I'm happy to say I'll be doing the Rust plugin for KDevelop!

Quick intro

My name is Emma. Just turned 21. I'm a second-year undergrad at Imperial College London. Been programming since I was 10. I've worked on a bunch of different projects over the years. Many of them are open source. I've contributed to the KDevelop Python plugin previously. I worked at Microsoft Research in summer 2016 on the AssessMS project. I'm interested in a couple of different areas of computer science: artificial intelligence, computer vision, and lately compilers, type systems and operating systems. Favourite languages: Haskell, C++ and as of recently...


Rust is a rather new programming language, but it's already gained a lot of traction. It was voted “most loved” language by developers for the second year in a row in the StackOverflow developer survey. There have been projects made using Rust on everything from operating systems to game engines for Minecraft-like games. Despite this, IDE support is still lacking. This has to change...


KDevelop is a really great IDE, but it currently does not support Rust at all. However, it does have an easily extensible plugin architecture, so the logical conclusion is to write a Rust plugin! 

And there you have it. That was basically my reasoning when applying to KDE to do this project.

What now?

I had a bit of a snag with timing: my university exams were basically back to back for the past three weeks, and May is supposed to be used for community bonding, so I'm a bit behind on that. However, I have been playing around with Rust quite a bit (I started writing a small OS kernel because why not). Rust does interface quite nicely with C (aside from half of the code being littered with 'unsafe's). Still, this means my initial idea should work quite nicely. The plan is to get all necessary packages and a skeleton project set up by May 30 when coding begins.

The plan for the next month: parsing Rust code

Arguably the most difficult part of this whole project. Rust is, in my opinion, very similar to C++ when it comes to parsing (that is, a nightmare). So the plan is basically not to do any parsing at all. Bear with me for a moment.

The Rust compiler is nicely split up into different modules. One of those is the syntax parsing library, appropriately named libsyntax. Normally, it's private, except in the Rust nightly compiler (mainly for debugging purposes I suppose). However, a fork of it is available for the stable branch, named the syntex_syntax package. Several other Rust tools including rustfmt, Rust Racer and Rust Language Server use this package, so I'll assume it's stable.

It does the parsing and provides a nice visitor-pattern approach to traversing the AST. Hook this up to C++ with some foreign function calls and that's about it for parsing.

Semantic highlighting at this point becomes a matter of traversing the AST produced by the syntax parsing library (which includes the ranges of all elements), and constructing the appropriate structures on KDevelop's side.

And afterwards...

The final goal is to have full language support, which includes semantic highlighting, navigation, code completion, as many possible code refactoring/generation options as possible, and debugging. Some of these partially overlap: highlighting, navigation and completions all depend on building a knowledge base of the code. Debugging, should be a matter of hooking up GDB/LLDB, which KDevelop already supports, for Rust-compiled objects. Finally, refactoring and code generation should be quite fun to do, and I think that would make KDevelop the Rust IDE.

Stay tuned for updates...

Installers for Kate 17.04.1 are now available for download!

This release includes, besides bug-fixing and features, an update to the search in files plugin. The search-while-you-type in the current file should not “destroy” your last search in files results as easily as previously. The search-combo-box-history handling is also improved.

Grab it now at  Kate-setup-17.04.1-KF5.34-32bit or Kate-setup-17.04.1-KF5.34-64bit

With an apology to English-speaking audiences ��

Anche quest’anno KDAB partecipa a QtDay, la conferenza italiana interamente dedicata a Qt. Giunta oramai alla sua sesta edizione, QtDay continua a crescere. Quest’anno QtDay si articola in 3 giorni: il primo dedicato a un training su QML, seguito da due giorni di conferenza vera e propria.

Durante la conferenza terrò due interventi:

  • Venerdì 23 giugno parteciperò ad una tavola rotonda sul come contribuire allo sviluppo di Qt;
  • Sabato 24 giugno

The post Ci vediamo a QtDay 2017? appeared first on KDAB.

The Akademy programme (saturday, sunday) is actually pretty long; the conference days stretch into feels-like-evening to me. Of course, the Dutch are infamous for being “6pm at the dinner table, and eat potatoes” so my notion of evening may not match what works on the Mediterranean coast. Actually, I know it doesn’t since way back when at a Ubuntu Developer Summit in Sevilla it took some internal-clock-resetting to adjust to dinner closer to midnight than 18:00.

Akademy LogoForeseen clock-adjustment difficulties aside, I have a plan for Akademy.

  • Attend a bunch of talks. Telemetry / User Feedback sounds like a must-see for me, and lightning talks, and Input Methods is something I know nothing about and should (hey, my work-work application is Latin-1 only and therefore can’t even represent the names of all of its developers properly, and that in 2017), and the analysing code and fuzzing talk connects way back to the English Breakfast Network days of KDE Code Quality.
  • Hammer (and saw, and sand, and paint) on the KDE CI for FreeBSD; this will involve a fair amount of futzing with the base system, but also gently pushing changes to a whole bunch of repositories. KDE Frameworks 5 are mostly blue / yellow. It’s time to start adding higher layers of the software stack to the whole.
  • BoF it up around CMake, FreeBSD, CI, and LDAP.
  • Have fun at the day trip.

Hi, I'm Davide and I'm 22.
I was born on May 17th so I'm considering being accepted by KDE as a little gift.
The first month is usually related to "Community Bonding". What does it mean?

First of all, I created this blog. Here I'll post updates about Chat Bridge (now renamed to Brooklyn) and myself.
Then, I retrieved my KDE Identity account. The main problem was that I had lost my username.
So I wrote to and five minutes after the username was no longer a problem.
Shortly after I've done a lot of stuff, but I don't want to bother my readers.

After this boring to-do list, I've contacted my mentor to keep him updated.
We decided to start the development of the application and we defined how the app configuration file should be.
It is obviously open-source, you can use it for your projects! For now, it works only on IRC/Telegram but it will support soon also Rocketchat.
It can only support plain text, but it's temporary, don't worry.

I'm planning (but I've not decided yet because of university exams) to go to Akademy 2017 with some guys at WikiToLearn.
I can't wait to start coding!

What do you think about this project?
Do you have plans to use it?
Don't be shy, write me everything you want!

External links:

May 21, 2017

The annual openSUSE Conference 2017 is upcoming! osc17finalNext weekend it will be again in the Z-Bau in Nuremberg, Germany.

The conference program is impressive and if you can make it, you should consider stopping by.

Stefan Schäfer from the Invis server project and me will organize a workshop about openSUSE for Small and Medium Business (SMB).

SMB is a long running concern of the heart of the two of us: Both Stefan, who even does it for living, and me have both used openSUSE in the area of SMB for long and we know how well it serves there. Stefan has even initiated the Invis Server Project, which is completely free software and builds on top of the openSUSE distributions. The Invis Server adds a whole bunch of extra functionality to openSUSE that is extremely useful in the special SMB usecase. It came a long way starting as Stefans own project long years ago, evolving as proper maintained openSUSE Spin in OBS with a small, but active community.

The interesting question is how openSUSE, Invis Server and other smaller projects like for example Kraft can unite and offer a reliable maintained and comprehensive solution for this huge group of potential users, that is now locked in to proprietary technologies mainly while FOSS can really make a difference here.

In the workshop we first will introduce the existing projects briefly, maybe discuss some technical questions like integration of new packages in the openSUSE distributions and such, and also touch organizational question like how we want to setup and market openSUSE SMB.

Participants in the workshop should not expect too much presentation. We rather hope for a lively discussion with many people bringing in their projects that might fit, their experiences and ideas. Don’t be shy ��



In KDE we cover a mix of platforms and form factors that make our technology very powerful. But how to reach so many different systems while maintaining high quality on all of them?

What variables are we talking about?

Form factors

We use different form factors nowadays, daily. When moving, we need to be straight-forward; when focusing we want all functionality.

Together with QtQuick Controls, Kirigami offers ways for us to be flexible both in input types and screen sizes.


We are not constantly on the same device, diversity is part of our lives. Recommending our peers the tools we make should always be a possibility, without forcing them into major workflow changes (like changing OS, yes).

Qt has been our tool of choice for years and it’s proven to keep up with the latest industry changes, embracing mobile, and adapting to massively different form factors and operating systems. This integration includes some integration in their look and feel, which is very important to many of us.

Devices & Quality Assurance

We are targeting different devices, we need to allow developers to test and make it easy to reproduce and make the most out of the testing we get, learn from our users.

Whatever is native to the platform. APK (and possibly even Google Play) on Android, Installers on Windows and distribution packages for GNU/Linux.
Furthermore, we’ve been embracing new technologies on GNU/Linux systems that can help a lot in this front including Snap/Flatpak/AppImage, which could help streamline this process as well.

What needs to happen?

Some of these technologies are slowly blooming as they get widely adopted, and our community needs as well to lead in offering tooling and solutions to make all of this viable.

  • We need straightforward quality assurance. We should ensure the conditions under which we develop and test are our users’ platforms. When facing an error, being able to reproduce and test is fundamental.
  • We should allow for swift release cycles. Users should always be on fresh stable releases. When a patch release is submitted, we should test it and then have it available to the users. Nowadays, some users are not benefiting from most stable releases and that’s makes lots of our work in vain.
  • Feedback makes us grow. We need to understand how our applications are being used, if we want to solve the actual problems users are having.

All of this won’t happen automatically. We need people who wants to get their hands dirty and help build the infrastructure to make it happen.

There’s different skills that you can put in practice here: ranging from DevOps, helping to offer fresh quality recipes for your platform of choice, improving testing infrastructure, or actual system development on our development tools and of course any of the upstream projects we use.

Hop on! Help KDE put Free Software on every device!

Hi everyone, is everything ok? I hope so.

Today, I will talk about my week working on Krita during this community bonding period that ends next Sunday.


You probably are asking, why I put a Garfield comic here. First, I love cats and Garfield :). Second, I figure out that represents what open source community needs, more consistency and constant work. Boud told me sometimes that we need to commit and be in touch with the community every day. It's a problem, send a huge modification or do not enter in IRC for a long time. I'm trying to be more constant because is not all about code.

This week was pretty cool why I could know more the community, talking with users and devs to define the initial set for the Krita's showcase.

  • Monday - I opened a discussion in the Krita’s forum to obtain new suggestions for the Krita’s showcase.

  • Tuesday - I was trying to understand some current features of the Krita that users told me like Image Reference and Palette.

  • Wednesday - I organized and wrote all suggestion of users from the forum and from the IRC on the phabricator task.

  • Thursday - I asked more experienced devs for help with suggestions in the task thread, as you can see here.

  • Friday - A day to solve some personal problems.

  • Saturday - I wrote an answear with my guideline for the GSoC period.

That’s it for now. Thanks, Krita community. Until next week, See ya!!

Today I streamed the first half of the Plasma 5.11 wallpaper production, and it was an interesting experience. The video above is the abridged version sped up ~20x, heavily edited to the actual creation, and should be a fun watch for the interested.

It looks like there’s another full work-day that needs to go into the wallpaper still, and while I think I’ll also record the second half I don’t think I’ll livestream it; while I’m very appreciative of the viewers I had, it was quite a bit of extra work and quite difficult to carry on a one-man conversation for 8 hours, while working, for at most a few people. Like I said, I will still record the second half of the wallpaper for posterity, I simply don’t think I’ll be streaming it. I do think I’ll keep streaming the odd icon batch, as those are about as long as I want, so they can be kept to a digestible hour.


The wallpaper as it is is based on an image of a reef along with a recent trip to the beach during the Blue Systems sprint. There’s still a long way to go, and I can easily see another 8 hours going into this before it’s completed; there’s water effects, tides, doing the rocks, and taking a second pass at the foam – among other things – especially before I hit the level of KDE polish I’d like meet.

Looking at it, I may also make a reversed image with only the shoreline components for dual-screen aficionados.

Within the next week or so I’ll post the next timelapse after I complete the wallpaper. ��

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.