Window management is one of those areas I’m fascinated with because even after 50 years, nobody’s fully cracked it yet. Ever since the dawn of time we’ve relied on the window metaphor as the primary way of multitasking on the desktop. In this metaphor, each app can spawn one or more rectangular windows, which are stacked by most recently used, and moved or resized manually.
The traditional windowing system works well as long as you only have a handful of small windows, but issues emerge as soon the number and size of the windows grows. As new windows are opened, existing ones are obscured, sometimes completely hiding them from view. Or, when you open a maximized window, suddenly every other window is hidden.
Over the decades, different OSes have added different tools and workflows to deal with these issues, including workspaces, taskbars, and switchers. However, the basic primitives have not changed since the 70s and, as a result, the issues have never gone away.
While most of us are used to this system and its quirks, that doesn’t mean it’s without problems. This is especially apparent when you do user research with people who are new to computing, including children and older people. Manually placing and sizing windows can be fiddly work, and requires close attention and precise motor control. It’s also what we jokingly refer to as shit work: it is work that the user has to do, which is generated by the system itself, and has no other purpose.
Most of the time you don’t care about exact window sizes and positions and just want to see the windows that you need for your current task. Often that’s just a single, maximized window. Sometimes it’s two or three windows next to each other. It’s incredibly rare that you need a dozen different overlapping windows. Yet this is what you end up with by default today, when you simply use the computer, opening apps as you need them. Messy is the default, and it’s up to you to clean it up.
What about tiling?
Traditional tiling window managers solve the hidden window problem by preventing windows from overlapping. While this works well in some cases, it falls short as a general replacement for stacked, floating windows. The first reason for this is that tiling window managers size windows according to the amount of available screen space, yet most apps are designed to be used at a certain size and aspect ratio. For example, chat apps are inherently narrow and end up having large amounts of empty space at large sizes. Similarly, reading a PDF in a tiny window is not fun.
Another issue with tiling window manager is that they place new windows in seemingly arbitrary positions. This is a consequence of them not having knowledge about the content of a window or the context in which it is being used, and leads to having to manually move or resize windows after the fact, which is exactly the kind of fiddling we want to avoid in the first place.
More constrained tiling window managers such as on iPadOS are interesting in that they’re more purposeful (you always intentionally create the tiling groups). However, this approach only allows tiling two windows side-by-side, and does not scale well to larger screens.
History
This topic has been of interest to the design team for a very long time. I remember discussing it with Jakub at my first GUADEC in 2017, and there have been countless discussions, ideas, and concepts since. Some particular milestones in our thinking were the concept work leading up to GNOME 40 in 2019 and 2020, and the design sessions at the Berlin Mini GUADEC in 2022 and the Brno hackfest in 2023.
I personally have a bit of a tradition working on this problem for at least a few weeks per year. For example, during the first lockdown in 2020 I spent quite a bit of time trying to envision a tiling-first version of GNOME Shell.
Problems with our current tiling
GNOME has had basic tiling functionality since early in the GNOME 3 series. While this is nice to have, it has obvious limitations:
- It’s completely manual
- Only 2 windows are supported, and the current implementation is not extensible to more complex layouts
- Tiled windows are not grouped in the window stack, so both windows are not raised simultaneously and other windows get in the way
- Workspaces are manual, and not integrated into the workflow
We’ve wanted more powerful tiling for years, but there has not been much progress due to the huge amount of work involved on the technical side and the lack of a clear design direction we were happy with. We now finally feel like the design is at a stage where we can take concrete next steps towards making it happen, which is very exciting!
Get out of my way
The key point we keep coming back to with this work is that, if we do add a new kind of window management to GNOME, it needs to be good enough to be the default. We don’t want to add yet another manual opt-in tool that doesn’t solve the problems the majority of people face.
To do this we landed on a number of high level ideas:
- Automatically do what people probably want, allow adjusting if needed
- Make use of workspaces as a fully integrated part of the workflow
- Richer metadata from apps to allow for better integration
Our current concept imagines windows having three potential layout states:
- Mosaic, a new window management mode which combines the best parts of tiling and floating
- Edge Tiling, i.e. windows splitting the screen edge-to-edge
- Floating, the classic stacked windows model
Mosaic is the default behavior. You open a window, it opens centered on the screen at a size that makes the most sense for the app. For a web browser that might be maximized, for a weather app maybe only 700×500 pixels.
As you open more windows, the existing windows move aside to make room for the new ones. If a new window doesn’t fit (e.g. because it wants to be maximized) it moves to its own workspace. If the window layout comes close to filling the screen, the windows are automatically tiled.
You can also manually tile windows. If there’s enough space, other windows are left in a mosaic layout. However, if there’s not enough space for this mosaic layout, you’re prompted to pick another window to tile alongside.
You’re not limited to tiling just two windows side by side. Any tile (or the remaining space) can be split by dragging another window over it, and freely resized as the window minimum sizes allow.
There are always going to be cases that require placing a window in a specific position on the screen. The new system allows windows to be used with the classic floating behavior, on a layer above the mosaic/tiling windows. However, we think that this floating behaviour is going to be a relatively uncommon, similar to the existing “always on top” behavior that we have today.
There’s of course much more to this, but hopefully this gives an idea of what we have in mind in terms of behavior.
New window metadata
As mentioned above, to avoid the pitfalls of traditional tiling window managers we need more information from windows about their content. Windows can already set a fixed size and they have an implicit minimum size, but to build a great tiling experience we need more.
One important missing piece is having information on the maximum desired size of a window. This is the size beyond which the window content stops looking good. Not having this information is one of the reasons that traditional tiling window managers have issues, especially on larger screens. This maximum size would not be a hard limit and manual resizing would still be possible. Instead, the system would use the maximum size as one factor when it calculates an optimal window layout. For example, when tiling to the side of the screen, a window would only grow as wide as its maximum width rather than filling exactly half of the screen.
In addition, it’d be helpful to know the range of ideal sizes where an app works best. While an app may technically work at mobile sizes that’s probably not the best way to use that app if you have a large display. To stay with our chat example, you probably want to avoid folding the sidebar if it can be avoided, so the range of ideal sizes would be between the point where it becomes single pane and its maximum usable size.
Ideally these properties could be set dynamically depending on the window content. For example, a spreadsheet with a lot of columns but few rows could have a wider ideal size than one with lots of rows.
Depending on apps using new system APIs can be challenging and slow — it’s not easy to move the entire ecosystem! However, we think there’s a good chance of success in this case, due to the simplicity and universal usefulness of the API.
Next steps
At the Brno hackfest in April we had an initial discussion with GNOME Shell developers about many of the technical details. There is tentative agreement that we want to move in the direction outlined in this post, but there’s still a lot of work ahead.
On the design side, the biggest uncertainty is the mosaic behavior — it’s a novel approach to window management without much prior art. That’s exciting, but also makes it a bit risky to jump head-first into implementation. We’d like to do user research to validate some of our assumptions on different aspects of this, but it’s the kind of project that’s very difficult to test outside of an actual prototype that’s usable day to day.
If you’d like to get involved with this initiative, one great way to help out would be to work on an extension that implements (parts of) the mosaic behavior for testing and refining the interactions. If you’re interested in this, please reach out :)
There’s no timeline or roadmap at this stage, but it’s definitely 46+ material and likely to take multiple cycles. There are individual parts of this that could be worked on independently ahead of the more contingent pieces, for example tiling groups or new window metadata. Help in any of these areas would be appreciated.
This post is summarizing collaborative work over the past years by the entire design team (Allan Day, Jakub Steiner, Sam Hewitt, et al). In particular, thanks to Jakub for the awesome animations bringing the behaviors to life!
This is a very cool idea!
I think the window manager and the workspace manager should work together. Instead of having a number of independent workspaces, we could have one large seamless horizontal workspace; and, instead of moving the viewport one whole workspace at a time, we could move it only one tile at a time:.
The extension PaperWM does something along the lines of what you are describing (though it also uses vertical workspaces, I think in theory this is optional).
So ur basically describing [paperwm](https://github.com/paperwm/PaperWM)
This is what 3, or 4, or 5 screens next to each other do for you.
This whole thing looks like driven by a single screen (pad / laptop) concept limitations.
Having a lot of physical screens significantly limits the problems.
Agreed! DesktopD when? Will Lennart save us once again?
Something like App Groups on Android or iPad OS?
Seems like a novel and interesting idea! Although I am not sure about these 2 ideas:
> You can also manually tile windows. If there’s enough space, other windows are left in a mosaic layout. **However, if there’s not enough space for this mosaic layout, you’re prompted to pick another window to tile alongside.**
> If a new window doesn’t fit (e.g. because it wants to be maximized) it moves to its own workspace.
Those behaviors seem kinda unpredictable/inconsistent since they depend on the current layout situation. Although I guess that can only be judged when actually trying it out in practice…
Any way, the state of the union of the design was certainly a cool talk a, good job!
Hopefully, some stuff makes it into gnome sooner™ than later :)
Having maximized windows go to their own workspace was the part of this proposal that sounded the most interesting to me and I don’t think it would be all that unpredictable.
Currently, if a window launches maximized (browser) or even full screen (game) then the other windows will be hidden behind them. If you open the overview and select one of the previous windows, then the full screen application will be hidden from view completely, as if it were on a different workspace anyway. If you just have a maximized application then selecting one of the previous windows will only raise that one window above the full screen one and you have to manually raise the other ones to see them since you can’t just send the maximized window to the back.
By automatically creating new workspaces for full screen or maximized applications, getting back to the previous windows is as easy as changing the workspace. Of course it would feel weird if closing a full screen application doesn’t return you to workspace it was originally created from and if you restore a maximized application then you’d want it to join the windows of the workspace it was created from instead of continuing to live in the workspace created for it.
Obviously it’s not without it’s potential issues and it might make workspaces function in a more complex way but it feels like an interesting idea that could potentially remove some annoyances and further make workspaces feel more integral to the using Gnome. I personally very, very rarely use workspaces yet Gnome’s implementation of them is my favorite by a decent bit. When I have used them in the past, it’s usually been for maximized or full-screen apps anyway.
I did an implementation for the same purposes as you describe (although it’s AwesomeWM based, but the workflow seems to fit to your needs): https://medium.com/@bimlas/distraction-free-desktop-workspace-for-developers-554bf89ae9c1
Have you looked at https://github.com/paperwm/PaperWM ?
You are proposing different things, but I think PaperWM is still worth looking at- it works very well, and it’s very simple to use…
Paperwm is the solution to the problem in this design that warping a window that doesn’t fit over to a new workspace is inconsistent and surprising. With something like paperwm, the window can just be pushed partly offscreen and the user can scroll the viewport over to it.
I used PaperWM for almost 2 years and than it sadly began to break with newer versions of Gnome. I loved it!
I would like to see a merge of a linear window management and this new mosaic mode, because with PaperWM, windows have always full height. Maybe the mosic mode can solve this last flaw of PaperWM. (:
https://gitlab.com/cardboardwm/cardboard
https://www.youtube.com/watch?v=6O6HplPR14k
I like to recommend you having a look at XMonad and it’s configuration options.
I have an ultrawide monitor that is flat.
This sets the unique problem that not all the screen is equally visible from normal working distance.
While mosaic is interesting, what I find myself doing is moving the window I am working on to the centre of the screen before working on it if it is for anything other than a very brief interaction.
That is why I hope any work they do on this can also be utilised by extensions.
Imagine even if they don’t implement what you want, an extension that reshuffles all open windows to centre the primary one. That could be awesome.
This blog post made me remember of a desktop concept I found a few years ago: https://desktopneo.com/
maybe you can get some inspiration from this
This was kind of interesting. I like the idea of a carousel with the metadata concept that is mentioned in the above article. I would add configurable sliding dock’s (like narrow book spines) to the sides for quick access apps like messengers, notepads, email, team collaboration apps, etc. They could expand out to their optimal size for a brief interaction and than retract back out of the way after use. Thus leaving the focused working apps on the desktop in place. This carousel approach could completely replace virtual desktops as the carousel would be limitless. Or you could retain workspaces with each one it’s own carousel, say to group main apps. Like personal and work carousels, or app combos frequently used together.
I have always wanted to organization of a tiling window manager, but I haven’t wanted to learn all these keyboard shortcuts and relearn how I use my desktop. That is why I think this Mosiac solution is genius, and I’m hoping to see it in a future GNOME release, or as an extension earlier on.
The opportunistic creation and destruction of workspaces for full screen windows was something we had in Moblin/MeeGo Netbook ‘back in the day’ and worked very well in practice and user testing (if any of that really old stuff is helpful). Looking forward to seeing a much more advanced version of this in future, this all looks very promising.
One behaviour I’ve been using a lot recently in GNOME is ‘popping out’ a picture in picture video window and using the ‘always on top’ action on the window to have that work ‘properly’. It’s a bit ungainly currently and would be nice if there were OS safeguarded ways of having that work more pleasingly, even in the floating case.
That’s very interesting, do you have any materials or research results from back in the day?
We discussed picture-in-picture as a new, distinct window mode at the Brno hackfest, it’s something we’d really like to see.
Along with Pip, I always use the calculator with always on top and always visible on workspace and then have all my apps full screened in different workspaces, so I can switch between them with my touchpad. I really like the idea that full screened windows are just in their own workspace, but sometimes, like with the calculator, I want a small window that floats over a maximized window and I think that maybe there should be a way to do that ““automatically”” or by say holding the super key while dragging the window to take it into the workspace where the maximized window is.
Interesting and well explained!
“If a new window doesn’t fit (e.g. because it wants to be maximized) it moves to its own workspace.” This could break my workflow (insert XKCD here). Shortcuts for window navigation and workspace navigation are different, which is why I generally avoid workspaces unless I have to repeatedly switch between groups of windows. Having window actions lead to workflow creation could impact current usage and might bring confusion. It might be a topic worth exploring in user testing.
Same for me, 90% of the time I use apps in fullscreen mode and avoid workspaces, I just switch between the apps wir Alt+Tab. And Super+number. Sounds like the mosaic mode would break this workflow, unless it’s possible to disable workspaces.
I meant maximized (top bar still visible) not fullscreen
I came to say this. It would break my workflow where I sometimes pin a single window on one side of screen and leave the rest floating or full screen. It’s the fastest way to make it taller without obscuring the context.
I might be designing something in KiCad and need to go to the filesystem for a while. So I launch file browser or terminal, move it to side to get comfortable working space, do what I need and then close it. I might alt-tab a couple of times, but not that much.
If I need “more space” or more windows, I just drag it to create a new workspace after the KiCad one.
I often need to enlarge the secondary window temporarily. I use the Super+Up shortcut, read the long lines, work with a wide LibreOffice Calc table etc., and then either close or un-fullscreen the window. Interrupting this workflow with “too many windows, please select just two” would be rather unwelcome.
I also frequently use the two-tile terminal layout, opening a third floating terminal for a brief moment to check for minor details. Sometimes even opening a browser window for a brief period and then closing it right away. Again, interrupting this workflow would not help me.
It could break my workflow in Gnome too – the thing is that switching between windows is a one-hand operation (Alt/Tab) or Win_key + mouse, while switching between workspaces is standardly a two-hand operation (Ctrl+Alt + arrow key).
Another thing is that in my workflow there are windows I like to have maximized and in the same workspace (think of IDE and web browser or DEVhelp) and be able to switch between the two fast and one-handedly, and ideally see their content in overview.
But I have to say the article brings forward some very interesting points and ideas, also presented very well. I could definitely use more tiling options in the default experience.
How does this play with multi monitor? Specifically the idea of automatically generating a new workspace for some cases – would not want all my monitors switching to another desktop when one needs a maximised window, or to have such behaviour constrained to the primary monitor only.
I’ve been thinking about this a lot for the past few years as I want to build something similar to a news reader, but can also function as a dashboard for office big screen. Maximizing space is key.
Well I ran into a game on hackernews called “Prosperous Universe” — I won’t link it so I don’t get put in the penalty box by antispam. The game UI could be subtly tweaked to function as a full OS UI. You get a tiled UI with floating windows “temporary buffers” which you can use sort of ephermally, or you can drag them into your tile setup for more permanance. You then have multiple named desktops you can fire up, but all the ephemeral floating windows follow you desktop to desktop. Nearly perfect. Try it out, go through the tutorial… actually I think they host them on youtube so you could technically take a peak without signing up for the game.
If you do try it out, let me know / email me, certainly it will provide some nice food for thought, and I’d be curious to know what you think.
What happens when there are too many windows to fit on a screen? It would also be useful to work through how the first picture from the post would be resolved with this idea.
This is what tiling window managers would be like if their developers didn’t have a keyboard fetish.
I really like Windows 11’s “Snap layouts”: https://support.microsoft.com/en-us/windows/snap-your-windows-885a9b1e-a983-a3b1-16cd-c531795e6241
Especially the UX that you are shown multiple layouts and can move the current window to one of the zones.
Glad that you mentioned Windows 11 capability. This was something I felt was missing in Gnome when I switched from Windows to Linux (and Gnome is usually ahead of innovation – so one point to Microsoft this time :-) ).
Even as a power-user, having the option to easily snap windows around my monitor for multitasking is something that I really enjoy, and I’m confident the Gnome team will implement something just as (if not even more so) useful as Windows 11 solution.
“Another issue with tiling window manager is that they place new windows in seemingly arbitrary positions.”
That sounds like an issue with nearly all window managers. It has nothing to do with tiling. Overlapping window managers pick seemingly arbitrary positions, too.
We solved this back in the 1980’s: twm let the user decide where to place new windows. It worked fabulously. Unfortunately, users can’t choose wm features piecemeal, so unless you want to give up literally every other window management development from the past 25 years, you’re SOL.
Great post ! iOS recently introduced “Stage Manager”, there could be inspiration to take from there too.
In the current classic floating mode, it can happen that one window entirely hides another one beneath, this is confusing and should be avoided I think
I believe Stage Manager always slightly smoothly offset any window so that we always see them all while they can still partially overlap, so no window ever completely hide another one . Could be an interesting idea
In anycase, glad to see thoughts into rethinking windows management !
It would be nice and a predictable behavior if the GNOME defines some predefined sizes for windows rather that every window defining its arbitrary size.
I think its important that developers have the ability to specify how the ideal way they envisioned the application being used should be, Gnome has been trying to give that kind of power to app developers and I think users ultimately benefit from it. Still, in the end I believe the user should have ultimate say on what the preferred size of the window should be.
I use GNOME, and I always maximize windows the moment they’re launched. If I could configure them to *launch* that way without an extension, I would. If I can see my desktop at all, either I’m in a momentary transitional state between one maximized window and two side-by-side windows, or something has gone wrong.
The premise of “if a window doesn’t fit, make a new workspace” really doesn’t feel at all like a good fit. I have one workspace, and I intentionally disabled dynamic workspaces.
I love the concept of a window having an optimal width, though. (“maximum” seems like a misnomer, since this thankfully does *not* set hard limits.) I like the possibility that I could put two windows side-by-side and the metadata would make it less likely that I’d need to adjust the split, because windows needing less space get less space.
Interesting proposal. Now let me tell you what I think would be really helpful: I almost have no usecase where I need to see more than one window at once. Seeing multiple windows at once confuses and distracts me. I never understood the idea of having multiple windows stacked one over the other, which is the default when you have multiple windows on one workspace or in any other DE. Its even visually difficult to distinct one window from the other. While I think it might make sense to have multiple windows on one workspace when they belong to a single task or project, it still confuses to see them stacked one over the other. Lets say I am working on a shell script and have a terminal open, a text editor and a web browser for researching commands. Its nice to have all these windows on a single workspace since they belong to one task/project I am working on, it still makes no sense for me to have lets say the web browser with all its bling bling and blinking adds or even any other windows in the background of the terminal I am working on. Its just pure distraction. If I switch to a window by alt-tab ov via the overview, I almost always want to see this window only, and nothing else in the background. So to achieve this and to stay focused, I have to press super+d first to hide all windows, then switch to the desired window via overview or alt-tab.
I wish there was a default setting that when you chose a window by alt-tab or via the overview, only this chosen window gets displayed, while all others hide.
Maybe does someone know of an extension that does exactly this?
I totally agree with you and the design proposal makes me worried that in the end one just ends up with a very advanced form of cluttering the workspace. I think tiling is great but I’m already frustrated by tiling managers opening a third column! The proposal sounds like a nightmare to me.
What I would love to see implemented is a window manager that puts the currently active window at the center of attention, taking extra space. Other windows are usually just there for reference. When I work, I might be following a manual how to do something or have a reference open from which I need to extract information. 90% of my multitasking needs come from work + lookup. From a user perspective, mosaics don’t solve that problem. They solve the technician’s problem of “how to minimize empty space and overlapping”. What is much more important than preferred layout is which apps are “friends” and how the system can learn this. My browser is a good friend with my terminal and my editor but my browser is not friends with my media player which is a good friend of my exercise app. A desktop system that dynamically learns which apps are friends, which are loners, and places them accordingly would be much more important than cramming the screen with windows.
A grid indicated and changeable at the borders, just came to mind.
Also, now that the default gnome desktop is empty, it could be used to define the shapes windows will fall into? Get attracted or repulsed based on type/metadata?
Maybe there is not always a good automatic option so asking the user could be a valid option. A user that got asked about the placement will not be surprised about where the window endet up.
As someone else who has been basically obsessed with the same problem for a few years now, I can honestly say this is a very novel idea that I didn’t think of.
I have been prototyping a “shell” in Java (so it could work on Windows and Android too) that is an attempt on tiling – only showing 1 to 3 tiles/windows at a time, side by side. Possibly 4 for superwide aspects. This would be a “files first” type of shell, somewhat like miller columns in file explorers of yore, but with a lot of “meta directories” much like we’re used to i.e Computer, Favourites, etc….
I really liked this idea since one of these columns/tiles will almost be the same aspect as a portrait smartphone screen, so I’ve since expanded it into yet another concept for a “unified, responsible, data-first touch/desktop interface”…
Not really relevant I know, but I decided to rant about that here because honestly, I lack the UX experience to pull it off. Maybe someone here will see this and steal the idea, haha!
Back on topic, the windowing work here is a very cool and something I’d love to try!
I am interested in beginning some initial work on an extension. How would I reach out?
Hi! I am curious what tools were used to create the video mockups? They’re quite compelling.
Blender
The experience of [Material Shell](https://extensions.gnome.org/extension/3357/material-shell/) can aggregate in this new way of thinking.
Today, I consider that I don’t use the GNOME DE experience, but the Material Shell’s one with the wonderful GNOME application environment.
I think it’s worth checking it out.
I would like to second Henry’s comment: I’ve tried several tiling WMs, and the Material Shell extension works very well for my workflow. There’s even a mosaic-like option called ‘ratio’, and one can choose for each workspace how the tiling is to be done (including keeping a float layer), and change it with a click. Moreover, one can keep an eye all the time at which windows are open in each workspace through the sidebar.
Am not a big fan of fully-automatic tiling systems (basically for reasons mentioned in the post), but the current GNOME window organising is not ideal either. Tiling Assistant helps a bit, like adding the window tiling choice or quarter tiling, didn’t explore any further.
This looks really nice and looking forward it :)
Love some of the ideas here. I agree with the criticisms of tiling WMs, and have tried to design something like this in the past. I agree with the Stage Manager comparison as well, though I haven’t tried it myself.
Not sure about moving windows automatically to new workspaces (although I am sometimes annoyed by doing it manually, so maybe I’ll like it if I actually use it), or the whole thing about requiring apps to report preferred sizes:
> Depending on apps using new system APIs can be challenging and slow — it’s not easy to move the entire ecosystem!
s/not easy/impossible/. People rely on unmaintained apps to keep working well.
I’m very excited to see this developed further. I don’t expect a tiling WM that can achieve max productivity with no learning, but I avoid tools that offer 0 productivity until you sit down with the manual as a matter of principle — hence my love of GNOME.
I would be happy with this kind of workflow for now: We have overlapping windows on all sorts of positions on the screen (current behaviour). When we select a window (dock, alt-tab etc) selected window is centered (with animation) and other re-arranged accordingly. If it’s maximized window it pops up front, and when some other window is selected then it’s unmaximized and “thrown in back”. It could be also used with tiled windows. Pop it in center and return it to it’s tile. We always want what we work on currently in front of us and I think this workflow would be nice (imo).
One of the reasons it is hard for me to use workspaces is lack of application support in context to workspaces.
In tabbed applications (like browsers and text editor) opening files or links externally will trigger xdg-open which will usually open the file/link in the last opened/active window, and that quite often is on entirely different workspace than you are currently on. When trying to group workspaces by the work I am doing it is very inconvenient to constantly manually move tabs between different browser windows.
I made a proof of concept extension for browser and gnome-shell which will ensure that browser tabs get opened on the active workspace. In a multi-monitor setup this is very convenient and removes a lot of frustration.
When working on a new window manager please take this into consideration as well.
The extension (and demo video) can be found here: https://github.com/Janhouse/tab-in-workspace
Just WOW!
Thanks for this article, I’m glad you guys put so much thought into this.
I’m very sceptical on using the workspace concept for expanding the space on one screen. Dealing with different workspaces introduces a lot of struggle (e. g. it is really hard to place two windows next to each other which are on different workspaces, in order to perform drag & drop operations etc.).
I think a scrollable, dynamically resizing/unlimited workspace (compare it to the “unlimited canvas” in apps like Rnote or MyPaint – an example implementation would be PaperWM) would be a much more fitting solution for the problems of the mosaic window managment, as it imposes less limitations, appears simpler, and doesn’t make general window positioning interfere with the workspaces concept.
Don’t get me wrong: I do think the workspace concept also needs improvement, as it currently also creates a lot of “shit work”. But I think this is an entirely different level of window organisation and therefore a different problem.
Since a few years, I work on a concept in order to reduce that “shit work” for workspaces. I never felt comfortable posting it anywhere, as my name is not very known in the Gnome community and I feared it would not get any attention – also because it might require changes throughout the stack.
Are you interested in this concept, or do you know a place where I could share it?
Usually the whiteboards repo is a good place for bluesky concepts like that :)
https://gitlab.gnome.org/Teams/Design/whiteboards
Did you share your idea somewhere?
I really like this idea, but I believe that there should be a way for the user to manually set these parameters for applications, for two reasons:
1 – There is no guarantee that every application will follow this API, so it’s essential that the user have the ability to set what the ideal sizing is in those cases, otherwise this mode would be too inconsistent and broken to be a default option.
2 – User preference. The app developer may imagine what is the ideal way to use an app, but in the end, the user decides that. Everyone resizes their windows, and there are too many variables like the type of activity being done, size and number of screens, screen resolution, etc. This is the kind of thing that might need to be adjusted.
Please also provide a way to select a window from second monitor using only keyboard.
(gnome-shell issue #412)
One suggestion for the full-screen window. If it’s going to take up a whole workspace, it should auto-position itself first not last as MacOS does it. If one is going to full-screen a window, then most likely it’s important and to have to rearrange things each time is irritating.
I actually love this idea! looking forward to it in the next gnome versions for sure!
How we can switch to Floating and some Edge-Tiling? And what is the default setting?
I navigate through windows by keyboard (Enter the name or Alt+Tab). GNOME-Shell is doing a good job with focusing on my work, especially on a laptop. Like most people I don’t use workspaces at all because the GNOME-Shell does already a incredible job with keyboard-navigation.
> If a new window doesn’t fit (e.g. because it wants to be maximized) it moves to its own workspace.
I assume this does not apply Floating and Edge-Tiling?
Have you taken a look at the GNOME extension: https://material-shell.com/#material-shell ?
It’s really amazing and there is much to get inspired from.
An idea i would like to put forward is dragging app icons together (like you do on ios to create a folder) but instead it would group those apps together and split them as required on the screen.
I tend to use apps in groups say
– text editor app and web browser app
– email app and calendar app
I typically I use virtual desktops but this can be pretty tedious, simply dragging one open app icon onto another creates a view group where the apps are automatically snapped together, then when i click another “group” both apps appear at once
Brilliant and very relevant to me. To generalise my comment below:- a new, default window manager would have to cope with some very unpredictable physical monitor set-ups.
An interesting display arrangement to factor in early, is vertically arranged multiple displays, as they lend themselves to tiling and tiling-like management (e.g. Windows 11 Snap). Specifically, ASUS “Duo” laptops (Zenbook and Zephyrus) have a second, ultrawide display below the main conventional display.
In practice this means tiling the lower display as if it were 2-4 workspaces side-by-side (though in fact they are just many tiled windows), with the user moving them to the workspace on the upper display for detail work. This can be very productive when workflow involves a large number of applications on the relatively small screen space of a laptop. The downside is how many application windows freak out, when presented with a very wide, physically small and vertically arranged second display, or being moved to a completely different physical display.
To complicate matters further, the primary (more conventional) display in many recent Asus Duo laptops is actually two displays in composite (physically superimposed in the same screen area). One is optimised for high frame rate and low latency, the other is optimised for high definition and colour accuracy. Which of the two “primary” displays is active, should respond to the resolution mode selected. (I say “should,”….)
In my workplace, about half of our users ask for Dell Display Manager to be installed on their machine, which is basically a fast tiling assistant thing a la the WinTile extension or FancyZones in Windows Powertoys. When I point out that they can tile windows by dragging them all the way to the side of the screen or using shortcuts, they tell me that they want to just be able to drag the windows into rectangles and they just don’t really understand the basic concepts of dragging, maximising, minimising or resizing windows very well.
You’d have to be careful about the implementation, but there is most definitely something here of real value.
This comment is hard to follow – are the people who don’t understand the basic concepts of moving windows the same people asking for Dell Display Manager? Knowing that things can be installed (and the names of specific ones) seems like more advanced computer knowledge than understanding the basic concept of a window.
What does “drag windows into rectangles” mean?
The key to the mosaic layout’s success is what happens when you open too many windows to the point that the next one won’t fit in the workspace.
Is a new workspace created to accomodate the new window? I feel like this misses the oportunity to fix the main problem with the floating window layout, that new windows hide old ones.
In floating window layouts, new windows hide old windows by covering them. If the mosaic layout places in a different workspace new windows that wont fit, it is essentially causing the same problem. That is, having windows you “forget about” because they are no longer visible, neither are they minimized or closed (as they should be)
This is why imo, we should get indicators for windows that do not fit, not just hide them in another workspace. This way, the user doesn’t forget about them and is encouraged in some way to minimize / close old windows before opening new ones.
In the mockups they have here, the moving to another workspace is always associated with an animation. FWIW.
This makes a lot of sense to me. I’d additionally want the ability to create stacks of windows that I can access via tabs. Visual Studio Code handles that quite well for its views.
The snap lay-outs of Windows 11 reflects well want people want. It would be great if GNOME Desktop would have such kind of functionality. Especially centering a window on a big monitor would be nice (the last screen in the Windows 11 snap lay-out).
I would like to throw in my own idea as well:
https://jeroenverhoeckx.com/gnome-workspace-management.html
The ideas is to open every new window/application on a new workspace.
This way you won’t have any overlapping windows anymore, but it also creates a ‘border’ between application (which you probably won’t want).
I tried it once however (Florian Müllner wrote an extension for it) and it worked better than I thought.
For multi-monitor setups the working should be adjusted.
On the one hand, I like the idea of integrating the concept of workspaces here, but on the other hand, I think working with workspaces is currently much harder and more time-consuming than working with windows.
To give a few examples:
* If I want to switch to a specific full-screen window, I just press Super to go the overview, and choose the big window tile based on its icon. If I want to switch to a specific workspace, I have to go to the overview and either squint at the workspace selector to try to guess which one I want or scroll through each workspace to find the right one.
* If I was using two fullscreen apps, but suddenly want to have them side-by-side, I just drag each to the sides of the screen. If I have them in separate workspaces, I have to take one, go to the overview, find the workspace with the other one (which is not easy — again, have to squint at the workspace bar or just try out each workspace), and then drag each window to the sides of the screen.
It’d be great if workspace behavior was adjusted as well to make it faster and easier to work with.
This comment was an eye opener!
I should really just give up on finding the perfect workspace setup. (Although material-shell would have come close if it had not been discontinued)
Thank you for saving me from more frustration of experimenting with workspaces, tiling, etc. Just maximize everything and give some love to the super key!
Renewing the window managers is always welcome, because it’s counter-productive to handle windows manually in a floating WM. I did the other way around: by default every window is maximized, because most of the apps I want to view in full size, but if I want to view multiple windows side-by-side, I can select them from a list and move them to a separate workspace. I’ve implemented this using Rofi + AwesomeWM, see Distraction free desktop workspace for developers https://medium.com/@bimlas/distraction-free-desktop-workspace-for-developers-554bf89ae9c1
This is a really interesting concept. What I think will enhance its usability is some sort of overview widget where you can see a zoomed out view of all of your windows across workspaces. Think of Visual Studio Code’s code overview panel to the right of the editor window or Space’s Horizon viewer https://deta.space/#:~:text=it%27s%20still%20yours.-,Warp%20through%20space,-Instantly%20swipe%20through
Stacked windows model is not good.
Tiled windows model is not good too.
Scroll-able tiled windows model is better.
But I think Stage Manager is better than others, as I can focus on the window group I’m working on, and can see the thumbnails of other window group at the same time.
But Stage Manager can only display up to 7 window groups, so I think Workspace + Stage Manager can be the perfect one.
I would sooo love a window manager that just intelligently organizes windows on my screen without me having to think about it!
Did anything come out of this?
Has there been any more work done on this?
The current state of tiling window management in Gnome is lacking quite a lot and I would love to be able to have an as efficient workflow within Gnome on Wayland as one can have in a fully tiling WM like Sway or Hyperland.
Tobias, is there any information on when this feature will be implemented?
Thank you.
Looking at tiling. It correctly notes that manual tiling doesn’t work with the arbitrarily small sizes that result in cramming enough windows into a single workspace but fail to note that isn’t how people actually use such window managers.
He describes the work of managing windows correctly as “shit work” work in service of the window manager instead of in service of the intended task. Tiling wm frees one from constantly tabbing or otherwise selecting from a shitpile of stacked windows, moving and sizing them but it imposes a different kind imo less onerous whereby one switches to a new workspace to open a new window. That is to say one uses more workspaces with fewer windows in them such that things have an appropriate amount of space for the task. This can be further decreased by assigning windows to a predefined workspace and autostarting them.
This proposal is to free users from the “shit work” of manual sizing and placement and the shit work of manually spreading windows through multiple workspaces but I fear its in a manner that will apt to be more confusing than either tiling or stacking window managers. The “shit work” of manually workspace management enables the user to create a consistent layout that is easy to use because it comports with his will and expectations.
I for instance use [a-z0-9] as workspaces. IRC chat is always on x, x is pre-assigned to the leftmost monitor and its started automatically taking the entire screen. I tap a few keys gx and I’m there it requires near zero thought and near zero management I don’t have to think about it. For the stuff that varies its easy enough manage that shit work is already fairly minimized.
Predictability trumps absolute minimization of shit work.
Half a year ago, I made a mock-up of how the GNOME desktop could function, but I never shared it properly.
You can find it here:
https://design.penpot.app/#/view/4192f1dd-455b-8162-8004-b8dee89b6d36?page-id=4192f1dd-455b-8162-8004-b8dee89b6d37§ion=interactions&index=0
The idea is basically that you have one big horizontal workspace and all applications are placed next to each other.
Do whatever you want with it. I just throw it into the pool of ideas. Who know what comes out of it.
Because Penpot doesn’t yet support the import of svg-files with text, the above link just contains an image of the original Inkscape file.
This looks sooo good! IMO better window tiling is the only thing Gnome is missing. I want this so bad and I hope we can get this done quickly.