[HN Gopher] Hyprland: A dynamic tiling Wayland compositor
       ___________________________________________________________________
        
       Hyprland: A dynamic tiling Wayland compositor
        
       Author : falkaer
       Score  : 84 points
       Date   : 2023-01-14 13:59 UTC (9 hours ago)
        
 (HTM) web link (hyprland.org)
 (TXT) w3m dump (hyprland.org)
        
       | friend_and_foe wrote:
       | Using sway currently, I intend to check it out.
       | 
       | Just so that I know beforehand, can transparency, gaps, animation
       | be turned off?
        
         | shaunsingh wrote:
         | Yes. All effects are entirely optional
        
       | eterps wrote:
       | Any advantages over Sway, other than look and feel?
        
         | crawl_soever wrote:
         | It uses dynamic tiling rather than static tiling meaning more
         | versatility how specific desktops get arranged such as bsp,
         | tree, or even custom arrangements
        
           | Izkata wrote:
           | I thought Sway was based on i3, which is an arbitrary-width
           | tree that can have different display modes per container node
           | in the tree.
           | 
           | Hyperland's wiki only lists "Dwindle" and "Master" layouts,
           | which from the description are strictly less versatile than
           | i3 (and Sway?) in exchange for convenience if those layouts
           | are what you want. Does it even have something as flexible as
           | i3? (and Sway?)
        
       | guerrilla wrote:
       | This looks beautiful and it's in AUR, so I'm definitely going to
       | try this tomorrow. I've been shopping for a replacement for GNOME
       | because they keep removing features I'm in the middle of my using
       | which is really stressful and I just can't trust them anymore.
        
       | E39M5S62 wrote:
       | It's a shame that they refuse to use a versioned release of
       | wlroots. It makes packaging this needlessly difficult (or
       | impossible, depending on distribution policy).
        
         | codetrotter wrote:
         | https://wiki.hyprland.org/Getting-Started/Installation/ has
         | some relevant info relating to this
         | 
         | > Arch, NixOS and openSUSE Tumbleweed are very supported. For
         | any other distro (not based on Arch/Nix) you might have varying
         | amounts of success. However, since Hyprland is extremely
         | bleeding-edge, distros like Pop!_OS, Ubuntu, etc. might have
         | major issues running Hyprland.
         | 
         | and
         | 
         | > This project is under development and is constantly changing.
         | 
         | It's not practical to expect that they will support every
         | distro from the get-go, when they are actively developing it.
        
       | Y_Y wrote:
       | I've never liked animations in interfaces like this. It was fun
       | to play with when Compiz was new, but it doesn't make the tool
       | any more useful or pleasant for me to use. At least it's not as
       | bad as the OSX "magic lamp" minimize.
        
         | eyelidlessness wrote:
         | For anyone like me who uses macOS and also dislikes the genie
         | minimize effect, you can change it[1] and/or change/turn off a
         | huge variety of animations[2].
         | 
         | 1: https://macos-defaults.com/dock/mineffect.html#set-to-
         | genie-...
         | 
         | 2: https://apple.stackexchange.com/a/63477
        
         | LarryMullins wrote:
         | I dislike almost all desktop animations, except for sliding
         | between virtual desktops, and an animated zoom-out to view all
         | desktops. Particularly the first; having an animated slide
         | between virtual desktops really helps me form a spatial feeling
         | for where windows on different desktops are. But miss me with
         | animated minimizing (magic lamp is the worst!), wobbly windows,
         | etc. That sort of eyecandy is very distracting, I used it for a
         | few days when I first tried Beryl, but never since.
         | 
         | Having a compositor that does desktop zoom is very nice too,
         | although not quite in the same class of features as those
         | eyecandy animations. Frustratingly, Kwin won't let you set a
         | mousewheel keybind for this zoom effect, a senseless
         | limitation. You can get around this with xbindkeys though,
         | using config like this:                   "qdbus6
         | org.kde.kglobalaccel /component/kwin invokeShortcut
         | view_zoom_in"           Mod4 + Super_L + b:4         "qdbus6
         | org.kde.kglobalaccel /component/kwin invokeShortcut
         | view_zoom_out"           Mod4 + Super_L + b:5
         | 
         | I have no clue how you'd fix this if you're using
         | Kwin/Wayland..
        
         | giardia wrote:
         | I'm not a fan of animations myself, though I think it could be
         | somewhat useful with a tiling WM to help maintain (for lack if
         | a better word) your orientation. Sometimes a new window will
         | open and move the other windows around and get resized
         | unexpectedly, or you'll move a window and lose track for a
         | split second. Animation would show you where everything gets
         | put so you don't have to reorient yourself. Not a very common
         | issue, but I could see animation helping there.
        
           | d_tr wrote:
           | Yeah they can be helpful in such cases. I used Gnome for a
           | while and although I liked the overview animation, it was too
           | slow for my taste and you needed an extension to speed it up,
           | so I just disabled them. I see that Hyprland allows you to
           | configure this OOTB though.
        
         | [deleted]
        
         | sheepdestroyer wrote:
         | I want my systems functional, efficient, snappy.
         | 
         | One of the first things I do on a new device is to disable
         | animations and similar "eye candy". On Gnome it's hidden, but
         | can be changed with gnome-tweek-tools ; on Android it's hidden
         | too, in the developer options that you have to unlock (7 taps
         | on build number).
         | 
         | In both cases, those animations easily lose frames and are
         | distracting, without talking about the frivolous power spending
         | on portable devices, but they are enabled by default and not
         | easily removed.
         | 
         | It bugs me to jo end that wrong priorities seem to apparently
         | be the norm.
        
           | Krssst wrote:
           | Note: when disabling animations on GNOME, a noticeable delay
           | seems to remain before the alt-tab switcher appears.
           | 
           | I don't remember which extension I use to work around that;
           | maybe this one:
           | https://extensions.gnome.org/extension/1317/alt-tab-
           | switcher...
        
           | d_tr wrote:
           | I like gsettings. You can just put the calls in a script once
           | and call it whenever needed. You can access everything from
           | there. You can search for relevant keys from the terminal or
           | with dconf editor.
        
         | LanternLight83 wrote:
         | Personally a huge fan of the animation showcase, I'd be willing
         | to take a latency hit because I find it much easier to keep
         | track of. Obviously I overcame any such issues in order to get
         | use standard TWMs, which I do just fine, so idk if I'd still
         | appreciate how they feel interactively? But I'm glad to see the
         | amount of customization available within them, maybe I'd just
         | speed them up or otherwise adjust the curves.
        
         | amalgamated_inc wrote:
         | #swaylife
        
       | 3836293648 wrote:
       | I want to switch, but it's still super glitchy on NVIDIA and
       | waaay too slow on my laptop.
        
       | dTal wrote:
       | The problem with "alternative" Wayland compositors is that so
       | much more functionality is pushed into the compositor under the
       | Wayland architecture compared to window managers on X11. So it's
       | a ton more work to write a Wayland compositor than an X11 window
       | manager, and most of it is tedious boilerplate that almost
       | certainly has nothing to do with your motivation for writing a
       | new compositor in the first place. This in turn affords many more
       | opportunities to introduce bugs, missing functionality etc. I
       | trust "weird" compositors much less than I trust "weird" X11
       | window managers - it's more like using an alternative Xorg than
       | an alternative WM.
       | 
       | "...there is still a lot of boilerplate involved in writing a
       | compositor, much more than for an X11 window manager, namely
       | setting up your own rendering code, registering and storing input
       | devices and screens in your own data structures, passing input
       | events to windows, calculating bounds for bars and other overlays
       | (courtesy of layer-shell) and others. X11 handles all of this for
       | you..."
       | 
       | https://tudorr.ro/blog/technical/2021/01/26/the-wayland-expe...
       | 
       | <edit> Several people mentioning wlroots. I can't say I've ever
       | attempted it myself, but if you take a look at the blog post
       | above, the author is very clear on the fact that even with the
       | benefit of wlroots (which they highly praise) writing a Wayland
       | compositor is still a lot more work than writing an X11 window
       | manager (which they have also done, so they are something of an
       | authority). wlroots doesn't abstract everything away, it just
       | gives you a bunch of useful tools.
       | 
       | "With Wayland, you handle everything, even with wlroots."
        
         | kaba0 wrote:
         | An X11 window manager is more akin to a gnome extension than a
         | proper window manager. Just because writing such a plugin is
         | easy shouldn't make our expectations all that different.
         | 
         | And frankly, for putting together a _window manager_ the proper
         | choice of action is extending an already existing compositor.
        
         | 3836293648 wrote:
         | Yeah, but wlroots is taking the role of Xorg there, leaving WM
         | writers to mostly just write the WM
        
           | Izkata wrote:
           | I'm just wondering how long it'll be until someone uses
           | wlroots to write a client/server architecture like Xorg...
        
             | TingPing wrote:
             | It will never be a popular way to use Wayland because its
             | just a worse design.
        
             | Cloudef wrote:
             | It already exists and its called xwayland. Most wayland
             | compositors also have X11 WM inside them...
        
         | charcircuit wrote:
         | So just push all that shared logic into a library that
         | alternative Wayland compositers can all use.
         | 
         | eg. wlroots
        
         | sprash wrote:
         | > "With Wayland, you handle everything, even with wlroots."
         | 
         | The observable effect of this is that the long tail of niche
         | projects like X11 window managers, custom toolkits or small
         | applications (that don't carry around extremely heavy
         | dependencies like GTK/Qt) gets decimated. The assumption that
         | this is done on purpose is plausible.
        
           | tadfisher wrote:
           | Plausible, but not realistic or actually happening, because
           | there's nothing at the protocol level that prevents the long
           | tail of small compositors, toolkits or applications from
           | implementing a Wayland backend.
        
         | gizmo686 wrote:
         | This compositor, like most Wayland compositors, uses the
         | wlroots library, so most of that tedious work is already
         | handled for you.
        
         | zokier wrote:
         | On the other hand, there is nothing in Wayland that prevents
         | anyone from writing a compositor that splits off some window
         | management tasks to a separate process. Afaik nobody has
         | bothered to do so yet, but if there is demand then it could be
         | done. Or maybe there isn't that much demand for such thing.
        
           | dTal wrote:
           | The blog post mentions Wayfire, which has a plugin
           | architecture, so not separate processes but an abstraction
           | boundary at least - which is the more important thing.
        
           | zajio1am wrote:
           | Does not phoc / phosh work like that?
        
       | netr0ute wrote:
       | How does Hyprland compare to the Pop!_OS tiling system?
        
       | yigitkonur35 wrote:
       | I'd love to take advantage of this incredible tool in MacOS.
       | Managing windows on MacOS is quite a challenge.
        
         | idle_zealot wrote:
         | I sorely miss tiling WMs when I use MacOS; Amethyst and yabai
         | just seem to big out all the time, lose track of windows, get
         | confused by native tabs, and deal poorly with windows that
         | force maximum/minimum sizes. I've concluded that MacOS's window
         | model just really doesn't mesh with tiling. My current
         | solution, after much experimentation with tools like Rectangle,
         | Hookshot, and Spectacle, is to use Swish[1]. It feels sort of
         | like an inside-out version of how I use Sway on linux. With
         | Sway each window that I open is tiled onto the current desktop,
         | then I re-balance the split or reposition the window with my
         | mouse, and set the window to float if it doesn't cooperate.
         | With Swish each window opens as floating, but by swiping on its
         | title bar I can tile it into whatever position I want. This
         | defaulting to floating works better on MacOS where the
         | frequency of uncooperative windows is much higher than on
         | linux. The killer feature of Swish for me is that it keeps
         | track of the grid you make by swiping windows into place and
         | maintains it even when you resize or reposition windows
         | relative to one another, much like i3/sway. It's still quite
         | frustrating though that I have to pay $16 for an app to make
         | window management bearable. This is a basic OS feature that
         | I've come to take for granted.
         | 
         | 1: https://highlyopinionated.co/swish/
        
         | drmidnight wrote:
         | Check out https://github.com/ianyh/Amethyst I've been using it
         | for years and it makes MacOS window management a dream.
        
         | creese wrote:
         | Try yabai.
        
       ___________________________________________________________________
       (page generated 2023-01-14 23:01 UTC)