Although Wayland is contentious atm from a practicality perspective, I actually do like the idea of the standard "desktop" as we use it being split up into smaller components. Modularity reduces...
Although Wayland is contentious atm from a practicality perspective, I actually do like the idea of the standard "desktop" as we use it being split up into smaller components.
Modularity reduces performance but it makes my brain feel good.
From what I read somewhere, I was afraid Wayland would not allow the things that i (we) do now like having bspwm as a wm, lemonbar as bar, shxkd as a keybinding daemon and other small tools, but...
From what I read somewhere, I was afraid Wayland would not allow the things that i (we) do now like having bspwm as a wm, lemonbar as bar, shxkd as a keybinding daemon and other small tools, but it seems that it's not really the case.
I just started using swaywm the other day, and I've been reading up on Wayland as a result (sway's maintainer, Drew Devault, has a few good blog posts about it). The overall impression that I'm...
I just started using swaywm the other day, and I've been reading up on Wayland as a result (sway's maintainer, Drew Devault, has a few good blog posts about it). The overall impression that I'm getting is that Wayland as a protocol is modular/flexible enough that tools can be written to handle pretty much everything people are worried about losing as they transition away from xorg.
I mean, I don't know anything about it (I used sway for about 30 seconds), but from the blog post, it looks like that's the case. If that's so, that's really good news. I don't think I'll make the...
I mean, I don't know anything about it (I used sway for about 30 seconds), but from the blog post, it looks like that's the case. If that's so, that's really good news. I don't think I'll make the switch to Wayland anytime soon, but when I eventually do, I won't be too scared.
My understanding from following the project since shortly after it started is that is still very much the case. Each compositor must handle its own inputs, and there are specific interactions that...
Wayland would not allow the things that i (we) do now like having bspwm as a wm, lemonbar as bar, shxkd as a keybinding daemon
My understanding from following the project since shortly after it started is that is still very much the case. Each compositor must handle its own inputs, and there are specific interactions that happen between wayland clients, creating a more sandbox-like system. AFAIK, there still isn't a clean way to handle, say, sway and a lemonbar-style bar. Even dmenu causes issues because of xwayland (selecting a wayland window after calling dmenu in sway will cause the spawned dmenu window to stay up unless the process is killed).
Hopefully, with ideas like waybox or way-cooler, or whatever other awesome compositors, this will become easier, or at least standardized via wlroots.
Although Wayland is contentious atm from a practicality perspective, I actually do like the idea of the standard "desktop" as we use it being split up into smaller components.
Modularity reduces performance but it makes my brain feel good.
From what I read somewhere, I was afraid Wayland would not allow the things that i (we) do now like having bspwm as a wm, lemonbar as bar, shxkd as a keybinding daemon and other small tools, but it seems that it's not really the case.
Is it?
I just started using swaywm the other day, and I've been reading up on Wayland as a result (sway's maintainer, Drew Devault, has a few good blog posts about it). The overall impression that I'm getting is that Wayland as a protocol is modular/flexible enough that tools can be written to handle pretty much everything people are worried about losing as they transition away from xorg.
I mean, I don't know anything about it (I used sway for about 30 seconds), but from the blog post, it looks like that's the case. If that's so, that's really good news. I don't think I'll make the switch to Wayland anytime soon, but when I eventually do, I won't be too scared.
My understanding from following the project since shortly after it started is that is still very much the case. Each compositor must handle its own inputs, and there are specific interactions that happen between wayland clients, creating a more sandbox-like system. AFAIK, there still isn't a clean way to handle, say, sway and a lemonbar-style bar. Even dmenu causes issues because of xwayland (selecting a wayland window after calling dmenu in sway will cause the spawned dmenu window to stay up unless the process is killed).
Hopefully, with ideas like waybox or way-cooler, or whatever other awesome compositors, this will become easier, or at least standardized via wlroots.
Trying to use Sway (after being a semi-convert to i3, I always keep it around), the biggest hurdle is the lack of wayland-specific software.