We’ve been working hard for the last months to improve GNOME Software both in Fedora Workstation and Silverblue, especially its reliability. One thing we identified as a problem is a long feedback loop. I took months before bug reporters and designers could easily test changes made based on their feedback.
That’s why Milan Crha, the new GNOME Software maintainer, created a Copr repository that includes the latest development version of GNOME Software. If you want to help us with testing, install GNOME Software from the Copr repository and report issues. They won’t be overlooked. Milan is a very responsive maintainer.
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:
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.
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.
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.
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.
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.
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:
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.
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.
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.
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.
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.
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.
I and Carlos Soriano, the upstream maintainer of Nautilus, have been discussing if batch file renaming is a feature that makes a sense for the default file browser in GNOME and Fedora.
I’ve seen quite a few users complaining/wishing for the feature and competition has it. Finder in OS X has probably the most advanced batch file renaming, but Windows Explorer and Dolphin can do it to some degree, too.
There are a couple of plugins that add the feature to Nautilus, but they’re not actively maintained, they haven’t been for years. So if we want to make this feature available to users, it’s probably better to include it in Nautilus directly than relying on any of these plugins.
Is is something you miss in Nautilus? Do you use any other tool or even the Nautilus plugins to perform such a task? What are use cases typical Nautilus users have for such a feature?
I planned to go to a FUDCon APAC or LATAM for some time because a lot of people told me they had a very different atmosphere from the ones in NA and EMEA and now Flock. I decided for FUDCon in Beijing this year and Jaroslav Reznik joined me. Originally, we planned it as holidays. But then the organizers asked us to do a keynote and we were invited to the Beijing office of Red Hat to do a presentation, so it wasn’t completely holidays in the end.
I must say that I was very positively surprised. The conference was very, very well organized. Co-hosting FUDCon with GNOME.Asia was also a very good idea. It attracted more people and more contributors of both projects. And it also made sense from the topic point of view because Fedora and GNOME definitely have some overlap.
We arrived on May 22 and didn’t have any problem to find the hotel mainly due to great information in the Guidebook app that was prepared by the organizers. The Beijing subway is one of the best I’ve seen and it’s extremely cheap. One unlimited ride is just for $.30! We had surprisingly big problems to communicate. Almost no one in Beijing understands English and if someone does it’s also quite challenging to communicate with him/her because the languages are so different. The Chinese characters were also a big challenge. Unlike with the Latin alphabet where you can get at least a bit of the sense even if you don’t understand the language the Chinese characters were completely untranslatable for us. Fortunately, I found an Android app Hanping Camera that scans Chinese characters and translates them to English. I also downloaded an offline vocabulary for Google Translate so that I can translate what I needed to say to someone who didn’t understand English. As I know from English-Czech translations Google Translate is not perfect, but it worked quite well. Definitely better than nothing and our Chinese language skill were really non-existent.
I met most of the attending Fedora contributors at the FUDPub. It was a nice event, but the pub didn’t have cold beer. They had everything (soft drinks, teas,…) in a fridge, only beer was outside. Quite a paradox. So after a while a bunch of Fedora contributors moved back to the hotel in need for cold beer 🙂
The next day in the morning, we had our keynote. We talked on Fedora.NEXT changes. Jaroslav talked more about changes in the technologies, I was talking more about the people part of the project. Unfortunately, we probably overestimated the knowledge of attendees and I was told several times after the keynote that it might have been too complicated. Maybe we should have gone for some general topic.
I also attended several other Fedora talks such Fedora Websites by Robert Mayr, Fedora Women by Nitesh Narayanlal, Life of Translator by Tommy He, Hackfest: Packaging a ROS Groovy SCL for Fedora by Ankur Sinha. What was quite interesting was the talk “Re-rolling Fedora with Conary” by Martin Bähr. I’d never heard of Conary before, actually I had, but I didn’t know any details. There were some useful features which can be used in Fedora. Collections of packages might be useful in Rawhide where users could update to the lastest tested collection of packages and avoid breakages. On the other hand, it wouldn’t work with the way Fedora repositories are done today when you only have the initial and the latest version of a package in the repositories, nothing between. This also prevents using Conary for rollbacks. I can also see some feature overlap with OSTree although Conary seems to be more package based.
The conference was closed by a dinner for organizers and speakers in a nearby hotel and I must say it was probably the best buffet I’ve ever had at an open source conference.
On Monday, we went to the Red Hat office to give a talk on cooperation with universities and on Fedora activities. I was quite surprised that not so many redhatters are involved in the local Fedora community. It’s quite different from e.g. the Czech Republic where redhatters are the backbone of the local community. I hope our talk showed a way and at least a bit contributed to improvement.
On Tuesday, we went to the office again to give a presentation about our country. It was interesting to see that the Chinese redhatters were surprised that Škoda is actually a Czech brand, not Chinese, that we also have dumplings, but quite different from the Chinese ones, and that our country is mostly atheistic. After the presentation, we went to Beijing Linux User Group meeting which was special this time because there were still a lot of foreigners that came for FUDCon or GNOME.Asia.
From Wednesday to Sunday, we explored Beijing and its neighourhood. The temperature went up to 41C, but air conditions were apparently one of the best because there was no visible air pollution and there was even a blue sky on some days which is pretty rare according to locals.
I really want to thank local organizers who did a truly great job with FUDCon APAC in Beijing and I also want to thank the Fedora Project for sponsoring our hotel accommodation during the conference. And FUDCon APAC 2015? I think we should start thinking about it as soon as possible so that it’s as successful as this year’s one.
Brno hat 