Six months in development, GNOME 41 is here as a hefty update and the first major release after GNOME 40 with new features like a new power mode setting in the Power settings panel of the GNOME Control Center called Performance, which will be available on hardware that supports this feature. The Performance mode increases CPU performance to allow your apps and activities to run faster.

Also new in the GNOME Control Center is a Multitasking settings panel that gives you control over window management and workspace multitasking options like the Activities hot corner, Active Screen Edges, the ability to show workspaces on all displays, choose between dynamic or fixed workspaces, and restrict app switching to the current workspace when using the Super+Tab keyboard shortcut.

For PC / notebook has a small display, it’s possible to hide the top panel in GNOME desktop to get more spaces and/or focus on your work.

There’s a ‘Hide Top Bar‘ extension that enables ability to auto-hide the top bar, just like the left dock does. However, in this tutorial I’m going to introduce another extension.

It’s a very light extension that the developer promoted it has no options and no bugs! It will ALWAYS hide the top-bar, except only in overview screen. Just like GNOME shows the dock only in overview without Ubuntu Dock (Dash-to-dock) extension.

The extension will also disable the top-left hot-corner, which is used to trigger the ‘Activities‘ overview. It’s designed for those who are accustomed to start overview screen using the Windows (or Super) key, or three-finger touchpad gestures in GNOME 40 (defaults in Ubuntu 21.10).

Before we start, let’s get this out of the way because the week long delirium on social media has dragged enough.

Yes, libadwaita “hardcodes” Adwaita. Yes, applications, as is, will not be following a custom system theme. Yes this does improve the default behavior of application for GNOME when run on other platforms like Elementary OS. However, this is was the result of a technical limitation, and not some evil plot as Twitter will keep telling you…

The reason is that in order for High Contrast (and the upcoming Dark Style) to work, libadwaita needs to override the theme name property so it doesn’t fallback to GTK’s “Default” High Contrast style. The “Default” style is an older version of Adwaita, not your system style.

Compared to GTK 3, there isn’t a new way to enforce the “hardcoded” style. The GTK_THEME variable still works, as does gtk.css and probably 3 other ways of doing this. Likewise, if you are developing a distribution, you have control of the end product and can do anything you want with the code. There is a plethora of options available. Apparently complaining on social media and bullying volunteers into submission was one such option…

And I guess this also needs to be stated: this change only affects apps that choose to use libadwaita and adopt the GNOME Design Guidelines, not “every” GTK 4 application.

As usual, the fact that the themes keep working doesn’t mean they are supported. The same issues about restyling applications when they don’t expect it apply and GNOME can not realistically support arbitrary stylesheets that none of the contributors develop against and test.

You may associate Linux with the freedom to make your desktop look however you want, but that’s not the case with GNOME. At least, not without knowing which extensions to install or how to read code. By default, GNOME is intended to look and feel a certain way, and many developers would prefer if Linux distributions didn’t change the appearance of their apps by using themes.

Is it an issue when you change the theme on your own personal machine? No, you know what you're getting yourself into. But confusion can arise when the customized experience comes presented as the default.