1. 27
    1. 3

      If unset, XDG_RUNTIME_DIR defaults to $HOME/.config

      I believe you mean XDG_CONFIG_DIR.

      1. 1

        Fixed, thanks!

    2. 3

      I played with Material Shell on GNOME 3 for a while, and coming from i3 I really enjoyed the experience - not as finicky as dwm/awesome, simpler than i3. What I didn’t like about Material Shell was the resource consumption of GNOME and the way that Material Shell would crash and take my entire desktop session with it.

      I’m really excited by the idea of the Material Shell UI built on a more solid base!

      There’s one thing I didn’t see in the screenshots, though. In i3/sway, to open a new app in a particular position you have to manipulate some invisible state beforehand (putting the focus in the right place and probably setting the “split horizontal” or “split vertical” flags) which works, but is complex. In Material Shell, when you move the keyboard focus past the “end” of a row or column it creates a new placeholder window which you can move around like any other. Inside that placeholder window is an application launcher (like rofi), and when you launch an application, it takes the place of the placeholder window. For whatever reason, that inversion of operations (from “open app → position it” to “find a position → open app there”) was just so much more pleasant that I want more UI systems to adopt it.

      1. 2

        The current situation for Spatial Shell is a bit of an inbetween. Currently, it only supports two layout which both forces the sway layout to be vertical. That is, you don’t have the “half” or “grid” layouts of Material Shell. So Material Shell will always launch a new window at the right of the current one. (also, as a side note: IIRC the spatial daemon is only assuming that you don’t mess with sway layouts… that is, it does not try to correct them if they changed, so I can only assume it might produce funny results if you change them manually under its feet).

        I tried very quickly, by starting wofi with the -n argument (normal window), you can have something like you describe, though it’s flaky and will not work if wofi is not started from the leftmost window. I might try to dig a bit to see if I can do something a bit more integrated, I agree it might be nice. Actually it already works pretty well as-is.

        wofi -W 100% -H 100% -n --show drun -I -G gets you basically what you want, you can bind it to a key of your linking and this gives you mostly what you are looking for.

    3. 2

      @lthms, I started brainstorming ideas for a horizontally scrolling window manager about 2 days before your post, so it came at the right time.

      Now I’ve looked at Spatial Shell, Material Shell, PaperWM, and 10/GUI from 2009. They all have slightly different features.

      The feature I most want that’s missing from Spatial Shell, but present in PaperWM, is the latter’s interface for moving the window on the right so it is underneath the current window, making a vertical stack, and the inverse unstack operator. Any of the slots in a horizontal ribbon of windows can contain a vertical stack. This is different from Material Shell’s fixed set of layouts.

      1. 1

        I think implementing something like that in Spatial Shell shouldn’t be complicated, at least in a naive way (no particular decoration for stacked windows, but support in waybar could help)

        I might give it a try, especially if it could interest more people :)

    4. 2

      This is exactly what I recently was looking for, excited to try it out!

      1. 1

        Don’t hesitate to let me know how it goes!

    5. 2

      How does Spatial/Material Shell compare to PaperWM?

      1. 1

        I would have to do a more involved comparison work to answer you, tbh.

        My main motivation for this work was to get the “horizontal scrolling window manager” on top of Sway rather than GNOME 3.

    6. 2

      It’s a neat idea! I saw something similar a while back in coderibbon but never tried that since I’d long since abandoned Atom for Vim.

      I do think I like the ribbon mode of interaction better at the smaller scope of an editor than I do when it takes over my entire environment. Multiple workspaces do allow for instant changes of context so the problem of having to trudge all the way over to the other end of the ribbon is ameliorated. My main issue is that I would want to use this instead of (e.g.) Vim splits rather than using both, which means multiple Vim instances with different buffer lists, and eventually running into problems with the same file being open in multiple instances or not being open in the background of the instance I want to pull it up in right now. At one buffer per window it’s great, but at the cost of all the utility I get from having multiple buffers.

      One suggestion – it wants some kind of indicator in the titlebar (at least) to show where you are on the ribbon in the current workspace! Even a basic text display like ==[==]==== would help a lot with a sense of place.

      1. 1

        One suggestion – it wants some kind of indicator in the titlebar (at least) to show where you are on the ribbon in the current workspace! Even a basic text display like ==[==]==== would help a lot with a sense of place.

        Actually, you get that with the waybar configuration provided in the contrib directory of Spatial Shell repository. It does show all the windows of the ribbon, and highlights the focused one. For instance,

        For instance, here is a screenshot of my current setup

        Granted, it does not show which windows are visible vs. hidden, this could be done quite easily though.

        1. 2

          ah, fair – I’m using eww instead of waybar so I didn’t try that out.

          1. 1

            Oh, I didn’t know eww but it looks pretty neat, judging from the screenshots of the README.

            I’d love to add a new folder in the contrib/ directory of Spatial Shell. I will try to have a look soon!