Maximizing windows in their own workspace is annoying and one of the worst parts of macOS window management. I really hope they don't bother with that. Just because I want a maximized window doesn't mean I want it in it's own workspace. It just makes dealing with windows harder because you now have to move to some other workspace to grab a window you want to reference first.
+1. This behavior is really confusing if you expect a particular window (typically a browser) to be on a particular workspace (I have keyboard shortcuts for the first 4 workspaces) and then it ends up off the end of the list because you happen to have been watching some content maximized.
If you option-click the green button or double-click the window handle, it expands a window to fill the screen without making it full-screen on its own space.
It's better than full screen, but it's not real maximised. In particular if you drag the right edge of the screen it will resize the window rather than moving the scrollbar.
Honestly Windows has basically nailed window management (earning its name I guess). Mac is much worse and Gnome is a little worse.
macOS manages _apps_ not _windows_. macOS (or iOS) is the last place to look for insights into window management because it's not even speaking the same language.
GNOME made this mistake a long time ago, trying to cargo cult (orig. definition) design their window management tools.
macOS manages both apps and windows. A lot of the things it does do make sense if you follow the original paradigm from the ground up. Unfortunately, most platforms copying ideas from macOS only do so from the surface, and the effect usually ends up half-assed.
Want a good idea to copy?
Ctrl-C in the terminal should copy text when something is selected, and send interrupt otherwise. In the macOS Terminal, you can rebind Copy from Cmd-C to Ctrl-C; when you do so, this is what happens. I will pledge my unending loyalty to the first terminal emulator on X11/Wayland that can implement this - I've tried over a dozen and none of them do.
I ended up using Moom [1] to work around some of the oddities of macOS window management. It's relatively low-feature, mostly for window arrangements and sizing. I use it on a vertical monitor to split window placement horizontally, since macOS can only natively do vertical splits.
It has other features too (like saving layouts and keyboard shortcuts), but I don't use them that much.
Personally I find switching between workspaces annoying, but not particularly more or less annoying than switching between maximized windows on Windows. So I am curious what you specifically find annoying about treating maximized windows as workspaces.
(Also, note that you can hold the Option key and click on the green plus in the upper-left corner you will get the standard Windows maximize behavior, which macOS calls "Zoom". Even better, you can go to System Settings > Desktop & Dock > Double click a window's title bar to... and select "Zoom" to make this action even easier.)
> you will get the standard Windows maximize behavior, which macOS calls "Zoom".
No, no you won't. Because 'zoom' is not equivalent to maximization. It means something like 'make this window as big as the current contents it has open for viewing in each dimension, unless that's too big (and then just maximize it in that direction)'.
Additionally it's just window resizing, not a window state. Which means that when you move the window again, it stays huge— so part of it must be offscreen— instead of snapping back to a reasonable unmaximized size.
> So I am curious what you specifically find annoying about treating maximized windows as workspaces.
I'm not GP, but
- there's a big, stupid, slow animation that must play every time you switch between workspaces
- you cannot float windows from other applications over a fullscreen window
It adds unnecessary delays and distractions any time you want to use a different application on that screen, and it doesn't let you multitask on that screen.
Interesting, I tried a few windows that I don't normally "zoom" and you are right. I suppose prior to this I only ever attempted to perform this action on browser/document/messaging/media windows that are able to be fully maximized.
> there's a big, stupid, slow animation that must play every time you switch between workspaces
I wondered how I never noticed this, and it looks like I had Accessibility > Display > Reduce Motion enabled.
> you cannot float windows from other applications over a fullscreen window
Agreed, I found it handy the first time I discovered I could move a floating window over a maximized window in Windows, but I've also noticed that I let my windows become a lot more disorganized when I'm using Windows. I'm not saying they're related, it may be that I just don't have enough Windows experience, but I do find that I end up keeping my workspace a bit tidier on macOS or a tiling WM.
> I wondered how I never noticed this, and it looks like I had Accessibility > Display > Reduce Motion enabled.
I use Reduce Motion too, but even then there's an animation (it's a cross-fade instead of a wipe) with the same duration and annoyance, although it is less visually distracting and doesn't try to reinforce the worse-than-useless-to-me spatial ordering.
I have to wonder if there's some deep wizardry possible, some hacky function you can call hidden way deep inside Dock.app or Mission Control.app, that will do the workspace switching without any animation.
> I have to wonder if there's some deep wizardry possible, some hacky function you can call hidden way deep inside Dock.app or Mission Control.app, that will do the workspace switching without any animation.
There's a plist file with animation speeds in it somewhere, and you can reduce the duration of the animations to something extremely low, which is what people with preferences like ours often used to do.
But some time in the last few major releases of macOS, Apple locked that away behind SIP. So to take advantage of it you have to disable some security features (not sure if you have to leave SIP off— you do for some changes but not others), and this may not be possible on a work machine.
> [disabling SIP, even temporarily,] may not be possible on a work machine
I wouldn't do it on a personal machine either (not that you're advocating that).
Yeah, the "full" installation of yabai [0] requires partially disabling SIP permanently, the reasoning for which is laid out very well in [1].
It seems like the "wizardry" I was hoping for would amount to circumventing some basic security design of post-SIP MacOS, so would either be an exploit or else equivalent to turning off the parts of SIP mentioned in [0].
I find switching between workspaces annoying, but not particularly more or less annoying than switching between maximized windows on Windows
that's not the problem (for me at least). i have both workspaces and multiple maximized windows on some of those workspaces. each workspace is dedicated to a task. all windows related to that task, maximized or not, are together on one workspace. pushing maximized windows to their own workspace breaks that. gnome currently behaves as expected, on macos i work around by resizing the window to fill size without using the maximize function. if each fullscreen window had their own space the number of work spaces would double, and they would not be in the order that i want them.
That makes sense to me. If you have a specific use for each workspace then I see how reordering them willy-nilly would be problematic and break muscle memory.
I have a multi-monitor setup and I often find myself using particular monitors for particular applications. I would be annoyed if the operating system decided to start reorganizing them.
absolutely. i configured a fixed number of workspaces too, because the dynamic one were more work to set up each time. but either way, everytime the monitor arrangement changes, windows jump around to different workspaces, or all workspaces get merged into one. it drives me nuts!
and it's not just muscle memory. it takes longer when you have twice as many workspaces in a row. if they would arrange in columns, say workspaces are arranged horizontally, but fullscreen windows are stacked vertically on top or below the workspace they were created from, i could work with that. just not the way macos is doing it, adding them to the end of the horizontal workspace list.
everytime the monitor arrangement changes, windows jump around to different workspaces
i just noticed that when i disconnect an external monitor, then a seemingly random number of windows that were not on the external monitor, moved to the active workspace. why, gnome, why?!!!
When workspaces are finite and defined one can simply bind hotkeys to switch to a particular workspace and tend to put the same things in the same workspace. EG your main browser window is in workspace 9 full screen on your monitor and you can switch to it immediately with super+9
Switching between windows in a unknown workspace arrangement is more effort because you are triggering an action, possibly by taking your hands off the keyboard, grabbing your mouse, moving it somewhere, clicking on something, hunting for the desired item, selecting it. This seems trivial but you are performing the same actually constantly.
Bonus points for not being able to move a window from screen 1 on workspace 1 to screen 2 on workspace 2 without first moving to the other screen and same workspace or vice-versa.
, which just makes the current frame maximized. A quick search turned up [0] which seems to give the desired effect of pre-lion "fullscreen" (hiding the menu bar and taking up 100% of the screen).
I've tentatively switched to it for now, although I noticed some weirdness when I got a message saying that I could run M-x toggle-frame-fullscreen by pressing f11: when I hit globe-f11 the
resulting frame/window configuration sometimes ends up being mostly black. When I use M-x toggle-frame-fullscreen, it doesn't have this behavior.
[0] https://stackoverflow.com/a/20429390
One of the things I like about Windows 11 is when you tile 2 windows, they form a group in the alt-tab menu. That way you can keep using your regular workflow with the group without the need for another workspace.
Logged in just to say this is probably one of the only things I prefer about macOS window management, if you are reading this Apple UX team please don’t take it away!
I like the idea of an initiative for applications to provide metadata for any window manager to handle them more intelligently. Letting the user quickly fill in the gaps in the meantime for local applications would also be nice.
I've played with super detailed Unux WMs (bspwm?) and I've also started using Powertoys FancyZones on Windows and in both cases it's a lot of setup that only works ideally for rather specific situations.
With a bit more work to not surprise the user and not break the window organization (e.g. the user really wanted these two windows next to each other), this mosaic paradigm could actually be really cool. Looking forward to see how it develops. If the kinks are worked out I may very well switch over from i3.
> 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.
I can see this part being really cool, when the user doesn't care about the layout, and really, really, annoying when the user does care.
Side note: the article should really have made a comparison between a tiling wm like i3 and this new mosaic concept, not between gnome tiling and mosaic...i3 is still way better and they'd do well to compare to the actual 'state of the art'.
Not sure how to feel about more windows, but the idea that first window shouldn't take all space is certainly good. If someone will come up with better intelligent control over that placement, that will take into account actual windows length (who knows, maybe even ML for learning typical window sizes used by an operator) that will be a killer feature.
Default sizing is one of my pet peeves with i3, even if it is the whole idea of tiling managers. You open first window and it takes entire screen space, meaning that with 32" screen (and even 27"), you need to look to the far left side for actual task (e.g. if it is a terminal, or code editor with column limit of 80 chars, dictated by code style). Then you open another window and you look straight into border between those 2 windows - your app isn't centered. etc etc
I have small bind in i3 that helps a bit, but it works only with one window
On the other side of the problem is how modern applications waste screen real-estate with empty space, bloated menus, and poor typography. The application designers also need to adopt responsive layout to make sure the app provides the right amount of information using provided space.
I hope a deeper rethink can consider the user's end goal being task management rather than window management. Maybe something in the spirit of "Ctrl + Z" and "fg" can be helpful.
I think modern SW is less thoughtful because it's easier to change and monitors have grown. Back in the day it was tough to make changes after the fact and screens were tiny. Screen real estate was more precious so you better put some thought into the layout. It's like- modern large screens create more wasteful bloated applications which need larger screens...
The new Outlook for example: I have the standard Windows but this also contains search? Below that I have Home, View, Help, and a hamburger menu? Below that I have the Outlook "ribbon" Then to sort my mail I have focused or other, we are now 4 "rows" deep in the shit now and each row wastes space. Since this is getting ridiculous they're starting to waste sidebar space as well by lining it with other apps. Stupid! Slack is even worse!
Have some vision! There seems to be no regard for where to stuff new features which is ironic since that's one of the stated reasons for all the telemetry.
> 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.
Oooh, that’s going to be a usability problem, because it introduces a special mode for answering the “prompt”. Most users will never know that this mode exists, just that the system behaves weirdly and half-maximizes a single window sometimes.
I see people today unknowingly or uncaringly invoking the window overview mode (sometimes called “Activities”), and then trying to, say, click a link in a visible browser window. They then become confused when the windows all zoom around, and the click they wanted is ignored.
> even a terminal full height might make sense but full width almost never does.
I disagree; things like atop can make good use of a full width (and full height) terminal, and log lines (for instance from dmesg or journalctl) are often long enough that a full width terminal makes reading them more comfortable.
I just resize terminal when(~5% of the time) that's needed; long lines are hard to read without wrap on even 24 inch full size terminal, let alone anything longer
I've been using i3 (within the larger Regolith package) for a few years now and its hard for me to non-tiling WMs now. However I do think there would be a lot of improvements, especially with large desktop monitors.
One idea I had would be to have a window manager only have a single main window in each desktop and then scaled down windows around the border on the desktop, like the TV in Idiocracy (https://www.soundandvision.com/files/_images/200902/21720091...). Selecting windows would swap out the main window with the scaled version on the border. This would give you the ability to focus on one window that is always centered while seeing scaled versions of all the other window's output.
Many years ago, 1982, there was an applie ii video game named Dung Beetles. It was a pac man style dot chomper in a maze. Except the maze was quite large and the area around the player was viewed as if through a magnifying glass. I would find it interesting -- but probably unworkable -- if my virtual desktop were 5x and any window not focused were small and when focused it blows up to normal size. With some options of being able to make windows stay large when not focused and etc.
Dynamic tiling window managers like dwm and xmonad can do this. They default to a 'master/stack' layout but you can change the layout algorithm. You esentially have a 'master' window and a stack of secondary windows. You can promote a window with super+enter and it gets swapped into the master area.
There are some autotiling scripts for i3 that can emulate this behavior as well.
I thought that xmonad just changed the windows dimensions and location for most of the layout configurations, can it change scale of the windows as well?
The centeredmaster patch for dwm works roughly like that - the master window(s) is in the center of the screen and the rest is stacked on the left and right.
Since there's going to be a lot of tiling WM users looking: what's the best way to get tiling WM and all the convenience of a "full blown WM like Gnome": things like Network Manager applet, bluetooth control, audio etc. all just few clicks away.
XFCE is super modular. You can turn off individual components. You can enable any program to start with the XFCE session.
So, for example, disable xfdesktop and xfwm; enable other window manager of your choice. Then, when you run xfce4-session via any mechanism you get all of XFCE, but with another window manager. You can pull up xfce4-settings manager to handle all system settings as you would in any other XFCE session.
I am pretty sure that LXDE/LXQT allows this sort of modularity as well. I have no clue about KDE and Gnome.
Of particular note, you can combine XFCE's panel applet with a tiling window manager. So then you can keep an application menu and notification area (with associated notification settings) from XFCE with an arbitrary window manager.
At least KDE (not sure about other DEs but I'd assume most except GNOME) supports EWMH, which lets its widgets control with any compliant window manager. Xmonad has a wiki page on this.[0]
One gotcha is that many full DEs use compositing window managers, which tilers usually don't. You can get around this by running a standalone compositor (such as picom).
It's not flawless. I had to patch plasma-desktop to get it to work at all, and there are still some bugs around widgets and toolbars I haven't found a solution for. But I'm still pretty happy with it. I have window animations with picom, and even window decorations that blend in pretty well, such that a casual observer probably wouldn't even notice that I replaced the window manager.
I'm pretty pumped that both Plasma and GNOME are now working on better tiling support by default. Maybe in a year I'll be back to using kwin or GNOME Shell.
Depends on what you put in your "full blow WM like Gnome" bag.
In my case, I just have nm-applet for my networking needs, blueman for my BT needs, pasystray for my audio needs, secret manager and polkit started on login, etc.
The only thing I miss from Gnome is that fancy pinentry program that shades the screen, which is replaced with a basic gtk window.
I get that treating overlapping windows as bad might sometimes be a thing. Trying to juggle getting sufficient data to do the job in screen can be a bit of a chore.
But personally I quite enjoy overlapped windows. Even when using a tiling window manager, I rely on stacked view a lot, where only one window of the stack is visible at a time. I need effective fast navigation across apps, not the simultaneous use/view of all.
I feel like Gnome often decides to pick goals that it says are user friendly, but which refuse to see the utility of the established alternatives. Making a big choice here feels like it's based entirely around a single argument that I fundamentally don't think is valid, in many cases.
I also worry that they are building a three mode system, and that it's unclear how if at all the various modes will blend. If there is a unified approach where standard/tiling/mosaic can coexist my concern is significantly lessened, but I'm not sure what that would look like, how mosaic would interact with standard.
>Another issue with tiling window manager is that they place new windows in seemingly arbitrary positions
Well we have Xresources to to solve this, but the Gnome and KDE people ignore a standard that has been there for years.
And Fluxbox solves this issue by having point/click option to allow you to say "Make this window show up here with this size". But as usual, many GNOME/GTK and some KDE applications ignore that to.
So off we go, invent a new standard that will make my (our?) lives harder.
After spending some time customizing my .Xresources I was amazed on how much functionality it has [1].
The learning curve is a bit steep, but after taking a few minutes to understand it, there's a lot it can do in a simpler manner than more modern configuration and tooling.
Do Xresources and friends make sense now Wayland is finally usable for many folks? Maybe having some sort of environment agnostic config would be good - even with Wayland - but I don’t know that a suitable one exists today.
It does, kind of, statically you configure positions manually in the configuration file, or dynamically, you can use its API through a pipe to save positions and then restore positions.
An idea everyone will hate: feed window descriptions to a tiny local language model, which decides how to organize the current windows based on the current context and the content of the windows already open.
Oh, you're coding? Put firefox to the left and keep VS Code focused. Oh, you're messing around with file managers? Bring the new file manager instance front and center. Oh, you've a ton of firefox windows open? Tile the new one side by side with the last one. Worst of all worlds.
For Gnome users, I really enjoy using Pop Shell (the window manager from Pop OS) as a tiling window manager. It doesn't exactly solve the problems with TWMs that this post discusses, but I often run into folks who don't know that you can use a lot of the bits from Pop OS in generic Gnome.
I made a video about how to set it up if anyone is curious. The series was aimed at beginners, so feel to hop around if you just want to see what it looks like.
https://www.youtube.com/watch?v=IoG0AsS6oPo
what i can't see with any of them is how to combine tiling of smaller windows with fullscreen windows. basically i want the tiling to only apply to windows that are not fullscreen, and i want to be able to switch between the tiled layer and the fullscreen layer. even better, if there are multiple tile layers.
one could implement that with workspaces of course but gnome puts all workspaces in a row , which makes this difficult. i really want all apps related to a task on one workspace and switch between multiple tile sets. paperWM can scroll, that may help. or i could try to combine it with something like wsmatrix that puts workspaces in a grid.
For any readers who can't watch a video at the moment:
1. To be precise, Pop Shell is an extension for Gnome, not a separate window manager
2. It's available pre-packaged on Fedora, Arch, and Manjaro
3. It's easy to install from source on other distros
The windowing UI/UX I wish for is to arrange a bunch of app's windows on my screen, then run some tool that notices what is running, where they all are,
and what has input focus, and can save that state to be reinstantiated later.
Think of how live stage theatre does set changes: there are tape marks on the stage floor showing where every object should go, and the crew just puts objects
where the crew knows the objects belong, according to the marks. Yes, one could edit multiple fiddly ~/.{X,x}* files with X/Y sizes and positioning in arcane syntaxes. Is there no tool in the Gnome-everse that can handle this?
I'm pretty sure that this (and a little bit more) is already present in KDE and it's called Activities. It's not very popular, possibly because it's not "marketed" enough IMO.
Back in the day I had an Autohotkey script to do exactly this on Windows. Was very simple with the WinGet, list, WinGetPos and WinSetPos in loops with window title, x,y,w,h, persisted to a .ini file
I wonder how you might do this on Gnome or KDE these days.
If you have used GNOME 2 for an extended period of time and then moved to GNOME 3, I think you'd find the shorter list of what wasn't removed.
The idea was a vast plugin ecosystem which would allow development of desktop features to be more distributed. The problem was, some of the most basic features (like a taskbar for displaying open windows, or panels, or applets, or sane window management tools) were left out.
At some point it becomes a security and performance nightmare when the idea is that to achieve a normal desktop experience, you need dozens of user-supplied scripts.
Of course that's not a problem in practice, because even with user plugins, several basic features continue to be missing. And the fact that most of these plugins are just recreating functionality that already previously existed should really tell you something about GNOME team's design philosophy.
To quote Linus Torvalds, GNOME 3 is a "total user experience design failure".
> He says that GNOME 3.x has been improving and that when pairing the desktop with the right extensions, it's a rather pleasant desktop. He specifically points out Frippery and GNOME Tweak Tool as making a huge difference to his experience.
Thank you, I didn't know that and didn't mean to misconstrue his opinion. GNOME Tweak Tool is a critical part of a usable GNOME experience, but I wouldn't dare call that a good user experience because it's a non-starter for the majority of casual users.
I stayed for a long time on Gnome Flashback, the Gnome 2 look alike. I moved to Gnome 3 when I was sure that there were enough extensions to recreate a sane Gnome 2 desktop. Did they waste all their work? Mostly. Did they waste the time of the people that had to undo their work? Definitely.
Starting with something as basic as bringing back the path input textbox in file dialogs. I mean... it's a file dialog! What else but inputting file _paths_ is it good for?
I recently got a macbook pro m2 in order to do local ML dev, and Finder has got to be one of the worst, most user-hostile programs I've ever used. It's not a good look when fucking windows explorer offers a better user experience.
In case you weren’t aware, though macOS’s Finder doesn’t show an editable file path control in each window like Windows Explorer does, Finder does support these path-related features:
• View > Show Path Bar (⌥⌘P) toggles visibility of a bar at the bottom of the window that shows the path to the currently open folder or currently selected file. The path is displayed as a series of folders, including their icons. You can hover over each these folders to see their full names, drag files into them, or drag them into other windows.
• Go > Go to Folder (⇧⌘G) pops up a text field where you can type the path of a folder or file to navigate to. The text field has tab completion. This shortcut works in any file dialog, not just the Finder.
• Edit > Copy “…” as Pathname (⌥⌘C) copies the absolute path to the currently open folder or currently selected file.
Another tip: in any file dialog, to navigate to the same folder as an open Finder window, start dragging the folder by pressing and holding on the proxy icon of the window (it’s in the title bar, left of the title), then drop the folder onto the dialog.
I really love the mosaic concept. I think it's indeed the missing piece for tiling on large displays. It's a kind of stack in usual tiling layouts, where all leftover windows are placed, but stacks tend to squeeze and deform windows, crippling many apps in the process. The mosaic approach can certainly avoid this issue, but it wastes some space (not ideal for small screens) and may not play well with big complex UIs(IDE, CAD, DAW, etc).
Every time when I look at what has become of Gnome, I wish Unity didn't die. Almost everything I loved in Gnome2 was broken or took a turn for the worse.
I run it on 3 or 4 machines, one of which has 2 screens and one of which has 3. Works great, scales well, handles modern Ubuntu just fine.
I use it with the Waterfox browser, which integrates natively with the Unity global menu bar, without any addons or config. I am currently on -- (hits alt-H, A) -- version 5.1.9.
The problem with this fairly complex solution is that the easier path by far is simpler window arrangements, multiple monitors, and many workspaces. Once you have more windows than fit on a workspace its easier just to have more workspaces and 1-3 windows is what basically universally fits on most monitors.
If you organize more things in the same space you probably need indivdual apps that themselves have tabs like browsers, editors, IDEs rather than more windows.
Personally I use https://github.com/chmln/i3-auto-layout to make slightly better layouts automatically be automatically alternating between v and h splits and find this fits my needs 95% of the time.
Shit work under i3 is already very small but if you wanted to reduce it further I think you could probably go a long way with a very simple feature.
Add a save button that saves current layout to a list like so
Browser, calculator
Browser, pdf reader
terminal terminal terminal
ide terminal terminal
Then have a restore function that simply walks the list finds the entry that matches the kind and number of window and shoves existing windows into that layout. You can at creation time use something like i3-save-tree, edit the json, yada yada but its all fairly manual and I think for the use case it would be relatively simpler. The few non standard all match for me a simple pattern eg there really isn't 2 different ways I want IDE terminal terminal
In my experience it depends on the user's workflow and preferences. Whenever I'm using a tiling-first desktop I find myself micromanaging my windows a lot more because inevitably, some windows tile in a way that's not usable or limits usability. It feels like I'm fighting it constantly, and the only way to fix it is to opt out of tiling, at which point I have to wonder why I'm using a tiling WM.
Exactly. I have dozens of different ways I like to organize my windows, depending on which task I'm doing or what I need to focus on.
The best I could manage so far with GNOME was the gSnap extension but it's still work and I've just noticed I've switched back to no tiling for a few days now.
Gnome doesn't even have functional drag and drop for files between two of their file windows. Every time I need to do that I end up selecting a lot of files, because that's the only thing that can be done with the mouse.
Then I use Double Commander or something similar to do the work.
If they can't get the basics right, what can we expect about more complex stuff like tilling?
It isn't perfect, but it does bring tiling window management to Gnome. The killer feature for me is that it remembers which workspace windows are on when external monitors are connected and disconnected.
* Putting maximized windows automagically in their own workspace is a horrible idea
> 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.
I emphatically disagree fundamentally people want to put the windows they want in a particular workspace because they are often part of a related task. It also violates user expectations from virtually every interface on the planet including prior versions of gnome leading to confusion and frustration as the users mental model of usage will not naturally conflate making it bigger with changing workspaces.
* Even more broken under the broke way gnome handles multiple monitors
This presents additional challenges for multiple monitors if the user has enabled workspaces across multiple monitors. A feature that isn't on by default but which as far as I know still exists.
EG your window gets to big and suddenly everything disappears on monitor 2 and 3 because your universe now switched to workspace 2.
The traditional arrangement for gnome where changing workspace only effects the primary monitor is possibly the worst thing about gnome. It turns a secondary monitor into a singular big bucket of windows you must manage manually as if virtual desktops had never been invented. It is a complete failure of design.
* There is a simple way to allow both usages without a configuration switch that provides users with an obvious mental model and a simple metaphor
An actually competent design that transparently allows both independent workspaces and workspaces across all monitors looks like this.
Locked pagers stay where you put them unlocked change together.
Size issues.
Expecting windows not to expand content arbitrarily may be better handled by just not tiling windows with a small maximum size. Note hints on minimum size and maximum size have existed forever.
Windows with medium maximum sizes can be expanded to $SIZE in a tiled layout but if the space is too plentiful some of that "tile" can be left empty with the app sized appropriately within it. For instance a pdf document on a large monitor may want to be as tall as it can be but only so wide.
If no hints are set one can also expect window to intelligently display content within a reasonable size like how competent web pages don't draw their content arbitrarily wide.
* Concerns about gnome specific designs and usability within other environments.
If gnome app developers rely on gnome specific affordances in other environments they may inherently look or feel like shit. At minimum work should be shared between other environments and existing affordances like WM_NORMAL_HINTS ought to be used where they can be for compatibility.
* Reasonable expectations
If this is adopted multiple monitors across desktops will be unusable thus gnome will simply disable and deprecate that feature.
Gnome apps will be designed in such a way as to work poorly in other environments.
Gnome developers response to any issues will be that you should be using Gnome.
KDE developers will 6 months later support whatever gnome did.
I don’t know. Overlapping windows may look messy, but I know where they are and their size is right for me. Not for you, for me.
If windows are moving all the time on their own as I open new ones, maybe it looks gorgeous on demos and screenshots, but I don’t think it’s going to be ergonomic to actually work with. And my work is not about posting screenshots to r/unixporn.
271 comments
[ 4.6 ms ] story [ 271 ms ] threadHonestly Windows has basically nailed window management (earning its name I guess). Mac is much worse and Gnome is a little worse.
GNOME made this mistake a long time ago, trying to cargo cult (orig. definition) design their window management tools.
Want a good idea to copy?
Ctrl-C in the terminal should copy text when something is selected, and send interrupt otherwise. In the macOS Terminal, you can rebind Copy from Cmd-C to Ctrl-C; when you do so, this is what happens. I will pledge my unending loyalty to the first terminal emulator on X11/Wayland that can implement this - I've tried over a dozen and none of them do.
It has other features too (like saving layouts and keyboard shortcuts), but I don't use them that much.
1. https://manytricks.com/moom/
(Also, note that you can hold the Option key and click on the green plus in the upper-left corner you will get the standard Windows maximize behavior, which macOS calls "Zoom". Even better, you can go to System Settings > Desktop & Dock > Double click a window's title bar to... and select "Zoom" to make this action even easier.)
No, no you won't. Because 'zoom' is not equivalent to maximization. It means something like 'make this window as big as the current contents it has open for viewing in each dimension, unless that's too big (and then just maximize it in that direction)'.
Additionally it's just window resizing, not a window state. Which means that when you move the window again, it stays huge— so part of it must be offscreen— instead of snapping back to a reasonable unmaximized size.
> So I am curious what you specifically find annoying about treating maximized windows as workspaces.
I'm not GP, but
It adds unnecessary delays and distractions any time you want to use a different application on that screen, and it doesn't let you multitask on that screen.Interesting, I tried a few windows that I don't normally "zoom" and you are right. I suppose prior to this I only ever attempted to perform this action on browser/document/messaging/media windows that are able to be fully maximized.
> there's a big, stupid, slow animation that must play every time you switch between workspaces
I wondered how I never noticed this, and it looks like I had Accessibility > Display > Reduce Motion enabled.
> you cannot float windows from other applications over a fullscreen window
Agreed, I found it handy the first time I discovered I could move a floating window over a maximized window in Windows, but I've also noticed that I let my windows become a lot more disorganized when I'm using Windows. I'm not saying they're related, it may be that I just don't have enough Windows experience, but I do find that I end up keeping my workspace a bit tidier on macOS or a tiling WM.
I use Reduce Motion too, but even then there's an animation (it's a cross-fade instead of a wipe) with the same duration and annoyance, although it is less visually distracting and doesn't try to reinforce the worse-than-useless-to-me spatial ordering.
I have to wonder if there's some deep wizardry possible, some hacky function you can call hidden way deep inside Dock.app or Mission Control.app, that will do the workspace switching without any animation.
There's a plist file with animation speeds in it somewhere, and you can reduce the duration of the animations to something extremely low, which is what people with preferences like ours often used to do.
But some time in the last few major releases of macOS, Apple locked that away behind SIP. So to take advantage of it you have to disable some security features (not sure if you have to leave SIP off— you do for some changes but not others), and this may not be possible on a work machine.
I wouldn't do it on a personal machine either (not that you're advocating that).
Yeah, the "full" installation of yabai [0] requires partially disabling SIP permanently, the reasoning for which is laid out very well in [1].
It seems like the "wizardry" I was hoping for would amount to circumventing some basic security design of post-SIP MacOS, so would either be an exploit or else equivalent to turning off the parts of SIP mentioned in [0].
[0] https://github.com/koekeishiya/yabai/wiki/Disabling-System-I... [1] https://github.com/koekeishiya/yabai/issues/798#issuecomment...
that's not the problem (for me at least). i have both workspaces and multiple maximized windows on some of those workspaces. each workspace is dedicated to a task. all windows related to that task, maximized or not, are together on one workspace. pushing maximized windows to their own workspace breaks that. gnome currently behaves as expected, on macos i work around by resizing the window to fill size without using the maximize function. if each fullscreen window had their own space the number of work spaces would double, and they would not be in the order that i want them.
I have a multi-monitor setup and I often find myself using particular monitors for particular applications. I would be annoyed if the operating system decided to start reorganizing them.
and it's not just muscle memory. it takes longer when you have twice as many workspaces in a row. if they would arrange in columns, say workspaces are arranged horizontally, but fullscreen windows are stacked vertically on top or below the workspace they were created from, i could work with that. just not the way macos is doing it, adding them to the end of the horizontal workspace list.
i just noticed that when i disconnect an external monitor, then a seemingly random number of windows that were not on the external monitor, moved to the active workspace. why, gnome, why?!!!
Switching between windows in a unknown workspace arrangement is more effort because you are triggering an action, possibly by taking your hands off the keyboard, grabbing your mouse, moving it somewhere, clicking on something, hunting for the desired item, selecting it. This seems trivial but you are performing the same actually constantly.
- very slow (even with animations turned off - very buggy. Windows resize and move themselves.
Up until today I'd been using
, which just makes the current frame maximized. A quick search turned up [0] which seems to give the desired effect of pre-lion "fullscreen" (hiding the menu bar and taking up 100% of the screen).I've tentatively switched to it for now, although I noticed some weirdness when I got a message saying that I could run M-x toggle-frame-fullscreen by pressing f11: when I hit globe-f11 the resulting frame/window configuration sometimes ends up being mostly black. When I use M-x toggle-frame-fullscreen, it doesn't have this behavior. [0] https://stackoverflow.com/a/20429390
If Gnome implements this well enough, I might consider switching back it from Sway. We'll see. I'm pretty pleased with Sway, though.
I've played with super detailed Unux WMs (bspwm?) and I've also started using Powertoys FancyZones on Windows and in both cases it's a lot of setup that only works ideally for rather specific situations.
> 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.
I can see this part being really cool, when the user doesn't care about the layout, and really, really, annoying when the user does care.
Side note: the article should really have made a comparison between a tiling wm like i3 and this new mosaic concept, not between gnome tiling and mosaic...i3 is still way better and they'd do well to compare to the actual 'state of the art'.
Default sizing is one of my pet peeves with i3, even if it is the whole idea of tiling managers. You open first window and it takes entire screen space, meaning that with 32" screen (and even 27"), you need to look to the far left side for actual task (e.g. if it is a terminal, or code editor with column limit of 80 chars, dictated by code style). Then you open another window and you look straight into border between those 2 windows - your app isn't centered. etc etc
I have small bind in i3 that helps a bit, but it works only with one window
I hope a deeper rethink can consider the user's end goal being task management rather than window management. Maybe something in the spirit of "Ctrl + Z" and "fg" can be helpful.
The new Outlook for example: I have the standard Windows but this also contains search? Below that I have Home, View, Help, and a hamburger menu? Below that I have the Outlook "ribbon" Then to sort my mail I have focused or other, we are now 4 "rows" deep in the shit now and each row wastes space. Since this is getting ridiculous they're starting to waste sidebar space as well by lining it with other apps. Stupid! Slack is even worse!
Have some vision! There seems to be no regard for where to stuff new features which is ironic since that's one of the stated reasons for all the telemetry.
Most people use laptops. (Or it's at least 50/50.)
Oooh, that’s going to be a usability problem, because it introduces a special mode for answering the “prompt”. Most users will never know that this mode exists, just that the system behaves weirdly and half-maximizes a single window sometimes.
I see people today unknowingly or uncaringly invoking the window overview mode (sometimes called “Activities”), and then trying to, say, click a link in a visible browser window. They then become confused when the windows all zoom around, and the click they wanted is ignored.
I disagree; things like atop can make good use of a full width (and full height) terminal, and log lines (for instance from dmesg or journalctl) are often long enough that a full width terminal makes reading them more comfortable.
One idea I had would be to have a window manager only have a single main window in each desktop and then scaled down windows around the border on the desktop, like the TV in Idiocracy (https://www.soundandvision.com/files/_images/200902/21720091...). Selecting windows would swap out the main window with the scaled version on the border. This would give you the ability to focus on one window that is always centered while seeing scaled versions of all the other window's output.
Maybe this has already been done?
There are some autotiling scripts for i3 that can emulate this behavior as well.
https://extensions.gnome.org/extension/4481/forge/
So, for example, disable xfdesktop and xfwm; enable other window manager of your choice. Then, when you run xfce4-session via any mechanism you get all of XFCE, but with another window manager. You can pull up xfce4-settings manager to handle all system settings as you would in any other XFCE session.
I am pretty sure that LXDE/LXQT allows this sort of modularity as well. I have no clue about KDE and Gnome.
Of particular note, you can combine XFCE's panel applet with a tiling window manager. So then you can keep an application menu and notification area (with associated notification settings) from XFCE with an arbitrary window manager.
One gotcha is that many full DEs use compositing window managers, which tilers usually don't. You can get around this by running a standalone compositor (such as picom).
[0]: https://wiki.haskell.org/Xmonad/Using_xmonad_in_KDE
It's not flawless. I had to patch plasma-desktop to get it to work at all, and there are still some bugs around widgets and toolbars I haven't found a solution for. But I'm still pretty happy with it. I have window animations with picom, and even window decorations that blend in pretty well, such that a casual observer probably wouldn't even notice that I replaced the window manager.
I'm pretty pumped that both Plasma and GNOME are now working on better tiling support by default. Maybe in a year I'll be back to using kwin or GNOME Shell.
In my case, I just have nm-applet for my networking needs, blueman for my BT needs, pasystray for my audio needs, secret manager and polkit started on login, etc.
The only thing I miss from Gnome is that fancy pinentry program that shades the screen, which is replaced with a basic gtk window.
But personally I quite enjoy overlapped windows. Even when using a tiling window manager, I rely on stacked view a lot, where only one window of the stack is visible at a time. I need effective fast navigation across apps, not the simultaneous use/view of all.
I feel like Gnome often decides to pick goals that it says are user friendly, but which refuse to see the utility of the established alternatives. Making a big choice here feels like it's based entirely around a single argument that I fundamentally don't think is valid, in many cases.
I also worry that they are building a three mode system, and that it's unclear how if at all the various modes will blend. If there is a unified approach where standard/tiling/mosaic can coexist my concern is significantly lessened, but I'm not sure what that would look like, how mosaic would interact with standard.
Well we have Xresources to to solve this, but the Gnome and KDE people ignore a standard that has been there for years.
And Fluxbox solves this issue by having point/click option to allow you to say "Make this window show up here with this size". But as usual, many GNOME/GTK and some KDE applications ignore that to.
So off we go, invent a new standard that will make my (our?) lives harder.
The learning curve is a bit steep, but after taking a few minutes to understand it, there's a lot it can do in a simpler manner than more modern configuration and tooling.
1. https://stuff.mit.edu/afs/sipb/project/doc/ixresources/xres....
Does Wayland even have a method to specifying canned Window Position ?
Oh, you're coding? Put firefox to the left and keep VS Code focused. Oh, you're messing around with file managers? Bring the new file manager instance front and center. Oh, you've a ton of firefox windows open? Tile the new one side by side with the last one. Worst of all worlds.
I made a video about how to set it up if anyone is curious. The series was aimed at beginners, so feel to hop around if you just want to see what it looks like. https://www.youtube.com/watch?v=IoG0AsS6oPo
https://extensions.gnome.org/extension/4481/forge/
what i can't see with any of them is how to combine tiling of smaller windows with fullscreen windows. basically i want the tiling to only apply to windows that are not fullscreen, and i want to be able to switch between the tiled layer and the fullscreen layer. even better, if there are multiple tile layers.
one could implement that with workspaces of course but gnome puts all workspaces in a row , which makes this difficult. i really want all apps related to a task on one workspace and switch between multiple tile sets. paperWM can scroll, that may help. or i could try to combine it with something like wsmatrix that puts workspaces in a grid.
1. To be precise, Pop Shell is an extension for Gnome, not a separate window manager 2. It's available pre-packaged on Fedora, Arch, and Manjaro 3. It's easy to install from source on other distros
Install instructions & source available here: 1. https://support.system76.com/articles/pop-shell/ 2. https://github.com/pop-os/shell
I use it as a daily driver on Debian 11. It's the best balance of tiling and "normal" desktop UI I've found so far.
Think of how live stage theatre does set changes: there are tape marks on the stage floor showing where every object should go, and the crew just puts objects where the crew knows the objects belong, according to the marks. Yes, one could edit multiple fiddly ~/.{X,x}* files with X/Y sizes and positioning in arcane syntaxes. Is there no tool in the Gnome-everse that can handle this?
I wonder how you might do this on Gnome or KDE these days.
The idea was a vast plugin ecosystem which would allow development of desktop features to be more distributed. The problem was, some of the most basic features (like a taskbar for displaying open windows, or panels, or applets, or sane window management tools) were left out.
At some point it becomes a security and performance nightmare when the idea is that to achieve a normal desktop experience, you need dozens of user-supplied scripts.
Of course that's not a problem in practice, because even with user plugins, several basic features continue to be missing. And the fact that most of these plugins are just recreating functionality that already previously existed should really tell you something about GNOME team's design philosophy.
To quote Linus Torvalds, GNOME 3 is a "total user experience design failure".
https://www.datamation.com/open-source/gnome-2-vs-gnome-3/
From https://www.phoronix.com/news/MTMxNj:
> He says that GNOME 3.x has been improving and that when pairing the desktop with the right extensions, it's a rather pleasant desktop. He specifically points out Frippery and GNOME Tweak Tool as making a huge difference to his experience.
• View > Show Path Bar (⌥⌘P) toggles visibility of a bar at the bottom of the window that shows the path to the currently open folder or currently selected file. The path is displayed as a series of folders, including their icons. You can hover over each these folders to see their full names, drag files into them, or drag them into other windows.
• Go > Go to Folder (⇧⌘G) pops up a text field where you can type the path of a folder or file to navigate to. The text field has tab completion. This shortcut works in any file dialog, not just the Finder.
• Edit > Copy “…” as Pathname (⌥⌘C) copies the absolute path to the currently open folder or currently selected file.
Another tip: in any file dialog, to navigate to the same folder as an open Finder window, start dragging the folder by pressing and holding on the proxy icon of the window (it’s in the title bar, left of the title), then drop the folder onto the dialog.
Hi from Unity on Ubuntu 23.04.
I am running the Unity flavour:
https://ubuntuunity.org/
It uses the latest Unity 7.7, released earlier this year:
https://gitlab.com/ubuntu-unity/unity-x/unityx
I run it on 3 or 4 machines, one of which has 2 screens and one of which has 3. Works great, scales well, handles modern Ubuntu just fine.
I use it with the Waterfox browser, which integrates natively with the Unity global menu bar, without any addons or config. I am currently on -- (hits alt-H, A) -- version 5.1.9.
https://www.waterfox.net/
If you organize more things in the same space you probably need indivdual apps that themselves have tabs like browsers, editors, IDEs rather than more windows.
Personally I use https://github.com/chmln/i3-auto-layout to make slightly better layouts automatically be automatically alternating between v and h splits and find this fits my needs 95% of the time.
Shit work under i3 is already very small but if you wanted to reduce it further I think you could probably go a long way with a very simple feature.
Add a save button that saves current layout to a list like so
Browser, calculator
Browser, pdf reader
terminal terminal terminal
ide terminal terminal
Then have a restore function that simply walks the list finds the entry that matches the kind and number of window and shoves existing windows into that layout. You can at creation time use something like i3-save-tree, edit the json, yada yada but its all fairly manual and I think for the use case it would be relatively simpler. The few non standard all match for me a simple pattern eg there really isn't 2 different ways I want IDE terminal terminal
The best I could manage so far with GNOME was the gSnap extension but it's still work and I've just noticed I've switched back to no tiling for a few days now.
Then I use Double Commander or something similar to do the work.
If they can't get the basics right, what can we expect about more complex stuff like tilling?
https://news.ycombinator.com/newsguidelines.html
1. https://github.com/paperwm/PaperWM
> 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.
I emphatically disagree fundamentally people want to put the windows they want in a particular workspace because they are often part of a related task. It also violates user expectations from virtually every interface on the planet including prior versions of gnome leading to confusion and frustration as the users mental model of usage will not naturally conflate making it bigger with changing workspaces.
* Even more broken under the broke way gnome handles multiple monitors
This presents additional challenges for multiple monitors if the user has enabled workspaces across multiple monitors. A feature that isn't on by default but which as far as I know still exists.
EG your window gets to big and suddenly everything disappears on monitor 2 and 3 because your universe now switched to workspace 2.
The traditional arrangement for gnome where changing workspace only effects the primary monitor is possibly the worst thing about gnome. It turns a secondary monitor into a singular big bucket of windows you must manage manually as if virtual desktops had never been invented. It is a complete failure of design.
* There is a simple way to allow both usages without a configuration switch that provides users with an obvious mental model and a simple metaphor
An actually competent design that transparently allows both independent workspaces and workspaces across all monitors looks like this.
my first ascii pager
M1 [1][2][3][4][] M2 [1][2][3][4][] M1 [1][2][3][4][]
Locked pagers stay where you put them unlocked change together.
Size issues.
Expecting windows not to expand content arbitrarily may be better handled by just not tiling windows with a small maximum size. Note hints on minimum size and maximum size have existed forever.
Windows with medium maximum sizes can be expanded to $SIZE in a tiled layout but if the space is too plentiful some of that "tile" can be left empty with the app sized appropriately within it. For instance a pdf document on a large monitor may want to be as tall as it can be but only so wide.
If no hints are set one can also expect window to intelligently display content within a reasonable size like how competent web pages don't draw their content arbitrarily wide.
* Concerns about gnome specific designs and usability within other environments.
If gnome app developers rely on gnome specific affordances in other environments they may inherently look or feel like shit. At minimum work should be shared between other environments and existing affordances like WM_NORMAL_HINTS ought to be used where they can be for compatibility.
* Reasonable expectations
If this is adopted multiple monitors across desktops will be unusable thus gnome will simply disable and deprecate that feature.
Gnome apps will be designed in such a way as to work poorly in other environments.
Gnome developers response to any issues will be that you should be using Gnome.
KDE developers will 6 months later support whatever gnome did.
If windows are moving all the time on their own as I open new ones, maybe it looks gorgeous on demos and screenshots, but I don’t think it’s going to be ergonomic to actually work with. And my work is not about posting screenshots to r/unixporn.