April 18, 2018

Calamares is a distribution-independent (Linux) system installer. Outside of the “big five” distro’s, many smaller “boutique” distro’s need an installer, and Calamares is a highly configurable one that they can use. There’s a few dozen distro’s that I know of that use it (although I’ve only actually installed maybe six of them).

One optional feature — optional at the discretion of the distro which is deploying Calamares, that is — is the use of GeoIP location to find the time zone of the device being installed. This is used to automatically set the clock, for instance. If it’s not switched on, or there’s no network, Calamares defaults to a location defined by the distro — generally New York, although there’s an Austria-based distro that I think defaults to UTC.

For years, the default and suggested GeoIP provider has been freegeoip.net. That service is shutting down — well, being upgraded to a nicer API, at a different location, and with different access limitations. Older ISO images that have Calamares configured to use GeoIP with that service will cease to get usable GeoIP data on july 1st, 2018.

I don’t actually know which distro’s have GeoIP enabled, nor what provider they use.

However, the fact that this provider is shutting down prompted me to go over the existing code and make it more flexible and more general (prodding from Gabriel and Phil and Harald helped here as well). So Calamares is now ready to use more, and different, providers of GeoIP data. The providers can’t agree on using “time_zone” or “timezone” or “TimeZone” as the attribute (JSON) or element (XML) name where the data lives, so there’s a little bit more code and configuration needed. But you (as a distro) can now shop around and pick a GeoIP provider that respects your privacy.

I use to joke that the last week before foss-north is the worst – everything is done, all that is left is the stress.

This year, we have the broadest program yet. 25 speakers talking about everything from community policies, GPU isolation, blockchain, historical KDE software, retro computers, IoT, Android, SailfishOS, bug triaging, crowd funding, software updates, yocto, home automation, design to sub-atomic particles.

You can still get a ticket (and make sure to bring a friend) at foss-north . Welcome!

Esta semana va a estar muy centrada en el próximo evento de la Comunidad KDE. Y es que toca anunciar que Akademy-es de Valencia será protagonista del podcast de KDE España que emitiremos en directo y dejaremos grabado para la posteridad el próximo 24 de abril a las 22:00 hora española.

Akademy-es de Valencia será protagonista del podcast de KDE España

Del 11 al 13 de mayo se va a celebrar en Valencia Akademy-es 2018. A menos de un mes del evento es el momento de que varios integrantes del podcast de KDE España se reunan y comenten qué se espera de la reunión, realicen un repaso a las charlas que se llevaran a cabo y nos cuenten algunas de las anécdotas que han vivido en alguna de sus casi 15 anteriores ediciones.

Akademy-es de Valencia será protagonista del podcast de KDE España

Aprovecho la entrada para volver a decir que el registro es libre y que no cuesta NADA. Se hace para contar asistentes. Así, es más fácil organizar, comidas, espacios y eventos.

En otras palabras:

Regístrate

Para poder disfrutar del podcast en directo seguiremos utilizando los servicios de acontecimiento en vivo de Youtube y contestaremos, si podemos, vuestras preguntas en directo. Por cierto, este podcast será el octavo de la cuarta temporada, para los que les gusta la metainformación.

¡Os esperamos el martes 24 de abril a las 22:00!

Los podcast de KDE España

Ayúdanos a decidir el temaEn un afán de acercarnos más a todos los simpatizantes de KDE hace un tiempo que empezamos a realizar podcast. En ellos varios miembros de la Comunidad KDE de España nos reunimos para hablar un poco de los diversos proyectos.

Hemos hablado de muchos temas como por ejemplo Akademy, KDE Connect, Plasma Mobile, etc.

Podéis seguirnos en el canal de Youtube de KDE España o en Ivoox, donde estamos subiendo poco a poco los audios emitidos. Esperamos que os gusten.

April 17, 2018

The latest release of CMake has landed in FreeBSD. Prior to release we had good contact with KitWare via the bug tracker so there were few surprises left in the actual release. There were still a few last-minute fixes left, in KDE applications no less. Here is a brief summary of changes we made:

  • FindQt doesn’t match the way FreeBSD ports are built and installed, so we defer to QMake rather than looking for directories,
  • FindOpenMP gets a tweak because it won’t find the system pthreads library when gcc (for Fortran) is used,
  • FindBLAS gets a larger tweak because BLAS may need to link to libgcc_s, and which gcc_s that is needs to be figured out via ldd(1).

Some older patches have gone away because upstream has picked them up. Tweaks downstream, in package-building-terms, of cmake that were necessary:

  • check_include_files respects the required libraries, which can be a surprise when the required libraries have been found but not fully plugged into the build (e.g. missing -L flags).
  • the order of includes in automoc sources has changed, which reveals places where a C++ header file doesn’t actually include all of the headers it needs to fully define the types it uses; previously the include order might implicitly include them and the issue is papered over.

CPack now fully supports producing FreeBSD packages from a build / install tree by default, so for non-ports software which uses CMake, cpack -G FREEBSD does the right thing. Previously, this was a non-default tweak to CPack as built in FreeBSD ports.
Edit: as of CMake 3.11.0_1, CPack no longer supports producing FreeBSD packages. There were some unexplored corners of the build process that cause build failures when the FreeBSD pkg(8) support is enabled. So it’s off again until we shine some more light into those corners.

.. and a PS., CMake 3.11.1 has just been released, which reverts the change to check_include_files which I’d been working around.

DSC00032“I put Qt on my ARM” : The only fun thing about ARM ever

The team over at Netrunner have just announced the launch of Netrunner 18.03 Idolon for the Pinebook. This is the direct result of a year of collaboration between the Netrunner, Pine and KDE Communities in a effort to drive down memory consumption, fix glitches in the graphics stack and enabling accelerated video decode, all of which has resulted in a product that showcases the coming together of the amazing software from KDE and some brilliant hardware engineering from the folks over at Pine.

It’s been quite a journey for my colleagues and I at Blue Systems in putting together this product. We have had to delve into areas where we originally did not have the expertise to fix bugs and constantly push the boundaries of our abilities. This was especially challenging in the ARM world since there are parts of the stack that were proprietary, meaning we cannot debug those parts, leading to many frustrating evenings having been spent on trying to reverse engineer buggy behaviour.

Personally, the launch of Netrunner on the Pinebook marks a milestone towards a goal that I’ve wanted to see realised ever since I discussed it with my peers at UDS N, nearly 10 years ago: Delivering Plasma on cheap and affordable computing devices. Being able to run a fully accelerated open source desktop environment on a device that costs 100 USD to me is a amazing accomplishment. It confidently signals to the world that Plasma is a versatile and mature product that spans across form factors and offers a compelling  alternative to other main stream products on these low end devices.

Shameless Plug: If you enjoy using KDE’s software products, please consider donating ��

Pronto se celebrará Akademy-es 2018, la reunión anual en España de usuarios y desarrolladores de KDE, que este año se realizará en Valencia del 11 al 13 de mayo. Ya he hablado en el blog de algunos de los detalles pero hoy quiero centrarme en algo básico. Y es que hace un tiempo que se ha abierto el registro de Akademy-es 2018 de Valencia, un requisito previo para prever mejor la asistencia.

Abierto el registro de Akademy-es 2018 de Valencia #akademyesComo he comentado muchas veces en el blog y delante de todo el mundo que me quiera escuchar, un evento libre es una oportunidad única para crecer en este mundillo. Ya seas un simple usuario, un desarrollador o una empresa interesada en este mundo, es un momento único para descubrir las personas excepcionales que dan forma a cualquier proyecto libre. Es por ello que siempre recomiendo la asistencia a los mismos ya que siempre se sacan cosas positivas.

 

Abierto el registro de Akademy-es 2018 de Valencia

Estás invitado. Cada vez falta menos para celebrar el mayor evento nacional de KDE en España: Akademy-es, que por si no lo sabéis será en Valencia del 11 al 13 de mayo.

Habrá charlas, talleres, actividades de carácter social y buen humor. Son de lo más productivas, ;) que no te lo cuente, ven y compruébalo tú mismo.

El registro es libre. No te costará NADA. Únicamente se hace para contar asistentes. Así, es más fácil organizar, comidas, espacios y eventos.

La asociación KDE España organiza este año Akademy-es 2018 en Valencia, concretamente en el Aula Capitular del Centre del Carme Cultura Contemporània, [Calle del Museu, 2] del 11 al 13 de mayo

Regístrate

Más información: KDE España


Muestra un mapa más grande
 

¿Qué se quiere conseguir en una Akademy-es?

Una Akademy-es se realiza por muchos motivos aunque el principal siempre es intercambiar ideas de forma más humana al tiempo que se estrechan los lazos de amistad entre los miembros de la Comunidad.

Durante el evento, como es costumbre, se realizan charlas tanto para usuarios como para desarrolladores, ademas de talleres prácticos y otras actividades de carácter más social con las que se pretenden cumplir los siguientes objetivos:

  • Poner en contacto a desarrolladores de KDE de toda España, para que puedan hablar de los proyectos en que están trabajando, compartir código, experiencias y conocimiento.
  • Dar a conocer los proyectos KDE como el entorno de escritorio nuevos usuarios.
  • Divulgar acerca de las tecnologías KDE, tanto para nuevos desarrolladores como para usuarios que quieran conocer mejor KDE.
  • Y por supuesto, el objetivo principal es que todos disfrutemos aprendiendo más sobre Software Libre y KDE.

Yo, si no tengo inconveniente de última hora, voy. ¿Te apuntas?

¡Os esperamos!

The 5.11 release of Qt 3D is mostly about speed and stability but it also introduces a number of new features.

One of them is generalized ray casting which can be used to find objects intersecting a 3d ray.

Object Picking

Available since 5.6, QObjectPicker can be used to detect mouse interactions with an entity. As the user moves the mouse and presses the buttons, events will be emitted by the component. This can be used to change properties of a entity based on the events, highlighting it when the mouse enters, scaling it up when a button is pressed, moving it when the mouse is dragged, etc.

By default, only mouse buttons will trigger events (if the mouse overlaps the geometry). This is done for performance reasons since computations can be expensive (see below). However, this can be changed by setting properties hoverEnabled, to detect when the mouse enters or leaves the entity, and dragEnabled, to detect when the mouse moves across the surface of the geometry.

When the mouse is pressed on an entity with a QObjectPicker component, that component will "grab" the mouse and only that object will be considered for picking events, until the mouse button is released.

When a hit is found, the generated event will contain information about the point of the geometry under the mouse. In particular, it will contain the coordinates of the mouse (in screen space) where the hit was made, the state of the buttons. But it will also include the coordinates of the point on the surface of the geometry both in local and in world coordinates.

By now it should be obvious that QObjectPicker, like MouseArea, is most suited to give behaviours to object in the scene, should as changing the scale to make them bigger when the mouse hover over them, or changing the colour when the object user "selects" the object by clicking on it.

While is very useful in its own right, it has several limitations:

  • It is dependent on mouse events: picking is implemented by casting a ray through the scene (details below) but there is no API to construct an arbitrary ray and test for objects intersecting it.
  • If the component is attached to an internal node of the scene graph, child objects will also be tested for hits but the resulting event does not contain any information about which child was actually hit.
  • There is no event generated when no hits occur.

Ray Casting

Picking as described above is implemented by casting a ray through the scene and looking for objects which intersect the ray. This is roughly how the process works:

  • For each mouse event, compute a ray between the near and far planes and transform it to world space.
  • Traverse the scene graph and look for every entity which has an object picker and where the bounding volume intersects with the ray.
  • If primitive picking is enabled (see below), traverse every primitive (triangle, line or point) to find which ones intersect with the ray.
  • Once all the hits are collected, sort them by distance to the origin of the ray.
  • Generate events for the closest hit or all of them depending on the settings (see below).

As you can imagine, on complex scene graphs with lots of primitives, this can be expensive. Qt 3D attempts to optimise things by using a bounding volume hierarchy to quickly eliminate entire portions of the scene graph which don't intersect with the ray. It also uses a thread pool to test multiple objects in parallel. Best results can be achieved by properly constructing scene graphs and avoiding single objects with large numbers of triangles.

The algorithm can be controlled globally by using the pickingSettings property of the QRenderSettings class, which is an instance of the QPickingSettings class.

The most important property is the pickMethod:

  • By default it's set to BoundingVolumePicking which is the fastest method: it will only test for bounding volume intersection. While this is very fast, it is also very imprecise. Internally, Qt 3D uses bounding spheres which can grossly exaggerate the actual volume of the object. Also, a small object positioned in front of a large one may be entirely encompassed by the large bounding sphere and thus be unpickable.
  • This property can also be set to TrianglePicking (and since 5.10 to LinePicking and PointPicking) to ask for hit tests to be made with individual primitives. This is of course far more time consuming.

Another important setting is the pickResultMode property:

  • When set to NearestPick (the default), only the closest hit will trigger an event
  • When set to AllPicks, an event will be generated for every intersection. If you imagine picking a sphere, in most cases this will generate two events. Events will be generated from front to back but they will be delivered separately and there is no way of knowing when the last event is received.

There are also settings to control how the face orientation affects picking and a world space tolerance factor to control line and point picking.

Generalized Ray Casting

The ray casting operations described above are those used by the QObjectPicker backend. As explained before, they rely on mouse events in order to compute the ray that will be used to do the hit tests.

But there are many uses cases for more generalized ray casting. Still in screen space, an application may use a specific cursor that can be controlled independently from the mouse cursor (like a gun sight). Or in an VR environment, you may want to find the object at the centre of the screen to implement gaze selection.

Also in a VR setting, you may want to implement a 3d "wand" which is manipulated using the VR controls. A 3d ray with a position, direction and length matching the virtual wand could be used to find intersecting objects. Using action buttons, you could then implement grabbing and dragging the intersecting objects.

QAbstractRayCaster

This is an abstract class that cannot be instantiated directly. If defines common properties for all sub-classes. Note that ray caster components cannot be shared between multiple entities.

The runMode property controls how often ray casting tests are performed. All ray caster instances are disabled by default. When enabled is set to true, a ray casting test will be done at the next frame. If runMode is set to SingleShot (the default), the component will disable itself and no further tests will be performed until it is enabled again. If runMode is set to Continuous, tests will be performed at every frame until the node is disabled.

Controlling what gets picked

The filterMode property and the list of QLayer instances can be used to control which portions of the scene graph are considered when casting rays. You may want to disable picking on certain portions of the scene graph, or use different rays in different sub-graphs.

This can be achieved by using QLayer components and then adding them to the relevant ray caster node. The filterMode will control if the layers enable or disable ray casting and how to evaluate multiple layers.

Remember the QLayer has a recursive property to control if the layer applies to the specific entity only or if it should affect all of its children.

Getting picking results

When a ray caster test completes, the list of results will be assigned to the hits property of the component. This list will be empty if nothing was found. A change notification will always be emitted even if two successive tests produce the same result.

Each entry in the list contains the details of a hit, sorted front to back. It contains:

  • the type of hit (Entity, Triangle, Line, Point) depending on the setting used in QPickingSettings
  • the id and a pointer to the entity containing the geometry
  • the coordinates of the intersection point in local and model coordinates
  • the distance to the origin of the ray
  • the index of the picked primitive
  • the indexes of the points used to build the picked primitive.

While the C++ implementation used a properly typed class, the QML api uses a QJSValue containing an array of javascript objects with the relevant properties included.

QScreenRayCaster

QScreenRayCaster is used to do ray casting queries based on window coordinates without relying on the user using the mouse pointer. A test will actually be performed for every active render target.

The 3d ray is computed by constructing a ray at the specified coordinates between the front and back clipping planes and transforming that ray back in to model coordinates using the relevant camera projection and transformation.

The component has helper methods to trigger a test. All that basically does is enable the component so that a test happens at the next frame.

QRayCaster

QRayCaster defines a ray in the local coordinate system of the entity the component belongs to. This means the actual ray is affected by the world transformation applied to the entity.

The ray has an origin and a direction.

The ray also has a length, any hit further away from the origin will be ignored. If that length is less or equal to zero, the ray is considered to be infinite. Bear in mind that it has an origin and a direction, so it's only half infinite :)

The component also has helper methods to trigger a test, optionally setting the properties of the ray.

Example

Qt 3d source code contains a basic QML example for using both ray caster classes.

    ScreenRayCaster {
        id: screenRayCaster

        onHitsChanged: printHits("Screen hits", hits)
    }

    MouseHandler {
        id: mouseHandler
        sourceDevice:  MouseDevice {}
        onReleased: { screenRayCaster.trigger(Qt.point(mouse.x, mouse.y)) }
    }

    function printHits(desc, hits) {
        console.log(desc, hits.length)
        for (var i=0; i<hits.length; i++) {
            console.log("  " + hits[i].entity.objectName, hits[i].distance,
                        hits[i].worldIntersection.x, hits[i].worldIntersection.y, hits[i].worldIntersection.z)
        }
    }

In the case of the ScreenRayCaster, a test is triggered whenever the mouse button is released.

    RayCaster {
        id: raycaster
        origin: Qt.vector3d(0, 0, 4)
        direction: Qt.vector3d(0., 0., -1.)
        length: 5

        onHitsChanged: printHits("Model hits", hits)
    }

    KeyboardDevice { id: kbDevice }
    KeyboardHandler {
        id: kbHandler
        focus: true
        sourceDevice: kbDevice
        onPressed: {
            if (event.text.toLowerCase() == "a") { raycaster.origin.x -= .1; raycaster.trigger() }
            if (event.text.toLowerCase() == "f") { raycaster.origin.x += .1; raycaster.trigger() }
            if (event.text.toLowerCase() == "s") { raycaster.origin.y += .1; raycaster.trigger() }
            if (event.text.toLowerCase() == "d") { raycaster.origin.y -= .1; raycaster.trigger() }
        }
    }

For the RayCaster, it defines a ray can be moved around the scene using key combinations.

[video width="1016" height="652" mp4="https://www.kdab.com/wp-content/uploads/stories/raycaster.mp4"][/video]

Not the most earth shattering demo :).   But it does exercise all the features of the newly introduced nodes and how to do picking without using QObjectPicker.

Notes

  • These nodes should not be used for rays which change constantly. In particular if the change rate is faster than the actual display rate, the results are undetermined and it will not be possible to correlate results to the actual value to the ray used to produce them.
  • At this time, the screen based ray caster has no way of controlling which render surface to test, they are all tested, including offscreen surfaces. This will be remedied in 5.12.
  • Picking settings are global and cannot be controlled per ray. So you can't have one ray to pick lines and one to pick triangles for example. This will be changed at a later time.

About KDAB

KDAB is a consulting company offering a wide variety of expert services in Qt, C++ and 3D/OpenGL and providing training courses in:

KDAB believes that it is critical for our business to contribute to the Qt framework and C++ thinking, to keep pushing these technologies forward to ensure they remain competitive.

continue reading

The post New in Qt 3D 5.11: Generalized Ray Casting appeared first on KDAB.

The Kdenlive team, creators of KDE's non-linear video editor, will be holding their next sprint at the Carrefour Numérique in the Cité des Sciences in Paris next week.

The sprint will run from the 25th to the 29th of April, and two days will be open to the public. On Friday, 27th of April, from 4pm to 6pm the event will be open to anyone interested in getting involved. You can meet the team and learn how you can contribute to the project. On Saturday, 28th of April at 2.45pm, there will be a public presentation. You can discover Kdenlive as used by professional editors and learn about the new features.

Just in case you can't make it to Paris, but can get to the south of Spain: directly after the sprint, the team will fly to Seville to participate in the Libre Graphics Meeting.

Come make movies with us!

April 16, 2018

This blog is about KDE Connect, a project to communicate across all your devices. For example, with KDE Connect you can receive your phone notifications on your desktop computer, control music playing on your desktop from your phone, or use your phone as a remote control for your desktop.

In my previous blog, I told you about some of my improvements to the remote media control of KDE Connect. I ended with a note that local album art was not supported yet. Also, no album art was displayed in the media notification or on the lock screen. In the meanwhile, both features have been implemented! If you have KDE Connect 1.8.1 on Android, and KDE Connect 1.3 on your desktop, you'll have both of these features. So all your album art from VLC or Elisa is now visible on your phone!

Secondly, I've been working a bit on KDE Connect's bluetooth support. The code was mostly working already, but the remaining stuff is (of course) the hardest part! Nevertheless, more and more parts start working, so I assume it'll come your way in a couple of months. I'll post an update when it's ready for testing.

Una cosa es lo que planificas, otra la que sale. En un principio pensaba que esta sección sería dominical, pero últimamente parece que me viene mejor que sea el lunes. Así que os doy la bienvenida a Noticias linux 06, la sección que se dedica a mostrar las novedades del mundo GNU/Linux que no aparecen en el blog por falta de tiempo y que deberían aparecer.  protagonistas son loes lectores de feeds, Krita y Serve.

Noticias linux 06, lunes edition volumen 3

Otro Noticias Linux que aparece en lunes, y la razón es que quería que apareciera el lanzamiento de KDE Frameworks lo antes posible, es decir, solo con un día de retraso. Y es que se avecinan tiempos complicados para el blog.

5 mejores lectores de feeds de GNU/Linux

Noticias linux 06, lunes edition volumen 3Empezamos la triada de noticias con una recopilación de aplicaciones aparecida en el imprescindible blog de Maslinux y que nos devuelve al mundo injustamente casi extinto de las noticias personalizadas mediante RSS con la recomendación de los 5 mejores lectores de feeds de GNU/Linux.

Según la entrada, estos son el incombustible Akregator, QuiteRSS, Liferea, FeedReader y Newsbeuter.

Lanzado Krita 4.0.1

Hace poco más de un mes del lanzamiento de Krita 4 y los desarrolladores de la increíble aplicación de dibujo artístico ya han sacado su primer revisión.

De esta forma, el pasado 11 de abril apareció Krita 4.0.1, una actualización que solucionaba un buen número de errores aparecidos a lo largo del mes.

Serve, comparte archivos estáticos en tu red local de manera sencilla

Finalizo la triada de noticias o artículos recomendados con uno de Ubunlog, donde nos enseñas a utilizar Serve y compartir archivos en nuestra red local de una forma sencilla y efectiva.

Y es que nunca está de más tener alternativas para poder acceder es

Y como siempre digo, son todos los que están, pero no están todos los que son. ¿Qué noticia os ha llamado la atención esta semana? Ponedlo en los comentarios y así todos estaremos más informados de todo lo que se cuece en el mundo del Software Libre.

For, quite literally a year or more, KMail and Akonadi on FreeBSD have been only marginally useful, at best. KDE4 era KMail was pretty darn good, but everything after that has had a number of FreeBSD users tearing out their hair. Sure, you can go to Trojitá, which has its own special problems and is generally “meh”, or bail out entirely to webmail, but .. KMail is a really great mail client when it works. Which, on Linux desktops, is nearly always, and on FreeBSD, iswas nearly never.

I looked at it with Dan and Volker last summer, briefly, and we got not much further than “hmm”. There’s a message about “The world is going to end!” which hardly makes sense, it means that a message has been truncated or corrupted while traversing a UNIX domain socket.

Now Alexandre Martins — praise be! — has wandered in with a likely solution. KDE Bug 381850 contains a suggestion, which deserves to be publicised (and tested):

sysctl net.local.stream.recvspace=65536
sysctl net.local.stream.sendspace=65536

The default FreeBSD UNIX local socket buffer space is 8kiB. Bumping the size up to 64kiB — which matches the size that Linux has by default — suddenly makes KMail and Akonadi shine again. No other changes, no recompiling, just .. bump the sysctls (perhaps also in /etc/sysctl.conf) and KMail from Area51 hums along all day without ending the world.

Since changing this value may have other effects, and Akonadi shouldn’t be dependent on a specific buffer size anyway, I’m looking into the Akonadi code (encouraged by Dan) to either automatically size the socket buffers, or to figure out where in the underlying code the assumption about buffer size lives. So for now, sysctl can make KMail users on FreeBSD happy, and later we hope to have things fully automatic (and if that doesn’t pan out, well, pkg-message exists).

PS. Modern KDE PIM applications — Akonadi, KMail — which live in the deskutils/ category of the official FreeBSD ports were added to the official tree April 10th, so you can get your fix now from the official tree.

Could you tell us something about yourself?

Hi! I’m Faqih Muhammad and my personal brand name is runend. I’m 22 years old and live in Medan in Indonesia. I love film animation, concept art, game making, 3d art, and everything illustration.

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

It can be said that I’m a hobbyist now, but I keep learning, practicing, experimenting to find new forms and new styles of self-expression, all to improve my skills and to be a professional artist in the near future!

What genre(s) do you work in?

So far I’ve made scenery background with character as a base to learn something. Starting from the basic we can make something more interesting, but still it was quite difficult for me.

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

Hhmmm, there are many artists who give me inspiration. Mainly I follow Jeremy Fenske, Atey Ghailan and Ruan Jia. I won’t forget to mention masters like Rizal Abdillah, Agung Oka and Yogei, as well as my friends and mentors.

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

It was in 2014 using photoshop, which I used to create photo-manipulations with. In 2015 I finally bought my wacom intuos manga tablet and could finally begin learning about digital painting.

What makes you choose digital over traditional painting?

Digital painting has many features that make it easy to create art. Of course there’s no need to buy art supplies: with a computer, pen and tablet you can make art.

Lately I’ve been learning traditional painting using poster color, and that makes me feel both happy and challenged.

How did you find out about Krita?

I used Google to search for “free digital painting software” and I found Krita :D.

What was your first impression?

I was like “WOW”, grateful to find software as good as this.

What do you love about Krita?

I have tried some of the features, especially the brush engine, UI/UX, layering, animation tools, I love all of them! And of course it’s free and open source.

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

Probably the filter layer and filter mask performance. Those run very slowly, I think it would be better if they ran more smoothly and more realtime.

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

Free open source software that runs cross-platform, no need to spend more. If you get a job or a paid project with Krita, there is a donate button to make Krita better still.

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

I love all my work, sometimes some paintings look inconsistent, then I will make it better.

What techniques and brushes did you use in it?

Before starting I think about what I want to create like situation and color mood. If that’s difficult from only imagination I usually use some reference.

I first make a sketch, basic color, shading, texture, refine the painting, and check the value using fill black layer blending mode in color.

In Krita 4.0 beta there are many new brush presets, I think that’s enough to make awesome art.

Where can people see more of your work?

Artstation: https://www.artstation.com/runend
Twitter: https://twitter.com/runendarts
Facebook: https://web.facebook.com/runendartworks
Instagram: https://www.instagram.com/runend.artworks/

Anything else you’d like to share?

Krita is an amazing program, I’d like to thank the Krita team. I wish Krita a good future, I hope Krita can be better known to the people of Indonesia, for instance on campus, schools, the creative industry etcetera.

The next weeks will be exciting for Kdenlive! First, there is a Kdenlive sprint, that will take place in Paris from the 25th to the 29th of april. We are very proud to be hosted at the Carrefour Numérique in the Cité des Sciences, Paris. Our team will dedicate this time to discuss near and long term goals, review the application workflow with professional editors, work on the major 18.08 release and much more. You can expect frequent updates during this event, and we  will open the doors for two public events in Paris (entrance is free for the Carrefour Numérique, see access map):

  • Friday, 27th of april, 4pm to 6pm: open to anyone interested to get involved. Meet out team and learn how to join the project.
  • Saturday, 28th of april at 2.45pm: public presentation, discover Kdenlive as used by professional editors and insights into the new features.

Just after that, part of the team will fly to Seville to attend the Libre Graphics Meeting for a Kdenlive workshop on the 30th. So spread the word and come visit us in Paris or Seville!

This sprint was made possible through support by the KDE e.v., so if you want more, please consider a donation.

If you are interested to follow Kdenlive, you are also welcome to join us in our next Café, tomorrow, 17th of april at 9pm.

April 15, 2018

This post is the continuation of the previous one, titled Dear software manager, working in the open for the very first time? Face the challenges (I)

Focus shift

I understand the transition that a front line manager needs to go through when moving to work in the open as a personal journey, mostly because the challenges described in the first post of this series, specially those related with personal values, have had a significant impact on who I am today.

I believe that working in the open long enough will charge not just the way you understand your work but other aspects like your personal relations, your view as a professional… you mindset. The key question to me is how to drive that change in a way that you do not use trial-error as the number one technique to learn, knowing that, unlike in the case of most developers, as a manager your mistakes have a significant impact on those around you.

I strongly believe that habits change mindsets, not the other way around. Which translated to a job means that in order to adapt to a new way of thinking it is required to work in a different way.

So in my opinion, in order to succeed faster as a front line project manager in the open you will need to embrace new habits as a manager. And I know by experience that the transformation process is faster when you realise that it is not just about changing the mechanics of your work but also about shifting your focus.

This is the core idea I want readers to take away. It is not just about adapting what you were doing already within your company, but also shifting the focus of your work to make a meaningful impact in a different area.

From autonomy to alignment

I created a model that helped me to understand where I was, what I needed to focus on in order to succeed as a manager, as a team, as an organization or project. I will provide some information about this model since so I can use it to describe that focus shits I mentioned before.

My personal model can be summarised in a cycle with four stages. I have written about this before, by the way:

toscalix management modeltoscalix management model

I came to this model through a bottom-up approach, as a result of my experience working in open organizations. The structure in these four stages came from two key popular references:

  • The motivation model described by Daniel Pink in his famous book Drive.
  • The challenges described by Nilofer Merchant in her book The New How, when moving from strategy to execution in order to innovate. Those challenges many organizations go through led Nilofer to the description of the air sandwitch problem and how to approach it: alignment.

You can find references to both books in the Reads section of this site.

In corporate/in-house projects, front line managers mostly focus on what in the model refers to autonomy. They are perceived as successful when the people they manage are efficient which build trust on development teams, who get more room to work their way. Managers can then focus on effectiveness, risk evaluation, and mitigation activities, etc. increasing their impact and allowing them to help the engineering teams to a greater extend.

In my experience, the initial focus of most front line managers when working in the open is learning the new mechanics that would allow them to increase efficiency first and effectiveness later on of those around them. That might not be a bad approach since sometimes in Open Source projects, efficiency is a significant issue. At the very end, we all want to add value since day one, right?

But often this approach lead those managers to become the project escribe, doing  non-technical work with lower impact they are used to: driving meetings, documenting, etc. I have seen many people in Open Source, even other managers who went through the same process, justifying this approach as necessary to learn the new culture while adapting to the new environment. In other words, you play the role of a junior instead of a newcomer, living in first person a tough contrast when comparing the role you play in the open with the one you play within their companies.

When working in the open, I strongly believe that the key point to significantly shorten the time frame required for a front line manager to add real value to the project is to put emphasis from day one in alignment.

In most companies, this is the focus of more senior managers, so front line managers partially lack the skills and experience required to make a positive impact in alignment early on. At the same time, working in the open represents a unique opportunity to develop those skills and experience without many of the constrains and responsibilities associated to a senior management role.

Execution alignment based on the project goals (shared vision) represents one of the outstanding challenges in Open Source projects, so the main opportunity for a front line manager to add real value.

pjm_role_closed_vs_open_projects

Back to the personal journey approach, there are several habits that managers will need to change in order to get the right mindset to succeed. I will focus on the two I think are more important, and tough at the same time.

Key habits to change

Back to the personal journey approach, there are several habits that managers will need to change in order to get the right mindset to succeed. I will focus on the two I think are more important, and tough at the same time.

The first one is the management style. As a manager you will need to transit towards coaching as the main style. If directive is the default one in your organization, your journey will be longer and tougher than if your style can be identified already as affiliative. There is plenty of literature about management styles but sadly not much (for this context) about the next habit.

The second one is transparency, which has different requirements and implications for a manager than for a developer working in the open, since they hold a different responsibility within their organizations compared than in the Open Source projects towards their managees.

Let me clarify an interesting aspect of transparency.

There are restaurants where the kitchen is exposed to the customers. We all can see if it is clean, if there is a good working atmosphere, who is the chef and who clean the dishes, etc. Many people feel better in those restaurants because for them, selecting a restaurant is not just about getting tasty food at a reasonable price from a good service.

But is it exposing your kitchen being transparent?

Out of what the experience as a customer, an accountant can tell more meaningful information about that restaurant by looking at the numbers that somebody like me can tell by looking at the kitchen, since I have no clue about cooking. Transparency and exposure are not the same thing.

A key goal as a manager working in the open is to figure out how to drive a symbiotic relation between the organization the team belongs to and the Open Source project and their participants. Transparency at a personal, team and organization level is so important that should be practised since day one. Again, transparency and exposure are not synonyms.

Conclusion

Working in the open involve new challenges that requires a different mindset to be successfully faced by front line managers moving from corporate to Open Source projects. They will need to develop new habits and the most effective way to do so, in my view, is understanding since day one that your focus will need to move towards alignment instead of insisting in autonomy, according to my mental model. With that in mind, my advice is to pay special attention to those habits that will lead you to become a servant for your managees, promoting transparency by example…

…together with a good doses of patience and tolerance to public criticism. ��

After the shoving is done — and it is, for the most part — it is time to fill up the void left behind by the KDE4 ports that have been shoved aside. In other words, all over the place <foo> has been shoved aside to <foo>-kde4, and now it’s time to reintroduce <foo>, but in the modern KDE Applications form. For instance, there is now a science/kalzium-kde4 (the old stuff) and a science/kalzium (the new stuff). It’s not 100% complete, but most of the applications are there.

Tobias has been the driving force behind this, with ports commits like r466877 which introduced the modern KDE applications in science/. So a huge shout-out to his work in bringing things almost-up-to-date.

Note that we now have KDE Frameworks (5.44 .. there’s an exp-run planned for this week’s 5.45 release) and KDE Applications (17.12.3) but not a Plasma 5 Desktop; so you will be running KDE Applications on the older desktop of your choice if you’re using FreeBSD ports.

Warning: these two posts are a “Lessons Learnt” kind of post, so there is a grandpa kind of smell on it that I am not sure I am comfortable with so there is very little science.

I’ve got lately a few questions from managers about different aspects involved in the transition to working in the open when coming from a traditional corporate environment. This post and the next one are an attempt to answer some of those questions.

In this post I will focus on describing some of the challenges any manager will face and a second one will deal with how to face them.

I will constrain my comments to management aspects, ignoring as much as possible the leadership topic, although they are related. These two articles target what I call front line managers, not senior managers (managers of managers) nor executives. By front line managers I mean those that is in daily contact with developers and that represent, in a top down view of an organization chart, the lower management level. It is true though than many of the ideas you will read  might be valid to other profiles. You tell me.

Challenges

When moving from managing software projects/teams in classic corporate environments into Open Source  (FOSS) projects, there are several new challenges any front line manager will need to face. I group them here in four categories:

  • Challenges derived from the fact that Open Source projects are public and open.
  • Challenges related with the FOSS culture which has some unique characteristics.
  • Open Source has a project nature different in many aspects from the service/product nature most companies have.
  • Working in the open implies new challenges from a more personal point of view, involving values, motivations, etc.

Feel free to add more challenges that those named below. I would go over them.

Challenges: public and open

Some of the challenges corresponding to this category, in my opinion are:

  • In open environments like Open Source projects, no matter if they are community, company or consortium driven, technical leadership is as relevant (or even more relevant) than any other type of leadership, including business leadership.
  • Open Source development and delivery are all about distributed teams and, in most cases, about  multicultural teams.
  • Every aspect of the project needs to consider asynchrony by default. I find this challenge one of the most difficult to understand early on for those coming from corporate environments, even from big corporations, since managers tend to be familiar with concentrating specific roles and responsibilities per site/location, even when high availability is a business requirement.
  • When working in the open, you not just represent yourself, but also the organization you belong to. This is magnified when talking about managers because very frequently they are also perceived as the voice of the team they manage, which is not necessarily the case every time.
  • Front line managers are familiar with dealing with private and confidential information, but working in the open brings new challenges in this regard. This seems obvious. But what in my experience is not so obvious, because it is very often not part of front line manager’s responsibilities within their companies, is to deal with the preparation, communication and consequences of making corporate/internal information public, for instance. There are other interesting cases to consider in this regard.

Challenges: culture

  • In Open Source, openness is a given, although depending on the governance model of the project, there might be different degrees. The same applies to sharing.
  • One of the pillars that has made Open Source so successful is code ownership. If you develop it, you own it, which means that you are expected to maintain it. I have written several times before about how important this point is for the professional and personal growth of any developer. I know a few that, by the time they turned  20, they were already maintaining software used by thousands of people. That is something no college will teach them… nor most companies, sadly. There are still many so called senior engineers that haven’t dealt with the consequences of their own code or the one done by their teams for a few years. The agile movement, through promoting the micro-service architecture, has recognised how important this point is. Development teams are in charge of maintaining what they deploy in production. Still, Agile has not reached the level taken in this regard by Open Source.
  • Standardisation through adoption. This concept is significantly different in corporate environments. The success that Open Source is having though is slightly changing the approach to standardisation many corporations have. There is still a long way to go.
  • Consensus is as important as efficiency in Open Source projects. Some people talk about consensus driven development when referring to Open Source development to highlight how important this aspect is. Corporate managers and executives very often perceive Open Source development as significantly slower compared to developing in-house, which technically speaking might be true in some cases. They underestimate though the benefits that consensus has within a project overtime, specially when talking about the motivational aspects, when dealing with complex problems, interoperability, etc..
  • Documentation always beats meetings, always. I go even further. Meetings are so expensive and precious in highly distributed environments, that front line managers go through a lot of pain until they learn to focus meetings on discussing instead of reporting. This is a fundamental disagreement I have with the stand up concept, by the way. And I am not the only one. Reporting should not be part of any meeting. Period. Document and read reports up front.
  • Open Source is all about specialists (aka rock stars) instead of about teams. Front line managers have a particularly hard time dealing with “unique personalities” in the open. The tools they’ve learn to deal with them are very often not valid in the new environment. As I have written before, the team culture is one of the assets that corporations are bringing into Open Source.

Challenges: project nature

  • Open Source projects are mostly related with R&D, technology or tooling development and, in some cases, specially in company driven communities/projects, about pre-production (early productization stages). They are not about developing products or services which is what corporations are mostly about, even when dealing with R&D. This difference requires, for example, that front line managers pay constant attention to value-capture-and-return cycles between the project and the company.
  • Within Open Source projects, the relation among organizations is not common to many managers coming from corporate environments. Other organizations are treated as partners instead of customers, even if they are service providers or suppliers. In a similar way somebody you work with is a peer, even when talking about members of their teams (managee).
  • Looking at delivery, in Open Source is frequent to release features when ready, on a time based release cadence, which helps to coordinate many different parties. Within most organizations, not even R&D delivery is managed this way. Lately, rolling/continuous approaches are becoming popular among FOSS projects. This way of understanding delivery is very often tough for managers risen in the “deadline drama” culture.
  • When taking decisions in the open, front line managers need to adapt to the fact that developers think about the project as much as they think about the company they belong to. Sometimes even more. Who pays your salary and what for are common question among those managers who do not fully understand yet the environment they are working on. They get the perception that people tend to forget the corresponding  answers after a while working in the open.
  • I always ask managers working in the open about their definition of success for the teams they manage. By their answers I learn a lot about the transition stage they are in. Defining success, even in FOSS projects with a clear shared vision, might become tough. And it is so important to have an agreed definition by every team member…. In general, a definition of success for a team working in the open should consider at least these elements:
    • The project/community.
    • The company or organization that pays the check.
    • How is the value capture-return cycle defined for both, the company and the project.
    • Additional aspects that motivates the team.

Challenges: personal values

  • Front line managers, specially those with little exposure to customers, are not familiar with every aspect involved in professional reputation. It is a relevant concept when your work is public and can be directly associated to you. It is so powerful that it is easily mistaken with the most negative aspects of “ego”. Senior managers coming from corporate environments understand it better but still not fully. Reading or talking about it, listening to those who has been there, working with them, is not enough to get what is like to be on the other side. You need to cross the river to understand it.
  • Open Source was born out of strong ethical values. So strong that they are still relevant to many. FOSS is now mainstream so most think that those values are disappearing, being relevant only to the “senior geeks” working in some specific projects. I believe though that those ethical values still matter and, in my experience, the longer people is involved in Open Source, the more relevant they become for them, no matter where they come from. It takes time for anybody coming from corporate environments to fully understand the impact some of these values have and their implications in day to day activities. These values tend to to manifest vigorously when conflicts arise.
  • One of the things that everybody learn very soon when collaborating in Open Source projects is that people have “two different personalities” which in some cases diverge: the offline and the online personalities.

These challenges, and many others not mentioned above, will require different levels of attention at different stages of the adaptation/transition process to any manager. So in one way or the other, they will need to develop skills and accumulate experience to successfully face them.

A second post describes some ideas about how to approach these challenges when joining an Open Source project as a manager.

Time for your weekly dose of Usability & Productivity! We’ve got some good stuff today, including some nice improvements for the Open & Save dialogs–with a lot more on that front to come soon!

Additionally, another major bug worth highlighting has been fixed! Previously, image slideshows used for the desktop wallpaper or in a media frame widget would leak memory like crazy, eventually crashing the system. Veteran KDE developer David Edmundson traced this to a Qt bug and submitted a patch that’s been accepted! It’ll go into Qt 5.11 which hasn’t been released yet, so go bug your distros to backport the fix into their Qt 5.9.x or 5.10.x branches, as we plan to do for the upcoming Kubuntu 18.04 release. Soon KDE Plasma users will once again be able to use slideshow wallpapers without blowing up their computers!

But wait, there’s more…

New Features

  • When audio is set to switch to new sources that become active, this is now indicated with an on-screen display depicting the new device (KDE Phabricator revision D12083, implemented in KDE Plasma 5.13, authored by Kai Uwe Broulik):
  • You can (once again!) copy the text of the date and time from the Clock widget (KDE bug 355190, implemented in KDE Plasma 5.13.0, authored by Bernhard Schiffner))

Bugfixes

  • Fixed a bug that prevented removable devices from automounting correctly (KDE bugs 391706, fixed in KDE Plasma 5.12.5 and KDE Frameworks 5.46, authored by Stefan Brüns)
  • Fixed a bug that could cause Plasma to crash when switching the desktop from Folder View to Desktop View (KDE bug 391642, fixed in KDE Plasma 5.13.0, authored by David Edmundson)
  • Fixed a bug that could cause Konsole to not copy long text correctly under certain circumstances (KDE bug 352616, fixed in KDE Applications 18.08.0, authored by Mariusz Glebocki)
  • Fixed a bug that could cause Gwenview to not update an image’s thumbnail in the Thumbnail bar after rotating it (KDE bug D11714, fixed in KDE Applications 18.04.0, authored by Peter Mühlenpfordt)
  • Fixed a bug in Gwenview that could cause an image’s thumbnail to not update properly after undoing a crop or rotate operation (KDE bug 356998, fixed in KDE Applications 18.04.0, authored by Peter Mühlenpfordt)
  • Fixed a bug in Gwenview that could cause changed shortcuts to not take effect until after the program was restarted (KDE bug 389331, fixed in KDE Applications 18.04.0, authored by Peter Mühlenpfordt)
  • Fixed a bug causing Baloo (KDE’s file indexing service) to incorrectly
    handle complex boolean queries (KDE bug 392620, fixed in KDE Frameworks 5.46, authored by Stefan Brüns)

UI Polish & Improvement

  • Columns in KDE Open & Save dialogs are now always sized correctly, and resize appropriately as the window is resized (KDE bugs 354388, 338502, 196508, 177743, and 96638, improved in KDE Frameworks 5.46, authored by Scott Harvey):
  • The Open dialog now opens in the correct location when using a file located on a remote filesystem (KDE bug 374913, improved in KDE Plasma 5.12.5, authored by Alex Richardson)
  • A consistent (and better) icon is now used for “configure” everywhere (KDE Phabricator revision D12034, improved in KDE Frameworks 5.46, authored by me, Nate Graham):


  • The login screen now uses the same icon as the Lock screen for the “find or log in as other user” feature (KDE bug 392830, improved in KDE Plasma 5.13.0, authored by Scott Harvey)
  • Dolphin’s Information Panel can now optionally show condensed absolute dates rather than long relative dates – try right-clicking on it! (KDE bug 392352, improved in KDE Applications 18.08.0)
  • Gwenview now displays a better background for parts of images that are transparent, and lets the user configure more alternate backgrounds if desired (KDE Phabricator revision D11630, improved in KDE Applications 18.08.0, authored by Huon Imberger):
  • Gwenview now honors the chosen background color setting for SVG images (KDE bug D11629, improved in KDE Applications 18.08.0, authored by Huon Imberger)
  • Gwenview’s transition effect between images has been improved (KDE bug 373161, improved in KDE Applications 18.08.0, authored by Huon Imberger)
  • Dolphin’s “Open path” and “Open path in new folder” actions now scroll to and highlight the selected file (KDE bug 377510, improved in KDE Applications 18.08.0, authored by me, Nate Graham)
  • Non-square icons can now be used for the Application Launcher’s button (KDE Phabricator revision D12161, improved in KDE Plasma 5.13.0, authored by Kai Uwe Broulik):

    ��

If my efforts to perform, guide, and document this work seem useful and you’d like to see more of them, then consider becoming a patron on Patreon, LiberaPay, or PayPal.

Become a patron Donate using Liberapay donate with PayPal

Tomorrow, I’ll be heading to Piter (St. Petersburg) for acclimatization training before the C++ Russia 2018 conference starts.

C++ Russia – the track in EnglishC++ Russia – the track in English

While most talks at C++ Russia are in Russian, this year will have more than a few amazing talks in English – from famous names like Andrei Alexandrescu, Jon Kalb and Herb Sutter, to a few less famous ones including yours truly. :)

My talk will be a bit out of my comfort zone – it will not be about monads nor any other aspect of functional programming. I’ll be talking about modern meta-programming for C++17 and 20 – the void_t meta-function and the detection idiom.

If you happen to be close to Piter, join us (the tickets are available at cppconf.ru) or if you just want to grab a beer, send me an e-mail.


You can support my work on , or you can get my book Functional Programming in C++ at if you're into that sort of thing.

April 14, 2018


Next week the combined Ceph and Cloudstack Day will be hosted in London (2018-04-19). The agenda is online, get ready and your ticket to a great event!


I will speak about our Email at Ceph project (librmb). See you all in London!

New Interfaces for kdesrc-build

A few weeks back, a fellow KDE developer asked me in the IRC development channel whether I had thought about adding a GUI for kdesrc-build, to supplement (or even replace) the existing text-based interface.

In fact, I’ve been thinking about how to improve the interface for some time.  I’ve long thought that the existing console interface is very wordy, and while that’s led to some very minor streamlining and internal code changes to prepare for a quieter future, the codebase would seemingly not make improvements here very easy.

We discussed in IRC whether it might be simpler to do something like CMake’s server feature for kdesrc-build, where kdesrc-build would export a simple REST-style API while it was running.  However it was difficult enough to permit kdesrc-build to run update and build processes at the same time, so expanding the existing codebase to also support being an HTTP server would probably have been quite difficult, especially since I actively try to avoid too many non-core Perl dependencies.  Maintaining a custom environment for KDE-based software is hard enough without making our users also become proficient at maintaining a full-fat Perl distribution.

kdesrc-build: it’s Web Scale(TM)

This would normally leave a dilemma of how to add the capability kdesrc-build would need without requiring a great deal of extra dependencies or invasive surgery.  But I think I’ve found a solution, using (of all things) a web framework, called Mojolicious.  It is Perl-based and can be installed without any additional non-core Perl dependencies, and perhaps more importantly, it is quite svelte for all the capability it delivers, which means we can use it without worrying about a large performance impact.  In fact my perception has been that some things have sped up after being replaced with Mojolicious counterparts.

The result of a good deal of code refactoring can be seen below.

kdesrc-build status being published to a browser session

The konsole session on the right is the normal kdesrc-build output you know and love, running from the kdesrc-build make_it_mojo git branch.  On the left is a Chrome browser tab pointing to an HTTP port on localhost.

The web page shown in that tab was served up by kdesrc-build, handled by Mojolicious even as Mojolicious was helping to take care of the asynchronous updates and build processes.

Within the web page, the table shown is updated dynamically using a WebSocket connection back to kdesrc-build.  It’s harder to see without animation, but as each build completed, the appropriate table cell was updated, and background changed to green (for success) or red (for error).  The effect is even more impressive when performing source code updates like normal, as you can visually see how fast source code updates are completed even as the first builds are underway.

When the build finished, a “Build complete” entry was listed at the top.  All of this is still quite ugly, of course, but it’s worked well in my testing.

Getting to this point has required quite a bit of work: I have 37 commits in make_it_mojo alone since it was branched off, encompassing:

  • The introduction of Mojolicious,
  • Porting from my custom multiprocess IPC handling code to Mojolicious, using Mojolicious’s support for running blocking code in subprocesses to be able to slowly add new changes in,
  • Restructuring the update/build process to use promises (Mojolicious supports the same concept for promises as used in JavaScript, though without support for async/await keywords).
  • Adding the HTTP server,
  • Making it work with WebSockets,
  • Adding the web page
  • And of course all the little bugs on the way…

Trying it Yourself

To try it yourself (and I’m hoping to get some testing here!), you would first need to install Mojolicious.  It seems to be libmojolicious-perl on Debian/Ubuntu, and perl-Mojolicious in Fedora or openSUSE.  Or if you’re familiar with Perl’s CPAN, it’s just a matter of installing the “Mojolicious” distribution.

From there you’d run git checkout origin/make_it_mojo within the kdesrc-build source directory, and then run kdesrc-build as normal, from where you normally run it.  Assuming everything turns on, you should be able to run kdesrc-build --launch-browser in a separate terminal window to open your preferred browser to whatever dynamic port the kdesrc-build web server ended up being pointed to, and hopefully watch a bunch of boxes start turning green.

Next Steps

As I continue this I will be interested to hear feedback on how I should take this.  I have a prototype Qt app that I was working on, though now that I’ve got WebSockets working I’ll probably shift to use QML once I pick it up again.

Clearly there’s still a lot of work left to do, such as sending important status messages across, hyperlinks to log files (for build failures), statistics on update/build time, perhaps even a dependency explorer.  At least the framework is in place for this now, and I think this is the kind of thing that would benefit from hearing from the users before I go too far in one direction.  How should this evolve?  What would help you all the most?

There have been a few smaller improvements to the Plasma Vault pushed to master in the past few days, scheduled for release in Plasma 5.13.

KDE Connect

Imagine you left your computer unattentded, unlocked with a few Vaults open. And you have a few spies from a competing company roaming around.

Thanks to the new feature of KDE Connect, it is possible to define commands that you can execute remotely from you phone.

KDE Connect and Vault integrationKDE Connect and Vault integration

This amazing feature can be used to lock your screen, but also to close the open vaults thanks to the new D-Bus commands of the Vault system.

The commands are defined in the KDE Connect Settings module. Select the phone you want to be able to run the commands from and go to configure the ‘Run commands’ plugin. There you can add any commands you wish, and they will automatically appear on your phone in the KDE Connect application.

For locking the session, you can create a new command that executes

qdbus org.kde.screensaver /ScreenSaver Lock

For closing the vaults, you have two options:

qdbus org.kde.kded5 /modules/plasmavault closeAllVaults
qdbus org.kde.kded5 /modules/plasmavault forceCloseAllVaults

The difference between these two commands is that closeAllVaults will close only the vaults that are not used by a running application, while forceCloseAllVaults will try to kill all those applications and close all vaults.

UI polish

A few things got more polished. The offline vaults I wrote about the last time got a nifty emblem to differentiate them from ordinary vaults:

Emblem for offline vaultsEmblem for offline vaults

Also, error messages in the password dialogue got more prominent:

Error messagesError messages

Next steps

The next task will be to rewrite the CryFS backend to use the features added in the 0.9.9 version. This will provide much better error handling and will finally allow CryFS to be the default encryption mechanism for Plasma Vault.


You can support my work on , or you can get my book Functional Programming in C++ at if you're into that sort of thing.

April 12, 2018

I just booked my flights and hotel for Akademy 2018.

If you're planning to come you should too! [1]

You can find information about the recommended accommodation here.

See you in Viena!

[1] unless you're applying for sponsored travel+accommodation

The Elisa team is happy to announce our first release, version 0.1.

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.
Screenshot_20180412_224656
Since this is the very first release of Elisa, the number of features is not as extensive as in other mature music players. We aim to provide a solid foundation for new features to be added in the following releases.
Elisa lets you browse music by album, artist or all tracks Songs can be searched and added to the playlist easily and it is also possible to inspect your music’s metadata.
The music is indexed using either a private indexer or an indexer using Baloo. The private one can be configured to scan music on chosen paths. The Baloo one is faster because Baloo is providing all needed data from its own database. You can build and play your own playlists. HiDPI monitors are supported.
The team would like to thank everyone who contributed to the development of Elisa, including code contributions, testing, and bug reporting.
We would also like to thank the people who wrote articles about Elisa. We have already received very helpful feedback from several publications like lwn.net and Linux Format.
We are already working on new features for the next releases, which include under-the-hood changes for better performance and better metadata support. If you enjoy using Elisa, please consider becoming a contributor yourself. We are happy for any support!
Elisa source code tarball is available here.

How to create a theme that looks and feels like Unity using Plasma’s Desktop Scripting API

Plasma is probably one of the most configurable desktop environments around. With Plasma 5 developers wanted to make the configurability even easier and more straightforward than ever before by applying the rule “simple by default, powerful when needed”. To make that happen, the concept of Plasma look and feel themes was born.

Plasma look and feel themes (L&F) let you change the look of your Plasma desktop with just a few clicks. The simplest way to create look and feel theme is by using utility called Look and Feel Explorer, as described in the official documentation. You should also check out this video tutorial.

However if you want to have more granular control over what exactly happens with your theme, especially with the layout you can use Plasma desktop scripting. Some time ago I rewrote my L&F theme (United) using desktop scripting API. In this post I am going to describe step by step how you too can create a Unity-like desktop layout by using Plasma’s desktop scripting API.

Let’s get started.

In short, desktop scripting lets you control and interact with a Plasma user interface shell via JavaScript like API. You can use an interactive scripting dialog to test your scripts.

qdbus org.kde.plasmashell /PlasmaShell org.kde.PlasmaShell.showInteractiveConsole

As you may know, inside your L&F theme (contents/layout) there is a file called org.kde.plasma.desktop-layout.js which controls your Plasma setup. If you are using Look and Feel Explorer that file and its content is created automatically.

First you need to create a proper L&F package structure with all the files you need and save it in:

/home/[yourusername]/.local/share/plasma/look-and-feel/

You can use Look and Feel Explorer or modify an existing theme like United. Next open org.kde.plasma.desktop-layout.js in your favorite text editor. I am using Kate (Plasma’s default text editor). At the beginning of your file you need to add:

var plasma = getApiVersion(1)

Ok, now let’s create a new plasma panel located at the top of the screen:

panel = new plasma.Panel
panel.location = “top”

Add the height property for the panel (gridUnit * 2 is a default value used in plasma)

panel.height = gridUnit * 2

Once you have a new shiny panel you can add some widgets.

To get a list of widgets installed locally (for example from the KDE Store), do this:

kpackagetool5 --list --type Plasma/Applet

To get a list of all installed widgets (system wide):

kpackagetool5 --list --type Plasma/Applet --global

Once you have a list of installed widgets, you can use the panel.addWidget method to add them to your top panel.

panel.addWidget(“org.kde.plasma.appmenu”)
panel.addWidget(“org.kde.plasma.panelspacer”)
panel.addWidget(“org.kde.plasma.systemtray”)
panel.addWidget(“org.kde.plasma.digitalclock”)

And here is the result:

You need to add another spacer on the left side of the appmenu (otherwise the appmenu will overlap with the left panel). You also need a user switcher applet on the right side of a digital clock. Let’s start with the spacer:

var spacer = panel.addWidget(“org.kde.plasma.panelspacer”)

Now our global menu is located at center of the panel. This is because the default spacer takes up all available space in a panel. You need to change that by setting the expanding value to false. You use the currentConfigGroup property and writeConfig method to modify config file.

/home/.config/plasma-org.kde.plasma.desktop-appletsrc.

var spacer = panel.addWidget(“org.kde.plasma.panelspacer”)
spacer.currentConfigGroup = [“Configuration”, “General”]
spacer.writeConfig(“expanding”, false)

Next you will add USwitch (https://store.kde.org/p/1194339/), the Unity-like user switcher applet, from the KDE Store.

You need to add it as a dependency to your L&F theme. If you want to know how to do that, check out this tutorial. Once added to the panel, USwitch shows full user name by default. However we want to show an icon, just like in Unity. The good news is that USwitch offers such an option: You only need to change it using plasma desktop scripting. While most of the settings (configuration keys) offered by default widgets are documented, this is not the case with third party widgets. The simplest way to get such information is to open plasma-org.kde.plasma.desktop-appletsrc in Kate, go to USwitcher Settings and change it to Show only icon. Close window settings and you will get something like this

Click View Difference to see what configuration keys were changed.

var uswitcher= panel.addWidget(“org.kde.plasma.uswitcher”)
uswitcher.currentConfigGroup = [“Configuration”, “General”]
uswitcher.writeConfig(“showName”, false)
uswitcher.writeConfig(“showSett”, true)

Now org.kde.plasma.desktop-layout.js should looks like this:

var plasma = getApiVersion(1)
// Create top panel
panel = new plasma.Panel
panel.location = “top”
panel.height = gridUnit * 2
// Add widgets to the top panel
var spacer = panel.addWidget(“org.kde.plasma.panelspacer”)
// Make first spacer non expandable by default
spacer.currentConfigGroup = [“Configuration”, “General”]
spacer.writeConfig(“expanding”, false)
// Appmenu
panel.addWidget(“org.kde.plasma.appmenu”)
// Spacer
panel.addWidget(“org.kde.plasma.panelspacer”)
// Systemtray
panel.addWidget(“org.kde.plasma.systemtray”)
// Clock
panel.addWidget(“org.kde.plasma.digitalclock”)
// USwitch https://store.kde.org/p/1194339/
var uswitcher = panel.addWidget(“org.kde.plasma.uswitcher”)
uswitcher.currentConfigGroup = [“Configuration”, “General”]
uswitcher.writeConfig(“showName”, false)
uswitcher.writeConfig(“showSett”, true)

Let’s create the left panel…

var leftpanel = new plasma.Panel
leftpanel.location = “left”
leftpanel.height = gridUnit * 3.2

… And add a fullscreen launcher and default shortcut:

var menu = leftpanel.addWidget(“org.kde.plasma.kickerdash”)
menu.currentConfigGroup = [“Shortcuts”]
menu.writeConfig(“global”, “Alt+F1”)

Now you can add an icon-based task manager:

leftpanel.addWidget(“org.kde.plasma.icontasks”)

Add Present Windows Button widget from KDE Store (https://store.kde.org/p/1181039/) and change its settings to show the desktop grid by default:

var windows = leftpanel.addWidget(“com.github.zren.presentwindows”)
windows.currentConfigGroup = [“Configuration”, “General”]
windows.writeConfig(“clickCommand”,”ShowDesktopGrid”)

Add a trash can:

leftpanel.addWidget(“org.kde.plasma.trash”)

You are almost there and only need to fix overlapping panels…

leftpanel.offset=panel.height

… And remove the desktop toolbox

var activityId = activityIds[0]
var activity = desktopById(activityId)
activity.currentConfigGroup = [“General”]
activity.writeConfig(“showToolbox”, false)

The final org.kde.plasma.desktop-layout.js should look like this:

var plasma = getApiVersion(1)
var activityId = activityIds[0]
var activity = desktopById(activityId)
//Remove desktop toolbox
activity.currentConfigGroup = [“General”]
activity.writeConfig(“showToolbox”, false)
//Create top panel
panel = new plasma.Panel
panel.location = “top”
panel.alignment = “left”
panel.height = gridUnit * 2
//Add widgets to the top panel
var spacer = panel.addWidget(“org.kde.plasma.panelspacer”)
//Make first spacer non expandable by default
spacer.currentConfigGroup = [“Configuration”, “General”]
spacer.writeConfig(“expanding”, false)
//Kickerdash
panel.addWidget(“org.kde.plasma.appmenu”)
//Spacer
panel.addWidget(“org.kde.plasma.panelspacer”)
//System tray
panel.addWidget(“org.kde.plasma.systemtray”)
//Clock
panel.addWidget(“org.kde.plasma.digitalclock”)
//USwitch https://store.kde.org/p/1194339/
var uswitcher = panel.addWidget(“org.kde.plasma.uswitcher”)
uswitcher.currentConfigGroup = [“Configuration”, “General”]
uswitcher.writeConfig(“showName”, false)
uswitcher.writeConfig(“showSett”, true)
//Create left panel

var leftpanel = new plasma.Panel
leftpanel.location = “left”
leftpanel.height = gridUnit * 3.2
leftpanel.offset=panel.height
//Add widgets to the left panel
var menu = leftpanel.addWidget(“org.kde.plasma.kickerdash”)
//Add default shortcut to the kickerdash menu
menu.currentConfigGroup = [“Shortcuts”]
menu.writeConfig(“global”, “Alt+F1”)
//Icontasks
leftpanel.addWidget(“org.kde.plasma.icontasks”)
//Present Windows Button https://store.kde.org/p/1181039/
var windows = leftpanel.addWidget(“com.github.zren.presentwindows”)
//Toggle desktop grid
windows.currentConfigGroup = [“Configuration”, “General”]
windows.writeConfig(“clickCommand”,”ShowDesktopGrid”)
//Trash
leftpanel.addWidget(“org.kde.plasma.trash”)

Are you still there? I hope you weren’t bored too much ;)

That said, if you want all the work done for you, you can download United from KDE Store or from GitHub. I also added documentation to the official KDE wiki.

This theme also uses:

-Color Scheme (Ambiance) made by CHICHOVOTO
https://store.kde.org/p/1001434/

-Plasma theme (Unity Ambiance) made by DARKBEASTOFPREY
https://store.kde.org/p/998797

- Plasmoids
Present Windows Button made by ZREN
https://store.kde.org/p/1181039/

USwitch made by DIVINAE
https://store.kde.org/p/1194339/


How to create a theme that looks and feels like Unity using Plasma’s Desktop Scripting API was originally published in KDEOK on Medium, where people are continuing the conversation by highlighting and responding to this story.

Qt 5.9.5 is released today. As a patch release Qt 5.9.5 does not add any new functionality, but provides important bug fixes and other improvements.

Compared to Qt 5.9.4, the new Qt 5.9.5 contains over  100 bug fixes. In total there are around 450 changes in Qt 5.9.5 compared to Qt 5.9.4. For details of the most important changes, please check the Change files of Qt 5.9.5.

Qt 5.9 LTS has entered ‘Strict’ phase in the beginning of February. It continues to receive important bug fixes and significant performance fixes still during the ‘Strict’ phase. Intention is to reduce risk of regressions and behavior changes by restricting the changes to the most important ones. We also continue to create new Qt 5.9.x patch releases, but with slower cadence than earlier.

Qt 5.9.5 can be updated to using the maintenance tool of the online installer. For new installations, please download latest online installer from Qt Account portal or from qt.io Download page. Offline packages are available for commercial users in the Qt Account portal and at the qt.io Download page for open-source users.

The post Qt 5.9.5 Released appeared first on Qt Blog.

During the last couple of months KDAB engineers have been working on improving CUPS printing support for Linux in Qt.

This work has been sponsored by the LiMux project, a big thank you to them for allowing us to spend time improving Qt :).

We started in early December with a series of small commits cleaning up some code, removing some code that was never called [1] and merging several small functions so the code flow is easier to understand and increases maintainability [2][3][4][5][6].

Our big goal was reviving the Advanced options tab that was present in the first versions of Qt 5 but was removed due to usability concerns [7]. Unfortunately this meant that support of advanced options like automatic stapling (see a quirky video of that here: [8]) was lost.

In the Linux world those advanced options are exposed through CUPS [9] and its support for PPD [10] files. The interesting feature of PPD files is that they have a way to describe not only the options but also how they should be grouped, so you can build an automatic UI on top of it relatively easily.

So working towards the goal we started adding a way to be able to access the PPD structures through the QPrintDevice and its Linux backend (QPpdPrintDevice) [11] [12].

Once that was in, we were in a position to restore the old code (improved thanks to code review) to show the Advanced CUPS options in the printing dialog [13]. The code basically traverses the PPD structures returned by CUPS and creates a model containing all the options. Then this model is plugged into an editable tree view. As said previously, one of the reasons it was removed was that some options were shown in two different places creating confusion for the user. That was solved easily through a blacklist, meaning that important options, like the Page Size, that already have their own space in the user interface, would not be shown in the advanced options tab.

PPD files also have a way of describing conflicts between various options, for example, you can't print on Photo quality unless you're using Photo paper. The initial code commit didn't fully  implement this correctly so we had to fix it [14].

Another usability problem the print dialog had is that it was a bit confusing how much of the state it kept, depending on which order you clicked Ok/Cancel and opened/closed it.  Some of the settings would or would not be stored, so we also fixed that :) [15][16].

Not strictly related to PPD and the advanced CUPS options, is a fix we did regarding the handling of Custom page sizes. Printers can define their own page sizes and the support for that was broken, so since we were going through the code, we also contributed a fix for it [17].

Going back to the Advanced options improvements, we added support for Installable Options [18][19]. Those are some options which basically say, if the user installed some add-ons to their
printer like a duplexer or stapler, that enables some of the Advanced options to actually be selectable. For that we also had to contribute a fix to CUPS itself [20] to fix the reported conflicting
options when Installable Options are involved, so make sure you're using CUPS >= 2.3 once it is released, or apply that patch to CUPS manually if you use a printer with Installable Options.

The last change we did for the Advanced tab was to make sure the text that comes from the PPD to describe the options is shown in the correct language (if your PPD has multi language support) [21].

One more feature we implemented in the Qt CUPS printing dialog is arbitrary range printing [22]. Previously one could only say "Print from page 3 to 5", but not "Print page 1, then from 3 to 5 and then page 11". This feature has been implemented in Qt itself, so applications don't need to support it explicitly. Any application that uses the Qt print dialog will gain support for this feature "automagically"!

All these improvements will be released with Qt 5.11. We will soon start to work on some more improvements and bugfixes for the Qt Linux printing dialog for Qt 5.12. Stay tuned!

[training_callout] continue reading

The post Better support for CUPS features in Qt 5.11 appeared first on KDAB.

Glad to announce the release of KStars v2.9.4 aka Emad is now release for Windows, MacOS, and Linux!

The new release brings in more performance improvements and bug fixes.

Spring Galaxy Season
Credit Turki AlAmri


Valentin Boettcher
introduced a highly efficient binary interface for asteroids that would allow quite large (> 100MB) and distant catalogs to be loaded into KStars without a major impact on performance. Before this change, loading any JPL catalogs for faint asteroids (> 15 mag) resulted in significant slowdown of KStars during startup as well as during run-time. Now users can comfortably load fainter asteroids given they have enough system memory to handle it.

Automatic Flat field calculations were fixed for multi-channel DSLR frames along with an improved DSLR popup dialog. The online astrometry option with offline server bug was fixed and now users can connect to local instances of astrometry.net without any problems.

The Ekos scheduler workflow was revamped to evaluate all jobs every time a new job is invoked to ensure all scores are updated accordingly and not only on the first job run. More SEP work for star & galaxy detection is merged into the internal guide module resulting in a better object detection even in noisy environments.
Messier Marathon with Ekos Scheduler

Furthermore, the guide module is now a lot more tolerant to passing clouds. When a star lock is lost, it will attempt to reacquire the lost star for several iterations before giving up.

On the capture frontend, users can now instruct Ekos to take flat field frames exactly at the same focus position where light frames of the same filter were captured. For example, suppose you are taking an LRGB sequence, and the best autofocus position for Green filter is 37,000 ticks. By the time you finish the sequence the focus position would most likely have moved due to the Blue filter (unless they're perfectly parafocal). Once you start capturing flat fields afterwards, typically the focus position is kept as-is. However, now it is possible to synchronize the focus position when capturing flat fields as well. When a flat field Green capture is requested, Ekos shall instruct the focuser to move to 37,000 ticks as indicated by the last successful autofocus operation of the same filter.

Finally, users might have noticed especially on slower systems that opening large FITS files can take a while to load up. In v2.9.4, the FITS handling code was optimized with loading times improving on the order of 300%.

FITS Speed improvements

Turns out that statistics calculations were eating up significant amount of precious CPU cycles. Many of these calculations would greatly benefit from SIMD support like SSE/NEON but since KStars runs on multiple architectures, it requires an architecture-agnostic solution and major refactoring of the code base. Another solution that was more readily available is to employ multiple threads to by partitioning the image and therefore spreading the calculations. It is certainly a poor-man's SIMD in a way, but the results were immediately noticeable.

Using 16 threads, computing min and max values was reduced from 122ms to only 30ms. Running mean and standard deviation calculations took 118ms instead of 270ms. Here is an excerpt from the Qt Concurrent magic that made this signifantly easier to code than using plain pthreads.

QList<QFuture<QPair<double,double>>> futures;

for (int i=0; i < nThreads; i++)
{
// Run threads
futures.append(QtConcurrent::run(this, &FITSData::getSquaredSumAndMean<T>, tStart, (i == (nThreads-1)) ? fStride : tStride));
tStart += tStride;
}

double mean=0, squared_sum=0;

// Now wait for results
for (int i=0; i < nThreads; i++)
{
QPair<double,double> result = futures[i].result();
mean += result.first;
squared_sum += result.second;
}

double variance = squared_sum / stats.samples_per_channel;

stats.mean[n] = mean/nThreads;
stats.stddev[n] = sqrt(variance);

There is room for more improvement still, especially since now we are loading the FITS twice unnecessarily. This could be resolved by using an implicit sharing data model among FITS files that does not require a deep-copy of the data until the underlying data is altered. This could result in a 100% improvement in loading speeds when using Ekos as well. Stay tuned!

April 11, 2018

Today the Krita team releases Krita 4.0.1, a bug fix release of Krita 4.0.0. We fixed more than fifty bugs since the Krita 4.0.0 release! See below for the full list of fixed isses. Translations work again with the appimage and the macOS build. Please note that:

  • The reference image docker has been removed. Krita 4.1.0 will have a new reference images tool. You can test the code-in-progress by downloading the nightly builds for Windows and Linux
  • There is no scripting available on macOS. We had it almost working when the one macbook the project has received a broken update, which undid all our work. G’Mic is also not available on macOS.
  • The lock and collapse icons on the docker titlebars are removed: too many people were too confused by them.

If you find a new issue, please consult this draft document on reporting bugs, before reporting an issue. After the 4.0 release, more than 150 bugs were reported, but most of those reports were duplicates, requests for help or just not useful at all. This puts a heavy strain on the developers, and makes it harder to actually find time to improve Krita. Please be helpful!

Improvements

Windows

  • Patch QSaveFile so working on images stored in synchronized folders (dropbox, google drive) is safe

Shortcuts

  • Fix duplicate shortcut on Photoshop scheme
  • Alphabetize shortcut to make the diffs easier to read when doing changes

UI

  • Make the triangles larger on the categorized list view so they are more visible
  • Disable the macro recorder and playback plugin
  • Remove the docker titlebar lock and collapse buttons. BUG:385238 BUG:392235
  • Set the pixel grid to show up at 2400% zoom by default. BUG:392161
  • Improve the layout of the palette docker
  • Disable drag and drop in the palette view: moving swatches around did not actually change the palette. BUG:392349
  • Fix selecting the last used template in the new document dialog when using appimages. BUG:391973
  • Fix canvas lockup when using Guides at the top of the image. BUG:391098
  • Do not reset redo history when changing layer’s visibility. BUG:390581
  • Fix shifting the pan position after using the popup widget rotation circle. BUG:391921
  • Fix height map to normal map in wraparound mode. BUG:392191

Text

  • Make it possible to edit the font size in the svg text tool. BUG:392714
  • Let Text Shape have empty lines. BUG:392471
  • Fix updates of undo/redo actions. BUG:392257
  • Implement “Convert text into path” function. BUG:391294
  • Fix a crash in SvgTextTool when deleting hovered/selected shape. BUG:392128
  • Make the text editor window application modal. BUG:392248
  • Fix alignment of RTL text. BUG:392065 BUG:392064
  • Fix painting parts of text outside the bounding box on the canvas. BUG:392068
  • Fix rendering of the text with relative offsets. BUG:391160
  • Fix crash when transforming text with Transform Tool twice. BUG:392127

Animation

  • Fix handling of keyframes when saving. BUG:392233 BUG:392559
  • Keep show in timeline and onion skin options when merging layers. BUG:377358
  • Keep keyframe color labels when merging layers. BUG:388913
  • Fix exporting out audio with video formats MKV and OGV.

File handling

  • Do not load/save layer channel flags anymore (channel flags were removed from the UI in Krita 2.9). BUG:392504
  • Fix saving of Transform Mask into rendered formats. BUG:392229
  • Fix reporting errors when loading fails. BUG:392413
  • Fix a memory leak when loading file layers
  • Fix loading a krita file with a loop in the clone layers setup. BUG:384587
  • Fix showing a wait cursor after loading a PNG image. BUG:392249
  • Make bundle loading feedback a bit clearer regarding the bundle.

Vector bugs

  • Fix crash when creating a vector selection. BUG:391292
  • Fix crash when doing right-click on the gradient fill stop opacity input box of a vector BUG:392726
  • Fix setting the aspect ratio of vector shapes. BUG:391911
  • Fix a crash if a certain shape is not valid when writing SVG. BUG:392240
  • Fix hidden stroke and fill widgets not to track current shape selection BUG:391990

Painting and brush engines

  • Fix crash when creating a new spray preset. BUG:392869
  • Fix rounding of the the pressure curve
  • Fix painting with colorsmudge brushes on transparency masks. BUG:391268
  • Fix uninitialized distance info for KisHairyPaintOp BUG:391940
  • Fix rounding of intermediate pressure values
  • Fix the colorsmudge brush when painting in wraparound mode. BUG:392312

Layers and masks

  • Fix flattening of group layers with Inherit Alpha property set. BUG:390095
  • Fix a crash when using a transformation mask on a file layer. BUG:391270
  • Improve performance of the transformation mask

Download

Windows

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.

Linux

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

When it is updated, you can also use the Krita Lime PPA to install Krita 4.0.1 on Ubuntu and derivatives. We are working on an updated snap.

OSX

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

Source code

md5sum

For all downloads:

Key

The Linux appimage and the source tarball are signed. You can retrieve the public key over https here:
0x58b9596c722ea3bd.asc
. The signatures are here (filenames ending in .sig).

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.

April 10, 2018

It has been over a month since my last progress update. Here is what I’ve done.

AtCore Changes:

D10813,D10845,D11185,D11252,D11702,D11565,D11381, D11403, D11345, D11024,D10299,D11772

AtCore will now deploy libAtCoreWidgets. Sd card support  is working for repetier and marlin. I can not assure you it will work for any other firmware correctly. Command injection is now done (D11024).

Atelier Update :

D12024,D12054,D12021,D12012,D12020,D11996,D11873,D11730,D11837,

D12030,D12046,D12076,D12008,D12009,D11995,D12010,D12011,D11476

General UI Improvements.

  • Remove “Profiles” and “New Instance” from toolbar by default.
  • Show Profile dialog upon connection attempt with no profiles created.
  • Embed fallback icons with awareness of Light / Dark Theme
  • Instance now get filelist on creation
  • Show the print actions only if a file has been opened or printing from sd.
  • Use AtCoreWidgets.
  • Clean up toolbars for atcoreInstance.
  • New Instance Button on tabWidget.
  • Close Tabs, if more then one tab open.

I’m slowly returning to KDE development after a few months of being mostly in bugfix mode due to my other-life obligations (more on that later), so I decided to implement a new feature for my youngest project – the Plasma Vault.

One of the possible attack vectors to your Plasma Vaults is that people could potentially have access to your computer while the vault is open.

This is not a problem if we consider direct access because it is something that is easily controlled – you see everyone who approaches your computer, but the problem can be remote access.

We have recently seen that even CPUs can sometimes be used as attack vectors, it is common for the web browsers to be, and obviously, through social engineering, the user can also be used to gain remote access to the system.

For this reason, starting with the next Plasma release, if you have an extremely sensitive data you can mark a vault as offline-only.

This means that networking will be shut down as soon as you open the offline-only vault so that any potential remote access is inhibited.

Offline Vault creationOffline Vault creation

The networking will be restored as soon as you close all offline-only vaults.

For this to work, you will need to use Network Manager as it is the supported networking interface in Plasma. I know it might be a burden for some of you (it is for me), but there is no alternative at the moment.


You can support my work on , or you can get my book Functional Programming in C++ at if you're into that sort of thing.

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.