21 Aug 2017

feedPlanet GNOME

Zeeshan Ali: Ich bin ein Berliner

Well, no, not really but maybe I'll be able to claim that at some point because I'm moving to Berlin to join Kinvolk. I'm told that I'm changing countries and companies too often but that's not true. I was at Red Hat for 5 years and at Nokia before that for 5 years as well. The decision to move out of Finland was not exactly mine.

Regarding Pelagicore

I'm not as much leaving Pelagicore as I'm leaving the automotive industry, more specifically the software side of it. While the automotive industry is changing and mostly for the good, I realized that it still is not a place for me. Things typically move very slowly in this industry and I realized that I don't have the required patience for it. Also, C++/Qt are big here and while an year ago I thought it's just another language and Open Source UI framework, I no longer think so. Since you can find a lot of rants from very experienced C++ developers on why C++ is a horrible language, I won't rant about that in here.

My experience with Qt hasn't been that great either. Most of the documentation I found would simply assume you use Qt Creator and despite my years of experience with D-Bus, it took me weeks to figure out how to make a few D-Bus calls from Qt (I have to admit though that the calls involved complex types). While Nokia made Qt a normal Open Source project by relicensing it under LGPLv2, the Qt company recently realized that it's loosing a lot of money by people using Qt in products without paying them anything so they relicensed it under GPLv3 and commercial (i-e dual-license). I maintained Genivi Development Platform for 6 months and because of this relicensing, we were unable to upgrade Qt5 to Qt6 and overtime it had been becoming a major pain point in that project. To make things even less open-sourcy, they require all contributors to sign a CLA. I believe (and I think many would agree) that CLAs are bad for Open Source. So all those things put together, I don't think of Qt as a typical Open Source project. Feel free to disagree but that's how I feel and hence I'm not keen on working with Qt in future.

Having said all that, Pelagicore is a very awesome company and probably the best place to be if you're fine with C++/Qt and want to be part of the next-gen automotive. It might sound like I just contradicted myself but not everyone thinks and sees the world like me. To each, his own and all. Also Pelagicore is hiring!

Why leave Gothenburg?

Gothenburg is a very lovely city and I'm going to miss it a lot for sure, even though I've been only here for an year. I still love the Swedish language, which I have been learning slowly over the year. However, I've not been happy with the cost of living in here, especially Veterinary costs. I have an old cat with multiple conditions so I need to visit the Vet every few months. The Vet charge 700 SEK just to see him and most often they don't even care to read through his records beforehand.

Gothenburg is also currently the best place to find an accommodation in. To get a first-hand contract, you register yourself in on Boplats website and keep on applying to new listings but typical wait-time is in years, not months or weeks. In practice, it's usually not a problem. Most people just get a second-hand contract or a room in a shared flat to start with and then look for a more permanent solution. However, add a cat into the picture and things get very difficult again.

Kinvolk comes along

Because of the reasons stated above, I've been looking for some exciting opportunities outside automotive world in some nice location. I had been focused on finding jobs that either involve Rust language or at least there were good chances of Rust being involved. Long story short, I ultimately got in touch with Kinvolk folks. I already knew the company's founders: Chris, Alban and Iago. They are very good at what they do and fun folks to hang out with.

While Rust is not a big part of work at Kinvolk currently, they (especially Chris) seem very interested in it. From what I know, main languages at Kinvolk are C and Go. I don't mind coding in C anyway and I've been missing the times when I did any kernel programming in it. I've no experience of Go but from what I hear, it's a pretty decent language.

So after interviews etc, when Kinvolk offered me a job, I couldn't resist accepting it. Berlin is an awesome city and it's hard to say "no" to moving there.

If you're looking for a great place to work at on Linux-related tech with some very competent Open Source developers, do consider applying at Kinvolk.


Talking of great companies to work at, I recently got in contact with some folks from Cellink. It's a biotech company based in Gothenburg, whose aim is to end animal testing. They plan to achieve this very noble goal through 3D printers that print human tissues. They already have 2 products that they sell to pharmaceutical companies in 30 countries across the globe. While they already have the bio and hardware side of things covered, they are looking to expand their software side of things now and to do that, they need good software engineers, especially ones with Open Source experience.

Here is a video of a very nice intro to their awesome work from their CEO, Erik Gatenholm.

So if you're an Open Source developer and either live in or willing to relocate to (especially) Gothenburg, Cambridge (USA) or Bay Area, please contact me and I can connect you to the right people. Alternatively, feel free to contact them directly. I only want to help these folks achieve their very noble cause.

21 Aug 2017 7:56pm GMT

feedPlanet KDE

Look what you have done^W^Wdo!

You are using Kate or KDevelop and often editing directly the sources of Markdown files, Qt UI files, SVG files, Dot graph files and whatever else formats which are based on plain text files?

And you are having to use a workflow to check the current state which is saving the file and (re)loading it in a separate viewer application?

Could be better, right? Perhaps like this:

Nice mock-up. Or is it? Seems not! So, KParts-based preview plugin for Kate & KDevelop coming soon near you to a well-stocked package repository? Read the whole story where things are heading.

And a Markdown kpart? Never seen before. Because it is new. Actually seems the week of Markdown in the KDE community, there is also a patch on review to add Markdown support for Okular. Sadly Markdown support in Okular with the Okular kpart would not yet replace that separate Markdown kpart, because Okular does not support webview-style display (single "reactive" page), misses support for data streaming without touching the filesystem, and has too much chrome in the kpart for simple usage. Hope is on the future and somebody (you?) improving that. I am doing my share of improving things with this preview plugin, so I am out 🙂

21 Aug 2017 6:11pm GMT

feedPlanet GNOME

Armin Krezović: The GSoC wrap-up

And so, another Summer of Code has ended. During the past three months, I was working on Mutter, a GNOME's Compositor. My main goal was to make Mutter, which was written as an X11 Window Manager more than a decade ago and recently ported to also be a Wayland compositor, start Wayland session without requiring X server (Xwayland) to be present. That goal was accomplished, and Mutter is now able to start without Xwayland being started. Other goals included making Wayland clients start without X11 being present, which wasn't accomplished (or even started), because after main goal was finished, there was only a week left before this evaluation, and nothing could be accomplished in that time, given the complexity of the task.

So, lets sum what needed to be done during these past three months:

- First task that I worked on was splitting X11 specific part from main display object, MetaDisplay. That code was moved into a new object, MetaX11Display, which is owned by MetaDisplay and is either created or not created at startup, depending on how Mutter was started. A more detailed explanation can be found at [1].

- Second task involved getting rid of MetaScreen object, an object which previously had more than one instance, that nowadays has only one. MetaScreen contained both X11 and non-X11 specific parts, so it was split between MetaDisplay and MetaX11Display, accordingly. A more detailed explanation can be found at [1] and [2].

- Third set of tasks (yes, set of tasks) involved getting X11 specific functionality out of objects managed by MetaDisplay. These include workspace management, startup notification, stack tracker and bell (visual/sound notification). A more detailed explanation can be found at [3] and [4].

- Final task involved getting rid of GDK usage early in the code, and moving control of GDK X11 display to MetaX11Display itself. This also involved (sadly) getting rid of some GtkSettings usage which was used to change some properties when it gets changed in GTK. A more detailed explanation can be found at [4].

- After the final task was done, a --no-x11 switch was added to Mutter command line, which can be used to start Mutter without starting Xwayland.

- Bonus tasks, which did not really need to be done in order for Mutter to be able to work without X11 included renaming and improving X11 error management code (x11 trap code), moving workspace management code from MetaDisplay (previously MetaScreen) into new object - MetaWorkspaceManagement, and getting rid of screen size tracking in MetaDisplay (again, previously MetaScreen), and utilizing MetaMonitorManager directly. A more detailed explanation can be found at [3] and [4].

During this effort, a lot of functions were removed or replaced by functions with different names/parameters. Any compositor using libmutter library (gnome-shell is its most known user) cannot be compiled against my Mutter branch. However, I did create an API changelog which can be found at [5], for those that want to make use of my work, which can now be found at [6], and is rebased against current git master, as of moment of writing. Instructions to try out the compositor code can be found at [4], as well.

This summarizes my work done over these past three months. I'd like to thank both of my mentors, Jonas and Carlos, for helping me when I got stuck, providing feedback whenever it was necessary, or answering calmly and kindly at any of my questions, however simple or stupid they might sound. Also, I'd like to thank Google and GNOME Foundation for accepting me as student developer and allowing me to participate in this year's Summer of Code.

[1] https://armin-gnome.blogspot.ba/2017/06/progress-report-for-period-june-12th.html
[2] https://armin-gnome.blogspot.ba/2017/07/progress-report-june-26th-july-9th.html
[3] https://armin-gnome.blogspot.ba/2017/07/progress-report-july-10th-july-23rd.html
[4] https://armin-gnome.blogspot.ba/2017/08/progress-report-july-31st-august-13th.html
[5] https://armin-gnome.blogspot.ba/2017/08/documented-mutter-api-changes-after.html
[6] https://github.com/krezovic/mutter/commits/gsoc-final

21 Aug 2017 5:44pm GMT

feedPlanet KDE

QtWebKit on FreeBSD

Over at lwn.net, there is an article on the coming WebKitGTK apocalypse. Michael Catanzaro has pointed out the effects of WebKit's stalled development processes before, in 2016.

So here's the state of WebKit on FreeBSD, from the KDE-FreeBSD perspective (and a little bit about the GTK ports, too).

So .. the situation is not particularly good, perhaps even grim for Qt4 / KDE4 users (similar to the situation for KDE4 users on Debian stable). The transition of KDE FreeBSD ports to Qt5 / Frameworks 5 / Plasma 5 and KDE Applications will improve things considerably, updating QtWebKit and providing QtWebEngine, both of which are far more up-to-date than what they are replacing.

21 Aug 2017 11:36am GMT

Building Qt on Debian

I recently followed the advice of @sehurlburt to offer help to other developers. As I work with Qt and embedded Linux on a daily basis, I offered to help. (You should do the same!)

As it is easy to run out of words on Twitter, so here comes a slightly more lengthy explanation on how I build the latest and greatest of Qt for my Debian machine. Notice that there are easier ways to get Qt - you can install it from packages, or use the installer provided from The Qt Company. But if you want to build it yourself for whatever reason, this is how I do it.

First step is to get the build dependencies to your system. This might feel tricky, but apt-get can help you here. To get the dependencies for Qt 5, simply run sudo apt-get build-dep libqt5core5a and you are set.

Next step would be to get the Qt source tarball. You get it by going to https://www.qt.io/download/, select the open source version (unless you hold a commercial license) and then click the tiny View All Downloads link under the large Your download section. There you can find source packages for both Qt and Qt Creator.

Having downloaded and extracted the Qt tarball, enter the directory and configure the build. I usually do something like
./configure -prefix /home/e8johan/work/qt/5.9.0/inst -nomake examples -nomake tests. That should build everything, but skip examples and tests (you can build these later if you want to). The prefix should point to someplace in your home directory. The prefix has had some peculiar behaviour earlier, so I try to make sure not to have a final dash after the path. When the configuration has been run, you can look at the config.summary file (or the a bit higher up in the console output) and you can see a nice summary of what you are about to build. If this list looks odd, you need to look into the dependencies manually. Once you are happy, simply run make. If you want to speed things up, use the -j option with the highest number you dare (usually number of CPU cores plus one). This will parallelize the build.

Once the build is done (this takes a lot of time, expect at least 45 minutes with a decent machine), you need to install Qt. Run make install to do so. As you install Qt to someplace in your home directory, you do not need to use sudo.

The entry point to all of Qt is the qmake tool produced by your build (i.e. prefix/bin/qmake). If you run qmake -query you can see that it knows its version and installation point. This is why you cannot move a Qt installation around to random locations without hacking qmake. I tend to create a link (using ln -s) to this binary to somewhere in my path so that I can run qmake-5.9.0 or qmake-5.6.1 or whatnot to invoke a specific qmake version (caveat: when changing Qt version in a build tree, run qmake-version -recursive from the project root to change all Makefiles to the correct Qt version, otherwise you will get very "interesting" results).

Armed with this knowledge, we can go ahead and build QtCreator. It should be a matter of extracting the tarball, running the appropriate qmake in the root of the extracted code followed by make. QtCreator does not have to be installed, instead, just create a link to the qtcreator binary in the bin/ sub directory.

Running QtCreator, you can add Qt builds under Tools -> Options… -> Build & Run. Here, add a version by pointing at its qmake file, e.g. the qmake-5.9.0 link you just created. Then it is just a matter of picking Qt version for your project and build away.

Disclaimer! This is how I do things, but it might not be the recommended or even the right way to do it.

21 Aug 2017 7:03am GMT


Eric Anholt: 2017-08-21

This week I finished fixing regressions from the VC5 QPU instruction scheduler, and polished the vc5 series up so I could post it for review in Mesa. I landed a few initial bits that wouldn't affect anyone else.

I also took another look at my DSI series. I had previously tried to work around the boot time dependency circle by letting the DSI device be created before the DSI host showed up. That proved to be fragile as well (in particular it would have had issues if the host had to -EPROBE_DEFER for some other reason), so I went back and made VC4 advertise a DSI host before any of the rest of the DSI encoder was ready. This proved to be not very hard, and I'm hoping once again that this is the final version of the series.

Other bits this week:

21 Aug 2017 12:30am GMT

20 Aug 2017

feedPlanet GNOME

Lucie Charvat: GSoC/GUADEC: Wrapping Things Up

The Google Summer of Code is slowly but surely coming to an end and it's time to start wrapping thing up for the final evaluation. The documentation cards have been officially pushed to the master of the GNOME Builder and last couple of days were spent just tweaking the feature and going through the code reviews.

I would also like to take a quick look back at the amazing GUADEC that was held in Manchester this summer and share some of my photos. I was so glad I could attend and connect the faces with the people I have only met online.


GUADEC kicked of at MMU's Birley Campus with series of talks varying from technical updates of tools to strengthening the community and the principles which it stands for.


The social calendar was packed as well, making it very easy to meet and get to know a bit all the amazing people who have been part of the for years. Including, for me the highpoint of the events, the GNOME's 20th birthday celebration held in Museum of Science and Industry. If you haven't yet, don't forget to checkout the GNOME's birthday page.

The last days in Manchester were spent in nearby Shed providing space to discuss and work on ideas surrounding GNOME.

Hope to see you all next year!


20 Aug 2017 6:26pm GMT

18 Aug 2017


Roman Gilg: End in Sight

The last week of GSoC 2017 is about to begin. My project is in a pretty good state I would say: I have created a big solution for the Xwayland Present support, which is integrated firmly and not just attached to the main code path like an afterthought. But there are still some issues to sort out. Especially the correct cleanup of objects is difficult. That's only a problem with sub-surfaces though. So, if I'm not able to solve these issues in the next few days I'll just allow full window flips. This would still include all full screen windows and for example also the Steam client as it's directly rendering its full windows without usage of the compositor.

I still hope though to solve the last problems with the sub-surfaces, since this would mean that we can in all direct rendering cases on Wayland use buffer flips, which would be a huge improvement compared to native X.

In any case at first I'll send the final patch for the Present extension to the xorg-devel mailing list. This patch will add a separate mode for flips per window to the extension code. After that I'll send the patches for Xwayland, either with or without sub-surface support.

That's already all for now as a last update before the end and with still a big decision to be made. In one week I can report back on what I chose and how the final code looks like.

18 Aug 2017 11:30pm GMT

Jente Hidskes: GSoC part 13: I solved global warming!

This week I have been solving more issues to make sure that Piper offers a pleasent user experience, doesn't crash and runs smoothly. My mentor and cvuchener from the libratbag project have been testing Piper the last week, and together with a handful of users attracted to Piper they have opened a bunch of issues for me to solve. Let's run through the most visible ones! Solving global warming Probably the most fun issue to resolve this week was the one reported by my mentor: Piper contributes to global warming (you won't believe what happened next!

18 Aug 2017 5:47pm GMT