
Way Cooler: A tiling window manager for Wayland written in Rust - pimeys
https://github.com/Immington-Industries/way-cooler
======
lkiux
Client-side decorations, visible in the screenshot, are a true PITA. It's
stupid that each widget set has to replicate this behavior. It results in
visual differences, and it's doubly stupid that this is touted as an
"advancement" just for the rate case that you want to override the title bar.

You could have done the inverse, as currently done with X11 (server-side
decoration by default, but overridable).

This incurs in stupid behavior for all tiling window managers in wayland, as
they cannot enforce the client to remove the title bar. For a tiling window
manager user, this a significant downgrade in wayland. The WM protocol in X11
is one of the few areas that let X11 innovate a lot compared to all other
desktops. The number of (wonderfully) different window managers is proof.
Server-side decorations, in particular, should have been a no-brainer!

~~~
sho_hn
FWIW, we use server-side decos in the Wayland implementation of KDE Plasma and
KDE/Qt apps, for these reasons and many others. If anyone says it can't be
done, feel free to point them our way :-)

~~~
cm3
How?

------
shadeless
Also check out sway, i3 compatible window manager for Wayland:
[https://github.com/SirCmpwn/sway](https://github.com/SirCmpwn/sway)

~~~
cm3
I've never used i3, but I've tried sway and it works, though isn't at feature
parity with i3. It's usable though. And as I wrote in a sibling comment,
Xwayland integration is even more buggier in libwlc (used by way-cooler and
sway) than it is in libweston, so be prepared for weirdness with X11 apps.
Floating window support is also wonky.

~~~
Lapsa
tried it half a year ago. wasn't usable - constantly crashed

~~~
cm3
If you're speaking of sway, it's usable now, but Xwayland is wonkier than in
Weston.

------
cm3
I wish they had picked libweston instead because it's less buggy and Xwayland
integrations has less problems as well. You can get libweston the 1.12 release
(aka current git master or the new release in probably two weeks). There's
also libweston-desktop that provides more abstractions and helpers for writing
desktop compositors which should land in weston.git soon.

But since wlc 0.0.5 is out there, I can understand why they'd base it on that
despite the deficiencies.

It's good to see more Wayland compositors and I hope that means someone will
port urxvt or xterm to Wayland for those of us who miss too much in vte-based
emulators or want something more stable than EFL-based Terminology.

------
transfire
An Electron powered status bar? So we have Rust, Lua and Javascript in there.
Hmm... Maybe someone can port
(nwm)[[https://github.com/mixu/nwm](https://github.com/mixu/nwm)] to Wayland?

~~~
pdkl95
> An Electron powered status bar?

Chromium and Javascript to run a status bar? A panel is a relatively simple
program; it shouldn't be using more than ~1MB of memory (maybe more with large
icons). Using Chromium adds many useless layers of abstraction (e.g. HTML, JS
engine) and wastes an incredible amount of memory.

~~~
cm3
You're right and the memory use of KDE, GNOME, XFCE is unjustifiable. Even
sway (the i3-inspired Wayland compositor) uses a lot of money for a simple
tiling compositor that doesn't have fancy "bling". It's three times the memory
use as xmonad and xmobar, but maybe it's an architectural issue with wayland.
I mean, Weston isn't light-weight either.

~~~
cesnja
Wayland compositors must also do (some) actions that were previously handled
by X server. Ergo your comparison is a bit unfair, you should try comparing
sway vs i3 + Xorg.

~~~
cm3
That's what I suspected by saying "maybe it's an architectural issue with
wayland".

~~~
anewhnaccount
More of an architectural goal than an architectural issue.

------
based2
[https://www.reddit.com/r/programming/comments/4xgcbd/announc...](https://www.reddit.com/r/programming/comments/4xgcbd/announcing_way_cooler_a_tiling_window_manager_for/)

