April 25, 2018
It's been 2 days since the GSoC accepted student list was announced and I'm still getting goosebumps thinking about the moment I saw my name on the website. I started contributing to open source after attending a GSoC session in our college by one of our senior and a previous GSoC student with KDE: Aroonav …
Autofocus module users would be happy to learn that the HFR value is now responsive to changing seeing conditions. Previously, the first successful autofocus operation would set the HFR Threshold value of which subsequent measurements are compared against during the in-sequence-focusing step.
However, this method suffers from two issues:
- Seeing could change during the night.
- HFR value could be different for different filters.
April 24, 2018
Since 2006, we have had the opportunity for Google to sponsor students to help out with Krita. For 2018 we have 3 talented students working over the summer. Over the next few months they will be getting more familiar with the Krita code base and working on their projects. They will be blogging about their experience and what they are learning along the way. We will be sure to share any progress or information along the way.
Here is a summary of their projects and what they hope to achieve.
Ivan Yossi – Optimize Krita Soft, Gaussian and Stamp brushes mask generation to use AVX with Vc Library
Krita digital painting app relies on quick painting response to give a natural experience. A painted line is composed of thousands of images placed one after the other. This image mask creation hast to be performed super fast as it is done thousands of times each second. If the process of applying the images on canvas is not fast enough the painting process gets compromised and the enjoyment of painting is reduced.
Optimizing the mask creation can be done using the AVX instructions sets to apply transformation in vectors of data in one step. In this case the data is the image component coordinates composing the mask. Programming AVX can be done using Vc optimization library, which manages low level optimization adaptable to the user processor features. However the data must be prepared so it optimizes effectively. Optimization has already been done on the Default brush mask engine allowing it to be as much as 5 times faster than the current Gaussian mask engine.
The project aims to improve painting performance by implementing AVX optimization code for Circular Gauss, Circular Soft, Rectangular Gaussian, Rectangular Soft Rectangular and Stamp mask.
Michael Zhou – A Swatches Docker for Krita
This project intends to create a swatches docker for Krita. It’s similar to the palette docker that’s already in Krita today, but it has the following advantages:
- Users can easily add, delete, drag and drop colors to give the palette a better visual pattern so that it’s easier for them to keep track of the colors.
- Users can store a palette with a work so that they can ensure the colors they use throughout a painting is consistent.
- It will have a more intuitive UI design
Andrey Kamakin Optimize multithreading in Krita’s Tile Manager
This project is about improving Krita overall performance by introducing lock-free hash table for storing tiles and improving locks described in proposal
Problem: In single threaded execution of program there is no need to monitor shared resources, because it is guaranteed that only one thread can access resource. But in multi-threaded program flow it is a common problem that resources must be shared between threads, furthermore, situations such as dirty read, etc must be excluded for normal program behavior. So the simplest solution is to use locks on table operations so that only one thread can access resources and read/write
We wish all the students the best of luck this summer!
|
|
Sirva esta entrada como recordatorio, para que no se te pase. Y es que esta noche toca podcast sobre Akademy-es 2018 de Valencia que emitiremos en directo y dejaremos grabado para la posteridad este 24 de abril a las 22:00 hora española.
Esta noche toca podcast sobre Akademy-es 2018 de Valencia
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 reúnan y comenten qué se espera de la reunión, realicen un repaso a las charlas que se llevaran a cabo, comenten algunos aspectos sociales del evento y nos cuenten algunas de las anécdotas que han vivido en alguna de sus casi 15 anteriores ediciones.
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
Y tanto si vienes como si no, no olvides ayudarnos en la promoción con la etiqueta #akademyes.
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 esta noche a las 22:00!
Los podcast de KDE España
En 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 23, 2018
Los fondos de pantalla son la carta de presentación de cualquier escritorio, y Plasma no es una excepción, aunque mucho usuarios sea lo primero que cambian cuando se instalan su sistema operativo o cambian de móvil. Es por ello me complace presentar el nuevo fondo de pantalla para Plasma 5.13. Además, y siguiendo con la tradición que inicié hace unos cuantos lanzamientos, he preparado un histórico de los otros wallpapers que ha disfrutado Plasma 5. Espero que os guste tanto como a mi me ha gustado elaborar ampliar esta entrada.
Nuevo fondo de pantalla para Plasma 5.13
De nuevo me toca presentaros el nuevo fondo de pantalla para Plasma 5.13 que nos ha vuelto a preparar Ken Vermette. En esta ocasión lo ha bautizado con el nombre de “Kokkini” y viene a querer representar una playa roja que hay en Grecia, pero pasada por el filtro habitual de la gama de wallpapers de la serie Plasma 5:
Más información y descarga: Opendesktop
Los fondos de pantalla de Plasma 5
Es el momento de echar un vistazo al pasado y realizar una compilación de los fondos de pantalla que el equipo de diseño de la Comunidad KDE (KVDG) nos ha ido ofreciendo en los lanzamientos mayores del escritorio Plasma.
Veamos las grandes creaciones para Plasma en versión reducida, aunque pinchando en ellos podrás obtener una versión de mayor tamaño, y al final del artículo tendrás el enlace a la carpeta virtual donde están todos en varios tamaños.
Plasma 5.0
Fue Nuno Pinheiro, el veterano diseñador de la Comunidad KDE y responsable del aspecto visual de KDE 4, el encargado de iniciar la serie con un fondo de pantalla elegante en tonos pastel. Fue una excelente tarjeta de presentación durante el primer año de existencia del entorno de trabajo más moderno y avanzado del mercado, asentando la idea visual inicial de colores y triángulos como base de los diseños, aunque fue una idea que ha ido evolucionando a lo largo de tiempo.
Plasma 5.2
Para la primera revisión anual de Plasma nos obsequiaron con “Vibrant”, un fondo de pantalla que seguía la estética triangular iniciada por Nuno pero añadía colores más vivos. Empieza la era de Ken Vermette, el diseñador que ha tomado las riendas de los fondos de pantalla oficiales de Plasma 5 y nos está proporcionado grandes lienzos.
Plasma 5.3
El orden empezó a perderse con la nueva versión del fondo de pantalla para Plasma 5.3 llamado “Deep” . De nuevo formas triangulares y colores todavía más vivos en un precioso diseño de Ken Vermette. Se intuye la evolución hacia un diseño ligeramente 3D ya que los triángulos empiezan a superponerse y a crearse sombras.
Plasma 5.4
“Horizon” fue el nombre elegido para el siguiente fondo de pantalla, que continúa con los triángulos de colores vivos pero en los que se muestra las primeras deformaciones. Si se observa bien, el título viene definido por la línea del horizonte que separa las dos superficies. Sigue subiendo la variedad de colores.
Plasma 5.5
Para el lanzamiento de la quinta versión de Plasma se siguió evolucionando y se dio otra vuelta de tuerca más a la idea inicial. Seguimos con una base de triángulos pero ahora con una deformación que le da un aspecto 3D, con la aparición de una textura que cogerá protagonismo en las próximas versiones. Así se consigue un tema precioso y colorido que Ken tituló como “Event Night” y que fue lanzado con otros dos: “Event day” y “Pastel Hills”.
Más información: Ken Vermette – Spooky Scary Post-Halloween Monster Post
Plasma 5.6
“Graphite”, el sexto fondo de la serie, es un tema que “aparta” los triángulos a un segundo plano, quedando en un primer las grandes superficies de colores fuertes pero sobrios. Otro excelente fondo que simboliza la transición entre los dos estilos que conviven en esta serie de fondos de pantalla.
Plasma 5.7
Cambio de tercio. Los triángulos dejaron de ser protagonistas aunque siguen apareciendo en el diseño de este fondo de pantalla llamado “Skylight”. Ahora los colores vivos pero sobrios son los predominantes en el penúltimo fondo de pantalla oficial de Ken para Plasma 5.
Más información: Ken Vermette – That Time of the Cycle
Plasma 5.8
Ken Vermette nos presentó el noveno fondo de pantalla oficial para el escritorio Plasma 5.8. Un fondo llamado “Bizmuth” que sigue con las formas abstractas geométricas, con centenares de triángulos y colores vivos pero que incorpora curvas. Un soplo de aire precioso para la primera versión de largo soporte de Plasma que además venía con la novedad de ser el primer fondo de pantalla con resolución 4K UHD.
Más información: Ken Vermette – Queueing up for Plasma 5.8
Plasma 5.9
Ken Vermette siguen presentándonos unos espectaculares fondos de pantalla para Plasma 5. En esta ocasión lo llamo “Canopee” y sigue con formas abstractas geométricas, con centenares de triángulos y paralelepípedos, donde dominan los colores azul y verde, con una cinta marrón y toques amarillos.
Un fondo de pantalla menos vistoso pero un poco más sobrio que el anterior. Espero que os guste tanto como a mi. Lo cierto es que me estoy aficionando a este tipo de fondos. Podéis pinchar en la imagen inferior para descargaros el nuevo fondo de pantalla para Plasma 5.9.
Por si tenéis curiosidad en el proceso de creación de Canopee os recomiendo que os leáis la entrada que ha escrito el mismo Ken Vermette – Plasma 5.9 Wallpaper “Canopee” donde relata con pelo y señales el nacimiento del mismo.
Plasma 5.10
Y siguió el gran Ken Vermette presentándonos unos espectaculares fondos de pantalla para Plasma 5. En esta ocasión lo llamó “Cascade”, y continua con las forma de “Canopee” en su parte derecha pero que presenta una más que interesante ola casi plana azulada en su parte izquierda. Personalmente me recuerda a la transición entre corteza continental a oceánica, con su plataforma continental y su talud.
Más información y descarga: Store.kde
Plasma 5.11
“Opal” fue el nombre con el que Ken Vermette bautizó el fondo de pantalla para Plasma 5.11. Un fondo que seguía con formas geométricas y colores apastelados pero que se desmarca de los anteriores por la elección de un tono mucho más oscuro en la composición. Podéis leer parte de las impresiones de Ken en la entrada de su blog donde presenta el fondo.
Puedes descargar el fondo de pantalla “Opal” para casi cualquier resolución que desees desde este enlace.
Y para ver la evolución ahora debéis subir al inicio y ver el nuevo fondo de pantalla de Plasma 5.13
En definitiva, espero que os haya gustado este recorrido por los wallpapers de Plasma tanto como a mi. Por cierto, si queréis descargarlos para casi cualquier resolución os dejo el siguiente enlace que me ha proporcionado el mismo Ken Vermetten donde podréis incluso disfrutar de las versiones beta del nuevo fondo de pantalla de 5.8.
April 22, 2018
At the end of my previous post we concluded with yet another question. Indeed, on the 2017 KDEPIM contributor network we found out that Christian Mollekopf while being a very consistent committer didn't appear as centrality as we would expect. Yet from the topology he seemed to act as a bridge between the core contributors and contributors with a very low centrality. This time we'll try to look into this and figure out what might be going on.
My first attempt at this was to try to look into the contributor network on a different time period and see how it goes. If we take two snapshots of the network for the two semesters of 2017, how would it look? Well, easy to do with my current scripts so let's see!
Alright, it still looks similar to the picture we got for the full 2017... Christian is still on the outter rings of our network and bridging toward low centrality nodes. Only difference is that he has a slightly higher centrality value than during the whole year. Needless to say just that semester doesn't learn us much. Time to look at the second semester then.
Ah-Ah! Now we see something new, Christian is now mostly disconnected from the network! He is part of a clique containing him and Michael Bohlender. Looking further at their activity they are indeed focusing almost exclusively on Kube. Michael was in fact one of those low centrality nodes Christian was bridging to previously.
So what are we looking at? It seems to be the birth of an insular sub-team in the KDEPIM community. It's technically not a fork since they're working on a specific software but this clique configuration indicates they moved their focus there, they didn't attract the rest of the KDEPIM community to contribute (yet?) and they stopped contributing completely to the wider KDEPIM effort (at least for the time frame we've been looking at). The community got split there.
Now we could leave it at that and consider it like a detail... or... if you're like me and want not only to produce those graphs and metrics but wonder if some of those things could be turned into useful tools for community stewardship in general and the Community Working Group in particular, you won't stop there.
From the two networks above and the one I produced the last time it's clear that we need to deal with time... From a single network we freeze the time and get a configuration for a given period. If we ever want to see that something like the clique we saw appearing here can be detected we need a less static view.
For the time being, we will look at individual centrality of a contributor over time. For that we will get their monthly centrality value in the network over a three months sliding window (previous month, current month and next month). Since it's also interesting to have an idea of the activity of the contributor over the time period, we'll also plot the normalized monthly activity of the contributor. Finally, since centrality is dependent on the team size, we'll plot the normalized team size on the period.
Regarding that last plot, a few more words because it's a fairly important one that Volker Krause helped me realize during the KDEPIM sprint because of his own plots and discussing them with him, unfortunately it's also what makes the centrality tricky to read. The centrality value of a node is a value between 0 and 1, if a node is not connected at all it gets a 0 if a node is connected to all other nodes it gets a 1. So obviously, if the team is large you need way more connections to get a high centrality than in a small team.
Corollary of the point above is that centrality values variation are meaningful only during a stable team size. If we're a period of decreasing or increasing team size variations on a centrality can occur for a node even though it would have maintained the exact same connections! And that's why we have the third plot on the team size in the graphs below to get an idea on how much trust we can put in the variation of the centrality plot.
Alright, with that out of the way (although it'll keep haunting us while reading those plots), now it's time to explore those plots. We won't look only at one, I think it's a good idea to look at more than one contribution pattern before coming back to Christian. To get there and keep those plots somewhat comparable I'll drastically expand the time period we'll look at, instead of looking at 2017 only, we'll go all the way back to 2007! This way we can see more of KDEPIM's history and get patterns also from old timers. Let's start!
So first thing first, we see the evolution of the team size in KDEPIM on the last ten years. Interestingly we see the decrease that Paul Adams was pointing out in his last Akademy talk... but it's not reaching the ground and it looks like it stabilized at least since 2014. Is it the case for the whole of KDE? Does the commit activity look the same globally? Clearly questions I'll have to investigate as well, it never ends! :-)
In any case this variation on team size seems to indicate that we can look at the centrality variations from 2007 to end of 2009 or from 2014 to the end of 2017 somewhat safely. Of course the team size keeps varying but it's more noise than a real trend so it should be fine overall.
With that in mind, what we can see from Till is a former core contributor who slowly stopped to contribute. This is crystal clear just from his activity plot and the centrality plot as expected follows the same pattern. It's indeed less correlated with his activity in the 2010 to 2012 period but that's to be expected with the downward trend in team size.
This second graph is now about Volker Krause. We can see the top activity he had during 2009 and because the team size was large at the time it required such a high activity for him to have his centrality spike as well. The mystery spike of September 2016 is what prompted the display of the team size plot. He had only a very tiny activity that month which generated a surge in centrality... well it turns out that even though he did only a hand full of commits some of them were on build system files which tend to be touched by others and because of the smaller team size than in 2009 the variation get amplified.
So now that we're done with our two "example" core contributors... let's get back in the territory of the very active contributors of the past year...
Let's look at Laurent in this third graph, clearly he has been contributing to KDEPIM for a long time but overall not on a very high volume. It really started to increase around 2012 so I guess that's when he slowly took over maintainership of KMail. As expected that's when we see his centrality raising as well as he was getting involved with more and more components of KDEPIM. Of course it's slightly amplified by the decrease of team size over the 2012 - 2014 period but he kept getting more central even after that.
And finally, this fourth graph gets us back to Christian. Clearly he joined KDEPIM at the end of 2010, from that point on he looks like any other future contributor with increased activity correlating with increased centrality (watch out for the decrease of team size until 2014 which amplifies a bit the effect on that period). Then during 2014 we have a somewhat stable centrality and activity. Some noise but nothing out of the ordinary over a year. It gets interesting after that though. During 2015 we see his activity increasing again but at the same time his centrality starts dropping a first time. It then stays somewhat stable while his activity spikes. And toward the end of 2017 centrality completely drops. This is a very different pattern from all the other contributors we looked at.
In my opinion, the interesting observation is that by looking at the contributor network, we see the clique only appearing at the second semester of 2017, but, on the centrality graph we see this pattern of increasing activity with decreasing centrality starting in 2015! Two years before the community split is visible.
Now the question I have, and I think it'll be a tough one so I might leave it unanswered for a little while. Could we detect this kind of pattern early? Could we detect without too much false positive (even though there always will be some of them)?
I think it's important to think about that because in that particular case, assuming we'd have such a tool, the Community Working Group would have been warned of a team split to come and maybe step in to see if they could save the situation. Currently our Community Working Group is mostly working in reactive mode since they talk to people when a conflict emerges, with such a tool they could also try to be proactive and check on a team if the "increasing activity with decreasing centrality" pattern emerges. I think it would be nice if they could do this and talk to people before too many feelings were hurt.
It'll take time to get there, if at all. But I think it's worth looking into.
Latte Dock v0.7.5 has been released containing important fixes and improvements! Hopefullly this is going to be the last stable version for v0.7.x family. During the next months the next stable branch (v0.8.x) is going to appear.
 |
| new gold editing pattern |
- fix for dodge maximized visibility mode in multi-screen environment
- when copying default layouts make sure they are writable in the destination
- new protocol to communicate between applets and Latte in order to
inform them when they are in a Latte panel/dock and when they dont want any change in their main icon behavior. (#983)
The Elisa team is happy to announce the first bug fix release for the 0.1 version.
The following changes have been integrated:
- c5bc988 search for more cover names in directory by Alexander Stippich (Fix bug 392843);
- 5113d00 remove the huge playlist icon by Alexander Stippich (Fix bug 392782).
One important note, Elisa is now available from flathub. Only the stable releases will be distributed through flathub.
Flathub Elisa pageThis release also has a windows setup at the time of release. Thanks a lot to the help from the Craft and binary-factory teams. Without them, I would not be able to do it.
Elisa source code tarball is available here. The Windows installer is also available from this place.
Let’s have some more Usability & Productivity!
I’ve initiated a big project: overhauling KDE Open & Save dialogs for greater usability and productivity. If you would like to follow along, here is the meta-task tracking the work: https://phabricator.kde.org/T8552
So far, we’ve:
- Fixed column widths (Scott Harvey)
- Added view mode buttons to the toolbar (Me, Nate Graham)
- Made the dialog always save the view settings even when canceling or closing (Me, Nate Graham)
All of this work–and hopefully the rest of the “open/save panel improvement” work–will ship with KDE Frameworks 5.46.
(Also, what do people think of the above style for these bullet points instead of the typical one I’ve used below?)
As usual, there’s more! Here’s the other Usability & Productivity-related work from the past week:
New Features
- Kate and other programs using the KTextEditor framework gained syntax highlighting for GDB files (KDE Phabricator revision D11902, implemented in KDE Frameworks 5.46, authored by Milian Wolff)
- Konsole now supports more XTerm-style cursor shapes (KDE Bug 347323, implemented in KDE Applications 18.08.0, authored by Ahmad Samir)
Bugfixes
- Bold, italic, and underline effects now work again for Kate’s syntax highlighting modes (KDE Phabricator revision D12221, fixed in KDE Frameworks 5.46, authored by Christoph Cullman)
- Dolphin’s icon view grid spacing no longer changes unpredictably when previews are turned on or off, and has tighter spacing when previews are on and icons are large (KDE bug 393306, fixed in KDE Applications 18.04.1, authored by me, Nate Graham):
- Gwenview no longer crashes when zooming after reloading an SVG image (KDE bug 359736, fixed in KDE Applications 18.04.0, authored by Peter Mühlenpfordt)
- Gwenview’s “Failed to save” warning dialog no longer displays raw HTML in it (KDE bug 393170, fixed in KDE Applications 18.04.04, authored by Peter Mühlenpfordt)
- Okular no longer loses highlighted search results when a page is rotated (KDE bug 387282, fixed in KDE Applications 18.04, authored by Ahmad Osama)
- The Media Frame widget’s mode chooser now displays the modes corrently even for languages where the words are very long (KDE bug 393232, fixed in KDE Plasma 5.12, authored by Friedrich Kossebau)
UI Polish & Improvement
- Changes to a Konsole profile’s keybingings are now immediately applied to that profile (KDE Phabricator revision D12255, improved in KDE Applications 18.08, authored by Ahmad Samir)
- Plasma and Plasma widgets now all use the same color picker widget (KDE Phabricator revisions D12330 and D12318, fixed in KDE Plasma 5.13, authored by Friedrich Kossebau:
- Gwenview now positions the viewport more intelligently after crop and resize operations (KDE Phabricator revisions D12167 and D12170, authored by Peter Mühlempfordt)
- Gwenview no longer shows duplicate confirmation dialogs when overwriting an existing image (KDE Phabricator revision D12346, fixed in KDE Applications 18.04.1, improved by Peter Mühlenpfordt)
- The KDirOperator widget (commonly used for inline file browsers in apps like Kate, Kile, and RKWard, as well as open and save dialogs) now has a reload button in the context menu (KDE bug 199994, improved in KDE Frameworks 5.46, authored by me, Nate Graham)
Might seem a little light this week, but trust me, there’s a ton of stuff in progress right now. It may not quite be ready yet, but it will be awesome once it is!
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.
Vuelve la sección que pensaba que sería dominical, pero que últimamente aparecía los lunes (me recuerda a cierta revista). Así que os doy la bienvenida a Noticias linux 07, 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 los protagonistas son GameMode, openSUSE y FFmpeg.
Noticias linux 07, dominical edition is back
Vuelven las Noticias Linux qal domingo, el día que seleccioné por diversas razones y que por otras diversas razones traspasé al lunes temporalmente. Esta semana ha estado marcada por el lanzamiento de KDE Aplicaciones 18.04 y por la apertura del registro a Akaddemy-es 2018 de Valencia (¿aún no lo has hecho? ¿a qué esperas?)
Gamemode, un potenciador para videojuegos para Linux
Si queremos que los jóvenes aficionados a los ordenadores sean usuarios de sistemas GNU/Linux, éste debe facilitarles el disfrute de una de sus aficiones favoritas: los videojuegos.
Con este objetivo nace, como nos presenta Linux Adictos, GameMode una librería/demonio creado por la empresa Feral Interactive y que adapta el rendimiento de la CPU en función de las necesidades del videojuego sin dañar al resto de hardware del ordenador.
En otras palabras, hará que la experiencia de los usuarios de los videojuegos en GNU/Linux de un salto de calidad en cuanto a fluidez y eficacia del procesador.
openSUSE Leap 15 se publicará el 25 de mayo de 2018
Ahora toca hablar de Victorhck in the free world, el blog de mi amigo Victor, que nos contó el pasado 19 de abril que la distribución d camaleón, es dcir, openSUSE Leap 15, se publicará el 25 de mayo de 2018.
Esta fecha coincide coincidiendo con la reunión anual de la comunidad de openSUSE en openSUSE Conference que se celebrará este año en la ciudad de Praga.
Grandes noticias para los simpatizantes, entre los que me incluyo, de una distribución que poco a poco se está reestructurando para convertirse en “rolling release”
Lanzado FFmpeg 4.0
Para quienes no lo conozcan, FFmpeg es una conjunto de aplicaciones con el que puedes grabar, convertir (transcodificar) y hacer streaming de audio y vídeo. Incluye libavcodec, una biblioteca de códecs. [Fuente: Wikipedia]
Pues bien, el pasado 20 de abril fue lanzada la versión 4.0 de esta gran colección de software que nos ofrece una asombrosa lista de novedades que os recomiendo leer en el anuncio oficial.
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.
Initial RC (Release Candidate) images for the Kubuntu Bionic Beaver (18.04) are now available for testing.
The Kubuntu team will be releasing 18.04 on 26 April. The final Release Candidate milestone is available today, 21 April.
This is the first spin of a release candiate in preparation for the RC milestone. If major bugs are encountered and fixed, the RC images may be respun.
Kubuntu Beta pre-releases are NOT recommended for:
- Regular users who are not aware of pre-release issue
- Anyone who needs a stable system
- Anyone uncomfortable running a possibly frequently broken system
- Anyone in a production environment with data or workflows that need to be reliable
Kubuntu Beta pre-releases are recommended for:
- Regular users who want to help us test by finding, reporting, and/or fixing bugs
- Kubuntu, KDE, and Qt developers
Getting Kubuntu 18.04 RC testing images:
To upgrade to Kubuntu 18.04 pre-releases from 17.10, run sudo do-release-upgrade -d from a command line.
Download a Bootable image and put it onto a DVD or USB Drive via the download link at
http://iso.qa.ubuntu.com/qatracker/milestones/389/builds
This is also the direct link to report your findings and any bug reports you file.
See our release notes: https://wiki.ubuntu.com/BionicBeaver/ReleaseNotes/Kubuntu
Please report your results on the Release tracker.
April 21, 2018
In February after Plasma 5.12 was released we held a meeting on how we want to improve Wayland support in Plasma 5.13. Since its beta is now less than one month away it is time for a status report on what has been achieved and what we still plan to work on.
Also today started a week-long Plasma Sprint in Berlin, what will hopefully accelerate the Wayland work for 5.13. So in order to kick-start the sprint this is a good opportunity to sum up where we stand now.
QT_QPA_PLATFORM
Let us start with a small change, but with huge implications: the decision to not set the environment variable QT_QPA_PLATFORM to wayland anymore in Plasma’s startup script.
Qt based applications use this environment variable to determine the platform plugin they should load. The environment variable was set to wayland in Plasma’s Wayland session in order to tell Qt based applications that they should act like Wayland native clients. Otherwise they load the default plugin, which is xcb and means that they try to be X clients in a Wayland session.
This also works, thanks to Xwayland, but of course in a Wayland session we want as many applications to be Wayland native clients as possible. That was probably the rationale behind setting the environment variable in the first place. The problem is though, that this is not always possible. While KDE applications are compiled with the Qt Wayland platform plugin, some third-party Qt applications were not. A prominent example is the Telegram desktop client, which would just give up on launch in a Wayland session because of that.
With the change this is no longer a problem. Not being forced in its QT_QPA_PLATFORM environment variable to some unavailable plugin the Telegram binary will just execute using the xcb plugin and therefore run as Xwayland client in our Wayland session.
One drawback is that this now applies to all Qt based applications. While the Plasma processes were adjusted to now be able to select the Wayland plugin themselves based on session information other applications might not although the wayland plugin might be availale and then still run as Xwayland clients. But this problem might go away with Qt 5.11, which is supposed to either change the behavior of QT_QPA_PLATFORM itself or feature a new environment variable such that an application can express preferences for plugins and fallback if to the first supported one by the session.
Martin Flöser, who wrote most of the patches for this change, talked about it and the consequences in his blog as well.
Screencasts
A huge topic on Desktop Wayland was screen recording and sharing. In the past application developers had a single point of entry to write for in order to receive screencasts: the XServer. In Wayland the compositor as Wayland server has replaced the XServer and so an application would need to talk to the compositor if it wants access to screen content.
This rightfully raised the fear that now developers of screencast apps would need to write for every other Wayland compositor a different backend to receive video data. As a spoiler: luckily this won’t be necessary.
So how did we achieve this? First of all support for screencasts had to be added to KWin and KWayland. This was done by Oleg Chernovskiy. While this is still a KWayland specific interface the trick was now to proxy via xdg-desktop-portal and PipeWire. Jan Grulich jumped in and implemented the necessary backend code on the xdg-desktop-portal side.
A screencast app therefore in the future only needs to talk with xdg-desktop-portal and receive video data through PipeWire on Plasma Wayland. Other compositors then will have to add a similar backend to xdg-desktop-portal as it was done by Jan, but the screencast app stays the same.
Configure your mouse
I wrote a system settings module (KCM) for touchpad configuration on Wayland last year. The touchpad KCM had higher priority than the Mouse KCM back then because there was no way to configure anything about a touchpad on Wayland, while there was a small hack in KWin to at least control the mouse speed.
Still this was no long term solution in regards to the Mouse KCM, and so I wrote a libinput based Wayland Mouse KCM similar to the one I wrote for touchpads.
I went one step further and made the Mouse KCM interact with Libinput on X as well. There was some work on this in the Mouse KCM done in the past, but now it features a fitting Ui like on Wayland and uses the same backend abstraction.
Dmabuf-based Wayland buffers
Fredrik Höglund uploaded patches for review to add support for dmabuf-based Wayland buffer sharing. This is a somewhat technical topic and will not directly influence the user experience in 5.13. But it is to see in the context of bigger changes upstream in Wayland, X and Mesa. The keyword here is buffer modifiers. You can read more about them in this article by Daniel Stone.
Per output color correction
Adjusting the colors and overall gamma of displays individually is a feature, which is quite important to some people and is provided in a Plasma X session via KGamma in a somewhat simplistic fashion.
Since I wrote Night Color as a replacement for Redshift in our Wayland session not long ago I was already somewhat involved in the color correction game.
But this game is becoming increasingly more complex: my current solution for per output color correction includes changes to KWayland, KWin, libkscreen, libcolorcorrect and adds a KCM replacing KGamma on Wayland to let the user control it.
Additionally there are different opinions on how this should work in general and some explanations by upstream more confused me than guided me to the one best solution. I will most likely ignore these opinions for the moment and concentrate on the one solution I have at the moment, which might already be sufficient for most people. I believe it will be actually quite nice to use, for example I plan to provide a color curve widget borrowed from Krita to set the color curves via some control points and curve interpolation.
More on 5.13 and beyond
In the context of per output color correction another topic, which I am working on right now, is abstracting our output classes in KWin’s Drm and Virtual backends to the compositing level. This will first enable my color correction code to be nicely integrated and I anticipate in the long term will be even necessary for two other far more important topics: layered rendering and compositing per output, what will improve performance and allow different refresh rates on multi-monitor setups. But these two tasks will need much more time.
Scaling on Wayland can be done per output and while I am no expert on this topic from what I heard because of that and for other reasons scaling should work much better on Wayland than on X. But there is currently one huge drawback in our Wayland session: we can only scale integer factors. To change this David Edmundson has posted patches for review adding support for xdg-output to KWayland and to KWin. This is one step in allowing fractional scaling on Wayland. There is more to do according to Davd and since he takes part in the sprint I hope we can talk about scaling on Wayland extensively in order for me to better understand the current mechanism and what all needs to be changed in order to provide fractional scaling.
At last there is cursor locking, which is in theory supported by KWin, but in practice does not work well in the games I tried it with. I hope to start work on this topic before 5.13, but I will most likely not finish it for 5.13.
So overall there is lots of progress, but still quite some work to do. In this regard I am certain the Plasma Sprint this week will be fruitful. We can discuss problems, exchange knowledge and simply code in unity (no pun intended). If you have questions or feedback that you want us to address at this sprint, feel free to comment this article.
Last week I was at work and start to listen my boss said: "We need to show this to our director". So I went to my coworker table to see what was happening. So they were using Gource to make a video about the git history of the project. Gource is a software version control... Continue Reading →
April 20, 2018
While I was working on a yet-to-be-announced super secret and cool Qt on Android project, I had to do a lot of debugging. This way I found that debugging Qt apps on Android using QtCreator was ok, but it had some issues, which was kinda frustrating.
- First issue was that I could not debug on an Android 8 device.
- Second issue was that, even if the debugger was almost ok for debugging Qt apps, debugging Qt itself was not that good.
Long story short, these problems will be fixed starting with QtCreator 4.6.1 (was too late for 4.6.0) or 4.7, and I also paved the way for using lldb if necessary, though, gdb works perfectly for me. And in the (distant) future MAYBE even being able to do java debugging from QtCreator as well!
Keep reading if you are interested in technical details.
How the debugging worked until now: it used a handshake technique:
- The application built for debugging bundles gdbserver into the apk.
- We start the application from QtC with some special params.
- The app checks these params, it starts gdbserver, it creates a socket, then it waits for QtCreator to connect to this socket.
- QtCreator uses adb to forward gdbservers and the socket port to your host.
- QtCreator tries to connect to the socket created by your application. When it succeeds to connect to that socket it attaches host gdb to gdbserver. At this moment all the application's .so files are loaded and gdb will search for their symbols on the host side. It sets the breakpoints.
- At the end it signals the java application (using the previous socket) that it can continue the execution.
How it works now: it's using the same technique that Android Studio uses:
- The application built for debugging bundles gdbserver into the apk.
- The application is started in debug mode (we add "-D" param to adb shell am start).
- The default wait for debugger dialog appears which waits for a jdb connection.
- QtCreator uses "adb shell run-as" to search for gdbserver and it starts it.
- QtCreator uses adb to forward gdbservers and the socket port to your host. At this moment no .so files are loaded by your application.
- QtCreator connects to gdbserver.
- QtCreator uses jdb to attach to the java debugger and it signals the application to continue the execution.
At first glance, both ways look similar, but .... there is a big difference :)
- First and foremost the application doesn't need the handshake hack, this means that we can soon drop that code from Android Qt apps.
- The second difference, which makes the debugging perfect, is at the point when we attach gdbserver to the application. As you can see, in the first way we attach gdbserver to the application after we load all .so file, this means that all breakpoints to static vars constructors or to JNI_Onload will not work, because these functions are already called by the linker.
- Now, because QtCreator is in control of the gdbserver part, with some effort it can search for lldbserver instead, and start it.
- Last but not least, because it's using jdb to start the application, it might be possible to use it also to debug the java part of the application!
The downside of the new way is that the start up is a little bit slower, because instead of loading the symbols for all the .so files at once, it will load them one by one as they are loaded by the application, which on my Ryzen 1700X is from 2 to 5 seconds slower.
If you can't wait for QtCreator 4.6.1/4.7 you can cherry-pick the following two patches and rebuild QtCreator yourself:
In the end I want to thank The Qt Company folks who helped me in testing these patches on all platforms and on as many devices as we had!
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.
The post Perfect Debugging Experience with QtCreator on Android appeared first on KDAB.
April 19, 2018
|
|
Virtlyst is a web tool that allows you to manage virtual machines.
In essence it’s a clone of webvirtmgr, but using Cutelyst as the backend, the reasoning behind this was that my father in law needs a server for his ASP app on a Win2k server, the server has only 4 GiB of RAM and after a week running webvirtmgr it was eating 300 MiB close to 10% of all available RAM. To get a VNC or SPICE tunnel it spawns websockify which on each new instance around 20 MiB of RAM get’s used.
I found this unacceptable, a tool that is only going to be used once in a while, like if the win2k freezes or goes BSOD, CPU usage while higher didn’t play a role on this.
Choosing a web interface for KVM/libvirt is no easy task, I have used Archipel and while it’s a nice app it is a pain to install, OpenStack is also overly complicated, and had a button labeled as “Terminate” button that deleted the instance entirely. A simple tool that’s specially simple to install was what I needed, and in fact is what a bunch of people need, here at work, OpenStack was also discarded due the hard installation process and a mix of virsh/virt-manager is used.
Since webvirtmgr is a DJango app, using it’s html templates was a breeze, Grantlee didn’t work with them out of the box, it has a few missing features but one can work around those, libvirt API is also quite well documented so development was quite fast, it took me 3 weeks but could easily be reduced to less than 2 if I had a bit more time.
So Virtlyst v1.0.0 is out, it uses less than 10MiB of RAM, and implements the VNC/SPICE web socket proxy in the same process thus each connections increases a almost nothing of memory usage. The software is already in production, and has all features of webvirtmgr except the migration part, that I plan to add in a future release.
Following the steps of some developer fellows I also created a Patreon account, so if you like what I do and would like to support my work please consider becoming a Patron.
Enough said, go get it!
Startup is one of the rougher aspects of the Plasma experience and therefore something we’ve put some time into fixing
Why is startup slow?
The primary reason for Plasma startup being slow is simply that it does a lot of things, including:
- Session restore
- Config migration
- Setting keyboard layouts
- Most esoterically, making sure your colour scheme gets synced to the xrdb database, so that loading xfig or dia or any other pre-Qt/GTK1 application still has the correct colours in your Plasma session
Too many to list. This means it’s easily a whole second or more before we even start loading plasmashell, one of the more time consuming parts of startup.
This slow load gets exaggerated by us not removing the splash screen till everything is actually properly loaded.
However, it’s still an area we can improve.
About startup
Startup consists of mulitple components invoked at 3 different levels.
- Kcminit
Config modules (kcms) typically update a system when the user applies the settings, however as we need to restore settings there is an optional hook called on startup for various modules. - KDE Daemons (kded)
Evolving from the more static nature above may services require running in the background waiting for external events. Some modules are loaded on demand, others are loaded explicitly during startup. - Autostarted applications
Meaning launcing core applications such as plasmashell/krunner as well as other applications a user might have selected; such as nextcloud or kgpg - User shell scripts
For anything else
These effectively all have their loading invoked at 3 different levels; as defined in the relevant kcminit/kded/autostart .desktop files. Note these may be shipped as core plasma, but can also include completely 3rd party items.
- Before plasmashell and other core autostart services
- Before user applications are restored / autoloaded
- After everything is restored and
A slightly more detailed version can be seen here.
Profiling
The most important part of any speed work is correctly analysing it.
systemd-bootchart is nearly perfect for this job, but it’s filled with a lot of system noise.
I’ve made a fork of systemd-bootchart that only tracks processes owned by that user on github.
To use put the following line into:
/etc/X11/Xsession.d/00-bootchart
/usr/lib/systemd/systemd-bootchart -o /tmp -r &
To profile wayland sessions, mod the SDDM config wayland SessionCommand option.
After 20 seconds an SVG will be placed in /tmp.
An example
Below shows the boot process of my personal machine. The important part to track is when ksplashqml gets destroyed, that signifies that boot is complete. In my case this happens after 4.5 seconds.
Just some of the many fixes
There have been and continue to be lots of tiny changes around the code. Mostly using the awesome tool hotspot here are just a few of the more significant and interesting ones.
A mysterious gap of nothingness
This stupid bug was caused by ksmserver blocking whilst it completed launching phase 1 of kded daemons before it continued onto loading the next section.
Problem is plasmashell and other GUI apps loaded in phase0 first task is to register with the X session manager, ksmserver. End result is we lockup in X code till
ksmserver is done. Solved by a logic rewrite.
Multiple starts of the same daemon
This is the result of the following code in a bunch of processes all started at once.
if (! serviceExistsOnDBus) {
startExecutable(…)
}
Whilst the daemon did handle this case correctly and the false starts aborted, it’s still a lot of time spend linking a process we don’t want.
Solution in this case was to port to DBus activation which is designed for this exact case.
Shortcuts writing on load
When profiling kglobalaccel5 we found it spent a lot of time writing entries on boot, which is a clear sign of something being wrong. The cause was quite complex. Powerdevil would report that the user visible name of the executable (kded) was “Powerdevil”. KScreen would load and report that the username of the executable (also kded) was “kded” this would cause the shortcut daemon to think locales had changed and forcibly reload and save everything.
Summary
Startup is an area that is being improved and we have tonnes of ideas left of things to do, but because it’s dealing with unpredictable 3rd parties it’s an area which requires 90% reading and 10% coding.
If you do have an excessively long boot time, please do try creating a boot chart as above, it will really help start to narrow down where we have problem. I hope to see some detailed reports on bugzilla soon.
Netrunner Pinebook
This week, there was the launch of Netrunner for Pinebook (1) (2). A lot of effort has gone into building the software, improving performance, getting automation and CI in place. That’s effort that benefits the wider KDE community, the wider Free Software-on-ARM community, and more. This is the laptop I’d take with me on a bicycle camping trip — clean, cheap and affordable, although heavier than a phone.
But there is an under-appreciated bit regarding images for an ARM laptop — or pre-installed Linux distro’s in general. And that’s the first-run experience. The Netrunner Pinebook image is delivered so that it boots to the Plasma 5 desktop, no passwords asked, etc. The user is called “live”, the password is “live”, and nothing is personalized. It’s possible, though not particularly secure, to use the laptop this way in a truly disposable fashion. A first-run application helps finalize the configuration of the device by creating a named user, among other things.
One of the under-documented features of Calamares is that it can operate as a first-run application as well as a system installer. This is called “OEM Mode“, because it’s of greatest interest to OEMs .. but also to distro’s that ship an image for users to flash onto (micro)SD card for use in a device.
Main Desktop on Pinebook
This screenshot is from Netrunner on the Pinebook, and you can see the purple-ish Calamares logo labeled “First Time Run This Installer” on the desktop — it’s partly hidden by the system information KCM. That runs Calamares in OEM mode, hardly distinguishable from the live-ISO-installer-mode that it usually has.
A Calamares OEM configuration generally:
- Resizes the image file to fill the entire card,
- Creates a user (the real one, personalised) with a password,
- Performs some initial configuration of the real user,
- Adds packages and system configuration based on that configuration, and
- Does some cleanup (e.g. removing Calamares, since you only need it once).
Configuring Calamares as an OEM installer is no different from any other Calamares installation: make sure the config files end up in /etc/calamares, and then set dontChroot to true (that’s the real difference between OEM mode and regular).
The way Calamares development works, downstreams — that is the distro’s, and in this case Netrunner — just file feature requests for the stuff they need in Calamares, and after some back-and-forthing to make sure it’s sufficiently general, I write it. So the run up to Netrunner on the Pinebook saw some Calamares development aimed specifically at the OEM mode, and some extra bug reports. Nothing, though, that isn’t equally applicable to any other distro that needs a first-run installer.
There is a lot more that could be done in a first-run installer. KaOS has a really nice one, basically hand-holding through initial KDE Plasma Desktop setup. Pardus and Pisi Linux have something similar. A downside is that the more you do, the more specialized it becomes — it would be nice to have a good GNOME counterpart to the Plasma Look-and-Feel selection module in Calamares, but that quickly leads to a multitude of modules and dependencies (not to mention that I can’t write it all myself).
Anyway, that’s my little square inch claim to being useful to the Netrunner Pinebook project (which deletes itself).
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!
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.
“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 
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.
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.
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 modelI 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.
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.