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

Niri – A scrollable-tiling Wayland compositor

github.com

Post reply on HN
Print view View original

61–70 of 234 posts

Re: Niri – A scrollable-tiling Wayland compositor

#61

Post by gedy »

baq wrote: post #6

I'm basically fullscreen with everything all the time on macos, but not in the super-duper-fullscreen mode so cmd-tab/cmd-` works predictably. I want this on macos. I know I can't have it on macos. I also can't switch to Linux since macos is mandated by my employer. Nothing really to take out of it except that I feel like I'm not alone feeling stuck, knowing there are better workflows and not being able to do anythin…

You might try Hammerspoon[0] with PaperWM.spoon[1] on macOS. This is what I use, and while it has quirks, it works better than not having it.

[0] https://www.hammerspoon.org/ [1] https://github.com/mogenson/PaperWM.spoon

Re: Niri – A scrollable-tiling Wayland compositor

#62

Post by jasperry »

Does this or any other scrollable-tiling WM remember your preferred size of windows per-application? For instance, if I open a new Firefox window, I always want it to be the same width and full height. If I open a terminal, I want it to be half-height and the width I've set for terminals.

Ideally, I'd want to set that in a configuration, so if I made adjustments to a window one time it wouldn't change the default sizes.

Re: Niri – A scrollable-tiling Wayland compositor

#63

Post by argiopetech »

ducktective wrote: post #58
argiopetech wrote: post #51

Earlier quoted context omitted.

Newly started applications receive focus, so they're visible by default. They are inserted right of the current view, so recovering the previous active pane is consistent ("left pane" keybinding, or the appropriate gesture). Things on other desktops are invisible in every WM. The only difference with niri is the possibility for things to be left or right of the current window. Overview helps with that, but I know wha…

Like imagine editor is on ws2, you open a terminal to /tmp/ to check something quick, it scrolls to the right, then jump to ws3 for your file manager and other stuff and go back to your editor. Now you want to access that terminal on /tmp/ again. Where was it? In i3, I just spam-switch workspaces in this case, but at least I can find them. With scrollable wms, every ws can potentially hold that target app.

It's right of your editor, where it started.

If you have (having had "Editor" focused, and just opened "TermT"):

  Editor | (TermT) | Term | Browser
  (FM) | Term | Browser | etc.
(where pipe delimits a pane and parens are the active pane), if you go "next desktop" from "TermT" (the terminal at /tmp), that moves you down the stack of desktops. Moving up the stack of desktops returns with focus on "TermT". You'd then go "left pane" from "TermT" to get back to the editor.

The answer (for me) is to think of desktops as topics. The terminal on /tmp is with the things that prompted its creation. If I needed to check some log output, for example, it's with the project that made that log output.

Edit: Note that there's nothing keeping you from stacking those terms if you like, i.e., the appropriate keybinding goes from the previous to

  Editor | (TermT), Term | Browser
  (FM) | Term | Browser | etc.
where the terms stack vertically in the ribbon of the desktop.

Re: Niri – A scrollable-tiling Wayland compositor

#64

Post by atlintots »

jasperry wrote: post #62

Does this or any other scrollable-tiling WM remember your preferred size of windows per-application? For instance, if I open a new Firefox window, I always want it to be the same width and full height. If I open a terminal, I want it to be half-height and the width I've set for terminals. Ideally, I'd want to set that in a configuration, so if I made adjustments to a window one time it wouldn't change the default siz…

Yes, please see this page: https://github.com/YaLTeR/niri/wiki/Configuration:-Window-Ru...

Re: Niri – A scrollable-tiling Wayland compositor

#65

Post by antonyh »

aeon_ai wrote: post #36
antonyh wrote: post #21

Earlier quoted context omitted.

I avoid anything to do with DHH for his views expressed on his blog. I'm sure Omarchy is nice and all, but there are other choices without the ethical baggage.

I'm familiar with DHH's opinions -- Can you elaborate on how there are ethical implications/baggage associated with using FOSS? Must we leave the vicinity of people we don't always agree with?

It's not the FOSS, it's the distribution. As far as I can tell everything in that distro is available elsewhere.

Re: Niri – A scrollable-tiling Wayland compositor

#67

Post by antonyh »

Philip-J-Fry wrote: post #32
antonyh wrote: post #24

Earlier quoted context omitted.

I hate that I have to hold option everytime I maximise a window. All I want is to change the default to stretch windows and not use the fullscreen mode at all because of the other weirdness it brings.

Just double click the top of the window? If I'm understanding right, that's what you want. I only ever double click windows on both Mac and Windows.

Never tried a double click, thanks!

Re: Niri – A scrollable-tiling Wayland compositor

#69

Post by antonyh »

diggan wrote: post #39
Philip-J-Fry wrote: post #32

Earlier quoted context omitted.

Just double click the top of the window? If I'm understanding right, that's what you want. I only ever double click windows on both Mac and Windows.

Was long time ago I used macOS in any professional capacity, but doesn't it just maximize the height of the window, not the width? I seem to recall some UX like that, but might have been a different action/button.

Yeah, that it does but I quite like the way it gets taller but keeps the width.

Re: Niri – A scrollable-tiling Wayland compositor

#70

Post by atlintots »

nickjj wrote: post #52

One thing that was holding me back from trying Niri is its configuration was limited to 1 file with no way to override or include additional configs which is quite important IMO for having 1 main config that you slightly change on different devices if you want to make your dotfiles public. For example you can have gitignored "local" files on each device to handle overrides. Just the other day the author merged 2 PRs…

Yes, this feature had been in the works for quite a bit since it required non-trivial changes to do it "the right way". Very excited to see these changes merged finally!
Post reply on HN