Developer Blogs en Randa sprint wrap-up and considerations on packaging complex applications with AppImage <p>On Sunday, <a href="">this year&#8217;s KDE sprint in Randa, Switzerland</a> came to an end and I am now back home. It was a productive and fun week, as always when meeting the other KDE folks.</p> <figure id="attachment_466" style="width: 774px" class="wp-caption aligncenter"><a href="" rel="attachment wp-att-466"><img class="wp-image-466 size-full" src="" alt="Screenshot_20160620_234752" data-recalc-dims="1" /></a><figcaption class="wp-caption-text">Navigation widget in KDevelop with proper spacing and margins</figcaption></figure> <p>I spent a lot of time on polishing things and fixing small issues mostly in KDevelop, such as:</p> <ul> <li>reduce flickering of the completion widget in kdevelop</li> <li>fix various cases where KDevelop&#8217;s navigation widget (see above) would have weirdly large spacing in between or at the end</li> <li>fix kdev-python&#8217;s completion widget from being absurdly wide in full mode for long type names</li> <li>fix some <a href="">scoping issues</a> in kdev-python</li> <li>fix colors in kdevelop&#8217;s Find in Files widget</li> <li>use a nicely formatted file name in the window title when no project is open</li> <li>fix a few crashes</li> </ul> <h3>Open project dialog</h3> <p>One mentionable major task I did was to make the &#8220;Open project&#8221; dialog work properly on non-linux platforms; that required a bit of thinking, because before, you could open either a project manager config file (e.g. CMakeLists.txt) or a directory from the dialog. However, when using the native file dialog, you have to select in advance whether you want to select a file or a directory (can&#8217;t have both). The solution is to always select only the directory, and offer a choice of possible project managers (and the associated config files) later in the process.</p> <h3>Remove assistant overlay in favour of navigation widget</h3> <p>Another major thing Kevin Funk and I worked on was rethinking KDevelop&#8217;s assistant popup; especially in the current 5.0 betas, it tends to be a bit annoying and gets in the way a lot. We are thus trying to remove the assistant overlay in favour of offering executions of assistants from the navigation widget:</p> <figure id="attachment_467" style="width: 560px" class="wp-caption aligncenter"><a href="" rel="attachment wp-att-467"><img class="wp-image-467 size-full" src="" alt="Screenshot_20160620_235618" data-recalc-dims="1" /></a><figcaption class="wp-caption-text">&#8220;Adjust signature&#8221; assistant invoked from the navigation widget.</figcaption></figure> <p>It&#8217;s not working perfectly yet, but it is certainly much less agressive than the previous solution, while behaving very similar in terms of usage (Alt+1 still executes the first fix, etc.). It&#8217;s currently only in the <em>assistantpopup-ng</em> branch, but we hope to be able to merge that soon.</p> <h3>Packaging KDevelop with AppImage: advanced thoughs</h3> <p>For users stuck on old systems and for testing purposes, we&#8217;d like to be able to ship single-file executables containing KDevelop to users (<a href="">click here to get one</a>). One solution for creating such executables is AppImage. An AppImage basically contains a file system hierarchy containing all the things which cannot be reasonably assumed to be on the user&#8217;s system (it is not a container or chroot though, just a set of libraries and assets). In our case, that is most notably a recent version of Qt, some Qt plugins, various KDE frameworks, llvm, KDevelop itself, and libpython plus the kdevelop-python plugin.</p> <p>In order to start up KDevelop in this environment, various environment variables have to be set in order to make it access the things from the AppImage. Most notably, that is $PATH, $LD_LIBRARY_PATH, $XDG_DATA_DIRS and $QT_PLUGIN_PATH. Sounds simple enough, right? But now consider this: the user wants to run cmake from inside KDevelop. cmake is not shipped with the AppImage, but inherits this environment &#8212; and crashes, because it picks up a wrong version of some library from the bundle. The solution seems simple enough: undo the changes to LD_LIBRARY_PATH before launching cmake.<br /> However, in practice, how do you do that? We cannot undo the changes &#8220;globally&#8221;, because executables shipped with the AppImage, such asĀ  kioexec (used to open [remote] files) still need it even after KDevelop is running. One solution is to go over the code base and change it back everywhere manually where it&#8217;s required. But even that is not sufficient; library calls (like KRun::run) might start processes as well, and the calling application cannot influence those processes&#8217; environment directly.</p> <figure id="attachment_468" style="width: 800px" class="wp-caption aligncenter"><a href="" rel="attachment wp-att-468"><img class="wp-image-468" src="" alt="Screenshot_20160620_233936" data-recalc-dims="1" /></a><figcaption class="wp-caption-text">KDevelop with kdev-python running from an AppImage. The image was built on CentOS6 from 2011 (and runs there), and runs on a bleeding-edge Arch system. It should run on most things in between as well.</figcaption></figure> <p>The solution I finally managed to come up with, and which seems to work okay, is by using LD_PRELOAD. By setting this environment variable, you tell the dynamic linker to load your own versions of library functions instead of the ones it would otherwise load. What use is that to us? Well, when a program wants to start another program, it has to ask the operating system. That usually happens through calling a function from the glibc library. The most common function to launch a process is <a href="">execve()</a>. We can now provide a library in LD_PRELOAD which overrides the system&#8217;s execve() and does this:</p> <ul> <li>Look at the path of the process which is launched. <ul> <li>If the path is inside the AppImage, do nothing.</li> <li>Otherwise, modify the environment such that the changes we did for start-up of the application are rolled back (remove added components from $PATH, etc.).</li> </ul> </li> <li>Call the original system&#8217;s execve() to execute the program in the modified environment.</li> </ul> <p>It <em>is</em> quite a hack, but it does seem to work well, and the beauty is that you don&#8217;t have to scatter &#8220;change the environment back&#8221; code all over your application code.</p> <h3>AppImage: Next steps</h3> <p>I will clean up my exec-wrapper and publish it. I will also clean up my KDevelop build script, and try to create a docker image I can run it in, so that people can do that easily (not requiring them to set up a CentOS6 VM themselves).</p> <p>If you like what we&#8217;re doing in those sprints, consider <a href="">supporting us</a> so we can do another one next year <img src="" alt=" Mon, 20 Jun 2016 22:22:16 +0000 sven KDevelop 5.0 standalone executable for Linux <p>I am currently at the <a href="">KDE sprint in Randa</a>, Switzerland. There are about 40 nice people here, working on making KDE software awesome. This year&#8217;s focus is on deploying our software more nicely &#8212; on Windows and OS X, but on Linux as well.</p> <figure id="attachment_459" style="width: 800px" class="wp-caption aligncenter"><a href="" rel="attachment wp-att-459"><img class="wp-image-459" src="" alt="randa" data-recalc-dims="1" /></a><figcaption class="wp-caption-text">The landscape around our sprint location</figcaption></figure> <p>Especially for user-faced applications like KDevelop, it really makes a big difference whether you use today&#8217;s version, or the one from two years ago. Many people run quite old Linux distributions, which do not provide up-to-date packages for KDevelop. Another situation where it can be hard to use an up-to-date version of our software is when you are at your workplace or at a university computer pool, and do not have privileges to install software. Thus in this week, besides enjoying the landscape, I spent some time building a stand-alone KDevelop executable. It is available from here: <a href=""></a>. The version from 16th June 2016 contains the beta version of KDevelop 5 from the master branch, including the new clang-based C++ plugin and the Python 3 language support plugin.</p> <p>After downloading, simply make the file executable (either by running chmod +x file or using your file manager&#8217;s properties dialog) and run it. If you try, please let me know if it worked and what distribution (and version!) you used &#8212; that would be interesting to know.</p> <figure id="attachment_461" style="width: 800px" class="wp-caption aligncenter"><a href="" rel="attachment wp-att-461"><img class="wp-image-461" src="" alt="Screenshot_20160616_174809" data-recalc-dims="1" /></a><figcaption class="wp-caption-text">KDevelop standalone running. Very interesting to look at.</figcaption></figure> <p>The executable is built by compiling all our dependencies (most notably Qt, a list of KDE Frameworks, and LLVM) on a very old system, in this case CentOS 6. Then all required libraries are installed into a directory, and the libraries they link against are copied there as well by a shell script. What is stripped out is the base system &#8212; glibc, libgl, libX, libxcb, things like that. The idea is that these libraries are forward binary-compatible, and by building on an old system and linking against old versions of those libraries, you can run the resulting programs on any more recent system. You could then simply tar up this tree, and include a script to update a few environment variables and launch KDevelop. A somewhat nicer variant of that, which was used for the above installer, is by using <a href="">AppImage</a>, which puts all the files into an ISO image and adds a startup header to make it look like an ELF binary. The startup header mounts the ISO using fuse, sets up a few environment variables, and runs the program.</p> <p>This reminds me of something else I would be interested in: On your computer, do you have fuse installed by default? If that is not the case for a lot of systems, it might be worth publishing a tarball instead.</p> <p>I did lots of other things at Randa too, but I&#8217;ll report on those in followup posts.</p> <p>If you like what we&#8217;re doing here, consider <a href="">supporting the meeting with a donation</a>!</p> Thu, 16 Jun 2016 15:58:32 +0000 sven Working on KDevelop and KDE on Windows in Randa <p><a href=""><img src="" alt="Fundraising banner" title=""></a></p> <p>Right now, around 40 developers are working together on bringing KDE to other platforms in <a href="">Randa</a> (Switzerland) for an entire week.</p> <p>I just arrived Sunday evening, and we immediately started with discussions around KDE on different platforms. Not much coding has happened yesterday evening yet, but I at least managed to work-around a <a href="">compiler bug of GCC 4.8</a> showing up in the KDevelop code base.</p> <p>My plans for this week are as follows:</p> <ul> <li>Preparing the KDevelop 5.0 release (fixing <a href=";bug_status=CONFIRMED&amp;bug_status=ASSIGNED&amp;bug_status=REOPENED&amp;keywords=release_blocker%2C%20&amp;keywords_type=allwords&amp;known_name=kdevelop_release_blockers&amp;list_id=1331358&amp;product=kdevelop&amp;product=kdevplatform&amp;query_based_on=kdevelop_release_blockers&amp;query_format=advanced">release blockers</a>)</li> <li>Introduce the Windows CI for KDE (means: adding a Jenkins Windows slave to, making it produce useful results)</li> <li>Generally be a source of help for people trying to port their application to Windows</li> <li>Plus upstreaming patches I've been too lazy to fix up and push yet (hint: <a href=""></a>, etc.)</li> </ul> <p>If you'd like to see what all the KDE people are working on, here's a work log of all participants of the sprint: <br> <a href=""></a></p> <p>If you want to support us, please <a href="">donate</a> to help us keeping up these developer meetings!</p> <p>Thanks! <br> Kevin</p> Mon, 13 Jun 2016 18:30:00 +0000 Kevin Funk 41d06435-fa22-4d5b-9f77-ca932bcb5c3a