Fedora, GNOME, Linux

Story of GNOME Shell Extensions

A long time ago (exactly 10 years ago) it was decided that the the shell for GNOME would be written in JavaScript. GNOME 3 was still looking for its new face, a lot of UI experimentation was taking place, and JavaScript looked like the best candidate for it. Moreover it was a popular language on the web, so barriers to entry for new contributors would be significantly lowered.

When you have the shell written in JavaScript you can very easily patch it and alter its look and behaviour. And that’s what people started doing. Upstream was not very keen to officially support extensions due to their nature: they’re just hot patching the GNOME Shell code. They have virtually unlimited possibilities in changing look and behaviour, but also in introducing instability.

But tweaking the shell became really popular. Why wouldn’t it? You can tweak your desktop by simply clicking buttons in your browser. No recompilations, no restarts. So extensions.gnome.org was introduced.

The number of available extensions grew to hundreds and instability some of them occasionally introduced seemed like a fair price for the unlimited tweakability. In the end when the Shell crashed it was just a blink. Xorg held up the session with opened clients, the Shell/Mutter was restarted and the show could go on.

In 2016 GNOME switches to Wayland by default. No Xorg and also nothing to hold up the session with opened clients when the Shell crashes. There is only Mutter as a Wayland compositor, but unfortunately it runs in the same process as GNOME Shell (a decision also made 10 years ago when it also looked like a good idea). If the Shell goes down, so does Mutter. Suddenly harmless blinks became desktop crashes with losing all unsaved data in opened applications.

I read user feedback and problems users are having with Fedora Workstation (and Linux desktop in general) a lot on the Internet. And desktop crashes caused by GS extensions are by far the most frequent problem I’ve seen recently. I read stories like “I upgraded my Fedora to 28 and suddenly my desktop crashes 5 times a day. I can’t take it any more and I’m out of ideas” on daily basis. If someone doesn’t step in and say: “Hey, do you have any GS extensions installed? If so, disable them and see if it keeps crashing. The extensions are not harmless, any error in them or incompatibility between them and the current version of GS can take the whole desktop down”, users usually leave with the experience of unstable Linux desktop. It hurts our reputation really badly.

Are there any ways to fix or at least improve the situation? Certainly:

  1. Extensions used to be disabled when the Shell crashed hard (couldn’t be restarted). Since on Wayland it’s the result of every crash, we should do that after every GS crash. And when the user goes back to GNOME Tweak Tool to enable the extensions again, she/he should be told that it was mostly likely one of the 3rd party extensions that made the desktop crash, and she/he should be careful when enabling them.
  2. Decoupling GNOME Shell and Mutter or/and other steps that would bring back the same behaviour like on Xorg: GS crash would not take everything down. This would require major changes in the architecture and a lot of work and GNOME Shell and Mutter developer community has already a lot on their plates.
  3. Discontinuing the unlimited extensions, introducing a limited API they can use instead of hot patching the GS code itself. This would be a very unpopular step because it’d mean that many of the existing extensions would be impossible to implement again. But it may become inevitable in the future.
Advertisements
GNOME

GNOME hackaton in Brno

Last week, we had a presentation on Google Summer of Code and Outreachy at Brno University of Technology. Around 80 students attended which was a pretty good success considering it was not part of any course. It was a surprise for the uni people as well because the room they booked was only for 60 ppl.

The main reason why we did the presentation is that there have been very few students in Brno who participated in such programs. And the open source community is pretty big at local universities due to the presence of Red Hat. When we asked students who had heard of Google Summer of Code or Outreachy before only two raised their hands. That was even fever then we expected.

Shortly before the presentation, we discovered that the money reward for successfully finishing Google Summer of Code was not the same globally any more. And for the Czech Republic, it’s now $3600 instead of $5500. So considerably less, but still fairly attractive to local students.

As a follow-up to this presentation, we organized a GNOME hackaton in the Red Hat lab at BUT. Carlos Soriano was in charge of it with me, Felipe Borges, and Debarshi Ray helping him. Carlos prepared images for VirtualBox and KVM with a prepared development environment every student was supposed to download. People had to work in a virtual machine, but they didn’t have to spend time configuring and compiling everything and it assured that everyone had the same environment.

Around 12 students showed up which I think was a good turnout. 3 of them were women which is definitely higher % than the average at the uni. First Carlos told them to read the GNOME Newcomers guide and pick an app they’d like to contribute to. Then he created a dummy bug and showed students the whole process of fixing it from searching the code to the patch review. Then they were supposed to find some easy bug in the app of their choice and fix it.

Almost all students picked apps written in C, which is not so surprising because that’s the language they learn primarily at the university. Only one picked GNOME Music written in Python. The hackaton lasted for 5 hours and all students were busy for the whole time and almost everyone submitted some fix in the end.

Carlos is planning to do a follow-up with those who want to continue, probably before our (ir)regular Linux Desktop Meetup next week. Let’s see if some of them will make it to Google Summer of Code or Outreachy and even become long-term contributors to GNOME later on. It was the first time we actually made students to dip their fingers into the code. At all events before we had presentations on how they can contribute and pointed them to the docs to study at home, but the response was minimal. Maybe such a hackaton where you help students in person to make the first steps is the right approach to break through the barrier.

I’m pretty sure Carlos will also blog about his findings and it will be much more insightful since he spent a lot of time preparing the hackaton and was the one who talked to the students the most.

img_-dhuozj
Carlos showing students how to fix a bug in GNOME

 

Fedora, GNOME, Uncategorized

Dark Adwaita and HighContrast Themes for Qt

One of our goals for Fedora Workstation is to run Qt applications in GNOME as seamlessly as possible. Their look should be as close to their GTK+ counterparts as possible, you shouldn’t have to set things on two different places just to make the change in both GTK+ and Qt applications.

A while back, we introduced the Adwaita theme for Qt and QGnomePlatform which makes sure all settings get translated from the GTK+ world to the Qt one. The original Adwaita theme was written from scratch. To write a theme for Qt is pretty complex and the look of Adwaita for Qt was close to Adwaita for GTK+, but not close enough. Then Martin Bříza, who is working on this, decided to change the approach and based the new version on the default KDE theme and kept changing it until he got a theme that is very similar to Adwaita for GTK+. And indeed it’s now much closer than the first version.

Martin also worked on the dark variant of Adwaita for Qt, so that if you switch to this variant, Qt apps still don’t look out of place. Or if there is a Qt app that uses a dark theme it can have a look that fits into GNOME.

Martin didn’t stop there. GNOME also offers a high contrast theme for those with visual impairment which prevents them from using standard themes. They’re also not left behind. If you switch to the HighContrast theme in GNOME Qt apps will switch to it, too.

On the video below, you can see a mix of Qt and GTK+ apps and how they change when you switch between different themes:

These changes should land in Fedora 26 Workstation, but you can already try them out. Martin created a Copr repository. Keep in mind it’s work in progress. If you’d like to report bugs or help with tuning the themes, all the code is on Github.

GNOME

Dark title bars for apps with dark UI

I really like the polished look of GNOME and its default theme Adwaita, but there is one thing that has been bugging me for some time. By default server side window decorations are light and if an app has a dark UI and uses a server side window decorations, you get a dark window with a light title bar. It doesn’t look every nice and when you maximize the window, it’ll get even worse because you get a nice black-and-white hamburger (black top bar, light title bar, and dark window content).

There are quite a few apps suffering from this: Atom, Firefox Developer Edition, Blender,…

But Mutter actually allows the clients to set a theme for their window decorations even though they’re rendered on the server side. They just need to set an x window property GTK_THEME_VARIANT=dark.

And I think the difference speaks for itself:

snimek-z-2017-01-10-18-55-41

snimek-z-2017-01-10-16-52-05

You can test it by executing: xprop -f _GTK_THEME_VARIANT 8u -set _GTK_THEME_VARIANT dark

and clicking the window where it should apply.

Are you a user of one of the apps that would benefit from it? Or even a contributor? Try to convince the project to implement this tiny change. If you’re a distro maintainer of such an app, you may consider applying a small patch.

Fedora, GNOME, LibreOffice, Linux

Installing flatpaks gets easier in Fedora 25

A lot of users complained that installing flatpaks was too difficult. And they were right, just look at the installation instructions on the Flatpak download page at LibreOffice.org. But that was never meant to be the final user experience.

flatpak-logo

Richard Hughes integrated Flatpak support into GNOME Software and the Red Hat desktop apps team worked with him to make sure it works well with apps we’ve already packaged for Flatpak. And this is the result. As you can see installing LibreOffice for Flatpak is now a matter of a couple of clicks with GNOME Software 3.22.2 in Fedora 25:

 

Flatpak allows you to generate a .flatpak bundle which includes the app and all the necessary info for installation of the app and setting up its repo for future updates. You can also create a .flatpakref file which doesn’t contain the app, but all the installation info and the app is downloaded during the installation. This format is also supported by GNOME Software now. LibreOffice offers a .flatpak bundle because it’s more similar to what users are used to from Windows and macOS.

As you can see on the video, installing .flatpak bundles is a matter of downloading the file and opening it directly with GNOME Software or double-clicking it. There is one prerequisite though. You need to have a repo of the runtime the app requires enabled which I had because I had been using the GNOME runtime for other apps already. Installation of runtimes is being streamlined as well. As a runtime provider, you can ship .flatpakrepo file which includes necessary info for setting up the repo and is as easy to install as .flatpak and .flatpakref. For Fedora Workstation we’re currently considering to enable repos of most common runtimes by default, so users would not have to deal with them at all, the required runtimes would get installed automatically with the app.

Fedora, GNOME, Linux, Red Hat

GNOME 3.22/KDE Plasma 5.8 release party in Brno

Last Thursday, we organized a regular Linux Desktop Meetup in Brno and because two major desktop environments had had their releases recently we also added a release party to celebrate them.

The meetup itself took place in the Red Hat Lab at FIT BUT (venue of GUADEC 2013) and it consisted of 4 talks. I spoke on new things in GNOME 3.22, our KDE developer Jan Grulich spoke on new things in Plasma 5.8, then Oliver Gutierrez spoke on Fleet Commander and the last talk was given by Lucie Karmova who is using Fedora as a desktop in a public organization and shared her experiences with the Linux desktop.

meetup

After the talks, we moved to the nearby Velorex restaurant to celebrate the releases. The whole event attracted around 25 visitors which is definitely above the average attendance of our meetups. Let’s see if we can get the same number of people to the meetup next month.

Last, but not least I’d like to thank the Desktop QA team of Red hat for sponsoring the food and drinks at the release party.

meetup2

GNOME, Red Hat

We’re looking for a GNOME developer

We in the Red Hat desktop team are looking for a junior software developer who will work on GNOME. Particularly in printing and document viewing areas of the project.

The location of the position is Brno, Czech Republic, where you’d join a truly international team of desktop developers. It’s a junior position, so candidates just off the university, or even still studying are welcome. We require solid English communication skills and experience with C (and ideally C++, too). But what is a huge plus is experience with GNOME development and participation in the community.

Interested? You can directly apply for the position at jobs.redhat.com or if you have any question, you can write me: eischmann [] redhat [] com.

198px-gnomelogo-svg