Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rethinking Window Management

blogs.gnome.org

Post reply on HN
Print view View original

21–30 of 272 posts

Re: Rethinking Window Management

#21

Post by jmclnx »

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

Re: Rethinking Window Management

#22

Post by generalizations »

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.

Re: Rethinking Window Management

#23

Post by snide »

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

Re: Rethinking Window Management

#24

Post by 2OEH8eoCRo0 »

low_tech_punk wrote: post #8

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

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.

Re: Rethinking Window Management

#26

Post by dbtc »

goosedragons wrote: post #2

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.

I like vlc, mpv, and alacritty because they can fullscreen without making a new 'workspace'. Haven't figured it out for emacs yet.

Re: Rethinking Window Management

#28

Post by ecliptik »

jmclnx wrote: post #21

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

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.

1. https://stuff.mit.edu/afs/sipb/project/doc/ixresources/xres....

Re: Rethinking Window Management

#29

Post by dmckeon »

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?

Re: Rethinking Window Management

#30

Post by pxc »

asoneth wrote: post #17
goosedragons wrote: post #2

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…

> 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.
Post reply on HN