I’ll be at QtCon and Akademy in Berlin, mostly as observer, I guess
I’ll have also two workshops/discussions on Tuesday 6th (see ).
For some time now, there were threads  about designing a new music player. The VDG people came up with a vision and some first design ideas  and I built a first specification page on the community wiki .
I’ll do a workshop which will deal about:
The first 3 points will be mostly a presentation of what I want to do, with discussions about how it can be done better.
I already wrote some code, but it was mostly to make some experimentation, the project was put on hold until this Akademy session, in order to start on the right basis.
I also reserved a slot for KApiDox, the program that generates the api.kde.org website. The codebase changed a lot lately, and more and more projects are being generated. However, it’s still not very robust to errors (the whole process would break instead of just ditching the error source) and it appeared not to respond to every usercases.
If you think our API documentation is important and can/should be enhanced, please join the discussion so that I can know your needs (as API user or API writer) and enhance the whole thing in the future.
El mundo del Software Libre es tan grande y variado que en ocasiones me sobrepasa… y eso que dedico ingentes cantidad de tiempo a aprender sobre él y promocionarlo. Eso significa que en ocasiones hay entradas importantes que no aparecen o se publican tarde, como la que estáis leyendo. Y es que el Kernel Linux cumplió 25 años… y yo estaba de vacaciones y no pude celebrarlo con unas líneas. Es hora de corregir este error.
Lo cierto es que es difícil hacer una entrada sobre el 25 aniversario de Linux cuando la lista de ellas es inmensa. Así que he decidido hacer algo diferente: una recopilación de dichos artículos al tiempo que invito a los novatos leer una vieja entrada del blog donde se explicaba qué era eso del Kernel.
El proyecto Linux fue anunciado un 25 de agosto de 1991, su “padre” es Linus Torvalds, ahora es utilizado por millones de personas y que tiene millones de líneas de código, su valor en el mercado sería de billones de dólares, casi todas las supercomputadoras del mundo lo utilizan, es apoyado por empresas como de Intel, Red Hat, Samsung, IBM, AMD, Google o ARM, se solucionana casi 8 parches por hora cada día, Android lo utiliza, y aún así todavía no es habitual en los ordenadores personales de la mayoría de los usuarios.
De esta forma si queréis leer sobre los 25 años del Kernel Linux os aconsejo leer, sin que el orden sea sinónimo de importancia, los siguientes artículos, que es de donde he sacado toda la información del párrafo anterior, así como buena parte de las imágenes de esta entrada.
En definitiva, una fecha muy importante para todos aquellos amantes del Software Libre que demuestra un par de cosas: que la constancia es la clave del éxito y que los proyectos colaborativos son el futuro.
Colorpick is one of my little side-projects. It is a tool to select colors. It comes with a screen color picker and the ability to check two colors contrast well enough to be used as foreground and background colors of a text.
Three instances of Colorpick showing how the background color can be adjusted to reach a readable text.
The color picker in action. The cursor can be moved using either the mouse or the arrow keys.
I wrote this tool a few years ago, using Python 2, PyQt 4 and PyKDE 4. It was time for an update. I started by porting it to Python 3, only to find out that apparently there are no Python bindings for KDE Frameworks...
Colorpick uses a few kdelibs widgets, and some color utilities. I could probably have rewrote those in PyQt 5, but I was looking for a pretext to have a C++ based side-project again, so instead I rewrote it in C++, using Qt5 and a couple of KF5 libraries. The code base is small and PyQt code is often very similar to C++ Qt code so it only took a few 45 mn train commutes to get it ported.
If you are a Colorpick user and were sad to see it still using Qt 4, or if you are looking for a color picker, give it a try!
Today we are officially publishing the first stable release of KDE Connect. Hooray! This version is the most solid yet feature-packed version we ever released. It’s been in development for a year now and it took a lot of hard work, we hope you like it!
Pre-configure commands in the KDE Connect desktop settings so you can trigger them from your phone. Use it to extend KDE Connect’s functionality to suit your needs!
Probably the most awaited feature ever! Now when you receive a text message notification on the desktop, a ‘Reply’ button will allow you to text back without having to use your phone at all. Note you will need the version 1.4 of the Android app for this to work, already available, as we had to ask for a new permission for it to work.
Contributed by Holger Kaelberer, this is the counterpart of the phone-to-desktop notification sync we already had. It might be a bit spammy sometimes, so we decided to ship it disabled by default. Make sure you enable it both in the Android app and the System Settings module if you are interested in this feature. From the plugin settings you can choose which notifications you want to forward to your phone and which not.
Thanks to the Google Summer of Code project of Vineet Garg, KDE Connect now uses TLS sockets instead of RSA private-key encryption. This is not only safer against replay and man-in-the-middle attacks, but also faster and less battery-consuming to compute on your devices. Like SSH, we do trust-on-first-use (or TOFU, which sounds funnier) of the device certificate, and we have added a command line option to allow you to check the certificate fingerprints match on both ends.
If your favorite Linux distribution doesn’t release an update for KDE Connect 1.0 soon, please contact the distro packagers and let them know you want it! If you are familiar with building software from sources and can’t wait for your distro to package it, you can always build KDE Connect 1.0 from the sources available on download.kde.org.
While the Android app is backwards compatible with desktops running old versions of KDE Conect, the just released desktop version requires you to use the version 1.0 or newer of the Android app. Since we have seen that Android updates reach final users much faster than their desktop counterparts, this shouldn’t impact your ability to use KDE Connect. Just make sure you are using a recent version from F-Droid or the Play Store.
Freelance artist Nikolai Mamashev has launched an initiative to create an animated version of the open source webcomic “Pepper & Carrot” by David Revoy.
Many Krita users are already familiar with David Revoy and his work. His comic is produced mainly in Krita and all .kra files are freely available online for reuse and to make derivative works.
Nikolai’s idea is to bring David’s comic into new media by animating one episode of “Pepper & Carrot”.
For this work Nikolai will also be using Krita to convert static webcomic images into separate layers and to do all additional painting (which he expects there to be a lot of).
The animation work will be done in Blender, with the assistance of the CoaTools addon. Also, he plans to use Krita to create some frame-by-frame animation elements (lipsync, complex movements etcetera). The rendering management will be done with RenderChan.
Nikolai has published a video demonstrating the first two animated shots:
To make this project possible, Nikolai has launched a crowdfunding campaign. If this campaign is successful he will be able to create an animated version of Episode 6 of Pepper & Carrot, “The Potion Contest“!
The result is going to be published under the Creative Commons Attribution-ShareAlike license, together with all sources.
David Revoy says… “Nikolai draws better than I do! Support this work!”
The 2016 Krita sprint has finally begun in the beautiful city of Deventer, Netherlands this weekend. Artists, developers, testers, designers, and documentation writers are gathering from around the world to learn from each other and help define the future of Krita. The last big Krita meeting was in 2014, and now we’re meeting again!
Most of us the people at this year’s sprint are volunteers. Only Dmitry is working on Krita full-time and Boudewijn part-time. It’s good to have a real-life meeting when we can see each other’s faces, have lively discussions, and enjoy meals together.
People started arriving in Deventer yesterday, August 25. The weather is tropical for the first time this summer. We moved into a twelfth-century cellar under Boudewijn’s house where at least it’s cool! Usually the cellar is in use as the coffee room at the Orthodox Church — but not right now. There are plenty of space, tables, coffee cups and glasses for all of the sprint participants. Add internet and we have an instant hacking room!
On the first day these were some of the topics we discussed:
Just imagine this: Krita 3.0.1 will already have the first results of the Summer of Code work done by Wolthera — soft-proofing!And of course, there was dinner, and then more hacking!
We will be having a couple more people show up tomorrow. Some of the conversations won’t begin until tomorrow where things will really pick up speed.
Hoy os presento un nuevo plasmoide que nos ofrece una nueva barra de tareas o lanzador de aplicaciones para Plasma 5. Se trata de Now Dock, un precioso lanzador de aplicaciones que se integra a la perfección en el estilo del escritorio de la Comunidad KDE.
De la mano de Psifidotos nos llega un plasmoide que siempre he pensado que le hacía falta a Plasma 5. Se trata de Now Dock un plasmoide que nos proporciona una lanzadera para nuestros programas favoritos muy al estilo Mac. No es que me guste mucho personalmente (en realidad soy muy clásico) pero creo que para crear escritorios Plasma bellos un lanzador de estas características es necesario.
Como podemos ver en la imagen superior, se trata de una barra sobre la cual se disponen los iconos de las aplicaciones, los cuales tienen un comportamiento dinámico con zoom y con puntos de señalización por si están activos.
Las características básicas son las siguientes:
Requiere Plasma Desktop 5.7.0 o superior, y el creador recomienda utilizar temas con paneles transparentes para una mejor integración, como puede ser MX Theme. Además él ha desactivado los efectos Blur.
Por cierto, también se adapta bien a una posición lateral.
Más información: KDE Look
Para los no iniciados en el blog, quizás la palabra plasmoide le suene un poco rara pero no es mas que el nombre que reciben los widgets para el escritorio Plasma de KDE.
En otras palabras, los plasmoides no son más que pequeñas aplicaciones que puestas sobre el escritorio o sobre una de las barras de tareas del mismo aumentan las funcionalidades del mismo o simplemente lo decoran.
To celebrate the release of KDevelop 5 we’ve added KDevelop 5 to KDE neon User Edition. Git Stable and Git Unstable builds are also in the relevant Developer Editions.
But wait.. that’s not all.. the package manager Muon seem to have a new maintainer so to celebrate we added builds in User Edition and Git Unstable Developer Edition.
Plasma 5.7.4 has been out for some time now so it’s well past time to get it into Neon, delayed by a move in infrastructure which caused the entire repository to rebuild. All Plasma packages should be updated now in KDE neon User Edition.
Want to install it? The weekly User Edition ISO has been updated and looks lovely.
There is new mobile IMG update, this brings,
You can flash using instructions at https://plasma-mobile.org/nexus-5/
Plasma 5.8 will bring an improvement fixing a bug reported more than a decade ago. Back then Plasma did not even exist, the bug is reported against an early KDE 3 version. The addressed problem is the handling of panels on multi-screen setups.
This is if one has multiple screens and tries to put a panel between two screens – on the shared edge – the panel does not have a “strut” set and thus windows maximize below it:
[------------][------------] | ||P | | 1 ||P 2 | | ||P | [------------][------------]
In this illustrated setup the panel is “P” and windows on screen 2 ignore the panel. What might be surprising here is that this was not just a bug, but deliberate behavior. There is code making sure that the panel on the shared edge gets ignored. Now one doesn’t write code to explicit break useful features, there’s obviously a good reason for that.
And to understand that we must look at how panels and there struts work. First let’s look at Wayland. Wayland doesn’t have a concept for panels or struts by default. KWin provides the PlasmaSurface interface which Plasma can use to give a window the role “Panel” and to describe how the panel is used: whether it’s always on top, or whether windows can cover it or go below. KWin can use that to decide whether the panel should have a strut or not. Thus on Wayland KWin was able to support the setup shown above since it supports panels.
On X11, though, we have the NETWM spec which describes how to set a partial strut:
The purpose of struts is to reserve space at the borders of the desktop. This is very useful for a docking area, a taskbar or a panel, for instance. The Window Manager should take this reserved area into account when constraining window positions – maximized windows, for example, should not cover that area.
The start and end values associated with each strut allow areas to be reserved which do not span the entire width or height of the screen. Struts MUST be specified in root window coordinates, that is, they are not relative to the edges of any view port or Xinerama monitor.
Now here we see already the problem: it’s not multi screen aware. The strut is specified in root window coordinates. So in our case above we would need to set a strut for the left edge which spans the complete height. So far so good. But the width of the strut must be specified in root window coordinates which includes the complete screen 1. If Plasma would set this, we would have a problem.
In Plasma 5.7 KWin’s strut handling code got slightly reworked to perform sanity checks on the struts and to ignore struts affecting other screens. Basically KWin broke the implementation of given spec and in multi-screen setups only allows struts which make sense.
Now at least KWin could handle this situation properly, but Plasma still has the check to not set a strut on shared edges. For Plasma 5.8 we now changed the condition: if the window manager is KWin we allow such struts. For any other window manager we still go with the previous solution. We still think that we cannot just set a strut which would in the worst case exclude a complete screen. As that’s how the spec is written, we need to assume the window manager is standard compliant. For KWin we know that it is not standard compliant any more and support such struts, so Plasma can make use of it.
This change hopefully improves the multi-screen experience for our Plasma users who use KWin as a window manager.
En muchas ocasiones es más interesante ver un vídeo que leer un artículo, sobre todo si eres novato o quieres descubrir opciones de personalización del escritorio más completo del mercado. Es por ello que me parece muy interesante el vídeo “Personalizando Plasma” un vídeo demostrativo donde podemos ver algunas de las posibilidades de nuestro escritorio favorito.
De la mano de Gianni de Leon nos llega un vídeo de casi 20 minutos bastante interesante, sobre todo para aquellas personas que empiezan su andadura en Plasma 5. Por cierto, en el momento de escribir este artículo el título no era del todo correcto ya que el escritorio de la Comunidad KDE se llama Plasma 5, es decir, no existe escritorio KDE 5.
A lo largo del mismo nos explica, mirando las opciones de las Preferencias del Sistema, acciones como:
En casi todas las opciones demuestra en vivo las opciones de incorporar todo tipo de temas para cualquier elemento gráfico.
En resumen, un buen vídeo donde se ve una pequeña muestra de toda la potencia del escritorio Plasma 5. Si os ha gustado, apoyad este tipo de iniciativas con un like o con un comentario de agradecimiento.
It’s august and probably you are on holiday, life seems beautiful and you hope this period never ends, but… Happy or not September is about to arrive, and your daily routine is too. Don’t be afraid though: in these months the WikiToLearn community is working hard to provide you the best WikiToLearn you’ve seen so far.
From a brand new homepage to a better organization for news and social pages: you’re going to love it! September is not that sad though: why? If the new WikiToLearn isn’t enough for you, probably Akademy is: the annual word summit of KDE, this year happening in Berlin with QtCon, is one of the greates events for FOSS and we are taking part to it! Why is it so special for us? First of all because we’re part of the KDE community and we are looking forward to meet other members, share opinions and help each other, but also because this period is going to be special: KDE has its 20th birthday while Free Software Foundation Europe and VideoLAN both have their 15th birthday. Not over yet: you know who’s celebrating its birthday too in the same period? WikiToLearn!
During these months we worked hard to create local communities, to spread the word about our project, to give more attention and help to new users and to come up with a better communication plan that allows you to be always up to date on what’s going on in our community. September is not that far and it’s full of great news, get ready and prepare yourself!
Watch out: #wtlatakademy #wtlbirthday and others can become viral on our social pages in few weeks, we’re going to Akademy!
I’m going to Akademy! Akademy 2016, as part of QtCon, that is. I missed last year in A Coruña because it conflicted with my family summer vacation, but this year is just fine (although if I was a university student I’d be annoyed that Akademy was smack-dab in the middle of the first week of classes — you can’t please everyone).
Two purely social things I will be doing are baking cookies and telling stories about dinosaurs. I have a nice long train ride to Berlin to think of those stories. But, as those of you who have been following my BSD posts know, the dinosaurs are not so backwards anymore. Qt 5.6 is doing an exp-run on FreeBSD, so it will be in the tree Real Soon Now ™, and the Frameworks are lined up, etc. etc. For folks following the plasma5 branch in area51 this is all old hat; that tends to follow the release of new KDE software — be it Frameworks, or Plasma, or Applications, or KDevelop — by a few days. The exciting thing is having this all in the official ports tree, which means that it becomes more accessible to downstreams as well.
Er .. yeah, dinosaurs. Technically, I’m looking forward to talking about Qt on BSD and KDE Plasma desktop and other technologies on BSD, and about the long-term effects of this year’s Randa meeting. I have it on good authority that
KDE Emerge^W Runda^W KDE Cauldron is being investigated for the BSDs as well.
Plasma 5.8 will be our first long-term supported release in the Plasma 5 series. We want to make this a release as polished and stable as possible. One area we weren’t quite happy with was our multi-screen user experience. While it works quite well for most of our users, there were a number of problems which made our multi-screen support sub-par.
Let’s take a step back to define what we’re talking about.
Multi-screen support means that connecting more than one screen to your computer. The following use cases give good examples of the scope:
The idea is that the user plugs in or starts up with that configuration, if the user has already configured this hardware combination, this setup is restored. Otherwise, a reasonable guess is done to put the user to a good starting point to fine-tune the setup.
This is the job of KScreen. At a technical level, kscreen consists of three parts:
At an architectural level, this is a sound design: the roles are clearly separated, the low-level bits are suitably abstracted to allow re-use of code, the API presents what matters to the user, implementation details are hidden. Most importantly, aside from a few bugs, it works as expected, and in principle, there’s no reason why it shouldn’t.
So much for the theory. In reality, we’re dealing with a huge amount of complexity. There are hardware events such as suspending, waking up with different configurations, the laptop’s lid may be closed or opened (and when that’s done, we don’t even get an event that it closed, displays come and go, depending on their connection, the same piece of hardware might support completely different resolutions, hardware comes with broken EDID information, display connectors come and go, so do display controllers (crtcs); and on top of all that: the only way we get to know what actually works in reality for the user is the “throw stuff against the wall and observe what sticks” tactic.
This is the fabric of nightmares. Since I prefer to not sleep, but hack at night, I seemed to be the right person to send into this battle. (Coincidentally, I was also “crowned” kscreen maintainer a few months ago, but let’s stick to drama here.)
So, anyway, as I already mentioned in an earlier blog entry, we had some problems restoring configurations. In certain situations, displays weren’t enabled or positioned unreliably, or kscreen failed to restore configurations altogether, making it “forget” settings.
Debugging these issues is not entirely trivial. We need to figure out at which level they happen (for example in our xrandr implementation, in other parts of the library, or in the daemon. We also need to figure out what happens exactly, and when it does. A complex architecture like this brings a number of synchronization problems with it, and these are hard to debug when you have to figure out what exactly goes on across log files. In Plasma 5.8, kscreen will log its activity into one consolidated, categorized and time-stamped log. This rather simple change has already been a huge help in getting to know what’s really going on, and it has helped us identify a number of problems.
A tool which I’ve been working on is kscreen-doctor. On the one hand, I needed a debugging helper tool that can give system information useful for debugging. Perhaps more importantly I know I’d be missing a command-line tool to futz around with screen configurations from the command-line or from scripts as Wayland arrives. kscreen-doctor allows to change the screen configuration at runtime, like this:
Disable the hdmi output, enable the laptop panel and set it to a specific mode
$ kscreen-doctor output.HDMI-2.disable output.eDP-1.mode.1 output.eDP-1.enable
Position the hdmi monitor on the right of the laptop panel
$ kscreen-doctor output.HDMI-2.position.0,1280 output.eDP-1.position.0,0
Please note that kscreen-doctor is quite experimental. It’s a tool that allows to shoot yourself in the foot, so user discretion is advised. If you break things, you get to keep the pieces. I’d like to develop this into a more stable tool in kscreen, but for now: don’t complain if it doesn’t work or eat your hamster.
Another neat testing tool is Wayland. The video wall configuration you see in the screenshot is unfortunately not real hardware I have around here. What I’ve done instead is run a Wayland server with these “virtual displays” connected, which in turn allowed me to reproduce a configuration issue. I’ll spare you the details of what exactly went wrong, but this kind of tricks allows us to reproduce problems with much more hardware than I ever want or need in my office. It doesn’t stop there, I’ve added this hardware configuration to our unit-testing suite, so we can make sure that this case is covered and working in the future.
QtCon is happy to welcome Julia Reda, the closing keynote speaker. Member of the European Parliament for the Pirate Party and Vice-Chair of the Greens/European Free Alliance. Reda's legislative focus is on copyright and internet policy issues.
As a member of the European Parliament and together with Max Andersson, Julia Reda initiated the pilot project “Governance and quality of software code – Auditing of free and open source software” in 2014 as a reaction to the so-called “heartbleed” bug in OpenSSL. The idea turned into the pilot-project "Free and Open Source Software Auditing“ (FOSSA) that is aiming at improving the security of those Free Software programs that are in use by the European Commission and the Parliament.
Although the implementation of this project did receive some feedback for improvement, Reda will explain why this project is important and how it takes use one step further towards understanding FLOSS as a public service: "If free/libre open source software belongs to the public, the public needs to take responsibility for it."
Julia Reda's talk will leave participants at QtCon with an inspiring and forward-looking talk about Free Software, security and public responsibilty.
Happening on: Sunday, 2016-09-04, 15:45 - 16:45 CEST, BCC Germany
Today I want to talk about the .ssh/config file, for who don’t knows about it is the configuration file for SSH to customize options to connect with SSH.
The issue with this file is: it don’t supports some kind of “include”, this can be an issue if you have to write long config file.
I wrote a bit of shell script to workaround this (you can see the script here https://quickgit.kde.org/?p=scratch%2Ftomaluca%2Fssh-build-config.git).
This script creates the .ssh/config reading slice of config from .ssh/config.d/ in order and recursively.
I hope to be helpfull for someone.
There is an handy tool to take advantage of Electron technology and make “native” apps from an URL, Nativefier:
npm install nativefier -g nativefier "https://example.com"
(you just need npm package manager to install it)
It will make a folder in your Home with the executable in it:
This is how Google+ looks for example:
Zero differences compared to Chrome/Chromium web app apparently, but the RAM used is much lower:
You also get a better integration with the desktop enviroment, for example clicking on a link open the default browser, not necessarily Chrome/Chromium, and native notifications:
For example I used some CSS rules to add a Breeze style to Diaspora*:
I’m going to build more apps. Ciao!
Almost two years after the release of KDevelop 4.7, we are happy to announce the immediate availability of KDevelop 5.0!
While the release announcement on kdevelop.org is kept short intentionally, this blog post is going more into depth, showing what's new in KDevelop 5.0.
We replaced our legacy C++ parser and semantic analysis plugin with a much more powerful one that is based on Clang from the LLVM project.
A little bit of history: KDevelop always prided itself for its state of the art C++ language support. We introduced innovative code browsing functionality, semantic highlighting and advanced code completion, features that our user base has come to rely upon for their daily work. All of this was made possible by a custom C++ parser, and an extremely complex semantic analyzer for the C++ language. Adding support for all the quirky corner cases in C++, as well as maintaining compatibility with the latest C++ language standards such as C++11, drained our energy and stole time needed to improve other areas of our IDE. Furthermore, the code was so brittle, that it was close to impossible to improve its performance or add bigger new features such as proper C language support.
Now, after close to two years of work, we finally have a solution to this dilemma: A Clang based language plugin. Not only does this give us support for the the very latest C++ language standard, it also enables true C and Objective-C language support. Furthermore, you get all of the immensely useful compiler warnings directly inside your editor. Even better, fixing these warnings is now often just a matter of pressing a single button to apply a Clang provided fix-it!
There are, however, a few caveats that need to be mentioned:
Another screenshot to make you want to try KDevelop 5.0 instantly:
(KDevelop analyzing doxygen-style code comments)
For the best C++ experience in KDevelop, we recommend at least Clang 3.8.
We removed the hand-written CMake interpreter and now leverage meta data provided by upstream CMake itself. The technology we're building upon is a so called JSON compilation database (read more about it in this insightful blog post). Technically, all you need to do is to run cmake with the
-DCMAKE_EXPORT_COMPILE_COMMANDS flag, and CMake will take it from there, emitting a compile_commands.json file into your build directory.
KDevelop now supports reading those files, which is way more reliable than parsing CMake code ourselves.
But this step also means that we had to remove some of the useful advanced CMake integration features, such as the wizards to add files to a target. We are aware of this situation, and plan to work together with upstream to bring back the removed functionality in the future. Hopefully, you agree that correctness and much improved performance, where opening even large CMake projects is now close to instant, makes up for the loss of functionality.
With KDevelop 5, we decided to officially include support QMake projects, too. Same story here, this functionality has been worked on for years and we now start to officially support them.
The new KDevelop plugin for QMake is simplistic but already super useful for many projects. If you are using more complicated QMake features and want to improve our interpreter, please get in touch with us!
Together with all this, KDevelop 5 will continue to officially support Python 3 and PHP. In our playground we also have support for Ruby, and there are plans to integrate basic Go and Rust support. If you are interested in improving support for any of these languages in KDevelop, please step up and start contributing!
Another major thing we worked on was rethinking KDevelop’s assistant popup; especially in the current 5.0 betas, it tended to be a bit annoying and got in the way a lot. We thus removed the assistant overlay in favor of offering executions of assistants from the navigation widget.
Here's a screenshot of the assistants in form of a navigation widget:
Thanks to Sebastien Speierer we got a super useful feature into KDevelop 5.0: Widget coloring based on an items affinity to a project.
A picture is worth more than a thousand words, see it in action here:
As you can see, both the project explorer rows as well as the document tab bar items are colored based on the project affinity. This is useful to quickly decide which project a specific file belongs to.
(Note this feature is optional, it's possible to enable/disable in settings)
We added support for tracking the progress of make/ninja jobs in KDevelop, we do so by simply parsing the first few chars of the output of make and ninja. For make, this will only work for Makefiles generated by CMake so far, as those contain proper progress information). Thus, this feature won't work when make is invoked on Makefiles generated by QMake.
The progress bar on the bottom right indicates the progress of the ninja invokation. Extra gimmick: Starting with Plasma 5.6, this progress is also indicated in the task bar entry of your task switcher in the Plasma shell.
The welcome page (the widget which is shown whenever you have no tabs open in KDevelop) got redesigned to better match the current widget style in use). Screenshot:
Debugger support is KDevelop's unloved child, but it got some improvements in 5.0, and will get quite a few improvements in the upcoming 5.1 release (due to the LLDB GSoC happening, which also touches lots of debugger agnostic code).
Debugger support in 5.0 was improved by simply streamlining the debugger related widgets where possible.
For performance reasons the splash screen got removed in 5.0. There's been a short discussion on the KDevelop development mailing list about the pros and cons, in the end we decided to drop it.
The reasons for dropping it were:
Just an excerpt:
Just to get you an idea how much work was put into the 5.0 release over the years:
kdevplatform% git diff --stat origin/1.7 v5.0.0 | tail -n1 1928 files changed, 65668 insertions(+), 73882 deletions(-) kdevelop% git diff --stat origin/4.7 v5.0.0 | tail -n1 1573 files changed, 131850 insertions(+), 30347 deletions(-)
If you're on Linux you can start using KDevelop right away, by downloading & running the new KDevelop 5.0 AppImage.
With KF5 overall cross-platform support of KDE applications got better by order of magnitudes. Tons of hours have been spent improving OS X and Windows support.
We hope to release an official OS X app bundle & a Windows installer package soon.
Read more about other installation instructions.
We're super proud to finally release KDevelop 5.0 to the public! We think it's a solid foundation for future releases.
With the use of Clang as the C++ support backend we hope to be able to put more energy into the IDE itself as well as other plugins instead of playing catchup with the C++ standard!
Happy to hear your opinions about KDevelop 5.0. What do you like/dislike?
KDevelop 5.0.0 release
This release announcement is kept short intentionally, to check out what's new in KDevelop 5.0, please read this blog post by Kevin.
The most prominent change certainly is the move away from our own, custom C++ analysis engine. Instead, C and C++ code analysis is now performed by clang. Aside from being much easier to maintain, this has a number of advantages:
Work on getting all our old utilities for C++ to work nicely with the new infrastructure is still ongoing in some areas, but most of the important things are already in place. In contrast to the C++ support, the Python support has not undergone any significant refactoring, but has instead seen further stabilization and polishing. The same is true for the PHP and QML/JS language support components.
Apart from those changes, KDevelop 5 has of course been ported to KDE Frameworks 5 and Qt 5. This will for the first time enable us to offer an experimental version of KDevelop for Microsoft Windows in the near future, in addition to support for Linux. Additionally, we offer experimental stand-alone Linux binaries, which make it much easier for you to try KDevelop 5 before upgrading your system-wide installation.
You can download the source code from here. The archives are signed with the following key ID: AC44AC6DB29779E6.
Along with KDevelop 5.0, we also release version 2.0 of the kdevelop-pg-qt parser generator utility; download it from here.
We also provide an experimental pre-built binary package which should run on any moderately recent linux distribution: Download AppImage binary for Linux (any distribution). After downloading the file, just make it executable and run it.
Update: We updated the AppImage (the new version is 5.0.0-1) and fixed a few issues with the packaging, esp. file and project templates not working. It also comes with kdev-php and the console toolview now.
Thanks to everyone involved in preparing the release!
We’ve made a new set of development builds in the road to Krita 3.0.1. Here are the most important bug fixes:
In other news, the Krita team will get together in Deventer, the Netherlands, this weekend to meet in person! We’ll be fixing bugs, discussing and planning new features and plans for new training videos and more!
On Windows, Krita supports Wacom, Huion and Yiynova tablets, as well as the Surface Pro series of tablets. The portable zip file builds can be unzipped and run by double-clicking the krita link.
Krita on Windows is tested on Windows 7, Windows 8 and Windows 10. There is only a Windows 64 bits build for now. Also, there is debug build that together with the DrMingw debugger can help with finding the cause of crashes. See the new FAQ entry. The Windows builds can be slower than usual because vectorization is disabled.
For Linux, we offer AppImages that should run on any reasonable recent Linux distribution. You can download the appimage, make it executable and run it in place. No installation is needed. At this moment, we only have appimages for 64 bits versions of Linux. This appimage has experimental desktop integration.
You can also get Krita from Ubuntu’s App Store in snap format. This version includes the translations for Krita itself. Install with
snap install --beta krita
Krita on OSX will be fully supported with version 3.1. Krita 3.0 for OSX is still missing Instant Preview and High Quality Canvas scaling. There are also some issues with rendering the image — these issues follow from Apple’s decision to drop support for the OpenGL 3.0 compatibility profile in their display drivers and issue with touchpad and tablet support. We are working to reimplement these features using OpenGL 3.0 Core profile. For now, we recommend disabling OpenGL when using Krita on OSX for production work. Krita for OSX runs on 10.9, 10.10, 10.11 and is reported to work on MacOS too.
Today is the deadline for submitting the final evaluations for Google Summer of Code 2016, that gives me the opportunity to write a wrap-up post about my project this summer.
GSoC’16 has come to an end and its time to report current status of my project ‘LabPlot: Theme Manager’. As the name suggests, project was aimed to develop a theme manager for LabPlot, which is a well known open source application mainly used for analyzing and visualizing scientific data.
There have been a lot of developments after the project’s mid-term evaluation period (previous results are discussed in my earlier blogs), as follows:
As a result, LabPlot is now equipped with a very well developed ‘Theme Manager’ providing a wide variety of 13 themes from basic to more advanced such as Solarized, SolarizedLight, DarkPastels, BlackOnWhite, BlueOnBlack, etc.(as mentioned above) and are also comparable to other existing applications. Currently, the Theme Manager has many useful functionalities such as application of themes on plots, saving personalized themes, uploading/downloading themes to share themes via web server (in progress). I believe current functionalities will make LabPlot a powerful tool to visualize scientific data as well as it will enrich the overall user experience and usability. Last but not the least, I am glad to say that I have successfully met all the proposed goals and deadlines as per my GSoC project proposal.
GSoc has been an amazing experience for me. As it was my first attempt at contributing to an open source project, I was amazed by the variety and quality of work carried out by the KDE community. Large number of developers and contributors working in parallel to produce interesting and extremely useful applications…It’s really motivating!
I would also like to thank my mentor Alexander Semke, who has been very responsive and supportive throughout my journey of GSoC. Along with the technical skills (Git, C++ concepts, understanding of Qt and KDE frameworks, visualization of themes + color palettes and color schemes), he also helped me to improve on my communication skills.
If interested, you can find the developments and code at this Github link: https://github.com/KDE/labplot/commits/thememanager?author=prakritibhrdwj
Please don’t forget to give me your feedback
It's been a while since my last blog post about Minuet but that doesn't mean we aren't moving it forward. Actually a lot of work has been done lately, mostly related to architecture improvements, UX revamping, refactoring, code convergence, and its availability on Android devices. Minuet is a quite recent KDE project (it's been developed since November, 2015) and I'm really delighted with what we achieved so far, given we are a small team made up of only two developers (including a GSoC student) and a designer.
So, keep reading for an overview on the improvements delivered in Minuet 0.2 (desktop version) and our journey towards the very first release of Minuet for Android devices :).
Minuet 0.1 already presented a somehow nice architecture, where all ear training exercises are defined in multiple JSON files, which are automatically merged by Minuet's core to make up the navigation menu. That makes it easy to maintain a huge number of exercises and add new ones with no changes in source code. Some technical debt regarding QML source code was identified though and, of course, challenges introduced by the advanced features we expect to address and the need to have Minuet running on other platforms (such as Android, iOS, and Windows) had to be properly tackled with a stronger and more flexible architecture.
The architecture improvements released in Minuet 0.2 address three fundamental aspects: JSON specification of ear training exercises, sound infrastructure, and UI/UX improvements.
In Minuet 0.1, exercises were defined in multiple JSON files, where intervals/chords/scales/rhythms were defined alongwith the exercises where they appeared as possible answers:
Although that allowed for defining new exercises with no changes in source code, music concepts definitions (e.g. the "Minor Second" and "Major Second" intervals) had to be duplicated in any other exercise category where they appear (e.g. in "Second and Thirds" and "Second to Octave" categories). That was a burden since it caused a lot of duplicated entries for those concepts appearing in multiple categories.
In Minuet 0.2, exercise specification JSON files were splitted in two different types: definitions JSON files and exercises JSON files. Definitions JSON files specify music content (scales, intercals, chords, and rhythm patterns) regardless of the exercise categories where they appear in:
In the new architecture, music content definitions are marked with any number of tags. Those tags are used by exercises JSON files to collect the definitions which will make up a given exercise category. That makes the definition of new exercises as simple as querying definitions by the tags they were marked with:
Note how any (sub-)category uses and-tags and/or or-tags to select the definitions marked with, respectively, all and/or any of the provided tags. Now, changes in definitions JSON files are propagated to all exercises JSON files. You can define any number of definitions and exercises JSON files, since both are merged into a single JSON file for each type.
Minuet 0.1 relied on Drumstick library to implement the required MIDI capabilities to play exercises. That not only yielded a high coupling between Minuet's core and Drumstick but also added a number of run-time dependencies, such as TiMidity++ and freepats. As a consequence, and in spite of a basic system sanity check executed at first Minuet's run, we still got some broken audio infrastructure in some installations.
The new architecture released with Minuet 0.2 totally decouples the sound infrastructure from Minuet's core and sound backends for different platforms are now implemented as Qt plugins. That enabled the move to using Fluidsynth + GeneralUser GS soundfont as Minuet Desktop's sound backend, with no run-time dependencies. Minuet Android's sound backend was built on top of CSound + sf_GMbank soundfont.
New Minuet sound backends can be easily created by implementing the Minuet::ISoundBackend interface:
The API is quite straightforward. The most important service is provided by prepareFromExerciseOptions(), where all required steps to initialize/create the audio representation of a given exercise option (a specific interval, scale, chord, or rhythm pattern) should be executed. After that, the exercise can be played by invoking the play() method. The methods setPitch(), setVolume(), and setTempo() should be also implemented to adjust, respectively, the overall pitch deviation, the playing volume, and the playing speed.
Minuet 0.2 is now totally based on QtQuickControls2 and, therefore, requires Qt 5.7 to build. The move to QtQuickControl2 is justified not only by its clean and simple API, but also because it allows for enhanced productivity and leverages code convergence. Enhanced UX and code convergence are ongoing efforts in Minuet, even though the codebase for Minuet Desktop and Minuet Android are already quite similar, differing only on the adopted sound backends.
We are glad to announce that Minuet 0.2 is available on Google Play Store.
Minuet for Android is the result of the nice work performed by Ayush Shash in Google Summer of Code 2016. After three months of intense work, struggling with different sound libraries for Android and diverse UX patterns for mobile applications, we are happy in making Minuet for Android available with all features already presented in its desktop counterpart.
The sound backend in Minuet for Android was implemented on top of CSound: a powerful domain-specific language for sound synthesis which works on Windows, OS X, Linux, Android, and iOS. Instead on using all those oscilators combinations and other complicated sound synthesis stuff, we again adopted soundfonts as audio samplers for CSound in Android.
Minuet for Android initial screen provides the user a simple dashboard with all top-level exercises categories. That allows for rapidly jumping to the subcategories which represents chords, intervals, rhythms, and scales ear training exercises. The UI is currently sticked to portrait mode in smartphones, although we're rethinking the UX strategy for tablets and larger devices.
A typical navigation drawer allows for the user to navigate through all exercise categories resulted from merging the available exercises JSON files. The source code responsible for loading and merging JSON files, creating the navigation menu, and dynamically exhibiting the exercise screen is 100% shared with Minuet Desktop.
Adapting the piano virtual keyboard to small form factors was a particularly challenging task. After some unsuccessful attempts, we ended up using some labels to identify the piano octaves, we constrained the visualization to a single octave and then implemented an automatic horizontal scroll to the keyboard region which encompasses the exercise being currently played.
The UI for running intervals, chords, scales, and rhythm patterns exercises is quite similar to Minuet Desktop's one. In order to keep it scalable for exercises with many available answers we implemented a vertical scroll inside "Available Answers" groupbox. The answer(s) selected by the user for a given exercise is(are) presented in the "Your Answer(s)" groupbox. Incorrect answers are shown with a red rectangle and can be clicked to have the associated right answer revealed.
As I mentioned before, Minuet is still on its infancy but I guess it's looking quite promising already :). Now, we'll concentrate our energies in merging remaining divergent code, stabilizing the architecture, making the last UI polishments and then work hard on providing really amazing music content. Addressing new platforms? Yes, that's also in our roadmap, hopefully :).
Minuet for Android wouldn't be possible without the support of the KDE community. Many thanks to Ayush Shah for the courage to brave this road, to Alessandro Longo for the amazing category icons, to the VDG team for valuable UI feedback, and to Aleix Pol for helping with Android cmake buildsystem.
Yeah! We are nearly one week away from QtCon. Dude, I'm excited to meet old friends and make new ones :) If you are heading Berlin and want to learn more about Minuet, I'll present a talk about it on Day 3 (saturday, 3rd September), at 3pm, in room A08.
( This post is related to my GSoC project with Marble. For more information you can read the introductory post )
As of now, If you load an openstreetmap file containing linestrings such as highways, lanes or streets, in Marble and zoom to level 11, you will find that the highways or streets are not contiguous and appear as broken.
You will find the roads/streets as broken
Instead of getting contiguous roads
One of the primary reasons for this discontiguity is that often a particular highway/lane/street is described using multiple contiguous OSM way elements instead of a single OSM way element. Marble treats each of these specific way element as a linestring object. However Marble omits rendering any objects which are smaller than 2px, in order to improve rendering performance. Due to this, many of the OSM way elements, which are smaller than 2px don’t get rendered. Hence the street appears broken since only those of its OSM way elements are rendered which are larger than 2px.
One of the reasons which I can think of and which justifies this highway description using multiple elements is that a street might be called by a certain name for a specific stretch and might be called by some other different name for the remaining stretch. However, at level 11 we are mostly concerned with the type of highways (primary, secondary, motorway , residential) rather than the specifics such as names.
Usually, the multiple OSM way elements of a single highway share the first and the last node ID references. For example consider <1n…2n> as an OSM way element where 1n and 2n corresponds to the first and last node IDs of the way. A highway described by an ordered list of node IDs 1 to 56 can then usually be represented by the following OSM way elements <1…5>, <5…13>, <13…28>, <28…36>, <36…56>
I exploited this way of representation to create a way concatenating module in the existing osm-module tool. For the above example, the module would concat all the 5 OSM way elements into a single OSM way element <1…56>
osm-simplify -t highway=* -w input.osm
The above command concatenates all the highways present in the input file and produces a new osm file as output.
Apart from solving the problem of discontinuity, way concatenation also results in data reduction since it is eliminating redundant node references and way elements. This data reduction in turn results in faster file parsing as well as improved rendering performance since now to render a single stretch of highway one only needs to create and render a single linestring object as opposed to multiple linestring objects.
The tricky part of coding this OSM way concatenator is actually coming up with an algorithm which concatenates all the linestrings present in an input file. Finally I and my mentors Dennis Nienhüser and Torsten Rahn were able to come up with a working algorithm for concatenating osm ways of a file in reasonable time (approximately O(n) time).
The algorithm involves a made up data structure called WayChunk which basically is a list of contiguous ways. It also stores a GeoDataVisualCategory which represents the type of linestring. For example in case of highways GeoDataVisualCategory will contain the kind of highway, whether it is a motorway, primary, secondary or a residential type of highway.
The algorithm utilizes a multi-hash-map to bundle together OSM way elements which share a common starting or terminating node. This multi hash map has nodeID’s as keys and WayChunk’s as the values. The idea is that at any given instant, this map will contain the starting and ending point of the ways which have been evaluated till now, as keys and the corresponding way chunk as the value pointed to by these keys. Now whenever we encounter a new way, and if it’s starting or ending node matches with any of the existing way chunks as well as the type i.e. GeoDataVisualCategory of the way matches with the type of the way chunk, then this way is added to the way chunk and the values of the map are adjusted so that the map’s keys are the starting or ending nodes of some way chunk and not the intermediary ones. This way, eventually, we are able to concat the multiple small OSM chunks of highways, railroads into singular way elements.
The reason we are using multi-hash-maps instead of regular hash maps is that at a particular node, two or more highways(linestrings) of different types may emanate or terminate. Hence a given node may be associated with two or more way chunks having different type(GeoDataVisualCategory).
The algorithm in more detail is described below:
Concat(input_osm_file): Iterate over all of the way elements having key=value tags specified during input Check if the first or the last node ID of the way is present in the multi-hash-map. If neither of the IDs are present CreateWayChunk(way) If only the first ID is present in the map Check if any chunk exsits in the map which has the key as that of first ID and GeoDataVisualCategory as that of the way. If such a chunk exists Append the way to this chunk accordingly(reverse the way if required) Delete the first ID from the map Insert a new entry into the multi map having the key as last node ID of the way and value as that of the found chunk If not CreateWayChunk(way) If only the last ID is present in the map Check if any chunk exsits in the map which has the key as that of last ID and GeoDataVisualCategory as that of the way. If such a chunk exists Append the way to this chunk accordingly(reverse the way if required) Delete the last ID from the map Insert a new entry into the multi map having the key as first node ID of the way and value as that of the found chunk If not CreateWayChunk(way) If both the IDs are present in the map Check if any chunk exsits in the map which has the key as that of first ID and GeoDataVisualCategory as that of the way. Check if any chunk exsits in the map which has the key as that of last ID and GeoDataVisualCategory as that of the way. If both the chunks exist Append the way and the second chunk to the first chunk and modify the map accordingly If only first chunk exists Append the way to the first chunk and modify the map accordingly If only last chunk exists Append the way to this last chunk and modify the map accordingly If none of the chunks exist CreateWayChunk(way) Finally iterate over all the WayChunks and merge the ways in each of their lists to form one single osm way for each chunk CreateWayChunk(way): Create a new WayChunk Append the way to this new way chunk Set the GeoDataVisualCategory of the chunk as that of the way Insert two new entries in the multi map having the starting and ending node IDs of the way as keys and the created WayChunk as the value.
The first image having discontiguous highways represents the raw input OSM file. This file has 2704 ways in total and has a size of 4.7 MB
The way-concatenator reduced the number of ways to 812 and the size to 2.9 MB. The second image having contiguous roads represent the output of the way concatenator.
If we remove the redundant nodes from the above output using the node reducing module described in the previous post, we get a resulting file having a size of 2.5MB. This node reducer removes 15146 redundant nodes (keeping the resolution at level 11).
If you suspect that due to node reduction there will loss in quality of rendering, then look at the below rendered image and compare it with the above ones.
The node reducer and the way concatenator have resulted in a size reduction of approx 46% for the above sample without any significant loss in rendering quality.
|Julia backend for Cantor in action|
Here goes slideshow demonstrating some of implemented features.
|Syntax highlighting based on known symbols|
|Syntax highlighting is working correctly in hard cases. New algorithm were ported also to Python highlighter|
|Variable management in action|
|Plotting wizard and inline plots|
This announcement is also available in Italian, Spanish and Taiwanese Mandarin.
The latest updates for KDE's Applications and Frameworks series are now available to all Chakra users, together with other package updates.
As always with a new series, Applications 16.08.0 ship with many changes, the most important ones being:
( This post is related to my GSoC project with Marble. For more information you can read the introductory post )
The requirement for medium level tiles are a little bit different from those of lower level tiles. The biggest difference being that the medium levels will use openstreetmap data as opposed to the Natural Earth data. Another difference is that in lower level tiles the major data pre-processing steps were concatenation and conversion since the data was in shapefile format and the requirement was that of OSM whereas in medium levels the major data-pre processing steps are reduction, simplification, filtration and merging.
As already mentioned in a previous post, openstreetmap describes data at a pretty high resolution. Such resolution is fine for higher levels such as street levels but cannot be suitably used for medium (and also lower levels). Hence data-preprocessing steps such as reduction to a lower resolution, filtering features such as trees and lamp posts which are not visible at medium levels , and merging of buildings and lanes which are very close to each other.
In order to pre-process data so as to reduce, filter, combine; various tools need to be built which modify the raw openstreetmap data so as to make it suitable for a particular Marble zoom level.
The first tool which I built removes redundant nodes from geographical features present in the input OSM file. Redundant nodes are the nodes which are just not required at a particular zoom level since the resolution with which these nodes describe their parent geographic feature exceeds the maximum resolution which is visible at a particular zoom level.
Consider this particular patch of lanes at zoom level 11.
Now observe the number of nodes with which this patch has been described.
A small square describes a single node. These squares are colored in a translucent manner so as to depict overlappings. Higher the intensity of the color, greater are the number of overlappings.
As you can clearly see, these many nodes are not required for proper rendering of OSM data at medium zoom levels. In order to overcome this problem, I wrote a node reducing module. This module is a part of osm-simplify which is an OSM data preprocessor jointly being developed by Dávid Kolozsvári and me which supports many different kinds of OSM data preprocessing such as clipping, tiling, way-merging(other simplification tools are still being developed)
osm-simplify -z 11 -n input.osm
The above command removes the redundant nodes according to the resolution of level 11 of Marble and produces a new reduced OSM file as output.
The underlying algorithm of this node reduction module is pretty simple
This simple tool results in significant removal of redundant nodes. The final goal is that this node reduction module along with other modules of osm-simplify tool will result in a significant size reduction of the OSM data for a particular zoom level resulting in improved rendering performance of Marble, without compromising much on the visual quality of the rendered data.
In the next post, I will describe about way-merging module as well as do a little bit of objective comparison of the reduction in size of OSM data caused by these modules.