February 20, 2018

Accessibility technology encompasses assistive tools such as screen readers, magnifiers and braille displays, as well as APIs and frameworks that allow applications to expose elements of their UI to such tools.

While some UI widgets provided by the operating system may already be prepared to provide content and metadata to assistive tools, Qt renders UI elements itself. This approach requires a way to expose information about these elements to accessibility frameworks, which would otherwise perceive the applications as sets of empty windows.

To expose information about UI elements on Windows, Qt relied on the legacy Microsoft Active Accessibility framework (MSAA), until Qt 5.10. However, proper framework support was lacking in some areas, and nowadays MSAA has been superseded by a new framework and its use is no longer recommended for new applications.

With release 5.11 we will replace the MSAA accessibility backend with a new implementation based on the more modern Microsoft UI Automation, which superseded MSAA as the de facto standard for accessibility on the Windows platform. UI Automation has been available in all Windows releases since RTM versions of Windows 7 and Server 2008, as well as provided with system updates on Windows XP, Vista and Server 2003.

Since the accessibility changes in Qt 5.11 are internal, existing accessible applications are not expected to require any changes to utilize the improved functionality provided by UI Automation. Compatibility with MSAA-only assistive tools is maintained by bridge components built in the UI Automation framework itself.

One area where immediate improvement resulting from the new approach can be perceived is in the control of Qt-based applications using the built-in virtual keyboard in touchscreen-based Windows computers, like the Microsoft Surface line. In Qt 5.10, compatibility with some UI widgets was limited and events like the automatic showing and hiding of the virtual keyboard were not supported. With Qt 5.11, the same level of functionality available to applications based on native Windows widgets should be expected.

Also, the new UI Automation support in Qt may become useful for application testing, since it can provide metadata and programmatic control of UI elements, which can be leveraged by automated test suites and other tools.

We invite users to test the new accessibility functionality, and to give us feedback by writing to the mailing lists and reporting bugs.


The post Qt 5.11 Brings New Accessibility Backend on Windows appeared first on Qt Blog.

The last months for Kdenlive have been very quiet from the outside – we were not very active on the bugtracker, did not make a lot of announcements, and the 17.12.x release cycle only contained very few minor bugfixes.

The main reason for this was the huge work that went behind the scenes for a major code refactoring that was required to allow further developments. So after more than a year working on it, we hope to get ready for the 18.04 release!

Tonight we will announce the first public testing beta release for the upcoming 18.04 version. There are some rough edges, it’s not ready for production yet as compatibility with older project files is not finalized and a lot of work is still required to fix the many remaining quirks, but we are on good tracks to bring you a modern, stable and enjoyable open source editor.

So if you are interested and want to have a look at our roadmap or try the latest development code in an AppImage, join us tonight at 9pm (CET time – UTC+1) for our 26th Kdenlive Café.

Qt 5.11 Alpha is released today. As usual the official Alpha is a source code delivery only, but later we will offer development snapshots of Qt 5.11 regularly via the online installer.

Please check Qt 5.11 New Features wiki to see what new is coming with Qt 5.11 release. Please note that the feature list is still in progress and not to be considered final before the first Beta release.

Next milestone in our way to final Qt 5.11 release (which is planned to happen in May) will be first Beta release. We are targeting to get it out as soon as possible soon after the Alpha. We will release several Beta releases in similar manner as before, available via the online installer.

Please download the Qt 5.11 Alpha source packages from your Qt Account or from download.qt.io.

Most importantly, remember to give us feedback by writing to the mailing lists and reporting bugs.

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

Ha sido la noticia de este lunes: la Comunidad KDE recibe 200000$ de donación. Y de esta forma se une a la lista de otras fundaciones como la Free Software Foundation que han recibido una donación de este tipo por parte de la Fundación Pineapple.

La Comunidad KDE recibe 200000$ de donación

La Comunidad KDE recibe 200000$Antes de empezar el artículo, debo reconocer que en esta ocasión voy a aprovecharme del trabajo realizado por Victorhck en su gran blog y a emplear parte del texto que él ha traducido.

Ayer lunes 19 de febrero de 2018 la fundación KDE e.V ha anunciado que ha recibido una donación de 200.000 dólares por parte de la Fundación Pineapple

En el comunicado oficial la Fundación Pineapple reconoce que la Comunidad KDE crea software del que se beneficia el público en general, hace avanzar el uso del software libre en toda clase de plataformas y protege la privacidad de los usuarios ofreciendo herramientas sencillas y de primera clase en las manos de las personas con un coste cero para ellas.

Por otra parte Lydia Pinscher la presidenta de KDE e.V ha declarado que con esta donación KDE está inmensamente agradecida y expresa su más profunda gratitud a la fundación Pineapple por su generosidad.

En cuanto al destino de la donación Lydia ha adelantado que se utilizarán para extender los objetivos que se ha marcado la comunidad KDE en hacer el software libre accesible a todas las personas y en todas las plataformas. En otras palabras, el dinero ayudará a conseguir la visión de KDE de crear un mundo en el que todas las personas tengan el control sobre su vida digital y disfrute de la libertad y privacidad.

Esta es una gran noticia para el software libre en genral, ya que estas importantes donaciones, pueden ser un catalizador para que otras fundaciones sigan el ejemplo o para que las instituciones públicas se den cuenta del incalculable valor del trabajo que está realizando la Comunidad KDE en particular y el Software Libre en general.

Más información: KDE News


February 19, 2018

WireGuard is participating in Google Summer of Code 2018. If you're a student — bachelors, masters, PhD, or otherwise — who would like to be funded this summer for writing interesting kernel code, studying cryptography, building networks, making mobile apps, contributing to the larger open source ecosystem, doing web development, writing documentation, or working on a wide variety of interesting problems, then this may be appealing. You'll be mentored by world-class experts, and the summer will certainly boost your skills. Details are on this page — simply contact the WireGuard team to get a proposal into the pipeline.

Could you tell us something about yourself?

I’m 35 years old from Shropshire in Britain. I like comfy socks and tea.

I did Archaeology in University and I love history, mythology, folklore and nature. I’ve always been drawing from an early age. I graduated in 2003 with an archaeology degree. I taught myself digital art and web coding skills for fun and practical reasons. I used to do self-employed web design and admin type jobs, but in 2013 I became disillusioned with my life and had depression. I took a Foundation art course in 2013 deciding to pursue my artistic passions instead.

Since 2014 I’ve been practising art like crazy and building up a portfolio of illustration work.

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

Both. I use digital painting to make studies for my illustration work and as a way to experiment. I would love to do paid freelance illustration work should the right opportunity come along. I am happy making my own projects as well, it helps me learn and get better.

What genre(s) do you work in?

I’ve found I like to draw and paint themes from nature and animals. I read about myths and folklore. I’ve been working on personal projects about mermaids and river goddesses. It’s still in the early stages. I’m developing my style to incorporate more fantasy subjects in the future and mix in my pattern work.

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

I look at archaeology, art history and graphic design for inspiration. I don’t have a favourite artist at the moment. There are lots of styles I’m inspired by it’s difficult to choose one. I’ve been looking at folk art more and trying to loosen up with my painting.

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

I tried digital painting for the first time in 2004 when I wanted to texture my own skins for the Maxis Sims game I used to play. I learnt web coding as well so i could share my efforts with people. My sister had a copy of Photoshop 6 which I used, and I had a tiny non-sensitive drawing tablet my mum had given me. My first job as a data entry clerk in a bank (yawn) enabled me to save up and get my first proper Wacom tablet around 2005. I wished I could do something with my Archaeology instead but there were no paid local jobs. From looking on the Internet I saw people made amazing works of art with digital software. I got obsessed with concept art and fantasy art and tried to get better. I used to haunt the CGSociety and GFXArtist and I bought ImagineFX magazine to try and learn all I could on my own. There were not the resources back then that there are now, but it was fun and a good distraction from the rest of my life.

What makes you choose digital over traditional painting?

Digital painting is a versatile medium. When I was starting out it saved me money on buying expensive art materials, and I didn’t have any room for doing traditional painting in my small bedroom. I bought a student version of Corel Painter to start with, which was one of my only options back in 2005. This enabled me to try lots of different types of art styles without the mess. Now I have my own house, I have more room and I’ve collected more art materials I tend to mix using traditional and digital mediums depending on the effect I want. If I want to have the texture of coloured pencils for example, I’ve found it is easier to do it with coloured pencils first. Over the years I’ve tried a lot of different digital painting programs and learnt how to do vector art as well.

How did you find out about Krita?

I found out about Krita from surfing on the Internet around 2011. I’d been using MyPaint and heard about Krita from my geeky research. I’m a bit of a geek when it comes to digital art so I like trying different softwares.

What was your first impression?

The first time I tried it I was still a heavy Corel Painter user, but I bookmarked it for future reference seeing it had potential. I tried it again around 2013 and fell in love with it over using Corel Painter. The interface was great, it was much nicer and easier to use than Corel Painter, and it had lovely practical brushes out of the box.

What do you love about Krita?

I love the layer system and the way the brushes work. They are as sensitive as any in more expensive programs, and are as customisable. The mirror tool is fun and I like the seamless pattern feature. I’ve been so busy I haven’t gotten around to trying animation yet, which is a cool feature.

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

I can’t think of anything which annoys me about Krita, unless it’s a fault of my own hardware setup. Sometimes I’ll have to minimise and maximise Krita to get pressure sensitivity back after using different programs while painting. It’s probably because I have an Ugee 2150 and I use Windows 10 which keeps doing annoying creator updates. Because I use other software as well (Photoshop CS3, Affinity Designer, Affinity Photo) any weaknesses in Krita can be overcome using those and vice versa.

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

I like the default brushes which come with Krita. In all the other programs I’ve used I have had to customise and make new brushes or buy brushes to get what I want. There is also a strong community feel about Krita and growing resources. I wrote a long article about why Krita is great for beginners to digital painting on Medium.

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

The gold fish studies, because they were fun to do and turned out pretty well. I want to do more work in the same style.

What techniques and brushes did you use in it?

I used the default brushes. Most of them are by David Revoy. The digital sketch brush is one of my favourites, and the alchemy brush is useful for blocking in areas. First I blocked in the silhouette of the goldfish with an opaque round brush. Then I tool advantage of layer clipping masks to paint within the shape of the goldfish blocking in areas of colour with alchemy brush and the magnetic lasso tool. I also used gradient fills in the early stages to get nice base colour blending for painting the details into. I used different layer styles for shadows (multiply) and highlights (screen / overlay). Start with blocking in, big brushes and go smaller for the details.

Where can people see more of your work?

I have a website at https://thimblefolio.com.

I’m also on the following websites:

Behance: https://www.behance.net/chrisgarnerart
Dribbble: https://dribbble.com/chrisgarnerart
Instagram: https://www.instagram.com/thimblefoliopress/
Tumblr: https://thimblefolio.tumblr.com/
YouTube: https://www.youtube.com/user/cribbyGart/featured
Medium: https://medium.com/@thimblefolio
Society 6: https://society6.com/thimblefoliopress
Curioos: https://www.curioos.com/thimblefolio
Spoonflower: https://www.spoonflower.com/profiles/thimblefolio

Anything else you’d like to share?

Thank you very much to all the people who work on developing and improving Krita, and to everyone who creates tutorials and resources. Its great digital art is accessible for as many people as possible, learning digital painting is a positive and fun thing to do.

KDE e.V. is announcing today it has received a donation of 200,000 USD from the Pineapple Fund.

With this donation, the Pineapple Fund recognizes that KDE as a community creates software which benefits the general public, advances the use of Free Software on all kinds of platforms, and protects users' privacy by putting first-class and easy to use tools in the hands of the people at zero cost. KDE joins a long list of prestigious charities, organizations and communities that the Pineapple Fund has so generously donated to.

"KDE is immensely grateful for this donation. We would like to express our deeply felt appreciation towards the Pineapple Fund for their generosity" said Lydia Pintscher, President of KDE e.V.. "We will use the funds to further our cause to make Free Software accessible to everyone and on all platforms. The money will help us realize our vision of creating a world in which everyone has control over their digital life and enjoys freedom and privacy".

"KDE is a vibrant community that has been developing a number of awesome products like Plasma that empower the user's freedom." said a spokesperson for the Pineapple Fund. "I especially admire the UX and design of KDE's products, as they are approachable to new audiences who are not Linux geeks. I hope this donation can power further KDE development!".

This donation will allow KDE to organize events that bring the community together; sponsor development sprints to improve the usability and performance of existing tools; pay expenses for contributors traveling from distant locations; attract more contributors and build a more inclusive community; create new and safer programs; and carry out research for future generations of KDE's environments and applications.

La evolución del Software es imparable. Se podría decir que cada año surgen nuevos lenguajes, desaparecen otros y los que quedan van cambiando. Hace un tiempo que ronda por mi entorno de trabajo el nombre de un lenguaje que hasta hace poco desconocía y que parece ser sencillo y potente: Markdown. Pues bien, junto al lenguaje suelen aparecer visores, como es el caso de KMarkdownWebView, el visor KDE de Markdown que también sigue evolucionando y que recientemente ha llegado a su versión 0.5.0.

¿Qué es Markdown?

Según podemos leer en la Wikipedia, Markdown es un lenguaje de marcado ligero creado por John Gruber que trata de conseguir la máxima legibilidad y facilidad de publicación tanto en su forma de entrada como de salida, inspirándose en muchas convenciones existentes para marcar mensajes de correo electrónico usando texto plano. Se distribuye bajo licencia BSD.

Y ya que estamos, por si queréis aprender algo más sobre este lenguaje os dejo el siguiente vídeo de Javier Cristóbal donde nos explica la sintaxis de Markdown en 5 minutos.


KMarkdownWebView, el visor KDE de Markdown

La filosofía KDE es la de dotar a todos los usuarios de herramientas para crear cualquier tipo de creación o gestión. Así, por ejemplo, podemos crear contenido multimedia con Kdenlive o gestionar nuestras imágenes con el increíble digiKam.

Es por ello que tenemos aplicaciones para casi cualquier tarea, y un visor para el lenguaje Markdown ya no es una excepción gracias a KMarkdownWebView, el cual recientemente ha llegado a su versión 0.5.0.

Básicamente KMarkdownWebView sirve para la visualización de este tipo de lenguaje utilizando tecnologías web. Implementa un contenedor basado en C ++ y Qt sobre una página web local con una biblioteca de JavaScript, con lo que creamos HTML a partir del texto con formato Markdown.
El software contiene
un complemento KParts para la visualización renderizada de archivos Markdown, lo que permite que las aplicaciones que usan KParts (como la herramienta de archivado Ark o el administrador de archivos Krusader) muestren los archivos Markdown en el formato de destino.

Además, KMarkdownWebViewer también hace la función de generador de miniaturas KIO del archivo Markdown, lo que permite a los gestores de archivos y cuadros de diálogo accionados por KIO mostrar miniaturas y vistas previas de archivos en formato Markdown (actualmente solo disponible cuando compila contra QtWebKit)

En definitiva, una excelente herramienta para aquellos que disfrutan o trabajan con este lenguaje.

Más información: Attracted by virtual constructs

February 18, 2018

Hay días que no tienes ganas de hablar de nada en concreto, pero como te has puesto como meta de esta vida no dejar ni un día sin publicar una entrada te tienes que reinventar. De este modo ha nacido este post de hoy, donde comentaré las noticias linux que se han generado estos últimos días, que no me dan para una entrada por razones diversas (tiempo, repetición, caducidad, etc.) pero que creo que son de interés general.

Noticias linux de un domingo de febrero

Esta semana ha venido marcada en el blog por el anuncio de Valencia como sede de Akademy-es 2018, el evento más importante para la Comunidad Kdeera española pero que no deja de lado, y de hecho hace un llamamiento, al resto de la Comunidad GNU/Linuxera.

Pero, a lo largo de la semana se han producido otras muchas noticias que ha continuación me permito resumir:

I love Free Software Day 2018 #ilovefs

El miércoles 14 de febrero, como viene siendo tradicional, la Free Software Foundation Europa nos animó para que mostrásemos nuestro amor por el software libre. Lamentablemente no pude hacerlo, y aunque empecé un artículo para el blog, se quedó en inacabado en borradores. No fue el caso del gran artículo de Victorhck que en su blog redactó “#ILoveFS ¿Y tú a quién quieres?” en el que nos animaba a participar de forma activa para celebrar ese día.

Noticias linux de un domingo de febrero

Plasma Mobile en tu móvil

Otra de las noticias de la semana fue la publicación en varios blog la posibilidad de instalar en móviles con Android.

De esta forma, grandes fuentes de noticias sobre el Software Libre como Linux Adictos, Muy Linux o MasLinux se hacen eco en español de la entrada del blog de Bhushan Shah donde está explicando como probar este proyectos de la Comunidad KDE en tu dispositivo

Krita trabaja en un nuevo conjunto de pinceles

Y necesita la ayuda los usuarios. De esta forma ha lanzado una encuesta para que entre todos se encuentre la mejor manera de visualizarlos y dotarlos de funcionalidades y opciones. Si te interesa no dudes en visitar Krita.

Una buena noticia para una aplicación que recibe buenas críticas allá donde va.

Plasma en Nintendo Switch

Y para finalizar este breve repaso nada mejor que ver que el Software Libre es sumamente flexible. Si hace un tiempo vimos en Linux Adictos como se podía poner Gnu/Linux en una Nintendo Switch, ayer vimos en Twitter que Plasma también puede habitar en la exitosa consola de la gran N.


Evidentemente, estas noticias son importantes pero claro está que el Software Libre ha generado muchas más.

It’s been another big week in Usability & Productivity! We’ve got usability improvements, performance improvements, and bugfixes galore! Have a look:

  • Plasma is now a full second faster to start (KDE Phabricator revision D10536, Improved in Plasma 5.13)
  • Fixed a severe freeze in Discover 5.12 (KDE bug 390123, available in KDE Plasma 5.12.1)
  • Apps whose desktop files contain spaces can once again be pinned and stay where they’re supposed to be on the panel (KDE bug 385942, fixed in KDE Plasma 5.13)
  • Creating a new file using Dolphin is now instantaneous (KDE bug 388887, fixed in KDE Applications 18.04)
  • The Open With panel received a UI redesign that yields significant usability and productivity boosts, in addition to fixing some bugs (KDE bug 359233, implemented in KDE Frameworks 5.44):
  • Fixed Drag-and-drop from Spectacle to Chromium (KDE bug 369404, available in KDE Applications 18.04)
  • Dolphin’s Edit menu now has menu icons for Select All and Invert Selection, making it a 100% icon-complete menu (KDE Phabricator revision D10503, implemented in KDE Applications 17.12.3):
  • All KDE Apps using the Deselect and Replace KStandardActions now get menu icons for them (KDE Phabricator revision D10508, implemented in KDE Frameworks 5.44):
  • Apps on the touchscreen-friendly Application Dashboard can now actually be launched with touchscreen taps (KDE bug 366527, fixed in KDE Plasma 5.12.2)
  • Gwenview can now be configured to not show the image action buttons that appear over thumbnails when you hover over them with the mouse (KDE bug 164847, implemented in KDE Applications 18.04)

  • The Web Browser Widget has been overhauled and now works much better, regaining the features it lost in the KDE4 -> Plasma 5 transition (KDE bugs 361939 and 371023)
  • Icons in Dolphin’s Information Panel now look good in HiDPI (KDE Phabricator revision D10532, fixed in KDE Applications 18.04)
  • The Toggle Touchpad shortcut actually toggles the touchpad now (KDE bug 370588, fixed in KDE Plasma 5.12.1)

I’ve noticed a significant influx of new contributors recently, so what we’re doing seems to be resonating with the community. It’s a great time to get involved. Our documentation and new contributor pipeline are getting better all the time. You don’t need to be a programmer to start submitting patches! Most of my first patches were simple one-liners and string changes. Once you’ve got your development environment set up, submitting trivial patches like these is as easy as pie, and will familiarize you with the codebase so you feel comfortable tackling slightly larger challenges.

If my efforts seem useful and you’d like to see more of them, consider supporting me on Patreon, LiberaPay, or PayPal.

The Machine

The Raspberry Pi3 is a small single board computer that costs around $35 (USD). It comes with a network port, wifi , bt , 4 usb ports , gpio pins , camera port , a display out, hdmi, a TRRS for analog A/V out. 1GB of ran and 4 ~1GHz armv8 cores Inside small SOC. Its storage is a microSd card they are a low cost and low power device. The Touchscreen kit is an 800×480 display that hooks to the Gpio for touch and dsi port for video. To hold our hardware is the standard touch screen enclosure that often comes with the screen if you buy it in a kit.


Most of the time it is sufficient to run Raspian the official distro that is made for the raspberry pi. raspian is a fork of debian as much like debian it has some old packages. In order to build AtCore (with the gui) you need at least qt5.8 raspian comes with 5.7. This is not a show stopper but compiling qt does take quite some time and can easily take a week if we were to build it on the rpi itself. Setting up a cross complier will save you a lot of time but even on my fastest machine it will still take some hours to build qt for the pi. I decided it would instead be faster to install a completely unsupported OS on the device. I was going to install install arch linux on the rpi. Arch is a rolling distro that ships with qt 5.10.

Doubly Unsupported

Arch linux on the raspberry pi is what you might call “doubly unsupported” That is that the raspberry pi foundation does not support running arch on the pi. You only get support from the arch community. Arch Linux is not officially supported on platforms other then x86_64 the rpi running on arm.  Worry not for the Arch community has some forks such as archlinux-arm this is what we will be installing. Like most things arch you get some instructions. After getting the os installed its still arch so you only get a cli interface on your first boot and are left to set up the rest of the system.

Post Install

For my system I installed plasma-meta , xf86-video-fbturbo-git and sddm. With those I was able to have a working plasma shell. I also installed dolphin, kate and konsole as well as the few atcore dependencies. I then added my user to the uucp group so I was able to r/w to serial devices and restarted. When all the dependencies are installed you can proceed to build atcore. Since this is arch we can simplify the building part just by using atcore-git from the aur. Im Happy to say it took only minutes and 48 seconds to build atcore-git on the rpi. I then used pacman to install the atcore-git package and it was time to see how our gui was looking on such a small screen.

The Result

At first the contents of the atcore-gui spill off the screen due to the way our docks are tabbed, however since they are docks you can just adjust them to make a quick usable interface. After adjusting the gui AtCore worked exactly the same as it does on other systems. Below you can see a picture and video.


Can do better

There is lots of room for improvement. Atcore-gui does not save any settings. You’ll need to move the docks around each time you launch the program. Atcore-gui can not automatically connect to a device on launch. Again for reasons of not saving settings This gui is of course not really made for use on a touch screen and it does seam to work good enough to use. Some non atcore changes on the system itself would be nice. A few services running on the pi would improve this over all. Mjpeg streamer or another method of streaming video from the attached camera on my printers extruder. Uploads are done via stfp that’s not always easy for everyone. The pi does not launch atcore-gui on start up . Small stuff like this could easily be adjusted. I was really just playing around to see how atcore ran on the rpi. I was very happy when this worked well.

February 17, 2018

Howdy everyone! So many folks have asked me to set up a Patreon page that I’ve gone and done it: https://www.patreon.com/ngraham

By supporting me on Patreon, you’re helping me provide the focus, direction, support, and technical contributions that work to turn the KDE software suite into a lean, mean, bug-free productivity machine, and get it distributed well so that our users have great options for getting our software.

Of course, I’m only one man; what really matters is not me, but rather you! KDE’s greatest strength is its passionate community of developers and users, who work tirelessly to develop, improve, polish, promote, and use KDE software. I truly couldn’t do this without all of you, and in fact, I wouldn’t even want to! All of you are the reason why I work so hard on KDE software. Thank you, so very much.

Become a patron

We’ve been focusing like crazy on the Krita 4 release. We managed to close some 150 bugs in the past month, and Krita 4 is getting stable enough for many people to use day in, day out. There’s still more to be done, of course! So we’ll continue fixing issues and applying polish for at least another four weeks.

One of the things we’re doing as well is redesigning the set of default brush presets and brush tips that come with Krita. Brush tips are the little images one can paint with, and brush presets are the brushes you can select in the brush palette or brush popup. The combination of a tip, some settings and a smart bit of coding!

Our old set was fine, but it was based on David Revoy‘s earliest Krita brush bundles, and for Krita 4 we are revamping the entire set. We’ve added many new options to the brushes since then! So, many artists are working together to create a good-looking, useful and interesting brushes for Krita 4.

It’s still work in progress! But we want your feedback. So… Download the new Krita 4 development builds, and start doodling, sketching, painting, rendering… And then tell us what you think:

Do the brush preset survey!

Apart from the new brushes, and the bug fixes, there’s also news for Linux users: we updated our AppImage build scripts, and the new appimage includes Python scripting and the Touch UI docker. Note: by default all scripts are disabled, so you need to go to Settings/Configure Krita/Python scripts and enable the scripts you want to use.

Help with the release!

We’re having our hands full with tasks like coding, bug fixing, manual updating… More than full! One task that looks like it’s going to slip is creating a cool what-new-in-4 release video. So: if you’re good at creating videos and want to help the team, please join us on #krita on irc.freenode.net and help us out!


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. On Windows, gmic-qt is included.


On Linux, you need to download the gmic-qt appimage separately. You can configure the location of gmic-qt in Krita’s settings. Krita requires the “XDG_DATA_DIRS” environment variable to be set. Most distributions do this, but if yours doesn’t, set “XDG_DATA_DIRS” to “/usr/local/share/:/usr/share/” as a workaround. Next build Krita will do this by itself.

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


The minimum version of OSX/macOS is 10.11

Note: the python, gmic-qt and pdf plugins are not available on OSX.


For all downloads:

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.

This is going to be a double-header: today we’re discussing Discover as well as Kirigami–KDE’s UI framework that facilitates writing convergent apps that look and feel good on both the desktop and a mobile device.

…At least that’s the idea. The truth is, KDE users have voiced a lot of criticism for how well this works out in practice. An especially common complaint is that the desktop user experience gets short shrift, and Kirigami apps feel like big phone apps.

We’ve heard this feedback, and we’re acting on it. Over the past week, we’ve been hard at work to make Kirigami UI components behave more appropriately on the desktop, and have Discover make use of them instead of its custom components.

So I have exciting news for everyone who has complained about Discover’s design being too mobile-ey and wasting too much space: that’s going to be a thing of the past. Here’s how the Featured page now looks in git master:

No more huge header with the picture of the coffee cup that nobody liked! This is not the final appearance; there’s still polish work to be done, and we are heavily iterating over Kirigami to improve it to make the Desktop UI a first-class citizen. But it’s a model for what we’re going for.

We also added some other much-requested user-centric features to Discover, such as making reviews more prominent. Have a look!

  • Discover now shows the top three reviews right on the app page (KDE bug 380514, implemented in KDE Plasma 5.13):
  • Discover’s review submission pop-up is now more user-friendly and makes it impossible to accidentally submit a one-star review (KDE bug 390426 and Phabricator revision D10500, improved in Plasma 5.13):
    Note the presence of a close button! Another much-requested feature for Kirigami pop-ups.
  • You can now use Discover to write an app’s first review (KDE bug 390339 and KDE Phabricator revision D10476, fixed in KDE Plasma 5.12.1):
  • Kirigami scrollable pop-ups (used for Discover’s review page) no longer let you scroll beyond the content in desktop mode (KDE bug 388942, fixed in KDE Frameworks 5.44)
  • Kirigami non-scrolling pop-ups (used for Discover’s review input pop-up) now have correct bottom padding (KDE bug 390032, fixed in KDE Frameworks 5.44)
  • Kirigami toolbar headers are bit taller their titles and navigation buttons have appropriate padding (KDE Phabricator revisions D10483 and D10524, fixed in KDE Frameworks 5.44)
  • Kirigami pop-ups (used for Discover’s screenshots and reviews pop-ups) now have close buttons (KDE bug 387815, Fixed in KDE Frameworks 5.44)
  • Discover’s “show more reviews” button now always shows the correct number of reviews, has slightly better text, and no longer lets you write the first review for apps that you haven’t installed yet (KDE Phabricator revisions D10527 and D10525, Fixed in KDE Plasma 5.13)
  • Items in app lists now have better top padding, so they don’t touch the header (KDE Phabricator revision D10548)
  • Improved the metadata for the KDE Nightly Builds Flatpak repo so it has a more appropriate name, in preparation for encouraging our users to try it out (more on that soon…):

Well there you have it. We never stop working on improving Discover, and we really do listen to user feedback. Mark my words, Discover is going to become one of the most-loved Linux software centers, you heard it here first! Help is always appreciated, so feel free to start contributing and making a difference to a project that truly matters. You don’t have to be a programmer to have an impact!

And if you look at my efforts and like what you see, consider donating on Patreon to help me do it full-time, rather than squeezing it in before and after my regular job. With your support, I could bring forth even more for KDE!

February 16, 2018

I was working on adding sounds to Pixel Wheels rescue helicopter, so I started SFXR Qt and after a few experiments I came up with a decent sound. Unfortunately it did not sound that good in the game. It was much more dull than in the app. Listening again to the sound in SFXR Qt I realized there were subtle variations between each plays, which made the sound more interesting.

Initial investigation

At first I was puzzled, how could the sound differ from play to play? After a more thorough code inspection I found the culprit: the noise buffer. When you select a noise wave form, the app generates a 32 item long array of random floats between -1 and 1, and go through it in a "segment" (a sound can be made of multiple segments). When a new segment starts, the buffer is regenerated, causing the sound to be subtly different each time it is repeated.

Let's make it sound dull

I want SFXR Qt sounds to sound like they are going to sound in the game, so I set out to get rid of those variations.

I picked the sound created the first time you click on the "Explosion" generator button as my guinea pig. It sounds like this:

My first fix attempt was to create a long buffer with as many items as there are samples in the sound, and reuse it as the sound was being replayed. That failed: the noise was much more high pitched.

Debugging random noise buffers is hard, or at least, I am not used to working on this kind of topics. One change I made to make behaviors more deterministic was to make the noise buffer generators of both the master branch and my work branch use their own, fixed random seed, separated from the seed used by the generator buttons. This made it possible to compare the sounds generated by running both versions side by side.

I could hear the difference but I was getting nowhere, why did my noise buffer sound differently than the original implementation? And then I had a revelation: the original buffer contains 32 items, and the code using it looks like this:

sample = noise_buffer[phase * 32 / period];

Where period is the duration of the current segment, and phase is the sample index in the segment.

As you can see, there is no modulo: the noise buffer is stretched to fill the segment. This means that each value in the buffer is used period / 32 times consecutively before the next value is used. Using the same noise values longer means less variations, which translate into lower pitched noises.

Comparison of the two generated noises

Armed with this revelation, I reworked the code to use a fixed 32 item buffer and reuse it between segments. The result was less high pitched, but it was also a lot less noisy:

More head scratching led to the second revelation: reusing the same noise buffer across segments caused the creation of regular waves with a frequency of 1 / period. The buffer needs to contain different values for each segments to avoid creating those low frequency waves.

My third implementation fixed this by creating a list of 32 item noise buffers, one for each segment, and reusing the same list each time the sound is replayed. This finally produced the same result as the original. Victory!


Using a list of buffers worked, but it felt over-complicated. My first simplification attempt was to use one long buffer again, but go through it by slices of 32 items. That worked, but the code was not much simpler.

I eventually came up with a simpler approach: what I needed was a random value generator which returned the same value for period / 32 calls, and which could be reset to produce the same pseudo-random sequence each time the sound restarts. This can be implemented by keeping the last value returned and changing it at the right time. Reproducibility can be achieved by resetting the random seed each time the sound restarts. I implemented this in a NoiseGenerator class:

// Header
class NoiseGenerator {
    explicit NoiseGenerator(int sampleCount);
    void reset();
    float get(float alpha);
    const int mSampleCount;
    unsigned int mRandomSeed = 0;
    int mLastIndex = -1;
    float mLastValue = 0;

    float randomRange(float range);

// Implementation
NoiseGenerator::NoiseGenerator(int sampleCount)
    : mSampleCount(sampleCount) {

void NoiseGenerator::reset() {
    mRandomSeed = 0;
    mLastIndex = -1;

float NoiseGenerator::get(float alpha) {
    int index = mSampleCount * alpha;
    if (index != mLastIndex) {
        mLastIndex = index;
        mLastValue = randomRange(2.0f) - 1.0f;
    return mLastValue;

float NoiseGenerator::randomRange(float range) {
    return rand_r(&mRandomSeed) / float(RAND_MAX) * range;

Back to this helicopter sound

Now that I can trust SFXR Qt to play sounds faithfully, the next step is ironically to make it capable of producing the sound it produced before by accident, but this time in a way which can be used in Pixel Wheels. To do so I plan to add an option to set a number of repeats so that it can generate N times the same sound with noise variations. But that's a story for another week...

Igor Ljubuncic of Dedoimedo is at it again, and has just published a list of high-profile KDE Plasma bugs and papercuts. As a Plasma fan, his intention is to call attention rather than criticize, and I’ve put together a response for every issue he raised. For the full list, scroll down.

Here’s the thing: reporting issues is important. QA is important. Raising awareness of problems is important. But as you’ll see from the list below, nearly every legitimate issue that Igor brings up is already known and tracked in Bugzilla. Many are already fixed, in fact.

The problem is lack of resources, not lack of awareness of issues. Fixing bugs requires developers. And we need more in order to fix them all at the rapid pace that our users expect. We know about the bugs. We want to fix the bugs. But we need your help to do it!

The best way is to start submitting some patches. You don’t even need to know any programming! Here is a non-programming patch I submitted just today, for example. A lot of my patches are utterly trivial in nature, like this one or this one. These are easy fixes; low-hanging fruit. Anyone with some technical knowledge can get started today! There’s a ton of support.

If you want to help propel KDE to the great heights it’s capable of, climb on board!

And now, for the full list, if you dare:

  • [C] Widget button on the left side is too close to the desktop folders.

    Will be fixed soon: https://phabricator.kde.org/D10563

  • [C] Widgets list always opens on the left side, regardless of the button placement.

    This isn’t a bug. The widget list can be opened from multiple interfaces; if it always followed the Desktop Toolbox, it would just be inconsistent with something else. Still, we may be able to make some usability improvements: https://bugs.kde.org/show_bug.cgi?id=390575

  • [C] Wireless icon (when not connected) is too pale and may be mistaken for a gap in the system area in the panel.

    Already fixed; see https://bugs.kde.org/show_bug.cgi?id=384018

  • [C] When connecting to a Wireless network, the user may be prompted for password twice, which is probably related to the KDEWallet service.

    See https://bugs.kde.org/show_bug.cgi?id=387502. This is mostly up to distros; most of them don’t configure KWallet properly. Kubuntu already does for the actual user account, but doesn’t for the live session. But it will soon; see https://phabricator.kde.org/T7981

  • [F] When you add/pin applications to the task manager, the menu auto-closes. This is annoying and distracting if you want to add more than one icon at a time.

    See https://bugs.kde.org/show_bug.cgi?id=390585

  • [F] Menu session end buttons all have the same result, regardless of what you click on. Whether you choose suspend, reboot or shutdown, you still have a 30-sec timeout screen with the same options presented again. A confirmation is nice, but it should also correlate to the chosen action. Clicking suspend or reboot and then choosing shutdown a few seconds later negates the first choice.

    It already does; the action you chose is the one that’s selected in the confirmation screen.

  • [C] The system menu does not differentiate between several versions of the same application, if installed. For example, the standard repo and the snap version of VLC 3.0 both show exactly the same, and the only way to tell them apart is by the icon (lower-res for the snap), or alternatively, by launching the program to check which version it is.

    See https://bugs.kde.org/show_bug.cgi?id=389035

  • [F] The order of different versions of the same application as listed in the system menu changes based on usage/launches.

    That’s a feature, not a bug. For an app list based on frequency of use, you should expect each version of an app to appear separately and have its own ordering. If you didn’t care about them being separate, you wouldn’t install multiple versions of the same app.

  • [C] Panel height resize is done using a drag/slider rather than a precise input value. Both options ought to exist, so that both methods can be used. Hand sliding, especially without an external mouse pointer, is tedious and inaccurate.

    Improved with https://bugs.kde.org/show_bug.cgi?id=372364. Further improvements possible.

  • [C] Brightness slider does not go all the way to the right on the 100% mark.

    Already fixed, a long time ago (Igor even blogged about it having been fixed!). Must have been using a distro with an old version of Plasma, or a defective theme.

  • [C] The clipboard in the system area, after you copy media files, does not have a perfect vertical alignment, leading to the bottom-most line to be partially obscured (cropped).

    Not a bug; this is how all scrollable lists work everywhere. Perfect alignment is impossible when the list can be filled with arbitrarily-sized content.

  • [F] Default font color is too pale – insufficient contrast; should be black.

    Already almost fixed. See https://bugs.kde.org/show_bug.cgi?id=381288

  • [F] Default font size is too small (10pt).

    See https://phabricator.kde.org/T7864

  • [C] Default font anti-aliasing settings are sub-optimal in all tests I have performed, including different laptops, with Intel and Nvidia graphics. The system defaults should be set to RGB and slight hinting.

    See https://bugs.kde.org/show_bug.cgi?id=389598 and https://phabricator.kde.org/T7618

  • [F] Spectacle does not have an option to remove/disable shadows when taking a screenshot of an active window area. The shadow size also depends on the selected theme – and may be impacted by compositing, which can lead to inconsistent results. It is also not apparent whether there are shadows in created screenshots or not while they are being taken.

    See https://bugs.kde.org/show_bug.cgi?id=372408

  • [F] Spectacle usage model is complicated – Save & Exit is the same button that opens the preferences menu, and it is not immediately apparent this is the case. It also makes no sense to place the two under the same hierarchy element.

    Already fixed. See https://pointieststick.wordpress.com/2018/02/15/usability-productivity-highlight-spectacle/

  • [C] System settings menu opens at a “wrong” default size, leading to category labels text breaking over multiple lines.

    See https://bugs.kde.org/show_bug.cgi?id=389617

  • [C] System settings category labels are too pale – and barely visible.

    See https://bugs.kde.org/show_bug.cgi?id=384638

  • [F] The installation of new themes, icons and other decoration is vague and broken. Sometimes, there are multiple install options that do not clearly signify to the user what they’re installing, and these installations often fail due to misconfigured third-party resources. Even when installed, decorations may not show up in relevant lists due to unlisted incompatibilities. It may take a full session restart (log out, log in) to see the effects of newly applied decorations.

    A known issue. This is a big task, too big for a Bugzilla ticket. But it’s on our radar screens.

  • [F] System customization should include a backup and restore-to-defaults options, including a desktop/system wide configuration, as well as individual options. This may also be realized as preview function, so the users can see what the new theme/decoration will do before it is applied.

    See https://bugs.kde.org/show_bug.cgi?id=389568

  • [F] Discover shows no screenshots and no rating for selected programs.

    No screenshots: Not Discover’s fault; it’s up to app developers to properly advertise their work, or packagers to bail them out and do it for them. We can’t do anything about this in Discover. See https://pointieststick.wordpress.com/2018/01/27/how-to-make-an-app-look-good-in-discover/ As a workaround, use Flathub instead of your distro’s packages wherever possible; they care about good packaging and make sure that app listings look good.

    No ratings: See https://bugs.kde.org/show_bug.cgi?id=389601

  • [F] Discover sources management remains confusing and insufficient – no way to change locality/priority of listed distributions, no way to search or install proprietary software.

    You already can change the priority of different backends. Changing priority of individual repos within a backend is tracked with https://bugs.kde.org/show_bug.cgi?id=388921

  • [F] In the sources view, Discover has a scrollbar that obscures the list of repos and also partially blocks the UI itself.

    Already fixed: https://bugs.kde.org/show_bug.cgi?id=389602

  • [F] Discover seemingly keeps on checking for updates, even though the action is not happening and/or it should have completed already.

    This is very distro-specific, and we haven’t seen it in quite a while with recent versions of Discover. Anyone who sees this should file a bug! Just complaining about it isn’t enough; we need for people who experience it to file bugs!. If you want to be QA, then you have to be willing to use the appropriate channels to report issues, or else it’s just noise. See https://community.kde.org/Get_Involved/Bug_Reporting

  • [F] Discover search results are broken; programs that can be found using the command-line package manager utility do not show in the UI when the same search string is used.

    Discover is not a package manager. By design, it only shows packages with AppStream metadata. The goal is that users shouldn’t ever need to do manual package management. If anything ever doesn’t show up in Discover that should, this is the your distro’s fault, but you can help us fix it!

  • [F] It is difficult to find the option to configure/enable the desktop session restart (X kill), normally activated by the Ctrl + Alt + Backspace combo. There are no less than three different options to configure and use keyboard shortcuts. You have normal and advanced settings, but then you also have the hardware configuration, and it’s the last one that you actually need for this.

    This is an advanced feature that shouldn’t be required for normal users during normal use; why would we want to make it more prominent?

  • [C] Dolphin requires drag ‘n’ drop to add shortcuts to the sidebar; an (easily discoverable) menu option would be preferable, especially for network shares.

    It’s right there in the right-click context menu:

  • [C] There’s no easy way to quickly remove/hide entries in the Dolphin sidebar, except by removing the entire category.

    Sure there is:

  • [C] The list of devices in Dolphin seems random – devices should include both label, device name and size through a configurable setting, and there should be an option to allow the user to sort the devices based on their preference.

    See https://bugs.kde.org/show_bug.cgi?id=367614

  • [F] In Dolphin, copying files to Samba shares will result in their timestamp being updated to the current mark. This is most significant when working with pictures.

    See https://bugs.kde.org/show_bug.cgi?id=356651

  • [C] No way to add URL shortcuts by drag ‘n’ drop from browsers; no favicons are used as shortcut icons.

    This works just fine. Could use some usability polish, though: https://bugs.kde.org/show_bug.cgi?id=389600

  • [C] No way to add an existing URL shortcut (on the desktop) to the task manager. Launched program/site via the shortcut defaults to the browser application icon.

    See https://bugs.kde.org/show_bug.cgi?id=389613

  • [C] The panel clock is too big – full height – while the rest of the system area icons are smaller. The use of the alternative gadget Event Calendar helps, but this should be a customizable option in Plasma defaults.

    Already fixed; see https://bugs.kde.org/show_bug.cgi?id=375969

  • [F] KDE Connect only works with Android devices.

    This is caused by limitations in the kinds of software allowed on iOS.

  • [F] iPhone/iOS devices will not be auto-mounted in Dolphin; you may need to use a manual configuration to identify and mount them.

    Never seen this; my iPhone works fine. A detailed bug report would be helpful here.

  • [F] The mount prompt in the system area (regardless of the device/phone/camera) type is vague. It offers several mount options, associated with programs, but it does not identify the mount protocol, e.g. MTP or PTP. This only becomes apparent after the device has been mounted and presented in the file manager.

    Not a bug; the mount protocol is (or should be) irrelevant to a normal user. No other OS includes this kind of super technical information there.

  • [F] There is no umount option for phones or cameras in Dolphin.

    Already fixed: https://phabricator.kde.org/D8348

  • [F] Media playback (music and video) from Samba shares does not work well. There is no unified approach to how the remote filesystems should be treated, and it is up to individual applications to handle authentication and playback.

    See https://bugs.kde.org/show_bug.cgi?id=75324

  • [C] Not all media players have system integration, and/or some have their individual icons + media playback button in the system area.

    This is entirely up to those media players to conform to the MPRIS spec. Blame them, not us.

  • [F] Accessibility options are vaguely defined or executed. They should be available out of the box and configured for immediate use, including the lock and login screens.

    A legitimate concern. We will investigate this.

  • [F] Open file dialogs for different applications behave in different ways, including how directory trees and files are displayed. Often, paths and names are truncated, and there’s no standard display method.

    These are most often Qt bugs, but still a priority in my list.

The above issues are high-profile and will earn their fixers a lot of praise, and will likely be featured here. So go on and fix some bugs! It’s easier than you think.

In the last post, we discussed a new approach to design time and build time integration of external tools in Visual Studio using MSBuild rules and targets. This will be included in the upcoming release of version 2.2 of the Qt VS Tools. In this post, we will discuss the performance improvements that are also included in this new version.

We’ll focus on two situations where users of the current version (2.1) of the Qt VS Tools have reported sub-standard performance:

  • Adding new header files, especially to projects with many configurations
  • Converting Qt projects (.pro files) with many files

We’ll look at the scale of these problems and why they occur, then discuss the steps that have been taken to fix the problems and the improvements that have been achieved.

Adding Header Files to a Project

To understand the scale of this problem and the effectiveness of our solution, we ran the same set of tests using both the current and the new version. These tests consisted of adding several header files containing Qt macros to projects with varying numbers of configurations. For more information on the test setup and a detailed analysis of the results, please refer to the section “Measuring Performance”, at the end of this post.

Looking into the results of testing version 2.1, we found that the time to add files to a project got progressively worse, up to several minutes, the more configurations were defined in the projects. The worst case scenario was just under 45 minutes for adding 10 files to a project with 20 configurations. It was possible to determine that the performance degradation is closely related to the approach previously followed, where files generated by moc were explicitly added to the project in order to be included in the C++ compilation. The time spent modifying properties of generated files accounted for 98% of total time.

As we discussed in the previous post, the new approach based on MSBuild rules and targets allows source files to be added to the build process while it is ongoing. This way, instead of adding the files generated by moc as static project items, they are added dynamically to the C++ compilation during the processing of the moc target. This should represent a significant improvement to the cost of adding new header files to a project. The test results from version 2.2 show that this is indeed the case: the time spent on each test case was, on average, 95% less than that of version 2.1, and what was previously the worst case scenario (10 files added to a project with 20 configurations) now took only 3,2 seconds to complete.

This improvement in performance is not limited to the action of adding header files to projects. It will have an impact in all operations that handle generated files as project items. The following is a list of other use cases that should also benefit from the increase in performance (especially in projects with several configurations):

  • Importing Qt projects (see next section);
  • Creating new Qt classes;
  • Manually adding/removing the Q_OBJECT macro in a file;
  • Changing the Qt version;
  • Changing the path to the moc, rcc and uic generated files.

Importing Qt Projects

The problem described above also applies when importing a .pro file, since properties of generated files are also accessed and modified during import; in fact, the import procedure modifies properties of all project files. To avoid this problem, in the new version of the Qt VS Tools, the Visual Studio project that is generated by qmake is not immediately loaded into Visual Studio; all modifications are carried out as an XML transformation on the project file. Only then is it loaded into Visual Studio. This way we avoid any project-wide processing while the project is loaded.

To test this optimization, we imported the Qt example project demobrowser. Below is a recording of this test using version 2.1 (left) and version 2.2 (right) of the Qt VS Tools (the recording also includes building and running the program). We found that the time to import the project decreased from over 30 seconds in the current version to less than 6 seconds in the new version.

Importing demobrowser


Measuring Performance

To measure the scale of the performance problem when adding new header files, we ran a series of tests with an instrumented build of the Qt VS Tools that recorded the number and duration of calls to every function. As the performance seemed to be influenced by the number of project configurations, we tested with several projects containing respectively 2, 5, 10, 20 and 40 configurations. As the number of files added also seemed to be a factor, we tested each project with 5, 10, 20 and 40 files added, for a total of 20 test cases. We will use the variable C to represent the number of configurations, and the variable F to represent the number of files added.

The results of testing with version 2.1 of the Qt VS Tools show that the performance degrades significantly as we increase the number of configurations and the number of files added. The graph below summarizes the test results. Some tests were interrupted after 45 minutes; this is noted in the graph by grayed-out bars. The blue bar on the left serves as a 1 minute scale.

Test Results v2.1

Looking further into the test data, we find that most of the elapsed time was spent calling functions of the Visual Studio SDK. For example, in the test case C=20,F=10, which took almost 45 minutes to complete, 98% of that time was spent in the following calls:

Calls to Visual Studio SDK

These functions were called while adding generated files to the project – files generated by moc must be added to the project in order to be included in the C++ compilation. For every header file added, one generated file per configuration will also be added to the project, i.e. F×C generated files. In the test case of C=20,F=10, this accounts for the 200 calls, e.g. to the AddFile function.

Each one of the F×C generated files can only be compiled if the corresponding project configuration is active. For all other configurations, the file must be set to “excluded from build”. This is the reason for the larger number of calls to the set_ExcludedFromBuild function, i.e. F×C×(C-1) calls to that function. In the example of the C=20,F=10 test case, this accounts for the 3800 calls to set_ExcludedFromBuild.

We’ve also found that the functions of the Visual Studio SDK tend to become slower as the number of calls increases. In the case of set_ExcludedFromBuild, we see that the average time per call went from 11 milliseconds, when calling the function 10 times, to 535 milliseconds per call for 3800 calls:

Calls to set_ExcludedFromBuild

With the approach followed in version 2.1, which requires that generated files be added to the project, there doesn’t seem to be much room for improvement in performance: almost all time is spent inside external functions and these functions are called exactly the number of times needed. The problem of the performance degradation seems then directly linked to the approach itself.

To test the performance of the new approach, we ran the same 20 test cases using the new version 2.2 of the Qt VS Tools, which uses the Qt/MSBuild targets; the results are shown in the graph below. As before, the blue bar on the left represents the same 1 minute scale.

Test Results v2.2

Comparing the results of both tests, in version 2.2 the time spent was, on average, 95% less than that of version 2.1. The average cost of adding header files to a project, per file and configuration (i.e. total time divided by F×C), decreased from 300 milliseconds to 40 milliseconds.

The post Qt in Visual Studio: Improving Performance appeared first on Qt Blog.

On Valentines day TechEmpower released the results of fifth round of it’s benchmarks tests on web frameworks, it took almost a year since round 14 and I really hope round 16 comes out sooner.

Since this round took a long time and was scheduled to be release many times last year I decided not to update Cutelyst to avoid not having the chance to fix any issues and have broken results. Cutelyst 1.9.0 and Qt 5.9 were used, both had some performance improvements compared to round 14, and thus you can see better results on this round compared to 14, most notably the JSON tests went from 480K request/second to 611K req/s, also due this old Cutelyst release jemalloc was again not used due a bug we had in CMake files that didn’t link against it.

In this round some  other frameworks also done their optimizations and a few managed to do better than Cutelyst, even though we were faster in all tests compared to the last round. It might be even related to some OS tuning as most results seemed to went up a bit, however if you put the filter on “FullStack” frameworks Cutelyst is leading in most tests.

TreeFrog framework had results in TechEmpower long before I wrote the tests for Cutelyst, but due errors on TreeFrog tests on last rounds this was the first round where you can compare the results of two Qt Web Frameworks.

For the next round I expect the results to be even better now that we will properly use jemalloc, and our epoll dispatcher got a better implementation, I also plan to use Cutelyst 2 and try increasing some buffers as the servers have plenty of RAM that I didn’t care on using.

If you want to know more about Cutelyst visit https://cutelyst.org/ and give us a Star on GitHub (we are now past 300!!) https://github.com/cutelyst/cutelyst

February 15, 2018

Over the past few weeks, we’ve done a lot of Usability & Productivity work for Spectacle, KDE’s screenshot tool. I’d like to share the progress! But first, a screenshot. Here’s how spectacle looks now:

We’ve been hard at work making Spectacle easier to use and more featureful, and you can see some of those changes in the above screenshot. Here’s the full list of user-facing changes and bugfixes:

  • The save button now defaults to showing “Save As…” (KDE Phabricator revision D10153)
  • The Save button now remembers the last Save mode that you used by default (KDE Phabricator revision D10198)
  • Removed the confusing and destructive Discard/Quit button (you can still quit the app with Ctrl+Q or the Escape key, or by clicking on the window’s close button (KDE Phabricator revision D10283)
  • Added a visible “Configure…” button so that you can more easily find Spectacle’s settings (KDE Phabricator revision D10289)
  • Added a new “Tools” menu button that can hold extra features, and moved “Print” to it. Now the “Save” button finally has only actual Save actions! (KDE Phabricator revision D10371)
  • Spectacle’s new Tools menu now provides an easy link to your screen recording app if you have one installed, and if you don’t, it suggests a few (KDE Phabricator revision D10295)
  • Made the main window size itself optimally based on the shape of the screenshot (KDE Phabricator revision D10377):
  • Spectacle can now be configured to quit after copying the screenshot to the clipboard (KDE bug 389773) – note that you will need to tell Klipper (the clipboard manager) to accept images for this to work. For more information, see the bug report.
  • Spectacle’s new Tools menu provides an easy way to see where the last screenshot was saved (KDE bug 389695)
  • Drag-and-drop to Chromium windows now works (KDE bug 369404)
  • Spectacle no longer displays the dreaded “Ambiguous shortcut warning” dialog if you use the same keyboard shortcut twice (KDE bug 389691)

All of these improvements will be available in KDE Applications 18.04.

And we’re not done yet. We’re scoping out work to add an inline image editor/annotator and improve the user experience where you want to use spectacle to quickly take a screenshot and copy it to the clipboard without showing the main window (often for the purposes of pasting it into a chat window). An option to omit window shadows or reduce their size is also in the works.

Spectacle is used by hundreds of thousands or even millions of people, so this work has an impact! It’s a great time to be part of something big. Hop on board, and we’ll work together to continue making everything even better.

A verdigris statue

I have just tagged the version 1.0 Verdigris. I am taking this opportunity to write an article about two C++ tricks used in its implementation.

Verdigris is a header-only C++ library which lets one use Qt without the need of moc. I've written an introductory blog post about it two years ago and have since then received several contributions on GitHub that extend the software.

Optionally Removing Parentheses in a Macro

This trick is used in the W_PROPERTY and the W_OBJECT_IMPL macro. The first argument of W_PROPERTY is a type. Typically: W_PROPERTY(QString, myProperty MEMBER m_myProperty).
But what happens when the type contains one or several commas, as in: W_PROPERTY(QMap<QString, int>, myProperty MEMBER m_myProperty)? That's not valid, macro expansion does not consider template and therefore the first argument would be up to the first comma. The solution is to put the type name in parentheses. The new problem is then how can we ignore parentheses in the implementation of the macro.

Let's rephrase the problem with simplified macros. Imagine we want to do a macro similar to this:

// Naive implementation of a macro that declares a getter function

// Can be used like this
DECLARE_GETTER(QString, property1);   // line A
// OK: expands to "QString get_property1()"

// But this does not work:
DECLARE_GETTER(QMap<QString, int>, property2);
// ERROR: 3 arguments passed to the macro, but only 2 expected

// And this
DECLARE_GETTER((QMap<QString, int>), property3);  // line B
// ERROR: expands to "(QMap<QString, int>) get_property3()"
// Can we get rid of the parenthesis?

The question is: How can we implement DECLARE_GETTER so both line A and line B produce the expected result? Can we get the macro to remove the parentheses.

Let's make a first attempt:

// REMOVE_PAREN will be our macro that removes the parenthesis


DECLARE_GETTER((QMap<QString, int>), property1);
// OK: expands to "QMap<QString, int> get_property1()"
// This worked because "REMOVE_PAREN_HELPER (QMap<QString, int>)" was expanded to "QMap<QString, int>"

DECLARE_GETTER(QString, property2);
// ERROR: expands to "REMOVE_PAREN_HELPER QString get_property2()"
// There was no parenteses after REMOVE_PAREN_HELPER so it was not taken as a macro"

We managed to remove the parentheses, but we broke the case where there are no parentheses. Which lead to a sub-question: How to remove a specific token if present? In this case, how to remove "REMOVE_PARENT_HELPER" from the expansion

// Same as before

// Macro that removes the first argument
#define TAIL(A, ...) __VA_ARGS__

// This time, we add a "_ ," in front of the arguments
#define REMOVE_PAREN_HELPER(...) _ , __VA_ARGS__


//  ##__VA_ARGS__ will "glue" the first token of its argument with "REMOVE_PAREN_HELPER_"
// The first token is:
//  -  "_" if REMOVE_PAREN_HELPER was expanded, in which case we have "REMOVE_PAREN_HELPER__"
//      which will be removed by the TAIL macro; or
//  - "REMOVE_PAREN_HELPER if it was not expanded, in chich case we now have

// So we define a macro so that it will be removed by the TAIL macro

The above code should give you an idea on how things should work. But it is not yet working. We need to add a few layers of indirection so all macros arguments gets expanded

Here is the real code from Verdigris:

#define W_MACRO_MSVC_EXPAND(...) __VA_ARGS__
#define W_MACRO_TAIL(A, ...) __VA_ARGS__



// And now it works as expected:
DECLARE_GETTER(QString, property1);
DECLARE_GETTER((QMap<QString, int>), property2);

Note that the W_MACRO_MSVC_EXPAND is there only to work around a MSVC bug.

Building a constexpr State in a Class from a Macro

Conceptually, this is what the macro does

class Foo : public QObject {
   W_OBJECT(Foo) // init the state
   int xx();
   W_INVOKABLE(xx) // add things to the state
   int yy();
   W_INVOKABLE(yy) // add more things
W_OBJECT_IMPL(Foo); // Do something with the state

But what's the state? How do we represent it?
The idea is to have a static function (let's call it w_state) whose return value contains the state. Each W_INVOKABLE macro would then expand to a new definition of that function. Of course, it needs to take a different argument, so this just declares a new overload. We do it by having a w_number<N> class template, which inherits from w_number<N-1>. (This idea is basically inspired from CopperSpice's cs_counter, whose authors described in a talk at CppCon 2015)

Here is a simplified expanded version:

template<int N> struct w_number : public w_number<N - 1> {
    static constexpr int value = N;
    static constexpr w_number<N-1> prev() { return {}; }
// Specialize for 0 to break the recursion.
template<> struct w_number<0> { static constexpr int value = 0; };

class Foo {
    // init the state  (expanded from W_OBJECT)
    static constexpr tuple<> w_state(w_number<0>) { return {}; }

    int xx();

    // add &Foo::xx to the state by defining w_state(w_number<1>)
    static constexpr auto w_state(w_number<tuple_size<
                decltype(w_state(w_number<255>()))>::value + 1> n)
        -> decltype(tuple_cat(w_state(n.prev()), make_tuple(&Foo::xx)))
    { return tuple_cat(w_state(n.prev()), make_tuple(&Foo::xx)); }

    int yy();

    // add &Foo::yy to the state by defining w_state(w_number<2>)
    static constexpr auto w_state(w_number<tuple_size<
                decltype(w_state(w_number<255>()))>::value + 1> n)
        -> decltype(tuple_cat(w_state(n.prev()), make_tuple(&Foo::yy)))
    { return tuple_cat(w_state(n.prev()), make_tuple(&Foo::yy)); }

// Use that state
constexpr auto FooMetaObject = buildMetaObject(Foo::w_state(w_number<255>()));

This is working pretty well. At the end of this simplified example, our state is a std::tuple containing &Foo::xx and &Foo::yy, from which we could build the meta object. (In the real implementation, the state is a bit more complicated and contains more data)

This works because the call to w_state(w_number<255>())) that we use to get the size of the tuple, is referring to the previous declaration of w_state. Since our current function is not yet defined yet, the most appropriate function is the remaining one with the highest number.
Notice that we have to repeat the same code in the decltype and after the return and we cannot use return type deduction because we need to use that function before the class is fully defined.

So far so good. However, I've hit what I think is a compiler bug when doing that with class template (eg, Foo would be template<typename> Foo). For this reason, instead of using static functions, I have used friend functions in verdigris. The principle is exactly the same. It is not well-known, but friend functions can be declared inline in the class, despite still being global functions. (I've also used that fact in the implementation of Q_ENUM)
One just needs to add a type which relates to the current class as an argument. I use a pointer to a pointer to the class instead of just a pointer because I don't want potential pointer conversion when calling it with a derived class.

class Bar {

    // init the state  (expanded from W_OBJECT)
    friend constexpr tuple<> w_state(Bar **, w_number<0>) { return {}; }

    int xx();

    friend constexpr auto w_state(Bar **t, w_number<tuple_size<decltype(w_state(
            static_cast<Bar**>(nullptr), w_number<255>()))>::value + 1> n)
        -> decltype(tuple_cat(w_state(t, n.prev()), make_tuple(&Bar::xx)))
    { return tuple_cat(w_state(t, n.prev()), make_tuple(&Bar::xx)); }

    int yy();

    friend constexpr auto w_state(Bar **t, w_number<tuple_size<decltype(w_state(
            static_cast<Bar**>(nullptr), w_number<255>()))>::value + 1> n)
        -> decltype(tuple_cat(w_state(t, n.prev()), make_tuple(&Bar::yy)))
    { return tuple_cat(w_state(t, n.prev()), make_tuple(&Bar::yy)); }

// Use that state
constexpr auto BarMetaObject = buildMetaObject(w_state(static_cast<Bar**>(nullptr), w_number<255>()));


Please let me know when you find Verdigris useful or want to help out, either here in the comments or contribute directly on GitHub.

February 14, 2018

After the initial release of Plasma 5.12 was made available for Artful 17.10 via our backports PPA last week, we are pleased to say the the PPA has now been updated to the 1st bugfix release 5.12.1.

The full changelog for 5.12.1 can be found here.

Including fixes and polish for Discover and the desktop.

Also included is an update to the latest KDE Frameworks 5.43.

Upgrade instructions and caveats are as per last week’s blog post, which can be found here.

The Kubuntu team wishes users a happy experience with the excellent 5.12 LTS desktop, and thanks the KDE/Plasma team for such a wonderful desktop to package.

Last week the Ceph Day Germany took place at Deutsche Telekom in Darmstadt. Around 160 people took part in the event and attended the talks of the 13 speakers over the day.

It was a great day with a lot of discussions, feedback and networking for the Germany/European Ceph community. The event ended in a networking reception with drinks and fingerfood, planed for an hour but actually ended after nearly two.

A big thank you to the sponsors (SUSESAPDeutsche Telekom AGTallenceIntel42on.comRed Hat and Starline) which made the event possible. The same applies to the speakers and attendees, without you it would have been a meaningless event. A special thank you to Danielle Womboldt from Red Hat for all the organisational help and Leo as the Ceph community manager.

We didn't manage to record all sessions due to technical problems, but the most of them. You can find the videos and slides from the speakers in the agenda of the Ceph day or directly in the following Google Drive folder. We will upload the recordings also to the Ceph YouTube channel later. There is also a subfolder with some impressions of the day.

I'm proud that we hosted the event. If you could not attend or would like to learn more about the community I recommend to attend to the next Ceph Day in London in April 2018. See you next time and at the Cephalocon APAC next month in Beijing.

Today is "I Love Free Software Day"!

We're celebrating by shining a spotlight on our contributors and on our collaboration with other FOSS communities and organizations. Free Software is an integral part of our lives, and it's important to show appreciation, support, and gratitude to everyone who works on making it better every day.

One of those people is Franklin Weng, a KDE contributor who started his Free Software journey by translating Kalzium. Franklin's contributions led him to amazing opportunities and projects. Read on to find out why he loves KDE so much.

Kalzium – The Start of An Amazing Journey

by Franklin Weng

When I was a high school student, chemistry was not my cup of tea. My grades in chemistry were not bad either, but I hated memorizing those organic compounds. Then, I decided to major in computer science at university, and from that moment, destiny tightly bonded me and Free and Open Source Software.

Around 2001 or 2002, I started to use and later contribute to KDE. However, Kalzium is the start of another amazing story for me. It happened in 2007...

A throwback to the old look of Kalzium - in Chinese!

I started translating KDE software around 2005. At the time, the Traditional Chinese language packages had almost been abandoned by KDE because of the very slow translation rate. Some senior FOSS community members called to others to "save" Traditional Chinese, and finally we did. From that moment on, I kept translating KDE because I simply asked myself: "Since I'm using this desktop environment, why not do it?"

So I translated everything in KDE. Everything. I started with KMail because I wanted a mail client that would reside in my system tray. Then I translated more KDE PIM applications, KDE Multimedia, KDE Graphics, KDE Games,... even KOffice. And of course, KDE Edu applications - from the simple, lovely ones, like KTuberling, KTouch, and KHangman, to huge ones like KStars and KGeography (that last one is enormous). Kalzium was just another one for me; I even translated KMyMoney - without any accounting background.

Then in 2007, I got an email.

Franklin's credits as the translator of the app.

"I saw you translated the Kalzium software. Could we meet and talk about that?"

That email was from my now friend, Eric Sun, who was (and still is) the Executive Secretary of the Open Source Software Application Consulting Center (OSSACC), a project launched by the Ministry of Education in Taiwan. The project promotes free software for use in primary and high schools. At first I had no idea why this guy would like to meet me. Would he discuss chemistry with me? I wasn't a chemistry-aholic at all!

We met at a Burger King in Taipei. He introduced himself and told me about his idea, which made me appreciate him a lot! He, as the Executive Secretary and also an FOSS enthusiast like me, wanted to introduce educational Free Software applications to teachers and students to help them acquire knowledge from many different fields, without any financial cost.

To promote those Free Software applications, the first step is, of course, to localize them. Teachers and students, especially in primary schools, would never accept software with English interfaces. He noticed that there had been some software with Traditional Chinese translations, and he was curious about who did it. Bingo! It was me.

This is what Kalzium looks like these days.

We started a series of plans. The main plan was a customized Linux distribution named ezgo - which I have already introduced here in October of 2013.

After that, we have also done a lot of work together, mostly introducing public domain educational resources, including FOSS to schools. I became one of KDE e.V. members and the president of the BoD of Software Liberty Association Taiwan, an NPO which promotes FOSS in Taiwan. In recent years, we have helped Taiwan governments to migrate to LibreOffice and ODF.

Thinking about the past 10 amazing years on the road of promoting FOSS, the start point was that I translated Kalzium. Of course, I wasn't aware that contributing translations to KDE would give me such an amazing tour in my life. Nevertheless, I always use this as an example to tell my young friends in Taiwan: "See? Chemistry is not my thing, but translating Kalzium (and many other KDE applications) made my life wonderful!"

Big thanks to Franklin for contributing to KDE for so many years, and for spreading the word about our software and its educational potential!

Do you have a story about how you fell in love with KDE? Let us know in the comments!

New year, new Kube =)

  • Setup a clearer structure for the application with “Views” as the highest level components (composer, conversation, addressbook, log, accounts).
  • Made sure that individual views are self contained and can be launched using qmlscene. This is not only good for modularity, but simplifies the workflow when working on the UI.
  • Improved the test and prototyping infrastructure: Blogpost
  • A little investigation in where all the memory goes: Blogpost
  • Added an extension mechanism that allows us to easily experiment with new views, without compromising the main application.
  • Support to unlock kube from the commandline as a poor-mans keyring integration.
  • A rather large cleanup of encryption related code used in the message parser got rid of over 1k SLOC.
  • The encrypted/signed state of a mail is now properly visualized.
  • A storage upgrade mechanism was added (Although upgrading for now means removing all local data).
  • Large payloads are no longer stored externally but inline in the database. Tests have shown that this is not less performant, but improves the fault resiliency and simplifies the system.
  • A first version of Xapian based fulltext search for local content just landed (Blogpost will follow).
  • As always, a variety of bugfixes.

Kube Commits, Sink Commits

Previous updates

More information on the Kolab Now blog!

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

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

February 13, 2018

I’m starting a new blog and this is the first post.

I’ll try to write about the things I do in the open source communities I’m involved in (openSUSE, SUSE, KDE, etc.). I also plan to write about other personal projects I work on and about development languages, technology, Linux and Free Software in general.

I hope I can keep it interesting ��

February 12, 2018

With the new Plasma LTS came an update to KDE neon LTS Edition and lots of people asking which edition to use and what the difference is.  This caused us to review the purpose of LTS and as a result we’ve just hidden LTS from the download page.  The only difference with the LTS edition is that it stays on Plasma’s LTS release but apps and libraries still get updates.  This doesn’t fit well with the main use cases of an LTS which is that it only gets bug fixes and no new features.  Further we test Neon LTS edition less than any other edition so it’s more likely we’ll miss some problem, which is the opposite of what most people would expect. There are distros whose release model fits better with the needs of Plasma LTS but the constant updates of Neon don’t fit too well.  We’ll keep the edition around and don’t expect to make any changes to the repositories or builds, they’re useful for devs testing Plasma LTS, but we’re not advertising it for download since it gives a different expectation of what to expect than fits into the release method of Neon.


KMarkdownWebView 0.5.0 has been released.

Example: KMarkdownWebView KParts plugin used by Ark (using Oxygen theme for some retro look �� )

The KMarkdownWebView software is for the rendered display of Markdown documents, using web technologies. It implements a C++/Qt-based wrapper around a local webpage with a JavaScript library (“marked”) which creates HTML from the plain text in Markdown format passed in.
The software contains

  • a KParts plugin for rendered display of Markdown files, which enables KParts-using applications (like the archiving tool Ark or the file manager Krusader) to show Markdown files in the target format.
  • a Markdown file KIO thumbnail generator plugin, which allows KIO-powered file managers & dialogs to show thumbnails and previews of files in Markdown format in the target format (currently only available when building against QtWebKit)

The KMarkdownWebView KParts plugin is also prepared for improved experience with the KTextEditor Document Preview plugin for KTextEditor-based applications like the editor Kate and IDE KDevelop.

KMarkdownWebView can be built with either QtWebEngine (preferred by the build system) or QtWebKit. Pass -DUSE_QTWEBKIT=TRUE to CMake to enforce the use of QtWebKit.

Changes since 0.4.0

  • Update of “marked” source copy to latest release v0.3.12
  • Translations updated for some languages (fi, fr, sl)

Download sources

Download from: https://download.kde.org/stable/kmarkdownwebview/0.5.0/src/

sha256: 84bcc4b2626109241633a52ee5cd203105fd2488277b478572a3a5b593d3de42 kmarkdownwebview-0.5.0.tar.xz

Signed with my PGP key
E191 FD5B E6F4 6870 F09E 82B2 024E 7FB4 3D01 5474
Friedrich W. H. Kossebau

February 11, 2018

This week involved a lot of visual polish, and we squashed quite a few bugs causing apps to appear pixellated when they should be crisp and sharp. There was more performance tuning, too, and of course general bugfixing and polish. Take a look!

  • Fixed a visual bug causing thumbnails in Folder View (i.e. desktop icons) to be pixellated and glitchy; they are now sharp and pretty (KDE bug 376848, fixed in Plasma 5.12.1):
  • Dolphin’s Ratings UI now looks good in HiDPI mode (KDE Phabricator revision D10324, improved in KDE Applications 18.04):
  • Fixed a visual glitch causing high-resolution or vector distro logos and the plasma logo in KInfoCenter to appear pixellated and glitchy in HiDPI mode; they are also now sharp and pretty (KDE bug 388633, fixed in KDE Plasma 5.12.1):
  • Fixed a bug causing Chromium and Chrome to always append “.bin” to the end of downloaded files for users of distros with old versions of Qt and/or the shared-mime-info package (KDE bug 382437, fixed in KDE Frameworks 5.44)
  • Network mounts from /etc/fstab, autoFS, or FUSE now show up under the “Network” category in the Places panel (KDE Phabricator Revision D10319, available in KDE Frameworks 5.43)
  • You can now use the F11 keyboard shortcut to toggle the aside preview pane in KDE open/save dialogs (KDE bug 389880, available in KDE Frameworks 5.43):
  • Alt+Enter keyboard shortcut now opens the Properties dialog for Folder View (i.e. Desktop icons) just like it does in Dolphin (KDE bug 389862, available in KDE Plasma 5.13)
  • Mouse wheel now scrolls the correct number of lines in Konsole when using the libinput driver (KDE bug 386762, fixes in KDE Applications 18.04)
  • The escape key now cancels out of the ctrl+tab tab switcher menu in Kate and KDevelop (KDE bug 389484, fixed in KDE Applications 18.04)
  • Spreadsheet files located on Google Drive accessed using Dolphin now open in the correct app (KDE bug 388598, fixed in kio-gdrive 1.2.2)
  • The Print Manager received an enormous amount of fixes and improvements (Available in KDE Applications 18.04)
  • Items in Kate’s Sessions applet are now sorted alphabetically (KDE Phabricator revision D10208, fixed in KDE Applications 18.04)
  • Gwenview now respects the window manager’s commands to enter and leave Full Screen mode (KDE Bug 195046, fixed in KDE Applications 18.04)
  • Dolphin’s git plugin (available in the dolphin-plugins package can now perform merge and log actions (KDE Phabricator revisions D10213 and D10267, available in KDE Applications 18.04)
  • Lots of UI polish for Discover, including making it and all other Kirigami apps look good in HiDPI mode (KDE bug 390076, fixed in KDE Frameworks 5.44)
  • Move and copy performance with large files has been dramatically improved (KDE bug 384561, improved in KDE Frameworks 5.43)
  • Even faster move and copy performance with many small files (KDE phabricator revisions D10085 and D10124, improved in KDE Frameworks 5.43 and KDE Applications 18.04)

KDE developers are really picking up momentum, and the improvements are coming very rapidly. It’s a fantastic time to get involved in something big!

Programadores e Wannabes, Eu estarei dando um curso gratuito de Qt dia 19 de fevereiro de 2018 na Unicamp, o local será no IC3 – Instituto de Computação – Lab 305.

Quem tiver interesse em participar, favor enviar um e-mail para tcanabrava at kde.org, o curso tera duracao de 8 horas e pegara um pouco de C++ e Muito de Qt

O horario do curso sera de 08 da manha as 18, e ofereceremos cerficicado para quem precisar.

.Fellow Hackers, I’ll be at Unicamp university in Campinas teaching Qt in a free course on the 19th of february, the course will take place in the IC3, Lab 305.

If anyone wanna join just e-mail me at tcanabrava at kde.org

February 10, 2018

Elisa is a music player developed by the KDE community that strives to be simple and nice to use. We also recognize that we need a flexible product to account for the different workflows and use-cases of our users.

We focus on a very good integration with the Plasma desktop of the KDE community without compromising the support for other platforms (other Linux desktop environments, Windows and Android).

We are creating a reliable product that is a joy to use and respects our users privacy. As such, we will prefer to support online services where users are in control of their data.

We have released the version 0.1 alpha 2 last week.

Screenshot_20180202_172327Elisa with Breeze Dark color theme

Now is really a good time to join the Elisa team. Alexander did quite a lot of changes to lower the barrier to entry. He is actively maintaining the community Elisa wiki page. We have plenty of small tasks open in Elisa workboard.

We also welcome other kind of contributions like design, graphics, promo, etc.

The project is trying to stay agile and to give users an easy way to follow our work by supporting distributions channels like binary-factory or the flatpak build of KDE applications. There are also some distributions with ways to build latest code as a package (Arch AUR).

The following things have been integrated in Elisa git repository:

  • Remove duplicated property in AbstractMediaProxyModel by Matthieu Gallien ;
  • Makes AllAlbumsModel use a thread for long operations in order to not block the UI by Matthieu Gallien ;
  • Reorder methods in mediaplaylist by Alexander Stippich ;
  • Fix comment about license of the documentation to match the one in kdoctools by Matthieu Gallien ;
  • Always explain that support for UPnP is currently broken by Matthieu Gallien ;
  • Add missing runtime dependencies to README.packagers by Matthieu Gallien ;
  • Add one missing dependency for packagers by Matthieu Gallien ;
  • Move application menu to own file by Alexander Stippich ;
  • Fix artist name in album view by Alexander Stippich ;
  • Use clearPlayList instead of extra code in qml by Alexander Stippich ;
  • Add dependency to readme and fix link by Alexander Stippich ;
  • Implement a filter view and play buttons for all views by Alexander Stippich ;
  • Remove duplicate MimeType entry in the desktop file by Robert-André Mauchin ;
  • Fixes warnings reported by clazy checker tool by Matthieu Gallien ;
  • Fix installation of elisa qml package for the configuration dialog by Matthieu Gallien ;
  • Small tweak to the qmlpackage for the elisa configuration module by Matthieu Gallien ;
  • Avoid crashing when invoked from dbus without a valid list of files to open by Matthieu Gallien ;
  • Unbreak the ability to configure shortcuts by Matthieu Gallien ;
  • Fix restore of playlist position on start by Matthieu Gallien ;

Elisa has moved to kdereview. The feedback from the different releases has motivated this move in order to be able to (if Elisa is accepted by the KDE community) make regular releases to allow user to give feedback.

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.