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

Hyprland: A dynamic tiling Wayland compositor

hyprland.org

Post reply on HN
Print view View original

61–70 of 86 posts

Re: Hyprland: A dynamic tiling Wayland compositor

#61

Post by roenxi »

QUrprUd1nCeicw wrote: post #59
roenxi wrote: post #58

Earlier quoted context omitted.

That is the view they took; but that view involved a decade-long process to get a Wayland ecosystem to where we could reliably screenshot the full screen. Still isn't possible in Debian Stable if I recall correctly. Wayland is the future, but lets not put on too brave a face. The design for accessing the composited output was bad and it fell over in practice. There is a small risk that we end up with competing, mutua…

>Still isn't possible in Debian Stable if I recall correctly. It depends on the app. Chances are older apps needs to be updated to use the portal. >There is a small risk that we end up with competing, mutually incompatible ways of taking screenshots on a Linux desktop. No, there's only one way. Use the XDG screenshot portal. It's not a library, it's a standard API the desktop implements. >for no particular reason oth…

Now I'm certainly no expert in this area (and I'm sure it shows) but xdg-desktop-portal was built to support Flatpak and is linked fairly closely to PipeWire.

"The protocol is great, you just need to rebuild your Audio/Visual stack to support it" is certainly a reasonable take when dealing with something as weird as X. But, and I say this with a certain level of sympathy, bit it showcases a deep inflexibility in the design of Wayland.

Taking screenshots is not that hard by default. I'm very glad that someone is taking on the mammoth task of improving the linux graphics stack, but it is obvious that they designed screenshots out of the system then had to work for a decade to design them back in by reworking the way multimedia is done, and de-facto we're only going to be able to use Wayland in conjunction with XDG standards making sure that implementing the light protocol in a light compositor is a mistake. That isn't the end of the earth, it is no worse than what we do now - but it is a glaring weakness in the Wayland protocol that could have found a way to be usable from 2008 -> 2018.

Re: Hyprland: A dynamic tiling Wayland compositor

#62

Post by jpeeler »

ccakes wrote: post #52
eterps wrote: post #4

Any advantages over Sway, other than look and feel?

I'm just giving this a try and with xdg-desktop-portal-hyprland (their fork of the wlr portal) I get perfect screensharing in Google Meet using pure Wayland. That alone is interesting enough to get me to look at switching..

Perfect screensharing meaning you can select individual windows to share as well as the entire screen(s)?

Re: Hyprland: A dynamic tiling Wayland compositor

#63

Post by QUrprUd1nCeicw »

roenxi wrote: post #61
QUrprUd1nCeicw wrote: post #59

Earlier quoted context omitted.

>Still isn't possible in Debian Stable if I recall correctly. It depends on the app. Chances are older apps needs to be updated to use the portal. >There is a small risk that we end up with competing, mutually incompatible ways of taking screenshots on a Linux desktop. No, there's only one way. Use the XDG screenshot portal. It's not a library, it's a standard API the desktop implements. >for no particular reason oth…

Now I'm certainly no expert in this area (and I'm sure it shows) but xdg-desktop-portal was built to support Flatpak and is linked fairly closely to PipeWire. "The protocol is great, you just need to rebuild your Audio/Visual stack to support it" is certainly a reasonable take when dealing with something as weird as X. But, and I say this with a certain level of sympathy, bit it showcases a deep inflexibility in the…

It's not a weakness or inflexibility in the Wayland protocol. There's no way to make it work there. They had to rework the way security is done, and that's a much bigger task that touches lots of other parts of the OS. I keep saying this but you're not listening to me. Why?

Yes, if you want to use a secure system then you need to only go through secure APIs. If you cut out security in the name of making a "light" compositor then you just lose the ability to run sandboxed apps correctly, so it's crippling your desktop for no good reason. The XDG portal was built as a secure API to support Flatpak but it doesn't actually need Flatpak. The compositor is what needs to implement it so any sandbox can use it.

Re: Hyprland: A dynamic tiling Wayland compositor

#64

Post by idle_zealot »

extr wrote: post #56
idle_zealot wrote: post #7

Earlier quoted context omitted.

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…

I've been using MacOS for awhile and this is likewise my one true gripe. I've played around with amethyst and yabai and also find them just a little too shaky to rely on. I miss the rock solid nature of i3/bspwm. And trying to script my own functionality with Hammerspoon or BTT has been an exercise in frustration. I'll give Swish a shot with this recommendation. However I'm not sure Swish solves the big benefit of i3…

> lightning-quick virtual desktop

I recall that yabai can achieve this with SIP disabled. It somehow injects code to disable the Space switching animation, so hotkeys to switch Spaces become instant.

Re: Hyprland: A dynamic tiling Wayland compositor

#65

Post by kaba0 »

sprash wrote: post #47
QUrprUd1nCeicw wrote: post #43

Earlier quoted context omitted.

>Severe over engineering, unstable interfaces, massive boiler plate and huge development overhead is preventing the long tail "at the protocol level". No, all those can be solved with client libraries. X11 had Xlib and the other client libraries. Those X11 libraries don't make sense in Wayland, but the client libraries that stayed relevant (freetype, cairo, etc) can still be used. >If you want to add the ability to t…

> No, all those can be solved with client libraries. There is no easy way to open a Window and render a string. Period! You either need to write it yourself completely (as OP stated) or you can use Gtk/Qt or other heavy weight "client libraries" (cairo and freetype do not create Wayland windows and therefore are not applicable here). Look at the code again! If you really think that the code at [1] is in any way a gre…

That’s just optimizing for the wrong thing. Why should it be easy to write from zero a “hello world” window? Where would you go from there, what’s useful about that? Should it also handle inputs, redraws, widgets, layouting?

Re: Hyprland: A dynamic tiling Wayland compositor

#66

Post by idle_zealot »

extr wrote: post #60
idle_zealot wrote: post #7

Earlier quoted context omitted.

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…

Actually, if you're interested at all, I just, after literally months of reading about this, found a pretty sick solution. Have you ever heard of Phoenix? https://github.com/kasper/phoenix/ . Despite googling around for this exact topic, with 3.8k stars I had never heard of it. Apparently someone has created slim, JS scriptable interface that is basically tailor made toward creating your own tiling WM. I just install…

I had not heard of Phoenix, and it looks interesting. Though I doubt I would be able to do a better job of reimplementing sway/i3 in Javascript than the folks working on yabai have managed.

Re: Hyprland: A dynamic tiling Wayland compositor

#67

Post by kaba0 »

sheepdestroyer wrote: post #13
Y_Y wrote: post #6

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.

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…

If implemented well it shouldn’t cost too much energy, it is basically interpolating a value and redrawing it a few times with the GPU.

Re: Hyprland: A dynamic tiling Wayland compositor

#68

Post by kaba0 »

ccakes wrote: post #52
eterps wrote: post #4

Any advantages over Sway, other than look and feel?

I'm just giving this a try and with xdg-desktop-portal-hyprland (their fork of the wlr portal) I get perfect screensharing in Google Meet using pure Wayland. That alone is interesting enough to get me to look at switching..

That works on most wayland compositors nowadays for quite some time now.

Re: Hyprland: A dynamic tiling Wayland compositor

#69

Post by extr »

idle_zealot wrote: post #66
extr wrote: post #60

Earlier quoted context omitted.

Actually, if you're interested at all, I just, after literally months of reading about this, found a pretty sick solution. Have you ever heard of Phoenix? https://github.com/kasper/phoenix/ . Despite googling around for this exact topic, with 3.8k stars I had never heard of it. Apparently someone has created slim, JS scriptable interface that is basically tailor made toward creating your own tiling WM. I just install…

I had not heard of Phoenix, and it looks interesting. Though I doubt I would be able to do a better job of reimplementing sway/i3 in Javascript than the folks working on yabai have managed.

So, you don't have to. Check out that spin2win "example" I linked, it's really less of an example and more of a pretty fleshed out implementation of XMonad. I don't really know javascript/TS at all and I was able to get it running with a few tweaks in 20 minutes or so. Phoenix is super intuitive.

I'll admit it is a little bit janky (which the author admits/warns about). But it seriously does work better than yabai. This config (using Phoenix) basically abandons the native "Spaces" functionality and does everything by just maintaining an internal window state and moving windows around fast. So you don't have to disable SIP (a big thing for me, since I want to use this at work). I'm seriously kind of blown away, this is miles better than apps that people are paying for, and it was just sitting here in this guy's github fork.

It is super disappointing this is the best that Mac can do though. There is no reason there shouldn't be a mostly-native (ie, less janky) tiling wm solution on the platform.

Re: Hyprland: A dynamic tiling Wayland compositor

#70

Post by boudin »

zokier wrote: post #24
dTal wrote: post #11

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…

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.

River does that for the windows layout https://github.com/riverwm/river
Post reply on HN