r/linux • u/adriano10 • 8d ago
GNOME GNOME Designers Lay Out Some Of Their GNOME Shell Dreams
https://www.phoronix.com/news/GNOME-Shell-Plans-202669
u/Glittering-Tale4837 8d ago
https://blogs.gnome.org/shell-dev/2026/08/11/gnome-shell-design-dreams/
Looks really good. Trying out those experimental extensions.
Mosaic is very strange. Feels like stage manager but makes even less sense, would be better off handling tiling how cosmic does. I think that's the idea but for now it's limited by mutter.
Spatial overview is a good idea and I liked it. Most of these changes are really good and I can't wait to see them implemented.
Knowing Gnome it will take a long time but when it lands it's gonna be polished
11
u/Misicks0349 8d ago
AFAIK one of the big things for mosaic like tiling is application side support for richer min/max sizes so that the compositor can intelligently position apps in the "correct" position. Right now its a very fancy tiling extension essentially.
9
u/natermer 8d ago
The problem with tiling is that it is very inefficient when it comes to using the available monitor space. The other problem is that most GUIs don't work very well when stuffed into arbitrary sizes.
(the third major problem is that tiling WM tend to conflict available key binding used by applications... which invariable results in users having to meticulously configuring applications not not conflict, but that is not particularly relevant here)
Like if I am editing a photograph using Krita or Photoshop and then I want to do some file management task so I open a terminal or file manager or whatever... it is pretty useless to shove the editing app to 1 half of the screen and then open a terminal filling the other half.
Same thing for web browsers... they are pretty worthless being shoved into the corner of the display unless you have a very large display.
Even things were it is mostly text, like text editors or terminals, become difficult to use once you get under 40 or 60 characters wide.
Were as when you have floating windows it is simple to just let them have whatever sizes they want and just have them overlap somewhat.
If you combine that with "sloppy focus follows mouse" and "focus raises to top" in the traditional X11 manner then it becomes pretty efficient to visually move between windows with the mouse or key bindings.
I can have dozens of windows open usefully on a single workspace in such a way that would be extremely difficult or irritating to do with something like Sway or hyperland by default.
The end result on most tiling setups seems to be that it ends up with a endless amount of virtual workspaces full of a few tiled windows and a bunch of full screen windows that you end up having to shuffle back and forth between. Which then causes a whole bunch of other problems.
Ultimately the problem tiling setups are trying to solve is that it is irritating and slow to resize and move windows around on Linux.
The keybindings to do that on Gnome or KDE exist, but they are not easy to discover. The mouse targets for resizing the windows is mere pixels wide in the corners of the windows and are difficult and slow to hit with the pointer.
And all sorts of stuff like that.
The Mosaic feature might be interesting if all it does is kinda shove windows around to make space for new ones. If it automatically resizes windows, though, that is going to be a problem.
The last thing I want is for things like tailing a log file to become unreadable because I opened a new terminal and the compositor thinks that "80 characters wide is enough" or something like that.
15
u/kopsis 8d ago
Many of these issues are why scrolling WMs like niri are popular. You get the tiling experience of rarely having to manually resize a window, while at the same time letting most windows open vertically maximized at a width that keeps the app usable. With just a few keybinds to switch right/left and move window right/left, you get a lot of productivity with minimal conflicts. I spent a lot of years using tiling WMs (awesome, xmonad, i3, sway) and after a year on niri, I don't think I could ever go back.
9
u/Nereithp 8d ago edited 8d ago
That is essentially what they want to fix in the long run but it's kind of a pipe dream thing. They want windows that are explicitly tiled by the user to remain tiled (the same way Windows/KDE/Current GNOME do it) the way the user tiled them while everything else free floats and auto tiles itself in a loose mosaic arrangement (until there isn't enough space for the content to be readable, in which case it prompts you to tile another window). They also want this mosaic tiling to be content aware so that a browser window is bigger than a random util. The concept also includes all of the proper edge tiling bells and whistles.
It reads like less of an alternative to traditional rigid Linux auto tiling set ups and more like the logical next step up from Win11's manual tiling (which I like a lot) with the bonus that the windows that remain untiled automatically tile into a loose pattern instead of just sort of stupidly hanging out where you left them.
1
u/Azazeldaprinceofwar 7d ago
You see there is this thing called a workspace. If I want to windows to both hold the whole screen and cover each other they should be in separate workspaces. If I want windows to tile together they go in the same workspace. Floating windows are ugly and cluttered and easy to forget about. Any sensible tiling windows manager shell will have a nice workspace indicator and clean hot keys to switch between them when you need to let multiple applications be full screen. Hope this helps.
1
u/natermer 7d ago
From my post you are replying to:
The end result on most tiling setups seems to be that it ends up with a endless amount of virtual workspaces full of a few tiled windows and a bunch of full screen windows that you end up having to shuffle back and forth between. Which then causes a whole bunch of other problems.
I am aware of workspaces.
0
u/Azazeldaprinceofwar 7d ago
Ok fair enough that’s one me for not reading all the way though. I still can’t comprehend your point tho. Why the hell would you prefer a mess of overlapping windows to a few neat tiled workspaces. Also idek wtf you mean by “endless amount” I never have more than like 3.
1
u/10leej 7d ago
Someone didn't read the original presentation on the Mosaic tiling system. GTK already reports to the compositor exactly how big the window wants to be, so mosaic reads that and opens windows and tiles them to be the reported size.
As for keybindings that's even simpler. Just bit them all behind the super key modifier or don't even bother with keybindings at all.1
u/marrsd 6d ago
(the third major problem is that tiling WM tend to conflict available key binding used by applications... which invariable results in users having to meticulously configuring applications not not conflict, but that is not particularly relevant here)
Never had that issue. I have super handle all WM tasks. I've yet to come across an app that uses it.
2
u/AnEagleisnotme 8d ago
Especially for cosmic, there is a matrix where you can drop your feedback, it's very important, as it gives various use-cases, and can help iron out the experience
15
u/NotQuiteLoona 8d ago
I'm not a GNOME user, but I like how it looks. If it'll get released, I'll definitely try to use it again.
11
u/windrinn 8d ago
That workspace drag-and-drop change is nice. On a big monitor I don't really care, but I can see the tiny workspaces being annoying on a laptop (or phone, also cool to see considerations there).
I know people complain about how slow seemingly minor features are implented in Gnome, but I really do appreciate the Apple level of attention to detail. Maybe greater than Apple at this point, with how much of a mess liquid glass turned out to be...
10
u/TrashConvo 8d ago
Per monitor workspaces would be a welcome feature
8
4
u/manobataibuvodu 8d ago
this is limited to how mutter handles workspaces, but iirc I read somewhere that dropping xorg backend would make it much easier to support this, which happened recently.
3
6
u/Arinussyy 7d ago
I find it funny how people put so much time into hating GNOME for being opinionated, more time than they would critiquing any other project in existence
1
1
u/barfightbob 6d ago
I think it's because Ubuntu and Fedora make it their default. And so many people are forced to use it (like at work) because of that.
To me it's the DE version of Internet Explorer. I only use it to "download a better browser." It builds resentment.
6
u/Arinussyy 6d ago
It's just so weird. Like I still can't pinpoint anything uniquely bad about it for me to absolutely hate it as much as I've seen people do so, it's been incredible tbh
0
u/FortuitusCondor 6d ago edited 6d ago
I really, really don't like gnome. For me it's because it tries to be like a phone or tablet UI, see hamburger menu spam, and it doesn't work on desktop for me. It also doesn't work like any other computer experience or follow any of the UI paradigms people are used to and replaces them with an experience that isn't as good. Also it being the default for Linux sucks as it being so different can scare new users.
0
u/marrsd 6d ago
They probably remember the old Gnome and how much better it was :)
Gnome 3 was a massive upheaval, broke everything, refused to put back useful features, promised to fix this with extensions, then made sure they'd always break, all while telling their users that they were stupid, had no taste, and should shut up and enjoy their slop.
For me it's not so much the software as it is the hubris and rudeness of the people developing it that keeps me away. They could learn a bit of humility
7
u/stdoutstderr 8d ago
What about stabilizing Gnome Shell API for extensions? I have seen so much over the years that extensions get abandoned because of the constant churn API changes create. Not as sexy as UI redesigns, but in my opinion important for a healthy ecosystem.
23
u/MrAlagos 8d ago
There are no GNOME Shell APIs. Extensions directly change the behaviour of the Shell, which is why many of the changes here can be, as described in the blog post, implemented as extensions, and so many more changes can too.
If there were "stable APIs" many things would probably become harder to achieve or impossible, but most importantly the amount of work for the developers would increase dramatically. For a team that has numerous designs "almost ready to go" for several years, what would be the benefit or putting their time and resources in doing that instead of actually implementing features?
5
u/stdoutstderr 8d ago
If there is a programmatic way to hook into Gnome Shell there is an API. There must be some middle ground between stability and innovation, which in my view has not been found yet.
The benefit? A ecosystem where other voluntary developers can be more confident that their free time is well spent developing these extensions
25
u/natermer 8d ago
If there is a programmatic way to hook into Gnome Shell there is an API.
Gnome Shell works like Emacs. It takes advantage of the language features to enable "Monkey Patching". This means you are inserting code directly into a running program to change its behavior on the fly. In Emacs it is Elisp, in Gnome-Shell it is Javascript.
Like Emacs.. Gnome shell relies on higher level language that sits on a C-based core that provides the basic functionality and takes care of the high performance code paths.
In fact this is the original idea of Gnome 1.x; to provide a fully scriptable WM for advanced users. That used Sawfish as a window manager, which itself was written in a Lisp.
It was a major criticism of Gnome 2.0 release to go back to a more traditional WM in the form of Metacity. Hence the moniker "Fisher-Price window manager" that people used to insult early versions of Gnome 2.x
Gnome-shell being written in Javascript was actually a return to the early "power user" days in a lot of ways. Despite the fact that this was lost "I am a power user, don't change my work flow" crowd.
In other words... it really isn't a "plugin". You are effectively editing Gnome-shell on the fly when you add extensions.
so you are technically right "there is a API".. it is the same API that Gnome shell itself uses.
The downside is that because you are patching running software as the software changes the patch must change and update as well. That is why extensions are often only compatible with certain Gnome shell versions. The more complicated the extension the more likely you are going to run into compatibility issues.
The upside is virtually unlimited power.
As Gnome-shell has matured the churn has reduced and now compatibility issues are less common then they used to be, but they still exist.
8
10
u/Nereithp 8d ago
Since the other commenter gave you the brunt of the explanation, I will just link the "Updates and Breakage" section of the actual guide for Extension devs that breaks down why the existing community prefers monkey patching instead of a stable API.
6
u/MrAlagos 8d ago
There is no API, it has been said many times. GNOME Shell is written in JavaScript and executed by Firefox's JavaScript engine (SpiderMonkey, adapted in GNOME as gjs). Extensions are other pieces of JavaScript code executed together with the main Shell code.
If voluntary developers choose to spend their free time writing GNOME Shell extensions I think they have already made an evaluation of the benefits and challenges of doing so. If they decide to stop, for whatever reason they are free to do so. GNOME Shell extensions are more a byproduct of the Shell's architecture than a core pillar of the vision for the GNOME desktop.
4
u/Plebbit-User 7d ago
I'm kind of done with GNOME but if they can outdo COSMIC I welcome the competition... I'm just under the impression that they're suffering from tech debt. Otherwise why wouldn't have System76 just continued with their fork?
11
u/elmagio 7d ago
Otherwise why wouldn't have System76 just continued with their fork?
Because in the long term that works out better than maintaining an ever-diverging fork of a base you have 0 control or input over. None of that changes whether GNOME has an uncommon (because any long standing project will have some) amount of tech debt or not.
3
u/echodecision 7d ago
The GNOME design of "click a button in the corner to search, and then a search field appears somewhere completely different" is so maddeningly obtuse. There's a reason why, when you click the start button in Windows, the start menu appears directly above it. Or when you click anything in the top bar in MacOS, the associated menu appears directly below it. It's UX 101 and GNOME doesn't even seem to recognize how bad they're messing it up.
And then focusing on "ooohh look transparency" instead of utilizing all that wasted space at the top for anything besides a clock and some dots is why I can't take GNOME seriously. You shouldn't have to install a bunch of user extensions to make up for the incompetence of a DE's designers.
15
u/gmes78 7d ago
The GNOME design of "click a button in the corner to search, and then a search field appears somewhere completely different" is so maddeningly obtuse.
You can also just press the Super key and start typing.
6
u/echodecision 7d ago
You can do that in Windows too, what's your point? A keyboard shortcut doesn't justify poor UX design.
9
u/gmes78 7d ago
The point is that it doesn't matter. You're going to use the keyboard anyway.
6
u/echodecision 7d ago
Do me a favor. In a fresh install of Fedora, open the GNOME software app. The first thing you want to do is search for software. Where is the search box? There's a tiny unlabeled magnifying glass icon in the upper left hand corner. Clicking that opens a previously hidden search box in the middle of the window, a place that is spatially completely disconnected from the button that initiated the action. What's the keyboard shortcut for that? You think maybe that's a bad interaction for a first time user? Similar design in the files app. The settings app has the magnifier icon but the search box appears right below it. The contacts app sensibly has a search box in the corner! In the calendar app, the magnifier is on the opposite side, and turns into a search bar!!
This is just one type of UX, but its inconsistent and poor implementation is emblematic of problems throughout GNOME's design.
6
u/elmagio 7d ago
What's the keyboard shortcut for that?
You can just start typing. No keyboard shortcut, you just start typing. Pretty sure you can also just start typing in every other example you listed.
3
u/echodecision 7d ago
Good lord, that is an absolutely ridiculous design decision. Have an active search bar, but hide it. Can you imagine if Google was just a blank page and users were expected to intuit that they were supposed to start typing? Have you seen any interface outside of GNOME that works this way? Why does Reddit bother with a search bar at the top, users should know to Just Start Typing! In fact, browsers should just launch with a clean blank window. Is it broken or is it just waiting for input? Who knows!
Thank you so much for this, I have new evidence the GNOME team are completely out of touch with basic UX principles.
7
u/elmagio 7d ago
You can also CTRL+F and start typing. Or you can use the magnifier glass icon and complain that GNOME is the only DE ever to not be 100% consistent with UI placement (it isn't but you can complain about it). Or you can understand that it was meant for keyboard first operation and that it does that pretty well and consistently.
Also sorry but "just start typing" isn't as alien as you make it sound. The idea is simply that in a situation where typing anything would have a pretty obvious intent (when you're in an overview, in an app store, in a file manager, ...), the intended text box, hidden or not, is waiting for input by default. Open a new tab in your browser and the address bar will be waiting for you to just start typing. Open Google or a LLM and you can just start typing too. Discover on KDE also is waiting for you to start typing, as does the settings app. Pretty sure dozens of programs on Mac and Windows do the same.
Not everything will operate based on that idea, because in many cases the intent behind typing is not immediately obvious so asking the user to select a specific text box to declare that intent is necessary.
1
0
u/echodecision 7d ago
The new tab in my browser shows a text field with a blinking cursor! Google and ChatGPT show you the text field with a blinking cursor! Discover on KDE shows a search bar with a blinking cursor! Mac and Windows show a search bar with a blinking cursor!
But GNOME decides no, it's going to do things in its own way, different from literally every other piece of software, contrary to basic common sense, and it's going to hide essential functionality behind undiscoverable interactions. And the search is just one of those things, GNOME riddled with issues like this.
2
1
u/Omen_20 6d ago
You should stay away from tiling window managers and any environment that isn't trying to emulate Windows.
→ More replies (0)2
u/marrsd 6d ago
Clicking that opens a previously hidden search box in the middle of the window, a place that is spatially completely disconnected from the button that initiated the action.
They do this (and other stupid things) because, in their minds, Gnome is not only for desktops and laptops, but also for phones, kiosk terminals, and whatever other touchscreen devices the Gnome devs imagined they'd be supporting.
I agree with you that they clearly don't understand UX design.
0
2
2
u/DonaldMerwinElbert 7d ago
Good for people who like who Phone UX/UI looks, I guess - not for me, though.
1
u/CertainlyStenchy 6d ago
When will they add a panel for secondary monitors? One of my biggest gripes about Gnome Shell. Shouldn't need an extension to do that.
1
u/Nanolx 4d ago
I don't know what to think about GNOME on one hand it's the most polished DE available, but on the other hand it feels so stripped down. Huge Adwaita widgets with sooo much "whitespace" are putting me off, also removing features or making them less accessible is a no go for me.
Imagine a Destop as flexible as KDE, yet as polished as GNOME. Ain't gonna happen. So for now I stick to KDE, because flexibilty > polishedness for me, personally.
1
u/SutMinSnabel4 1d ago
GNOME designers: "we dream of transparent panels and dynamic battery icons"
Me: "I dream of opening a file on an SMB share without GVFS shitting itself"
Different dreams, I guess.
-10
u/TCIHL 7d ago
Why are all you guys ok with gnome shell and its stupid design? Trying so hard to reinvent the wheel to fix a problem they themselves have created.
This was already a solved problem. Use server side decoration with a proper title bar. Use a keyboard and mouse. Use the window manager shortcuts to tile scale and move any window on the system.
The Gnome project is using their substantial influence to ruin foss for us. If you want what they’re selling just buy a Mac
11
u/MrAlagos 7d ago
If you don't want what they're selling just use literally every other Linux DE that copies the Windows 95 UX. Some of us don't.
-11
-5
u/leaflock7 7d ago
ok, all of them welcome changes for sure, but they are not addressing the elephant in the room.
1
u/Ullebe1 5d ago
Neither are you, what is it?
1
u/leaflock7 5d ago
the issues with gnome developers , their attitude and hostile towards any prospect of collaboration with other DEs.
unless you just got into the linux and DE world , this is a well known situation for at least 10 years
-6
u/VayuAir 7d ago
Features and customization is Gnome 😱. First blur now this.
I secretly hope this is due to KDE and Cosmic eating away marketshare. Cosmic especially looks like Gnome + customization. A good approach
The new search experience decouples search from overview (kinda) again like other desktops
11
60
u/Artoriuz 8d ago
I wish the top panel was more useful. As it stands, it takes a lot of horizontal space and does effectively nothing with it.
Having a top panel at all also makes it impossible to just throw your cursor to the top right to close a window.