[–] 2 points 4 weeks ago*

Wow! For how long have you been using scrollers?

Probably a over a year now I think

That workflow just really clicked for me.

I also still use multiple desktops with the scrolling

EDIT: And before that I used Hyperland after switching to Wayland. Before Wayland I had used i3 for several years

  • source
  • parent
  • context
  • [–] 15 points 4 weeks ago* (2 children)

    I freaking love niri

    It’s easy to lose windows that are off-screen

    By default. They should really change the defaults, but in config, you can make it so if there is a window to the side hidden, a piece is always visible.

    It's called struts.

    layout {
        ...
        struts {
             left 16
             right 16
         }
    }
    

    It ensures a piece of the window is always visible

    Plus with a bar like from QuickShell or WayBar you can see all open windows anyway up there.

    To achieve this, I’ve been using Niri with the tilemod script. It helps make Niri behave more like a regular tiling.

    The things you show in the gif are already possible with niri via Super + [ and Super + ] (default bindings) for placing into columns

    It has limitations, but everything in the gif at least is already there. Niri actually has quite a bit of support for base tiling.

    I can't go back to non-scrolling ever. I even use a similar setup on my work machine (a Mac) via PaperWM.spoon, tho it isn't as well integrated (bc it's a mac and you're forcing it to not be a mac)

    EDIT: One tiling feature of niri I love is that with Super + W you can switch to a stacked mode like in a tiler. For KiCAD PCB editing, you have three windows - project, schematic, and pcb. It is essential that at the very least the project tab be stacked behind and out of the way imo, since there is no minimize

  • source
  • [–] 4 points 1 month ago* (last edited 1 month ago) (8 children)

    Not sure if it helps, but traditionally the max was 80 columns by 25 rows on old computers, and that became a standard.

    Nowadays we can be much bigger with a terminal emulator window, but 80x25 is still the "standard" and most terminal emulators default to that size when you open their window.

    It's not the max size possible, but if you're making software for terminal, that really should be your target size imo

  • source
  • [–] 8 points 2 months ago (1 child)

    Wii U version is better than GCN version, even with upscaling in Dolphin, so def stick with that. Quality of life changes and upgraded textures - it's the way to go. Give it a try in emu.

    But low key a Wii U runs for less than $100 these days, and it's got great games (one of the best consoles for Zelda generally) but is also an emulation and homebrew beast. Even the vWii on it can be hacked for GameCube games and standard Wii homebrew. I would just buy a Wii U tbh. I love mine!

  • source
  • [–] -3 points 3 months ago*

    Niri + QuickShell (e.g. DMS) is already better than what you can get on Windows and Mac. Manual window dragging should die off already (GNOME and KDE; looking at y'all)

    Even tools like PaperWM.spoon can only mimic a fraction of the grace of Niri (no offense to the PaperWM.spoon team; macOS is holding them back)

  • source
  • parent
  • context
  • [–] 57 points 3 months ago (6 children)

    I wonder how many Arch haters have actually used Arch and ever ran into a breaking issue.

    In my 8 years of daily driving Arch, I have had 1 ever, and it was only bad bc I didn't know of BTRFS yet.

    That happened 3 years in, and I went on a new distro-hopping spree in between, trying Fedora, NixOS, and others, and they had actual problems. Not "oh an update broke my system and was fixed in a day."

    So now I've been back on Arch for more years.

    This whole "Arch is always breaking and takes so much maintenance" is a myth. In reality, Arch is the most stable, because it packages everything Vanilla. Everything works the "standard" way. On Debian, things decay, and then some stuff that's new breaks with some stuff that's old. On Fedora, there is a Red-Hat tax: configs in weird places, strange scripts, software missing from main repos (COPR sucks btw). On Arch, it's just "normal" Linux; and that works

  • source
  • [–] 3 points 3 months ago* (1 child)

    I'm not really talking about teaching and guiding though.

    If you look at the meme, one of the responses is something like "PRs welcome."

    I think that's appropriate in certain circumstances.

    You are correct, there is nothing wrong with a lack of knowledge or dumb questions. I'm referring more to how they ask their dumb questions.

    Some newbies come with hostility, pride, and entitlement, not ignorance.

    They request new features, say something sucks bc of blah blah blah, and then get mad at people responding rudely back. But what else should we respond with in this kind of situation? They aren't looking to learn. They are looking to degrade projects, users, and maintainers.

    They aren't looking for answers; they're looking to be mad about something and confirm their opinion that "Linux sucks" or some other such bias.

    So yeah, when someone comes humbly even with bad assumptions, absolutely correct and guide, but there's no point guiding people who don't actually want guidance, ya know? Pearls before swine

    So sometimes these aren't bad responses

  • source
  • parent
  • context
  • [–] 21 points 3 months ago (9 children)

    Tbf, those are sometimes valid responses, the new user just doesn't realize what they're asking is dumb, and it's exhausting to deal with when a bit of reading would solve the problem or show them what they're asking is impossible.

  • source
  • [–] 0 points 3 months ago* (1 child)

    It's not really 130-150 words per min though bc mostly the words we say are nonsense, "uhms" and saying the wrong thing and starting over and pausing and such.

    Not to mention, when we speak to a computer, it's not like to a person, as others have pointed out. The 130-150 wpm number comes from in context speaking where we already know what we're going to say. That isn't the case when doing things on a computer such as responding to a comment, anything requiring thinking, coding, etc.

    Also, speech-to-text systems do not immediately recognize the speech we say, adding further delay.

    So it's not actually 130-150 words a minute.

    In terms of meaningful day-to-day use, I maintain that it's far slower and less precise than a keyboard, especially if you're a proficient typer.

    And this makes sense as everyone I've ever met who likes to use speech-to-text (excluding those who MUST use it for disability reasons) are simply those who are bad at typing. Cope harder. slow-mo. This comment was written using a keyboard

    EDIT:

    so what they’re saying is true for that one use case

    This doesn't follow. Both of us are talking about inputing in english. Vibe-coding with a keyboard is also superior there

  • source
  • parent
  • context
  • view more: next ›