KDE

Today we release the next version of LabPlot – 2.1.0. The summary of all new features was given already in the announcement of the release candidate. Only couple of small fixes were made after the release candidate was announced. Starting with this ... [More] release we’ll provide two versions of LabPlot – the first based on KDE4-libs and the second based on KDE Frameworks 5 (KF5). For the next release we plan to finish and to integrate the code written during GSoC2015. For more information on the features to be expected in the next release(s) see the following blogs: http://datapicker.blogspot.com/2015/08/datapicker-for-labplot-gsoc-project.html http://garvitdelhi.blogspot.com/2015/08/final-evaluation.html https://minh.fedorapeople.org/2015/08/21/gsoc-last-report.html Only smaller improvements and fixes will be added in addition to the main features described in the blogs mentioned above. [Less]

As I wrote in part one of this series, we are currently creating Human Interface Guidelines (HIG) for phone user interfaces for KDE applications. In this part, I want to tell a bit more about the process of creating these guidelines. This is rougly ... [More] the process we’re planning to follow from the first idea brainstorming to a finished guideline: Step 1: Identify which guidelines are needed First of all, we have to find out where guidelines are needed. There are different sources for this. One source are the already existing, desktop-specific KDE HIG. There we can identify the cases where what we suggest for desktop applications can’t be transferred 1:1 to phone user interfaces, and then write the phone-specific guidelines accordingly. Another source are of course the HIG users, i.e. mostly developers and interaction designers. From time to time, we explicitly ask them where they need guidelines the most, or they come to us telling us what they need. A third source are other phone HIGs, like for example the Material Design Guidelines. They’ve been written based on past experience with what mobile app designers and developers need, so it makes sense to check out what they define, as it’s likely our designers and developers will need the same information. Step 2: Brainstorm The extent of this step depends on the specific topics. Things like defining how checkboxes should be used involve more “dull” work and less creativity, whereas more innovative parts like navigation patterns involve more creative ideation. Our brainstorming usually happens on a Telegram group we have created for that purpose. There everyone can present their ideas, we discuss them, weigh the pros and cons. Then we have to think about edge cases to prevent bad surprises later on. Once we think our ideas are solid, we can go to the next step Step 3: First draft Now it is time to write a first draft of the HIG. If it is an addition to an existing HIG page which just details phone-specific guidelines, the existing page has to be separated into global and desktop-specific parts and then the phone-specific parts are added. This is mostly work on the details. If the HIG is completely phone-specific, it has to be created from scratch. The challenge is to find the sweet spot of “as long as necessary, as short as possible”. Too many details, and it risks becoming too long for people to want to read it. Too few details, and we risk a lack of consistency between applications because everyone interprets it differently. A good HIG of course also has to be understandable and to feel useful for its readers. Step 4a: Discussion on the mailing list The draft is then sent to the KDE Guidelines mailing list (you’re invited to subscribe to it here if you’re interested) where everyone interested can give feedback. Particularly (but not only) developers are invited to give feedback on technical feasibility here. In this step, the HIG is iterated until no more suggestions for improvements are coming in. Step 4b: Creating a library implementation of the HIG If the HIG describes a specific part of a user interface (which most of them do, except for very generic ones such as wording or icon usage), a developer creates a library implementation (for example a shared QtQuick Component) which allows developers to easily implement the HIG without starting from scratch. This happens ideally in parallel with the discussion on the mailing list. Creating a library implementation is very important because the HIGs are much more likely to be followed correctly – and much more likely to be followed at all – if following them makes a developer’s life easier, not harder. The library implementation is at the same time also a first test case for both the clarity of the HIG and the technical feasibility of implementing it, often resulting in valuable feedback from the developer creating them. Stop 5: Finalizing and publishing the HIG When all the designers and developers involved are happy with the state of the HIG, it is time to put it on the HIG Wiki. This is the point where the HIG is ready for use by designers and developers. HIGs as living documents That does not mean it’s set in stone yet, however. While the API of the components should be kept as stable as possible, the HIG itself has only existed in a vacuum up to that point. It still has to see implementation in real application user interfaces, where we can test prototypes with real users and see how our ideas which were sound in theory hold up in practice. Based on the feedback from these tests and experience with implementing it in general, the HIG may still be refined later on. On the one hand, we don’t want to force developers to continuously adapt their user interfaces to ever-changing HIGs, but on the other hand, setting a HIG in stone and refusing to update it with new knowledge would prevent us from providing users the best experience we can. The next (and probably last) part of the series will describe the application of the HIGs in the design of a KDE application’s phone user interface. You will have to be a bit patient for that one, though, because we’re only just starting the design work which the post is going to talk about.Filed under: KDE [Less]

At the beginning of this month, KDE held a sprint for KDevelop and Kate, where a bunch of us met and coded like crazy. I was the first to arrive, in the morning of the 7th of October and around 10, and since I couldn’t get in the apartment till 14 I ... [More] had some time to kill. So I decided to go for a little sight seeing in the nearby park. In the evening people started to arrive, and started coding before unpacking. My first impression of them was: “These people really love to code”. During this sprint I’ve worked on several things: I’ve improved the docker image with the Qt Android applications using CMake build toolchain, and done some tests with my QML android app. I’ve started building KDevelop on Windows. I say started because I’ve never managed to finish it. Why? Because I ran out of disk space on my Windows tablet while building KF5. But, putting all this aside, most importantly I’ve learned many things from the others. Most importantly: “Code for fun; Code because I like it; Code because I want to do something right. Don’t treat these projects like a job, where if I don’t do everything I’ll get fired.” (Milian Wolff – He didn’t say it exactly like that, but close enough) I’ve learned how to better balance my free time, and work on my hobbies when I’m in the right state of mind, and well rested; and to stop being stressed all the time because there are bugs in the code and they need urgent fixing. I can say that since then, I’ve changed my approach and I’m now more relaxed, and less stressed. I’ve organised myself better, and my contributions are more compact. [Less]

After a bit more work, toolbars (and other places ;=) have icons, too. More Kate plugins do work, like the nice project plugin I use the whole day, see: Updated .dmg files can be found at (alpha quality, only tested on Mac OS 10.10): ... [More] ftp://kate-editor.org/cullmann/kate-20151024.dmg ftp://kate-editor.org/cullmann/kwrite-20151024.dmg Help to get more stuff working and fix the remaining crashs is highly appreciated. A script how to build that all can be found at: https://quickgit.kde.org/?p=kate.git&a=blob&f=mac.txt You can use a plain Qt and current KDE Frameworks & Kate master to get that running. Guess the next goal would be to get KIO working without patching Qt, lets see how much work that is. P.S. With the guide in mac.txt you should be able to try out how to port other KDE based applications, too, and get a application bundle, as most stuff should be available now, for the average application. How to use some bundled Breeze icon set can be found here, just call code like that after QApplication is constructed: https://quickgit.kde.org/?p=kate.git&a=blob&f=icons.h Where to put the Breeze resource see mac.txt (its actually toplevel in the <app>.app folder, not in Resources like told by Qt docs). [Less]

On the road to a Calligra with no more need of the porting util KDELibs4Support another milestone has been passed: Karbon now also is based purely on Qt5 and KF5. As with the other ported Calligra apps, some small glitches here and there and then ... [More] the old bugs. Well, work in progress :) You might have discovered on the screenshot that the Stencil box is shown, which in Calligra versions 2.x and before was exclusive to Calligra Flow. Adding stencils for flow diagrams and other things can be also useful in presentations or text documents, so the Stencil box will be made generally available in Calligra 3. It still needs to be thought about how to perhaps merge it with the general Shape box, that is left for later for now and surely something to work on with the VDG. Calligra Flow itself has not seen any porting efforts so far, as the plan is to rewrite it using Karbon components, given that Calligra Flow handles the same document type as Karbon, rich vector graphic documents. The main difference has been that Karbon only supports single-page documents, while Calligra Flow also supports multiple pages. And both UIs have been targetting different use cases. The idea and goal here is the same as with e.g. Calligra Words and Calligra Author: reusing components while providing optimized UI for the different usecases. For now though we are still in the porting phase: get rid of “KDELibs4Support” completely, fix any regressions and then some bugs, also get all unit tests to pass again. So no dreaming about future features yet, first we need a real base for that. There are still 21 matches in 16 CMakeLists.txt files on “KDELibs4Support” in Calligra’s codebase, sigh… Calligra Sheets, Calligra Plan and Calligra Gemini are still awaiting their final port. So time to get back to the KDevelop window… ;) [Less]

KDE Project: KDE GeneralToday I have the pleasure to announce that Marble is the first popular virtual globe that ships and visualizes the Behaim Globe. The Behaim Globe is the oldest surviving terrestrial globe on earth. It was created between 1492 ... [More] and 1493 - yes at the same time when Christopher Columbus made his first voyage towards the west and "discovered" America. This fact makes the Behaim Globe very special and also subject to scientific research: It documents European cartography during that era and it's probably the only historic globe which completely lacks the American continent. These days the Behaim globe can be visited in the Germanisches Nationalmuseum in Nuremberg, Germany. The Germanisches Nationalmuseum (GNM) has kindly granted the Marble project permission to release the photo scan material of the Behaim Globe under the CC BY-SA 3.0 license and they have supported us in bringing it for the first time to the users of a widely deployed virtual globe: Marble. Right now our users can immediately download the Behaim Globe from inside Marble by entering File->Download Maps (or download it via our maps download website.). Starting with the next Marble release scheduled for December 2015 the Behaim Globe map theme will become a regular part of the map themes that are shipped with the Marble installation package by default. In addition the Marble project released a special Behaim Marble version in the Google Play Store. So users of Android devices – like smartphones and tablets – can enjoy the Behaim Globe, too! This also marks the first public release of a Marble based application on Android devices. The Behaim map theme for Marble was created as part of the master thesis (Diplomarbeit) 3D Modelling of the Behaim Globe using Marble by Halimatou Poussami. The map theme allows to pan and zoom the whole Behaim Globe - curiously the whole globe is almost fully covered with detailed inscriptions in early modern German. Via checkboxes in the legend tab inside Marble our users can also overlay today's accurate coastlines. This allows to compare the Behaim cartography with today's known actual coastlines. Quite obviously the Behaim map depicts the continents stretched in longitude. So the creators of the Behaim Globe have probably based their globe on an earth radius value that was too small. The photographic material of the Behaim Globe is based on digital scans made by the Friedrich Alexander University (FAU) in Erlangen-Nuremberg and the IPF TU Wien. These scans were performed using polarized light. This is also part of the reason for the vibrant colors that you can see in the map theme - visually the colors of the Behaim globe are much more subdued. During the past centuries the Behaim Globe has been subject to several "restoration attempts" and "editing", which also resulted e.g. in text changes. Therefore today's scientific research also focuses on the Behaim globe as a palimpsest. Using Marble's legend tab our users can compare the photomaterial of the Behaim Globe with facsimile drawings from 1853 and 1908 which also reveals differences. The Marble Team would like to thank the Germanisches Nationalmuseum for its decision to release the Behaim imagery under the CC BY-SA 3.0 license. In particular we'd like to thank Dr. Thomas Eser (GNM), Prof. Dr. Günther Görz (FAU) and Halimatou Poussami for their active support in bringing the Behaim Globe to our Marble users and to the public! [Less]

KDE Project: KDE GeneralToday I have the pleasure to announce that Marble is the first virtual globe with major deployment that ships and visualizes the Behaim Globe. The Behaim Globe is the oldest surviving globe on earth. It was created between ... [More] 1492 and 1493 - yes during the same period of time when Christopher Columbus made his first voyage towards the west and discovered America. This fact makes the Behaim Globe very special and also subject to scientific research: It documents European cartography during that era and therefore it's probably the only historic globe which completely lacks the American Continent. These days the Behaim globe can be visited in the Germanisches Nationalmuseum in Nuremberg, Germany. The Germanisches Nationalmuseum (GNM) has kindly granted the Marble project permission to release the photo scan material of the Behaim Globe under the CC BY-SA 3.0 license and they have supported us in bringing it for the first time to the users of a widely deployed virtual globe: Marble. Right now our users can immediately download the Behaim Globe from inside Marble by entering File->Download Maps (or download it via our maps download website.). Starting with the next Marble release scheduled for December 2015 the Behaim Globe map theme will become a regular part of the map themes that are shipped with the Marble installation package by default. In addition the Marble project released a special Behaim Marble version in the Google Play Store. So users of Android devices – like smartphones and tablets – can enjoy the Behaim Globe, too! This also marks the first public release of a Marble based application on Android devices. The Behaim map theme for Marble got created as part of the master thesis (Diplomarbeit) 3D Modelling of the Behaim Globe using Marble by Halimatou Poussami. The map theme allows to pan and zoom the whole Behaim Globe - curiously the whole globe is almost fully covered with detailed inscriptions in early modern German. Via checkboxes in the legend tab inside Marble our users can also overlay today's accurate coastlines. This allows to compare the Behaim cartography with today's known actual coastlines. Quite obviously the Behaim map depicts the continents stretched in longitude. So the creators of the Behaim Globe have probably based their globe on an earth radius value that was too small. The photographic material of the Behaim Globe is based on digital scans made by the Friedrich Alexander University (FAU) in Erlangen-Nuremberg and the IPF TU Wien. These scans were performed using polarized light. This is also part of the reason for the vibrant colors that you can see in the map theme - visually the colors of the Behaim globe are much more subdued. During the past centuries the Behaim Globe has been subject to several "restoration attempts" and "editing", which also resulted e.g. in text changes. Therefore today's scientific research also focuses on the Behaim globe as a palimpsest. Using Marble's legend tab our users can compare the photomaterial of the Behaim Globe with facsimile drawings from 1853 and 1908 which also reveals differences. The Marble Team would like to thank the Germanisches Nationalmuseum for its decision to release the Behaim imagery under the CC BY-SA 3.0 license. In particular we'd like to thank Dr. Thomas Eser (GNM), Prof. Dr. Günther Görz (FAU) and Halimatou Poussami for their active support in bringing the Behaim Globe to our Marble users and to the public! [Less]

Ever since our first kickstarter in 2014, we've been building every release of Krita for OSX. The initial work to make that possible took two weeks of full-time hacking. We did the work because Krita on OSX was a stretch goal and we wanted to show ... [More] that it was possible to bring Krita to OSX, not because we thought two weeks would be enough to create a polished port. After all, the port to Windows took the best part of a year. We didn't make the stretch goal, and the port to OSX got stuck. And that shows. We build Krita on a mid-2011 Mac Mini that runs Mavericks. That has a couple of consequences: Krita doesn't run well on anything but Mavericks, and the hack-build-test cycle takes about half an hour. That means that fixing bugs is nigh on impossible. Some things have been broken since the start, like OpenGL, other things broke along the way, like proper tablet support, loading and saving jpeg files. And more. Still, though we didn't make the stretch goal, the demand for Krita on OSX is there: we're getting about half a dozen queries a week about Krita on OSX. So, what should be the next steps? Step one: define the goals. That's easy. Krita on OSX should run on all versions of OSX that are supported by Qt5, be a good citizen, that is, come as an app bundle in a disk image, save settings to the usual locations, use the regular temporary file location and provide the same feature set and performance as on Windows and Linux. (Which might be difficult because of problems with Apple's OpenGL implementation: Apple wants developers to use their platform-specific alternative.) Step two: estimate the effort needed. With the Qt5/Kf5 port of Krita, estimation is more difficult because only now people are creating the first Kf5-based applications on OSX, and are running into new and interesting problems. Things like finding resources in standard locations: for Krita 2.x, we had to hack KDE's standard paths implementation quite severely. The main issues are: OpenGL, tablet support, standard paths, bundle creation, platform integration and optimization. My best effort estimation is three to four months of nearly full-time work. That's similar to the Qt5 port, and comes to about 12,000 to 16,000 euros. Add in a decently fast Mac, and we're looking at, roughly, an investment for 15,000 to 19,000 euros. Add a bit for unexpected events, and let's say, 20,000 euros. A lot of money, but actually quite cheap for a development effort of this kind. It's more than the Krita Foundation has availabe, though... There is a secondary consideration, borne from experience with the Kf5/Qt5 port: if it will take three months of development time, then that development time is not spent on other things, like bug fixes or kickstarter features. That will have an immediate impact on the project! The port has already made the bug list grow horribly long, because work on the port meant less work on bug fixes. If we decide to it, step three then must be: do it... There are a couple of possibilities. The first: run a kickstarter campaign to get the money. Wolthera and I actually started setting one up. But we're just not sure whether a kickstarter campaign is going to succeed, and to fail would be really bad. It would reflect badly on Krita as a wider project and might jeopardize the 2016 kickstarter campaign to fund the next round of feature improvements. It might even cannibalize the 2016 campaign. We're not sure how likely that is, though, because we're not sure the campaigns would be targetting the same user group. Right now, our campaigns are supported in equal parts by free software enthousiasts and by artists. We're not reaching the OSX community, because Krita isn't ready on OSX, but conversely, we don't know how to reach the OSX community. We don't even know whether the OSX community can be involved enough to reach a funding level of at least 15,000 euros. That makes starting a kickstarter campaign (which is in itself two months of full-time work) a really dicy proposition. Even cutting the goal up into tranches of 5000 euros for the basic port (and a new Mac) and then stretch goals of 2500 euros seemed chancy to us. Plus, if we get stuck at 5000 euros there really is not enough money to do a decent port. The second possibility: fund it out of pocket, and try to get the investment back. That could be done by making Krita for OSX exclusively available on Steam, or by a possible increase in donations because we can now reach the OSX user community. The first option could be scotched by someone taking our work and making Krita available gratis on OSX. That would be totally OK of course: Krita is free and open source. Nothing says we have to give our binaries aways, but on the other hand, nothing can stop anyone else from giving our binaries away. Or making their own, once the hard work is done. The second possibility, increased donations, is a kind of gamble. It might work out, or it might not... The third possibility: fund the development out of pocket, but take a longer period to work on it. Get a Mac and devote, say, two weeks of initial work, and then invest a day a week to OSX. Slice up the week. A bit like I'm now doing four days a week of paid non-krita development to fill up my empty bank account, one day a week of porting and one day a week of stable-version bug fixing. The final possibility is to do nothing. Maybe a capable OSX-loving developer will come around and start doing the work out of love for Krita. But I'm not sanguine about that happening, since we've seen four or five people trying to build Krita on OSX, and all but two failed. The first attempt was using MacPorts, which doesn't lead to an installable app bundle, and the second attempt was the one done for the 2014 Kickstarter. Which brings us full-circle to the question: what now? [Less]

Update4: Albert Astals Cid mentioned that KDE maintains also a version of that script: draw_lib_dependenciesUpdate3: Marco Nelissen fixed an issue, that caused dependency resolution to break, as soon MAXDEPTH was reached once. This issue was fixed ... [More] now and I am quite happy that this old script is still useful and even get's improved. The updated version can also be found at dependencies.sh. Version below fixed as well.Update2: pfee made some more fixes. The script parses now the dependcies tree correctly using readelf and ldd so that only direct dependencies apear in the graph. The updated version can also be found at dependencies.shUpdate: Thanks to the feedback from pfee, I made some fixes to the script. The script is now also available for direct download dependencies.shSometimes it is useful to know the library dependencies of an application or a library on Linux (or Unix). Especially OpenSource applications depend on lot's of libraries which in turn depend on other libraries again. So it is not always quite clear which dependencies your software has.Imagine you want to package up your software for a customer and need to know on which libraries your software depends. Usually you know which libraries were used during development, but what are the dependencies of these libraries? You have to package all dependencies so that the customer can use and/or install your software.I created a bash-script which uses ldd to find the dependencies of a binary on Linux and Graphviz to create a dependency graph out of this information. Benedikt Hauptmann had the idea to show dependencies as a graph - so I cannot take credits for that. Using this script I created the depency graph of TFORMer, the report generator we are developing at TEC-IT. The result is a nice graph showing all the dependencies a user has to have installed before using TFORMer.Another beautiful graph is the one of PoDoFo. See below the graph of PoDoFo.The dependencies of Firefox are way more complex than the examples shown above...If you want to create a graph of your favorite application or library your self, get the script from here. I pulished the simple source code below. Graphviz is the only requirement. Usage is very simple, just pass an application or library as first parameter and the output image as second argument. The script will always create a PNG image:./dependencies.sh /usr/bin/emacs emacs.png./dependencies.sh /usr/local/lib/libpodofo.so \ podofo.pngThe code of the script is as follows: (Warning: the style sheet cuts of some lines, so better download the script from dependencies.sh)#!/bin/bash # This is the maximum depth to which dependencies are resolvedMAXDEPTH=14 # analyze a given file on its# dependecies using ldd and write# the results to a given temporary file## Usage: analyze [OUTPUTFILE] [INPUTFILE]function analyze{ local OUT=$1 local IN=$2 local NAME=$(basename $IN) for i in $LIST do if [ "$i" == "$NAME" ]; then # This file was already parsed return fi done # Put the file in the list of all files LIST="$LIST $NAME" DEPTH=$[$DEPTH + 1] if [ $DEPTH -ge $MAXDEPTH ]; then echo "MAXDEPTH of $MAXDEPTH reached at file $IN." echo "Continuing with next file..." # Fix by Marco Nelissen for the case that MAXDEPTH was reached DEPTH=$[$DEPTH - 1] return fi echo "Parsing file: $IN" $READELF $IN &> $READELFTMPFILE ELFRET=$? if [ $ELFRET != 0 ]; then echo "ERROR: ELF reader returned error code $RET" echo "ERROR:" cat $TMPFILE echo "Aborting..." rm $TMPFILE rm $READELFTMPFILE rm $LDDTMPFILE exit 1 fi DEPENDENCIES=$(cat $READELFTMPFILE | grep NEEDED | awk '{if (substr($NF,1,1) == "[") print substr($NF, 2, length($NF) - 2); else print $NF}') for DEP in $DEPENDENCIES; do if [ -n "$DEP" ]; then ldd $IN &> $LDDTMPFILE LDDRET=$? if [ $LDDRET != 0 ]; then echo "ERROR: ldd returned error code $RET" echo "ERROR:" cat $TMPFILE echo "Aborting..." rm $TMPFILE rm $READELFTMPFILE rm $LDDTMPFILE exit 1 fi DEPPATH=$(grep $DEP $LDDTMPFILE | awk '{print $3}') if [ -n "$DEPPATH" ]; then echo -e " \"$NAME\" -> \"$DEP\";" >> $OUT analyze $OUT $DEPPATH fi fi done DEPTH=$[$DEPTH - 1]} ######################################### main ######################################### if [ $# != 2 ]; then echo "Usage:" echo " $0 [filename] [outputimage]" echo "" echo "This tools analyses a shared library or an executable" echo "and generates a dependency graph as an image." echo "" echo "GraphViz must be installed for this tool to work." echo "" exit 1fi DEPTH=0INPUT=$1OUTPUT=$2TMPFILE=$(mktemp -t)LDDTMPFILE=$(mktemp -t)READELFTMPFILE=$(mktemp -t)LIST="" if [ ! -e $INPUT ]; then echo "ERROR: File not found: $INPUT" echo "Aborting..." exit 2fi # Use either readelf or dump# Linux has readelf, Solaris has dumpREADELF=$(type readelf 2> /dev/null)if [ $? != 0 ]; then READELF=$(type dump 2> /dev/null) if [ $? != 0 ]; then echo Unable to find ELF reader exit 1 fi READELF="dump -Lv"else READELF="readelf -d"fi echo "Analyzing dependencies of: $INPUT"echo "Creating output as: $OUTPUT"echo "" echo "digraph DependencyTree {" > $TMPFILEecho " \"$(basename $INPUT)\" [shape=box];" >> $TMPFILEanalyze $TMPFILE "$INPUT"echo "}" >> $TMPFILE #cat $TMPFILE # output generated dotfile for debugging purpossesdot -Tpng $TMPFILE -o$OUTPUT rm $LDDTMPFILErm $TMPFILE exit 0 [Less]

Some of the feedback we got, is that we should blog more about how we improve the quality, what kind of bugs we fixed. So today I want to do that with an in-depth explanation of four crash reports I looked at and fixed this week. All of them will go ... [More] be part of the upcoming 5.4.3 release. All of them were related to QtQuick with three of them being caused by a problem in QtQuick and one caused by a workaround for a QtQuick problem. As I explained in my Monday blog post we are getting hit by issues in the libraries we use, in this case QtQuick. Closing glxgears crashes KWin The first issue was communicated to me through IRC. After a small investigation together with the user we figured out the condition to crash it and how to reproduce it: 1. Use an aurorae window decoration theme (e.g. Plastik) 2. Open glxgears 3. close glxgears through the close button This got reported as Bug 346857 and was nothing new to us: we have had similar problems before, which makes it a little bit sad. The problem here is that glxgears doesn’t speak the close window protocol. Normally when you click the close button the window isn’t closed directly, but the window gets notified “please close your window”. So the mechanism is asynchronous. This also explains why such an issue has not been detected during the testing: it’s not happening with default decoration and it’s not happening with “normal” applications. It can only be reproduced with applications which do not behave correctly. So what’s the difference in this case? KWin handles the destruction in a synchronous way which causes the decoration to be destroyed in direct result of the mouse click. When the decoration is destroyed the QtQuick scene driving the decoration is also destroyed and it looks like Qt doesn’t like that: <code>#0 0x00007ffff50fd107 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #1 0x00007ffff50fe4e8 in __GI_abort () at abort.c:89 #2 0x00007ffff5de8291 in qt_message_fatal (context=..., message=...) at global/qlogging.cpp:1578 #3 0x00007ffff5de495c in QMessageLogger::fatal (this=0x7fffffff8ca0, msg=0x7ffff6104270 "ASSERT: \"%s\" in file %s, line %d") at global/qlogging.cpp:781 #4 0x00007ffff5dddb90 in qt_assert (assertion=0x7ffff67df129 "context() &amp;&amp; engine()", file=0x7ffff67df0e4 "qml/qqmlboundsignal.cpp", line=183) at global/qglobal.cpp:2966 #5 0x00007ffff6667fe7 in QQmlBoundSignalExpression::function (this=0xf56080) at qml/qqmlboundsignal.cpp:183 #6 0x00007ffff6667d4c in QQmlBoundSignalExpression::sourceLocation (this=0xf56080) at qml/qqmlboundsignal.cpp:155 #7 0x00007ffff663f1fb in QQmlData::destroyed (this=0x873d90, object=0xf54eb0) at qml/qqmlengine.cpp:1709 #8 0x00007ffff663cf6b in QQmlData::destroyed (d=0x873d90, o=0xf54eb0) at qml/qqmlengine.cpp:674 #9 0x00007ffff605c6e9 in QObject::~QObject (this=0xf54eb0, __in_chrg=&lt;optimized out&gt;) at kernel/qobject.cpp:912 #10 0x00007ffff7265df9 in QQuickItem::~QQuickItem (this=0xf54eb0, __in_chrg=&lt;optimized out&gt;) at items/qquickitem.cpp:2224 #11 0x00007ffff7324866 in QQuickMouseArea::~QQuickMouseArea (this=0xf54eb0, __in_chrg=&lt;optimized out&gt;) at items/qquickmousearea.cpp:439 #12 0x00007ffff72d69c5 in QQmlPrivate::QQmlElement&lt;QQuickMouseArea&gt;::~QQmlElement (this=0xf54eb0, __in_chrg=&lt;optimized out&gt;) at ../../include/QtQml/../../src/qml/qml/qqmlprivate.h:98 #13 0x00007ffff72d69fa in QQmlPrivate::QQmlElement&lt;QQuickMouseArea&gt;::~QQmlElement (this=0xf54eb0, __in_chrg=&lt;optimized out&gt;) at ../../include/QtQml/../../src/qml/qml/qqmlprivate.h:98 #14 0x00007ffff605e516 in QObjectPrivate::deleteChildren (this=0xf54c90) at kernel/qobject.cpp:1946 #15 0x00007ffff605cb80 in QObject::~QObject (this=0xf56050, __in_chrg=&lt;optimized out&gt;) at kernel/qobject.cpp:1024 #16 0x00007ffff7265df9 in QQuickItem::~QQuickItem (this=0xf56050, __in_chrg=&lt;optimized out&gt;) at items/qquickitem.cpp:2224 #17 0x00007ffff72c3e22 in QQuickRectangle::~QQuickRectangle (this=0xf56050, __in_chrg=&lt;optimized out&gt;) at items/qquickrectangle_p.h:128 #18 0x00007ffff72d6357 in QQmlPrivate::QQmlElement&lt;QQuickRectangle&gt;::~QQmlElement (this=0xf56050, __in_chrg=&lt;optimized out&gt;) at ../../include/QtQml/../../src/qml/qml/qqmlprivate.h:98 #19 0x00007ffff72d638c in QQmlPrivate::QQmlElement&lt;QQuickRectangle&gt;::~QQmlElement (this=0xf56050, __in_chrg=&lt;optimized out&gt;) at ../../include/QtQml/../../src/qml/qml/qqmlprivate.h:98 #20 0x00007ffff736a976 in QQuickView::~QQuickView (this=0x6b1980, __in_chrg=&lt;optimized out&gt;) at items/qquickview.cpp:225 #21 0x00007ffff736a9d2 in QQuickView::~QQuickView (this=0x6b1980, __in_chrg=&lt;optimized out&gt;) at items/qquickview.cpp:227 </code> Now in order to never have that happen again I created a test application and reported a bugreport against Qt. And of course we worked around the problem by delaying the handling of the close to the next event cycle. Now you might wonder how it’s possible that we allowed such a regression to sneak in again given that we had seen it before? Well that’s easily explained, up until recently we were not able to run full tests against KWin. We might have been able to unit test this area, but it would have passed, this issue needed an integration test. And that’s what I added now, so that we won’t hit it ever again. It’s probably the weirdest auto test I have ever written, involving starting glxgears (thanks to our sysadmins for installing it for this test case!), simulating the mouse click on the close button and ensuring glxgears closes without crashing KWin. Crash when opening window decorations configuration module The second crash I run into directly after investigating the first one. I wanted to switch back to Breeze decoration but couldn’t because the config module crashed directly. This was bug 344278 – a really nasty one with 74 duplicates. We had wonderful crash traces, but missed the important part about how to reproduce it. From the crash trace alone we were not able to figure out what’s going on. Well we saw some aspects but it wasn’t enough to properly investigate. Now alas I had a 100 % sure way to reproduce the problem and also understood what’s going on. So here the actual steps to reproduce: 1. Open Window decoration configuration menu 2. Download many themes, many of them, the more the better 3. Select a theme which name’s first latter is far away from “B”, e.g. Plastik. 4. Apply and quit 5. Open window decoration configuration menu again And boom! What happens is that we load all decorations and put them into a ListView, then we select the theme the user is currently using and ensure it’s centered in the list view. This results in the list view scrolling. ListView has a cache of elements and if you have too many it will throw out other elements. So our Breeze deco which gets created at the start (early in alphabet, will be shown) is kicked out again when selecting Plastik if there are too many decorations. This is the requirement to have many themes installed and also to select one far down in the alphabet. With anything else you won’t trigger it. The bug itself got triggered through Breeze decoration because there is a Property animation running which triggers another update on the decoration after it has been kicked out. It accesses a member which got destroyed by the QtQuick engine. All of that also means that the crash would not have been triggered if that code would have been e.g. in Oxygen and not in Breeze. Because then it would not have hit. Also just scrolling in the list after it loaded even if you have many installed, won’t trigger the crash, because then the animation is no longer running. It’s only running after loading in the preview. What I want to show here is that this is an extremely hidden corner case to find. You must have exactly the same conditions to trigger it. Given that I’m also surprised that we have so many duplicates for the report. So how to fix it? Obvious idea: one could disable the anyway not visible animation in Breeze. But that’s not a fix, that’s just a workaround and doesn’t solve the actual problem. Other decorations might trigger that again. So we need to understand what’s going on. What we knew is that the Decoration triggers an update and crashes because the DecorationBridge is no longer valid. But that’s impossible! The contract of the KDecoration API is that the DecorationBridge will always be valid if there’s a Decoration. So how could the contract break? For this we need to look into how the QtQuick code for rendering the previews works. Each Decoration is wrapped by a PreviewItem and each decoration gets it’s own DecorationBridge provided by a PreviewBridge. The PreviewBridge is directly constructed through QtQuick, the Decoration is loaded later on. What is now interesting is the tear down. When the PreviewItem gets destroyed by QtQuick it doesn’t delete the Decoration directly, but delays it to the next event cycle. So the Decoration outlives the QtQuick items. When the PreviewItem gets destroyed by QtQuick also the PreviewBridge gets destroyed by QtQuick and thus we have a Decoration which is still alive, but the PreviewBridge isn’t. Why was it done that way? Well to prevent crashers caused by QtQuick. So our workaround for a crash just introduced a new one. Meh. The solution now is to also delay the deconstruction of the PreviewBridge to the next event cycle. I hope this does not again create a new crash. Crash when exiting Screens configuration module The third issue I looked into was also reported to me in response to my Monday’s blog post. This one was supposed to be fixed in Qt 5.5, but wasn’t. It has a clear way to reproduce it: 1. Open Systemsettings 2. Go to “Display Configuration” 3. Click “All Settings” to go back to overview According to our users that should crash it. Just it doesn’t. This raised my interest – also that it has 73 duplications which makes it rather important. I know the user who reported this to me and know that I can fully believe what he tells me. So this crash raised my interest. It also has a very interesting crash trace: <code>#0 0x00007ffff2e48d59 in QQuickItemPrivate::addToDirtyList (this=0xdbdcc0) at /mnt/AUR/qt5-declarative-git/src/qt5-declarative/src/quick/items/qquickitem.cpp:5610 #1 0x00007ffff2e48e43 in QQuickItemPrivate::dirty (this=0xdbdcc0, type=&lt;optimized out&gt;) at /mnt/AUR/qt5-declarative-git/src/qt5-declarative/src/quick/items/qquickitem.cpp:5594 #2 0x00007ffff2e496cd in QQuickItem::update (this=0xdbdc40) at /mnt/AUR/qt5-declarative-git/src/qt5-declarative/src/quick/items/qquickitem.cpp:4088 #3 0x00007ffff2e56c0d in QQuickItem::qt_static_metacall (_o=&lt;optimized out&gt;, _c=&lt;optimized out&gt;, _id=&lt;optimized out&gt;, _a=&lt;optimized out&gt;) at .moc/moc_qquickitem.cpp:597 #4 0x00007ffff45f2ae1 in QObject::event (this=this@entry=0xdbdc40, e=e@entry=0x7fffc41f80b0) at kernel/qobject.cpp:1239 #5 0x00007ffff2e53a63 in QQuickItem::event (this=0xdbdc40, ev=0x7fffc41f80b0) at /mnt/AUR/qt5-declarative-git/src/qt5-declarative/src/quick/items/qquickitem.cpp:7294 #6 0x00007ffff6087d94 in QApplicationPrivate::notify_helper (this=this@entry=0x681dd0, receiver=receiver@entry=0xdbdc40, e=e@entry=0x7fffc41f80b0) at kernel/qapplication.cpp:3717 #7 0x00007ffff608d2c8 in QApplication::notify (this=0x7fffffffe4a0, receiver=0xdbdc40, e=0x7fffc41f80b0) at kernel/qapplication.cpp:3500 #8 0x00007ffff45c49dc in QCoreApplication::notifyInternal (this=0x7fffffffe4a0, receiver=0xdbdc40, event=event@entry=0x7fffc41f80b0) at kernel/qcoreapplication.cpp:965 #9 0x00007ffff45c7dea in sendEvent (event=0x7fffc41f80b0, receiver=&lt;optimized out&gt;) at ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:224 #10 QCoreApplicationPrivate::sendPostedEvents (receiver=receiver@entry=0x0, event_type=event_type@entry=0, data=0x681430) at kernel/qcoreapplication.cpp:1593 #11 0x00007ffff45c8230 in QCoreApplication::sendPostedEvents (receiver=receiver@entry=0x0, event_type=event_type@entry=0) at kernel/qcoreapplication.cpp:1451 #12 0x00007ffff4617f63 in postEventSourceDispatch (s=0x6d7aa0) at kernel/qeventdispatcher_glib.cpp:271 #13 0x00007fffefcce9fd in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #14 0x00007fffefccece0 in ?? () from /usr/lib/libglib-2.0.so.0 #15 0x00007fffefcced8c in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0 #16 0x00007ffff4617fd7 in QEventDispatcherGlib::processEvents (this=0x6d5850, flags=...) at kernel/qeventdispatcher_glib.cpp:418 #17 0x00007ffff45c339a in QEventLoop::exec (this=this@entry=0x7fffffffe380, flags=..., flags@entry=...) at kernel/qeventloop.cpp:204 #18 0x00007ffff45cb23c in QCoreApplication::exec () at kernel/qcoreapplication.cpp:1229 #19 0x00007ffff592cbf4 in QGuiApplication::exec () at kernel/qguiapplication.cpp:1528 #20 0x00007ffff6084bb5 in QApplication::exec () at kernel/qapplication.cpp:2977 #21 0x000000000040f52b in main (argc=1, argv=&lt;optimized out&gt;) at /mnt/AUR/systemsettings-git/src/systemsettings/app/main.cpp:55 </code> The interesting part here is that it’s completely inside Qt. We come from the event loop and an event is handled inside Qt and crashes. No code of the control module is executed in this trace any more. But why am I not able to reproduce? After all there are so many users hitting it. I have the same Qt version, so it should crash. That I figured it out was pure chance. I remembered that the user has an NVIDIA system and I verified that this is still the case. I have an Intel system. So why is that important? For NVIDIA QtQuick uses threaded rendering, while for Mesa it uses the main gui thread for rendering. I had seen in the past that with threaded rendering destruction might be moved to the next event cycle. So easy thing to test: QSG_RENDER_LOOP=threaded systemsettings5 and follow the reproduction steps and boom! Yay, I have a test case. Following the old saying: “consider a bug fixed when a developer is able to reproduce” the hardest way was solved. So I started investigating. Let’s try with kcmshell5 instead of systemsettings. Hmm doesn’t crash. Let’s try with kscreen’s test application instead of systemsettings. Hmm, doesn’t crash. So something in systemsettings must trigger it! And I started reading code and read and read, tried here something, tried there something and come to the conclusion: systemsettings is not doing anything wrong. Given that it must be the QtQuick code of the screen configuration. After some trials I had a minimal derivation to the QtQuick code which didn’t crash any more. Here again helped previous experience with QtQuick related crashers: I saw some usage of QtGraphicalEffects and remembered that this one used to crash KWin with the Breeze Aurorae Theme prior to Plasma 5.2. Removing the OpacityMask didn’t crash. Yay! So how to get that into a fix? The solution was actually in the debug output of QtQuick: QSGDefaultLayer::bind: ShaderEffectSource: ‘recursive’ must be set to true when rendering recursively. So obviously I set this missing recursive on the OpacityMask. Hmm, compile error, that doesn’t exist. So let’s make it non recursive and there we go, it doesn’t crash any more. I would love to report this to Qt, but so far I failed with creating a simple test case. Just like with my testing with kcmshell5 and the kscreen test application I’m not able to hit the condition and I haven’t figured out yet what is different in systemsettings. Opening effects configuration twice crashes The last issue to look at was triggered through the previous issue. During review it was pointed out that there are more QtQuick configuration modules which crash in similar ways. So I tried them all and hit a crash if: 1. Open Systemsettings 2. Go to Desktop Behavior 3. Click Desktop Effects 4. Click All Settings 5. Repeat steps 2 and 3 Again a very interesting back trace: <code>#0 0x00007ffff28e7107 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #1 0x00007ffff28e84e8 in __GI_abort () at abort.c:89 #2 0x00007ffff35d2291 in qt_message_fatal (context=..., message=...) at global/qlogging.cpp:1578 #3 0x00007ffff35ce95c in QMessageLogger::fatal (this=0x7fffffff3920, msg=0x7ffff38ee270 "ASSERT: \"%s\" in file %s, line %d") at global/qlogging.cpp:781 #4 0x00007ffff35c7b90 in qt_assert (assertion=0x7ffff1f9276a "value.isString()", file=0x7ffff1f92710 "jsruntime/qv4runtime.cpp", line=439) at global/qglobal.cpp:2966 #5 0x00007ffff1ddb5eb in QV4::RuntimeHelpers::convertToObject (engine=0x139a400, value=...) at jsruntime/qv4runtime.cpp:439 #6 0x00007ffff1ddcc6e in QV4::Runtime::getProperty (engine=0x139a400, object=..., nameIndex=136) at jsruntime/qv4runtime.cpp:682 #7 0x00007ffff1dca362 in QV4::Moth::VME::run (this=0x7fffffff41d7, engine=0x139a400, code=0x7fffcc15f830 "\357\230\334\361\377\177", storeJumpTable=0x0) at jsruntime/qv4vme_moth.cpp:487 #8 0x00007ffff1dce656 in QV4::Moth::VME::exec (engine=0x139a400, code=0x7fffcc15f6c8 "\366\251\334\361\377\177") at jsruntime/qv4vme_moth.cpp:925 #9 0x00007ffff1d58eb3 in QV4::SimpleScriptFunction::call (that=0x7fffd3424010, callData=0x7fffd3424018) at jsruntime/qv4functionobject.cpp:564 #10 0x00007ffff1c93e14 in QV4::Object::call (this=0x7fffd3424010, d=0x7fffd3424018) at ../../include/QtQml/5.5.1/QtQml/private/../../../../../src/qml/jsruntime/qv4object_p.h:305 #11 0x00007ffff1e93cac in QQmlJavaScriptExpression::evaluate (this=0x2b7a690, context=0x1392ad0, function=..., callData=0x7fffd3424018, isUndefined=0x7fffffff4553) at qml/qqmljavascriptexpression.cpp:158 #12 0x00007ffff1e939a5 in QQmlJavaScriptExpression::evaluate (this=0x2b7a690, context=0x1392ad0, function=..., isUndefined=0x7fffffff4553) at qml/qqmljavascriptexpression.cpp:116 #13 0x00007ffff1e9c484 in QQmlBinding::update (this=0x2b7a670, flags=...) at qml/qqmlbinding.cpp:194 #14 0x00007ffff1e9cfac in QQmlBinding::update (this=0x2b7a670) at qml/qqmlbinding_p.h:97 #15 0x00007ffff1e9cab2 in QQmlBinding::expressionChanged (e=0x2b7a690) at qml/qqmlbinding.cpp:260 #16 0x00007ffff1e94d67 in QQmlJavaScriptExpressionGuard_callback (e=0x15ddbb0) at qml/qqmljavascriptexpression.cpp:361 #17 0x00007ffff1e72d0f in QQmlNotifier::emitNotify (endpoint=0x0, a=0x0) at qml/qqmlnotifier.cpp:94 #18 0x00007ffff1dfb3f6 in QQmlData::signalEmitted (object=0x33914f0, index=30, a=0x0) at qml/qqmlengine.cpp:763 #19 0x00007ffff384d31e in QMetaObject::activate (sender=0x33914f0, signalOffset=29, local_signal_index=1, argv=0x0) at kernel/qobject.cpp:3599 #20 0x00007ffff1df7906 in QQmlVMEMetaObject::activate (this=0x3391720, object=0x33914f0, index=44, args=0x0) at qml/qqmlvmemetaobject.cpp:1325 #21 0x00007ffff1df5436 in QQmlVMEMetaObject::metaCall (this=0x3391720, c=QMetaObject::WriteProperty, _id=42, a=0x7fffffff6860) at qml/qqmlvmemetaobject.cpp:841 #22 0x00007ffff1bb7432 in QAbstractDynamicMetaObject::metaCall (this=0x3391720, c=QMetaObject::WriteProperty, _id=42, a=0x7fffffff6860) at /home/martin/src/qt5/qtbase/include/QtCore/5.5.1/QtCore/private/../../../../../src/corelib/kernel/qobject_p.h:421 #23 0x00007ffff1df5e91 in QQmlVMEMetaObject::metaCall (this=0x2ca1900, c=QMetaObject::WriteProperty, _id=42, a=0x7fffffff6860) at qml/qqmlvmemetaobject.cpp:969 #24 0x00007ffff1bb7432 in QAbstractDynamicMetaObject::metaCall (this=0x2ca1900, c=QMetaObject::WriteProperty, _id=42, a=0x7fffffff6860) at /home/martin/src/qt5/qtbase/include/QtCore/5.5.1/QtCore/private/../../../../../src/corelib/kernel/qobject_p.h:421 #25 0x00007ffff3817ce1 in QMetaObject::metacall (object=0x33914f0, cl=QMetaObject::WriteProperty, idx=42, argv=0x7fffffff6860) at kernel/qmetaobject.cpp:294 #26 0x00007ffff1e14605 in QQmlPropertyPrivate::write (object=0x33914f0, property=..., value=..., context=0x3391390, flags=...) at qml/qqmlproperty.cpp:1308 #27 0x00007ffff1e13f47 in QQmlPropertyPrivate::writeValueProperty (object=0x33914f0, core=..., value=..., context=0x3391390, flags=...) at qml/qqmlproperty.cpp:1237 #28 0x00007ffff1e163ab in QQmlPropertyPrivate::writeBinding (object=0x33914f0, core=..., context=0x3391390, expression=0x3391bd0, result=..., isUndefined=false, flags=...) at qml/qqmlproperty.cpp:1597 #29 0x00007ffff1e9c567 in QQmlBinding::update (this=0x3391bb0, flags=...) at qml/qqmlbinding.cpp:198 #30 0x00007ffff1e9cfac in QQmlBinding::update (this=0x3391bb0) at qml/qqmlbinding_p.h:97 #31 0x00007ffff1e9cab2 in QQmlBinding::expressionChanged (e=0x3391bd0) at qml/qqmlbinding.cpp:260 #32 0x00007ffff1e94d67 in QQmlJavaScriptExpressionGuard_callback (e=0x15dd948) at qml/qqmljavascriptexpression.cpp:361 #33 0x00007ffff1e72d0f in QQmlNotifier::emitNotify (endpoint=0x0, a=0x0) at qml/qqmlnotifier.cpp:94 #34 0x00007ffff1dfb3f6 in QQmlData::signalEmitted (object=0x3391fc0, index=31, a=0x0) at qml/qqmlengine.cpp:763 #35 0x00007ffff384d31e in QMetaObject::activate (sender=0x3391fc0, signalOffset=31, local_signal_index=0, argv=0x0) at kernel/qobject.cpp:3599 #36 0x00007ffff384d120 in QMetaObject::activate (sender=0x3391fc0, m=0x7ffff2688b20 &lt;QQuickLoader::staticMetaObject&gt;, local_signal_index=0, argv=0x0) at kernel/qobject.cpp:3578 #37 0x00007ffff2432687 in QQuickLoader::itemChanged (this=0x3391fc0) at .moc/moc_qquickloader_p.cpp:321 #38 0x00007ffff2431370 in QQuickLoaderPrivate::incubatorStateChanged (this=0x2ca0700, status=QQmlIncubator::Ready) at items/qquickloader.cpp:666 #39 0x00007ffff24312e4 in QQuickLoaderIncubator::statusChanged (this=0x30f9e70, status=QQmlIncubator::Ready) at items/qquickloader.cpp:654 #40 0x00007ffff1e1f2ea in QQmlIncubatorPrivate::changeStatus (this=0x30f9e90, s=QQmlIncubator::Ready) at qml/qqmlincubator.cpp:701 #41 0x00007ffff1e1eab7 in QQmlIncubatorPrivate::incubate (this=0x30f9e90, i=...) at qml/qqmlincubator.cpp:368 #42 0x00007ffff1e1dd0e in QQmlEnginePrivate::incubate (this=0x13882d0, i=..., forContext=0x30f9db0) at qml/qqmlincubator.cpp:87 #43 0x00007ffff1e1a6d3 in QQmlComponent::create (this=0x15bfe90, incubator=..., context=0x2ca7160, forContext=0x0) at qml/qqmlcomponent.cpp:1068 #44 0x00007ffff24317a4 in QQuickLoaderPrivate::_q_sourceLoaded (this=0x2ca0700) at items/qquickloader.cpp:714 #45 0x00007ffff2430f10 in QQuickLoaderPrivate::load (this=0x2ca0700) at items/qquickloader.cpp:597 #46 0x00007ffff24319bf in QQuickLoader::componentComplete (this=0x3391fc0) at items/qquickloader.cpp:806 #47 0x00007ffff1ead859 in QQmlObjectCreator::finalize (this=0x31869c0, interrupt=...) at qml/qqmlobjectcreator.cpp:1207 #48 0x00007ffff1e1a094 in QQmlComponentPrivate::complete (enginePriv=0x13882d0, state=0x30b89a0) at qml/qqmlcomponent.cpp:928 #49 0x00007ffff1e1a17c in QQmlComponentPrivate::completeCreate (this=0x30b8900) at qml/qqmlcomponent.cpp:964 #50 0x00007ffff1e1a12c in QQmlComponent::completeCreate (this=0x1544040) at qml/qqmlcomponent.cpp:957 #51 0x00007ffff1e19953 in QQmlComponent::create (this=0x1544040, context=0x2bdd5f0) at qml/qqmlcomponent.cpp:791 #52 0x00007ffff24396e6 in QQuickView::continueExecute (this=0x134d440) at items/qquickview.cpp:476 #53 0x00007ffff2438617 in QQuickViewPrivate::execute (this=0x15c38c0) at items/qquickview.cpp:124 #54 0x00007ffff2438a2c in QQuickView::setSource (this=0x134d440, url=...) at items/qquickview.cpp:253 #55 0x00007fffd5c20a65 in KWin::Compositing::EffectView::init (this=0x134d440, type=KWin::Compositing::EffectView::DesktopEffectsView) at /home/martin/src/kf5/kde/workspace/kwin/kcmkwin/kwincompositing/model.cpp:613 </code> Like in the previous example it’s a crash deep down in Qt. The first code related to code we distribute is at stack position 55. So again I needed to experiment to figure out the minimal code which triggers the crash and after some trials I figured out what causes it: setting root context properties. After reworking this to no longer needing a context property, it doesn’t crash any more. Again this should be reported to Qt, bug so far I failed to create a simple example demonstrating the problem Of course setting a root context property works in my examples. If one of my readers have an idea what’s so special about systemsettings to trigger it, please let me know so that I can report bugs against Qt. Summary As we can see with these four cases: we are hit by issues further down in the stack. We can work around them, but this comes with a cost as it doesn’t fix the actual problem. Some of the problems are real corner cases, hardware dependent and cannot be reproduced by all developers. [Less]