When Wayland replacing X, lots of cool window managers and mini applications will be gone.
IMO Ganeti died because of such a choice. There aren't enough programmers that are willing to invest into that niche.
I have nothing against that language per se, still such a choice can easily develop into a dead end.
I think the closest thing that could get most of the way there is https://github.com/domferr/tilingshell/
Even accounting for wlroots, you're not exactly just running sed on a glob. And unfortunately, wayland didn't actually fix X's complexity problem. Arcan did, but we're not allowed to have nice things because Redhat has no taste.
https://docs.qtile.org/en/stable/manual/ref/layouts.html#mon...
I really hope it makes the jump to Wayland. I've used XMonad for more than a decade and it's still my favorite WM.
XMonad really let me forget about managing windows---I never have to resize a window or remember where I put a window. XMonad handles the arranging and resizing and floating for me. There's a nice layout for small screens that will zoom your active window[0]. You can cobble your desktop together into whatever makes you happiest: Active corners. ScratchPads. So much in XMonad Contrib[1].
Since I'm not the right person to help with porting to Wayland, I'm giving money via the GitHub sponsorship page[2].
I check in on discourse from time to time: progress looks slow. The person/people they need are hard to come by.
[0]: <https://xmonad.github.io/xmonad-docs/xmonad-contrib/XMonad-L...>
From the Wayland devs' PoV, mainstreaming Wayland successfully shifted responsibility for doing most of the heavy lifting in the graphics layer from the neglected X-Windows project to the well-established KDE and GNOME. The state of wlroots and the ecosystem of personal WM projects is unavoidable collateral damage.
For an individual developer, perhaps the thing to do is take a page out of bbLean's [1] bag of tricks and implement your WM on top of one of the big two desktop environments.
Fvwm people are very smart and have been developing fvwm for longer than Linux have been around. From what I understand and have read, bring fvwm or creating a fvwm clone on Wayland is near impossible. Far too much work.
So we will really end up with "pigs" like Gnome3, KDE or a slew of tiling environments. None of the cool WMs like Windowmaker, fvwm, dluxbox, twm, ctwm, vtwm ....
(Incidentally, I love the way that my Xmonad setup works, even though I don't know Haskell. I tried using an i3wm setup at work for maybe a year, but every evening coming back to Xmonad on my personal laptop felt like a boost of agility. I guess, if I were wealthy and wanted to move to Wayland, I would seriously consider either doing the work myself or paying someone to.)
For me, the winning feature is FvwmButtons. Long before we had system trays and notification busses, if you wanted to put a media player, a clock, some stat counters, or a full-blown xterm, in a little desktop dock, you just captured a regular window. You didn't have to invent an entirely new category of "software designed to live as an icon inside someone else's ecosystem." I'm not aware of any compositor that offers anything like it-- it seems like the best we get now are ugly bars with a limited vocabulary of "we can integrate over some signaling bus with these three specific programmes and that's it".
I'll also lament the loss of bold, opinionated design. "Modern" compositors are either minimal to the point of nothingness, or insipid and generic. They don't look like the awesome UIs you'd see in old hacker movies, or the classic systems that were backed by 500 page HCI standards guides, they just look like the sort of UI you'd use in an textbook where you wanted to imply a GUI without anything specifically branded.
On Mastodon I follow a bot that posts screenshots of old Mac Kaleidoscope schemes and the creativity on display both leaves me in awe and makes me sad that no modern windowing system can hold a candle to it. With Kaleidoscope there were no rules. You could do a hacker OS[0], or game UI[1], or titlebars on the left[2] or underneath[3], or non-rectangular and chrome[4], or made of denim[5], and those are just a few of the thousands of wildly different themes[6].
Nothing on modern Linux comes close. Even if you seek out third party themes all you find are dozens of minor permutations on popular flat themes like Material and Nord. It's so dull.
[0]: https://macthemes.garden/themes/24c0f39f11eb-net-ghost/ [1]: https://macthemes.garden/themes/8f7b145a33f3-Millenniac [2]: https://macthemes.garden/themes/95203ae3bfe0-my-sidewyas-os/ [3]: https://macthemes.garden/themes/6da656d65263-modulus/ [4]: https://macthemes.garden/themes/7e008718df3c-dt-chromxium-tw... [5]: https://macthemes.garden/themes/0305d1075f5e-dt-denim/ [6]: https://macthemes.garden/
The packages I install are: xmonad libghc-xmonad-extras-dev gnome-flashback gnome-panel
(plus suckless-tools and xmobar)
That should give you a login option for "GNOME Flashback (Xmonad)"
I recall there were a couple of hacks necessary to show the Gnome Panel:
gsettings set org.gnome.gnome-flashback root-background true
gsettings set org.gnome.gnome-flashback desktop false
and then the panels you can hide or remove per your preference
This gives you the advantage of Wayland's modern display stack and no legacy Xorg code while still running a classic X11 window manager.
The main downside is you have to run all X11-compatible apps, it's unable to manage any Wayland-native applications. But, X11 apps aren't going away any time soon, just the display server.
For those unaware, though I doubt you're reading this thread if so, I want n desktops that are shared between all screens, not desktops _assigned_ to particular screens. If I summon a desktop on screen 1 and it's currently displayed on screen 2, they should swap.
Ideally also does layouts kind of like xmonad too, not "here's a tiling tree structure and a bunch of commands to manually manage it".
At least i3's (and I imagine sway's) config is sufficiently flexible for that. Here's a shell function that brings the workspace you specify to your current output:
i3_bring_workspace_to_focused_output() {
local workspace="$1"
i3 "
workspace $workspace
move workspace to output $(
i3-msg -t get_workspaces |
jq -r '.[]|select(.focused).output'
)
"
}
You can turn that into an executable and have it be called through a keybinding.This is such a crazy mentality to me, coming from game development, where you can just go to a random 22yo kid's desk, ask them "do you want to port this game to the Nintendo Switch?" and they'll go "hell yeah" and do it in a few months, despite never having programmed for the device before.
You can just learn to do new things. By all accounts the Wayland protocol is simpler than X11, and you've already done the majority of the work. It's just a matter of adding a new backend. People do that all the time when they port a program to the web, a game to a new platform, or when they add a new architecture to a compiler.
That doesn't mean anything. xmonad is not broken afaik, still in use everywhere and wayland, which is just a protocol, has no power over it.
Remember that many open-source contributors do it on their free time, with whatever energy they have left after their job.
https://docs.qtile.org/en/stable/manual/ref/layouts.html#mon...
They don't seem to be saying they can't do this or that it is some insurmountable technical challenge. They're saying that they aren't going to do it themselves and aren't giving reasons.