Live data from Hacker News

Rethinking Window Management

blogs.gnome.org

31–40 of 272 posts

Re: Rethinking Window Management

#32
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).

Re: Rethinking Window Management

#34
post #14

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.

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.

[deleted]

Re: Rethinking Window Management

#37
post #17

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.

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 call…

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.

Re: Rethinking Window Management

#38
* 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.

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.

Re: Rethinking Window Management

#39

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.sounda…

That sounds like how dwm tiles windows

Re: Rethinking Window Management

#40

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.sounda…

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.

Post reply on HN