fidzu : GNOME

During the last few days there has been an ongoing Twitter storm about 10× developers. And like all the ones before it (and all the future ones that will inevitably happen) the debate immediately devolved into name calling and all the other things you'd except from Twitter fights. This blog post is not about that. Instead it is about a personal experience about productivity that I had to experience closer than I would have liked.

Some years ago I was working for company X on product Y. All in all it was quite a nice experience. We had a small team working on a code base that was pretty good. It had nice tests, not too many bugs, and when issues did arise they were usually easy to fix. Eventually the project was deemed good enough and we were transferred to work on different projects.

I have no idea what our "industry standard performance multiplier" was when we worked on that project, but for the sake of argument let's call it 1×.

The project I got transferred to was the thing of nightmares. It was a C++ project and all the bad things that have ever been said about C++ were true about that code base. There was not much code but it was utterly incomprehensible. There were massively deep inheritance hierarchies, , compilation speed was measured in minutes for even the most trivial changes, and so on. It was managed by an architecture astronaut that, as one is wont to do, rewrote existing mature libraries as header only template libraries that were buggy and untested (one could even say untestable).

Thus overnight I went from being a 1× down to being a 0.1× or possibly even a 0.01× developer. Simply trying to understand what a specific function was supposed to do took hours. There was, naturally, a big product launch coming up so we needed to get things finished quickly. All in all it was a stressful, frustrating and unpleasant situation to be in. And that was not the worst of it.

After a few weeks my manager wanted to talk to me in private. He was very concerned about the fact that I had not achieved any visible progress for a while. Then I explained to him in detail all the problems in the current project. I even demonstrated how compiling a simple helloworld-level program with the frameworks we had to use took tens of seconds on the beefiest i7 desktop machine I had available. He did not seem to be able to grasp any of that as his only response was "but you used to be so productive in your previous project". Shortly thereafter the same boss started giving me not-al-all-thinly-veiled accusations that I was just slacking off and that this could lead to serious reprimands.

This story does not have a happy ending. The project eventually failed (due to completely different reasons, though), money was squandered and almost everyone involved got fired. In the aftermath I seriously considered getting out of the software engineering business altogether. The entire experience had been so miserable that becoming a 0× developer was seriously tempting.

Is there something we can learn from this?

16 Jul 2019 2:40pm GMT

The final API so far in this mini-series on new APIs in the GLib 2.62 series is g_array_binary_search(), put together by Emmanuel Fleury and based on code by Christian Hergert. It's due to be released in 2.61.2 soon. But first, a reminder about GLib version numbering.

Like the rest of GNOME's official module set, GLib follows an odd/even versioning scheme, where every odd minor version number, like 2.61.x, is an unstable release building up to an even minor version number, like 2.62.x, which is stable. APIs may be added in unstable releases. They may be modified or even removed (if they haven't been in a stable release yet). So all of the APIs I've blogged about recently still have a chance to be tweaked or dropped if people find problems with them. So if you see a problem or think that one of these APIs would be awkward to use in some way, please say, sooner rather than later! They need fixing before they're in a stable release.

Back to today's API, g_array_binary_search(). As its name suggests, this does a binary search on an array (which it requires is already sorted). You can use it like this:

static gint
compare_guint64 (gconstpointer a,
                 gconstpointer b)
{
  guint64 uint64_a = *((guint64 *) a);
  guint64 uint64_b = *((guint64 *) b);

  if (uint64_a < uint64_b)
    return -1;
  else if (uint64_a > uint64_b)
    return 1;
  else
    return 0;
}

g_autoptr(GArray) my_array = g_array_new (FALSE, TRUE, sizeof (guint64));

for (guint i = 0; i < 100; i++)
  {
    guint64 random_uint64 = ( (guint64) g_random_int () << 32) | g_random_int ();
    g_array_append_val (my_array, random_uint64);
  }

g_array_sort (my_array, compare_guint64);

/* Is '1234' in the array? If so, where? */
const guint64 search_uint64 = 1234;
guint search_index;
if (g_array_binary_search (my_array, &amp;search_uint64, compare_guint64, &amp;search_index))
  g_message ("Found '1234' at index %u", search_index);
else
  g_message ("Didn't find '1234'");

As all computer science algorithms courses will tell you, a binary search is faster than a linear search, so you should use this in preference to iterating over an array to find an element in it, where possible.

(That's not entirely true: the overheads of accounting for the binary search bounds, and the slowness of scattered memory loads from the array in a binary search vs sequential access in a linear search, will probably make it slower than a linear search for small arrays. But both will be fast, and if you need to care about that level of performance, you should be using a custom data structure rather than GArray.)

16 Jul 2019 10:51am GMT

July Marked the beginning of II GSOC coding month. This month our goal is to make the diff bar model as accurate and intuitive as possible.

One of the biggest thing which I learnt so far is how to contribute on upstream repositories on which our project depends.

In our case this was with Libgit2, we discovered a bug in Libgit2 while doing our project, and Albfan made this a perfect example to show me how to contribute on upstream, how to raise bugs and how to do discussions for getting it solved.

https://github.com/libgit2/libgit2/issues/5153

While this got solved we can't wait to get the solutions merged. So we filtered out which patches works best for us and I learnt how to apply patches to projects with Flatpak.

I really think the Flatpak team has done a great job on this one, and it was super easy and useful for me to get those patches working with my project. Without flatpak manifest Idk how I would have pulled it off.

https://gitlab.gnome.org/gaurav1999/diferencia/commit/3c5c93137acfd3c11d5aeeffdd03af68523d6e3e

I tried to understand how amazing is Gtk.TextView and I used something called Gtk.TextTag for highlighting the Diff text in appropriate colors.

Red -> Removed Text

Green --> Insertion Text

In order to make grounds for Three way merge diff view, we are able to make sure now we paint the diff bar in relative manner.

For this, we introduced a reverse direction property which essentially makes the model know which direction we will be painting the diff curves, Right to Left or Left to Right.

https://gitlab.gnome.org/gaurav1999/diferencia/commit/79ff5406f3ecdca07c3caed204ca1aff13922a2c

Now comes the hard part…

Right now our model works on DiffLineCallback, where we basically pick up each line diff and paint the indicating curve for it. The disadvantage of doing this is that, the curves are getting overlapped and it not looks good.

So I tried to do some pre processing of the data and improve this situation.

and the results look pretty!

While there are still tuning required for the algorithm, and I hope we get this completed real soon.

Now, the most Hard part !!!!!

Visa , It's really hard to arrange all of your documents required for European visa, really hoping my hard work pays off and I meet you all Gnome Folks in GUADEC soon.

In the end it's almost one and a half week left for this month to get end, and I have learnt a lot like always!

15 Jul 2019 2:24pm GMT

A slightly more in-depth post in the mini-series this time, about various new functions which Emmanuel Fleury has landed in GLib 2.61.2 (which is due to be released soon), based on some old but not-quite-finished patches from others.

There's g_ptr_array_copy() and g_array_copy(); and also g_ptr_array_extend() and g_ptr_array_extend_and_steal().

g_ptr_array_copy() and g_array_copy() are obvious functions and it's not clear why they haven't been added before. They allow you to copy a GPtrArray or a GArray, including its contents.
When copying a GPtrArray, you pass in a GCopyFunc to copy each element (for example, by increasing its reference count). If the GCopyFunc is NULL, the element is copied by value.

For example,

g_autoptr(GPtrArray) object_array = g_ptr_array_new_with_free_func (g_object_unref);

for (gsize i = 0; i < 10; i++)
  g_ptr_array_add (object_array, create_new_object (i));

object_array_copy = g_ptr_array_copy (object_array, g_object_ref, NULL);
/* object_array and object_array_copy now contain copies of the same elements, but
 * modifying one array will not modify the other */

The g_ptr_array_extend() functions are used to join one array onto the end of another. This means you can turn the following code to join the GObject elements of array2 onto the end of array1 and ref them all:

for (gsize i = 0; i < array2->len; i++)
  g_ptr_array_add (array1, g_object_ref (g_ptr_array_index (array2, i)));

into

g_ptr_array_extend (array1, array2, g_object_ref, NULL);

If you no longer need array2, you can go further and use g_ptr_array_extend_and_steal() to avoid copying each element. This might be particularly beneficial when using string arrays, where each copy (a g_strdup()) is more expensive. So the following code:

g_autoptr(GPtrArray) array1 = g_ptr_array_new_with_free_func (g_free);
for (guint i = 0; i < 10; i++)
  g_ptr_array_add (array1, g_strdup_printf ("array1 %u", i));

g_autoptr(GPtrArray) array2 = g_ptr_array_new_with_free_func (g_free);
for (guint i = 100; i < 110; i++)
  g_ptr_array_add (array2, g_strdup_printf ("array2 %u", i));

for (gsize i = 0; i < array2->len; i++)
  g_ptr_array_add (array1, g_strdup (g_ptr_array_index (array2, i)));

would become:

g_autoptr(GPtrArray) array1 = g_ptr_array_new_with_free_func (g_free);
for (guint i = 0; i < 10; i++)
  g_ptr_array_add (array1, g_strdup_printf ("array1 %u", i));

g_autoptr(GPtrArray) array2 = g_ptr_array_new_with_free_func (g_free);
for (guint i = 100; i < 110; i++)
  g_ptr_array_add (array2, g_strdup_printf ("array2 %u", i));

g_ptr_array_extend_and_steal (array1, g_steal_pointer (&amp;array2));
/* array2 has now been destroyed */

15 Jul 2019 1:36pm GMT

Hey folks, I'm back and I'm looking for some new work to challenge me-preferrably again for an organization that does something good and meaningful for the world. You can read my profile on my website, or keep reading here to discover about what I've been up to in the past few years.

Sometime after the end of my second term on the GNOME Foundation, I was contacted by a mysterious computer vendor that ships a vanilla GNOME on their laptops, Purism.

A laptop that was sent to me for review

They wanted my help to get their business back on track, and so I did. I began with the easy, low-hanging fruit:

• Reviewing and restructuring their public-facing content;
• Doing in-depth technical reviewing of their hardware products, finding industrial design flaws and reporting extensively on ways the products could be improved in future revisions;
• Using my photo & video studio to shoot official real-world images (some of which you can see below) for use in various marketing collaterals. I also produced and edited videos that played a strong part in increasing the public's confidence in these products.

As my work was appreciated and I was effectively showing business acumen and leadership across teams & departments, I was shortly afterwards promoted from "director of communications" to CMO.

At the very beginning I had thought it would be a short-lived contract; in practice, my partnership with Purism lasted nearly three years, as I helped the company go from strength to strength. I guess I must've done something right

Here are some of the key accomplishments during that time:

Fun designing a professional technical brochure for conferences

• Grew the business' gross monthly revenue significantly (by a factor of 10, and up to a factor of 55) over the course of two years.
• Helped devise and run the Librem 5 phone crowdfunding campaign that raised over $US 2.1 million, with significant press coverage. This proved initial market demand and reduced the risk of entering this new market. As the Linux Action Show commented during two of their episodes: "Wow, can we hire this PR department?" "They've done such a good job at promoting this!"
• Made the public-facing brand shine. Over time, converted some of the toughest critics into avid supporters, and turned the company's name into one that earned trust and commands respect in our industry.
• Did extensive research of over a hundred events (tradeshows, conferences) aligned with Purism's business; planned and optimized sponsorships and team attendance to a selection of these events. Designed bespoke brochures, manned product exhibit booths, etc.
• Leveraged good news, mitigated setbacks, managed customer's expectations.
• Devised department budget approximations and projections in preparation for investment growth.
• Provided support and business experience to the "operations" & "customer support" departments.
• Defined the marketing department structure and wrote critical roles to recruit for. The director of sales commented that those were "the best job descriptions [he'd] ever seen, across 50 organizations", so apparently marketeers can make great recruiting copywriters too
• Identified many marketing and community management infrastructure issues, oversaw the deployment of solutions.
• Onboarded members of the sales & bizdev teams so that they could blend into the organization's culture, tap into tacit knowledge and hit the ground running
• Coined the terms "Adaptive Design" and "Adaptive Applications" as a better, more precise terminology for convergent software in the GNOME platform. Yes, I was the team's ghostwriter at times, and did extensive copy editing to turn technical reports into blog posts that would appeal to a wider audience while satisfying accuracy requirements.
• Designed public surveys to gauge market demand for specific products in the B2C space, or to assess enterprise products & services requirements in the B2B space.
• Etc. Etc.

That's the jist of it.

With all that said, startups face challenges outside the scope of any single department. There comes a moment when your expertise has made all the difference it could in that environment, therefore making it necessary to conclude the work to seek a new challenge.

After spending a few weeks winding down that project and doing some personal R&D (there were lots of things to take care of in my backlog), I am now officially announcing my availability for hire. Or, in retweetable words:

If you know a business or organization that would benefit from my help, please feel free to share this blog post with them, or to contact me to let me know about opportunities.

The post Available for hire, 2019 edition appeared first on The Open Sourcerer.

15 Jul 2019 1:08pm GMT

The All Systems Go! 2019 Call for Participation Re-Opened for ONE DAY!

Due to popular request we have re-opened the Call for Participation (CFP) for All Systems Go! 2019 for one day. It will close again TODAY, on 15 of July 2019, midnight Central European Summit Time! If you missed the deadline so far, we'd like to invite you to submit your proposals for consideration to the CFP submission site quickly! (And yes, this is the last extension, there's not going to be any more extensions.)

All Systems Go! is everybody's favourite low-level Userspace Linux conference, taking place in Berlin, Germany in September 20-22, 2019.

For more information please visit our conference website!

15 Jul 2019 1:06pm GMT

A common source of all kinds of bugs is using variables without properly initializing them. Out of all security problems this one is the simplest to fix, just convert all declarations of type int x; to int x=0;. The main reason for not doing that is laziness, manually going through existing code bases and adding initialization statements is boring and nobody wants to do that.

Fortunately nowadays we don't have to. Clang-tidy provides a nice toolkit for writing source code refactoring tools for C and C++. As an exercise I wrote a checker to do this. It is submitted upstream and is undergoing code review. Implementing it was fairly straightforward. There were only two major problems. The first one was that existing documentation consists mostly of reference manuals. There is no easy to follow tutorials, only Doxygen pages. But if you dig around on the net and work on it a bit, you can get it working.

The second, and bigger, obstacle is that doing anything in the LLVM code base is sloooow. Everything in LLVM and Clang is linked to single, huge, monolithic libraries which take forever to link. Because of reasons I started doing this work on my secondary machine, which is a 4 core i5 with 16 gigs of RAM. I had to limit simultaneous linker jobs to 2 because otherwise it would just crash spectacularly to an out of memory error. Presumably it is impossible to compile the code base on a machine that has only 8 gigs of RAM. It seems that if you want to do any real development on LLVM you need a spare data center to run the compilations, which is unfortunate.

There is an evil hack to work around this, though. Set the CMake build type to Debug and then change CMAKE_CXX_FLAGS_DEBUG and CMAKE_C_FLAGS_DEBUG from -g to -Og. This makes the compilation faster and reduces memory usage to a fraction of the original. The downside is that there is no debug information, but it turns out to not be necessary when writing simple Clang-Tidy checkers.

Once all that is done the actual checker is almost trivial. This is the part that looks up all local variables without initial values:

void InitLocalVariablesCheck::registerMatchers(MatchFinder *Finder) {
Finder->addMatcher(
varDecl(unless(hasInitializer(anything()))).bind("vardecl"), this);
}

Then you determine what the initial value should be based on the type of the variable and add a warning and a fixit:

diag(location, "variable %0 is not initialized")
<< MatchedDecl;
diag(location, "insert initial value", DiagnosticIDs::Note)
<< FixItHint::CreateInsertion(
location.getLocWithOffset(VarName.size()),
InitializationString);

All in all this amounts to about 100 lines of code plus tests.

But what about performance?

14 Jul 2019 8:28pm GMT

Introduction I've always liked a clean, slim, lightweight, and robust OS on my laptop (which is my only PC) - I've been running the i3 window manager for years, with some custom configuration to enable the Fn keys and set up my preferred desktop session layout. Initially on Ubuntu, for the last two and a half years under Fedora (since I moved to Red Hat). I started with a minimal server install and then had a post-install script that installed the packages that I need, restore my /etc files from git, and some other minor bits.

14 Jul 2019 12:07pm GMT

Pitivi is a video editor, free and open source. Targeted at newcomers and professional users, it is minimalist and powerful. This summer I am fortunate to collaborate in Pitivi development through Google Summer of Code.

My goal is to implement an interval time system, with the support of Mathieu Duponchell, my menthor, and other members of the Pitivi community.

An interval time system is a common tool in many video editors. It will introduce new features in Pitivi. The user will be able to set up a range of time in the timeline editor, playback specific parts of the timeline, export the selected parts of the timeline, cut or copy clips inside the interval and zoom in/out the interval.

Mi proposal also includes the design of a marker system to store information at a certain time position.

Interestingly, we started working on the markers system. It was decided that it would be useful later in the interval implementation. To implement markers we have been working on GES, creating two new classes, GESMarkerContainer and GESMarker.

After define the API I started implementing it. At this stage it was incredible helpful to me the dedication of Mathieu orienting me along the process. GES could be "quite" complicate for newcomers like me but it also makes things more interesting! Thanks to my menthor I could focus, divide task into smaller and factible chunks, both in GES and Pitivi code.

My work until now can be summarized in these steps: implement something needed in the API, go to Pitivi and work there until I need something else from the API, then go back to the API…

After some redesings now we have a new row in the timeline, which allows us to insert markers, move and delete them, and edit their content, which for the moments is just a string. Of course they can be saved and recovered. UI is still provisional.

I am really enjoying the experience, my first time in open source. The code is huge, involves differents technologies and I have to work on different levels. But it feels challenging and the community is really supportive.

13 Jul 2019 4:53pm GMT

Since my last blog post I have been on a short vacation but I have also managed to make some progress on my GSoC project again with guidance from my mentor.

My latest work concerns the UI used for the Savestates Manager.

The current Savestates Manager

The available savestates are listed on the right. Note that every savestate has a thumbnail which is a screenshot of the game taken at the moment when the savestate was created. For me it was very satisfying to reach this milestone

Every savestate also has a creation date which is displayed in the menu, but that's certainly not as eye-catching as the screenshots.

There are still many missing features and things that need improving (such as the date formatting) but with every commit I feel that I am getting closer to the finished project.

How the finished Savestates Manager is supposed to look like

Next up I will be working on the menu header bar which is going to contain the Load, Delete and Cancel buttons.

13 Jul 2019 8:53am GMT

Fork-Awesome Logo Yesterday, I sat down to upgrade the Font Awesome package used by Beast's new UI from 4.7.0 to 5.9.0. In the end, I found that the icons look way more crispy and professional in the 4.7.0 version. Here is an example: Font-Awesome 4 vs 5 The Font Awesome 5 package has some other…

12 Jul 2019 8:18pm GMT

GNOME applications (and others) are commonly using the GSettings API for storing their application settings.

GSettings has many nice aspects:

• flexible data types, with GVariant
• schemas, so others can understand your settings (e.,g. dconf-editor)
• overrides, so distros can tweak defaults they don't like

And it has different backends, so it can be adapted to work transparently in many situations. One example for where this comes in handy is when we use a memory backend to avoid persisting any settings while running tests.

The GSettings backend that is typically used for normal operation is the DConf one.

DConf

DConf features include profiles, a stack of databases, a facility for locking down keys so they are not writable, and a single-writer design with a central service.

The DConf design is flexible and enterprisey - we have taken advantage of this when we created fleet commander to centrally manage application and desktop settings for large deployments.

But it is not a great fit for sandboxing, where we want to isolate applications from each other and from the host system. In DConf, all settings are stored in a single database, and apps are free to read and write any keys, not just their own - plenty of potential for mischief and accidents.

Most of the apps that are available as flatpaks today are poking a 'DConf hole' into their sandbox to allow the GSettings code to keep talking to the dconf daemon on the session bus, and mmap the dconf database.

Here is how the DConf hole looks in the flatpak metadata file:

[Context]
filesystems=xdg-run/dconf;~/.config/dconf:ro;

[Session Bus Policy]
ca.desrt.dconf=talk

Sandboxes

Ideally, we want sandboxed apps to only have access to their own settings, and maybe readonly access to a limited set of shared settings (for things like the current font, or accessibility settings). It would also be nice if uninstalling a sandboxed app did not leave traces behind, like leftover settings in some central database.

It might be possible to retrofit some of this into DConf. But when we looked, it did not seem easy, and would require reconsidering some of the central aspects of the DConf design. Instead of going down that road, we decided to take advantage of another GSettings backend that already exists, and stores settings in a keyfile.

Unsurprisingly, it is called the keyfile backend.

Keyfiles

The keyfile backend was originally created to facilitate the migration from GConf to GSettings, and has been a bit neglected, but we've given it some love and attention, and it can now function as the default GSettings backend inside sandboxes.

It provides many of the isolation aspects we want: Apps can only read and write their own settings, and the settings are in a single file, in the same place as all the application data:

~/.var/app/$APP/config/glib-2.0/settings/keyfile

One of the things we added to the keyfile backend is support for locks and overrides, so that fleet commander can keep working for apps that are in flatpaks.

For shared desktop-wide settings, there is a companion Settings portal, which provides readonly access to some global settings. It is used transparently by GTK and Qt for toolkit-level settings.

What does all this mean for flatpak apps?

If your application is not yet available as a flatpak, and you want to provide one, you don't have to do anything in particular. Things will just work. Don't poke a hole in your sandbox for DConf, and GSettings will use the keyfile backend without any extra work on your part.

If your flatpak is currently shipping with a DConf hole, you can keep doing that for now. When you are ready for it, you should

• Remove the DConf hole from your flatpak metadata
• Instruct flatpak to migrate existing DConf settings, by adding a migrate-path setting to the X-DConf section in your flatpak metadata. The value fo the migrate-path key is the DConf path prefix where your application's settings are stored.

Note that this is a one-time migration; it will only happen if the keyfile does not exist. The existing settings will be left in the DConf database, so if you need to do the migration again for whatever reason, you can simply remove the the keyfile.

This is how the migrate-path key looks in the metadata file:

[X-DConf]
migrate-path=/org/gnome/builder/

Closing the DConf hole is what makes GSettings use the keyfile backend, and the migrate-path key tells flatpak to migrate settings from DConf - you need both parts for a seamless transition.

There were some recent fixes to the keyfile backend code, so you want to make sure that the runtime has GLib 2.60.6, for best results.

Happy flatpaking!

Update: One of the most recent fixes in the keyfile backend was to correct under what circumstances GSettings will choose it as the default backend. If you have problems where the wrong backend is chosen, as a short-term workaround, you can override the choice with the GSETTINGS_BACKEND environment variable.

Update 2: To add the migrate-path setting with flatpak-builder, use the following option:

--metadata=X-DConf=migrate-path=/your/path/

12 Jul 2019 6:21pm GMT

Matthias Clasen is enjoys spending time outdoors, having great hair, and working on GNOME Tool Kit (GTK).

What is your role within the GNOME community?

I have been involved GNOME for a long time. My first commits to GTK are from sometime around 2002. GTK is where I spend most of my development and project maintenance time. But I've been involved in many other parts of GNOME at one point or another, from GLib to GNOME Software.
Apart from writing code and fixing bugs, I am a member of the release team, and do a few of the GNOME releases every cycle. In recent years, I've often done the .0 stable releases.

Other affiliations you want to share?

In my day job, I manage the "GNOME" part of the Red Hat desktop team, which is an outstanding group of engineers. We juggle upstream work on GNOME and related projects with maintaining the workstation products in Red Hat Enterprise Linux and Fedora.

Why did you get involved in GNOME?

That is a tough question to answer - these things usually just happen, and we try to retroactively make sense of them. To give some answer: My first love in software was typography - I spent my university years in Germany happily doing math and TeX. At some point, I got interested in window managers, and trying to write a better menu system for fvwm is what created my first contact with GTK. And things just grew from there, with many lucky coincidences along the way, not the least of which was that I got a job in the Red Hat desktop team.

Why are you still involved with GNOME?

On the one hand, it is part of my job (and I am extremely lucky that it is). But, really, it is just a way of life. There are so many good friends and colleagues in the GNOME community that I can't imagine not being involved in it anymore.

What are you working on right now?

It is always a mix of things that are going on at the same time. The big tasks are getting Fedora Silverblue ready for prime time and trying to push GTK4 over the finish line. But there are a whole lot of smaller things that take up some of my time. A few weeks ago, I took a day to write a Flatpak portal that lets applications update themselves. And last week I spent a day working with Behdad on pango (I still have a soft spot for typography) and wrote a post about it.

What are you excited about right now - either in GNOME or free and
open source software in general?

I am feeling quite positive about Flatpak, and the opportunities it opens up for getting out of the "Linux distro" conversation. It is exciting to see many apps on flathub that I had no idea existed. And now it is just one click for me to try them out. Together with gitlab and its CI, flatpak has also changed the way we develop GNOME. It is like night and day, compared to a few years ago - things generally just build and work these day, and you can download flatpaks to try out branches - it is fantastic.

What is a major challenge you see for the future of GNOME?

I think it is a challenge to teach generations the value of having a local computing device (e.g. your laptop) that is powerful and accessible enough to let you explore and build things. Between phones and the online world, there is a risk that we lose that important aspect of the freedom to tinker an explore - you don't compile things on your phone, and you can't reboot the cloud…

What do you think GNOME should focus on next?

I have a hard time answering this, because GNOME is thousands of individuals, who all have their own motivations and goals, not a monolithic block that can be turned in a different direction with a quick command. I think the work Endless has been doing for bringing computers (and GNOME) to people in the developing world and to young people is very relevant for the long-term future of the project, and we should support them.

What should we have asked you about that we didn't?

You could have asked me about my kids and my cats.

My kids are 21 and 19, and in college. Thankfully, they are both at home for the summer, so we can share the cooking and do some hiking and kayaking together.

The cats are not in college.

A lovely leaf Matthias found while hiking in the White Mountains.

This interview has been edited for clarity.

12 Jul 2019 2:53pm GMT

Who's new at the GNOME Foundation?

Over the past few months, we've been building up the Foundation's staff. In addition to executive director Neil McGovern and director of operations Rosanna Yuen, we're thrilled to welcome:

• Emmanuele Bassi, GTK+ core developer
• Molly de Blanc, Strategic initiatives manager
• Bartłomiej Piotrowski, Devops/sysadmin
• Kristi Progri, Programs coordinator
• Andrea Veri, Systems administrator

The election for the 2019-2020 board of directors is going on right now!

Where have we been?

In April we visited FOSS North in Gothenburg, Sweden and Linux Fest Northwest in Bellingham, Washington, USA. Our table at FOSS North was staffed by Kristi and Neil, and volunteers Bastian, Anisa and Stefano. GNOMEie Zeeshan Ali presented on open source geolocation. Molly and Sri were at LFNW, where Molly spoke about following through on a code of conduct. Kristi participated remotely in FLISOL. There were two hackfests in May, Rust+GNOME 2019 Hackfest#5 in Berlin and Gstreamer Spring Hackfest 2019 in Oslo. We'll be in Portland, OR, USA in July for OSCON. After OSCON we'll be hosting a West Coast Hackfest, July 18th - 21st.

Exciting Goings-on

• We are participating in Google Summer of Code! You can learn more about our ten interns on the GSoC web site.
• Emmanuele finished moving the GTK+ development mailing list to Discourse. He also increased the reliability and usibility of CI for Glib and GTK. You can read about it on his blog.
• Kristi has been busy working with community members around the world on organizing GUADEC.
• What to know more about what's going on with the GNOME community? Check out planet.gnome.org.

Meet the GNOMEies!

The GNOME project is what it is because of the GNOME community. This month, we'll be introducing you to Matthias Clasen!

Want this in your inbox?

Become a Friend of GNOME to get this mailed directly to you once a month.

12 Jul 2019 2:53pm GMT

In my slightly infamous email to fedora-devel I stated that I would turn off the snapd support in the gnome-software package for Fedora 31. A lot of people agreed with the technical reasons, but failed to understand the bigger picture and asked me to explain myself.

I wanted to tell a little, fictional, story:

In 2012 the ISO institute started working on a cross-vendor petrol reference vehicle to reduce the amount of R&D different companies had to do to build and sell a modern, and safe, saloon car.

Almost immediately, Mercedes joins ISO, and starts selling the ISO car. Fiat joins in 2013, Peugeot in 2014 and General Motors finally joins in 2015 and adds support for Diesel engines. BMW, who had been trying to maintain the previous chassis they designed on their own (sold as "BMW Kar Koncept"), finally adopts the ISO car also in 2015. BMW versions of the ISO car use BMW-specific transmission oil as it doesn't trust oil from the ISO consortium.

Mercedes looks to the future, and adds high-voltage battery support to the ISO reference car also in 2015, adding the required additional wiring and regenerative braking support. All the other members of the consortium can use their own high voltage batteries, or use the reference battery. The battery can be charged with electricity from any provider.

In 2016 BMW stops marketing the "ISO Car" like all the other vendors, and instead starts calling it "BMW Car" instead. At about the same time BMW adds support for hydrogen engines to the reference vehicle. All the other vendors can ship the ISO car with a Hydrogen engine, but all the hydrogen must be purchased from a BMW-certified dealer. If any vendor other than BMW uses the hydrogen engines, they can't use the BMW-specific heat shield which protects the fuel tank from exploding in the event on a collision.

In 2017 Mercedes adds traction control and power steering to the ISO reference car. It is enabled almost immediately and used by nearly all the vendors with no royalties and many customer lives are saved.

In 2018 BMW decides that actually producing vendor-specific oil for it's cars is quite a lot of extra work, and tells all customers existing transmission oil has to be thrown away, but now all customers can get free oil from the ISO consortium. The ISO consortium distributes a lot more oil, but also has to deal with a lot more customer queries about transmission failures.

In 2019 BMW builds a special cut-down ISO car, but physically removes all the petrol and electric functionality from the frame. It is rebranded as "Kar by BMW". It then sends a private note to the chair of the ISO consortium that it's not going to be using ISO car in 2020, and that it's designing a completely new "Kar" that only supports hydrogen engines and does not have traction control or seatbelts. The explanation given was that BMW wanted a vehicle that was tailored specifically for hydrogen engines. Any BMW customers using petrol or electricity in their car must switch to hydrogen by 2020.

The BMW engineers that used to work on ISO Car have been shifted to work on Kar, although have committed to also work on Car if it's not too much extra work. BMW still want to be officially part of the consortium and to be able to sell the ISO Car as an extra vehicle to the customer that provides all the engine types (as some customers don't like hydrogen engines), but doesn't want to be seen to support anything other than a hydrogen-based future. It's also unclear whether the extra vehicle sold to customers would be the "ISO Car" or the "BMW Car".

One ISO consortium member asks whether they should remove hydrogen engine support from the ISO car as they feel BMW is not playing fair. Another consortium member thinks that the extra functionality could just be disabled by default and any unused functionality should certainly be removed. All members of the consortium feel like BMW has pushed them too far. Mercedes stop selling the hydrogen ISO Car model stating it's not safe without the heat shield, and because BMW isn't going to be supporting the ISO Car in 2020.

12 Jul 2019 1:05pm GMT

This summer I am working under the mentorship of Alexandru Băluț to improve the user experience of the Effects feature in Pitivi.

In the first phase of my project, I worked on redesigning Pitivi's "Effect Library" to allow users to easily find, organise and utilize their desired effects.

Current Effect Library UI

Video not supported

My first assignment was to remove the ComboBox at the top and replace it with seperate Expanders for the various categories. In the process, we also decided to move away from showing Audio and Video effects separately, instead choosing to integrate "Audio" just as another category. This enabled us to present a hierarchical yet simple interface which also allowed the user to have multiple categories open at once.

The next order of business was to replace the tiny 4:3 thumbnails we have for the effects with larger and more expressive 16:9 ones (Thanks to Valentin Orient for contributing these beautiful new thumbnails!).

My final task for this phase was to add a "Favourites" feature which would allow the user to gather all the effects of their choice in a separate view for quick and easy access. For this, I added a ☆ button to the effects which enables the user to effortlessly check or change its "favorited" state.

New Effect Library UI

Video not supported

Concluding my work on the "Effect Library" and I will now be moving onwards to renovating the "Clip Tab" for the next phase.

If you wish to reach me, you can find me in #pitivi and #newcommers on GIMPNet as yat_irc.

12 Jul 2019 12:39pm GMT