I think that’s rather presumptuous. Personally, I’d be quite happy with just core xmonad (or something very similar) running on Wayland. I’m stuck with Wayland, so I’d be quite happy with a “bad imitation” (with limits on the “bad” part) - it only needs to work for me better than sway or gnome.
5 Likes
I disagree with this. Firstly, some things which work well on X won’t work nearly as well on Wayland, purely due to the differences between them. I’m thinking particularly of window decorations in this regard, though I’m sure there are other things.
But secondly: XMonad is fairly old for a Haskell program, and its design is, shall we say, rather eccentric. Waymonad presents us with a great opportunity to revise its architecture to make it easier to extend and easier to configure. As much as I loved XMonad, it was always a bit difficult for me to achieve what I wanted when using it.
1 Like
I agree with this in both respects: not only am I expecting that Wayland will do some things better and others worse, but I’m expecting some if not all of the hooks to change just because Wayland does things differently.
As for re-architecting, we do in fact have a fairly major revision waiting in the wings for after a future 1.0 release. Depending on how things work out, it might go into wmonad or whatever we end up calling it instead. I’m also wondering of this will give us a chance to revisit the StackSet and its handling of floating windows, which has always been a pain point.
I would not. Xmonad without contrib is not really different from any other tiling manager.
They are a few working already for Wayland which are probably good enough (compare to Xmonad core) out of the box.
1 Like
That’s interesting, any link to share ?
1 Like
Model–View Deviation Tracking by LSLeary · Pull Request #432 · xmonad/xmonad · GitHub through Purify the unclean by LSLeary · Pull Request #436 · xmonad/xmonad · GitHub, which redesign the logHook and manageHook and replace windows with an MVC architecture.
4 Likes
I totally agree
Xmonad is loved for it’s flexibilitity and features , mostly obtained with xmonad-contrib
Also, in my opinion is important to maintain active the x11 xmonad , until the Wayland version will have the most of / all the features that currently xmonad have.
It’ important to support the current, loyal user base, and avoid the migration of some users to other alternatives, letting xmonad without a valid userbase for testing the Wayland version (if Wayland xmonad will miss some features and the old one will cease the development, users may stop using xmonad at all)
The key point of difference is that the configuration language is a pleasant to use programming language. Doing something like automatically changing the tiling layout when a certain program is launched is straightforward in xmonad, but not in most other tiling window managers.
1 Like
The programming language is far less important than usability and features.
I don’t think is smart to use a piece of software only because it’s written in a pleasant language, the features provided is the main point
Haskell made xmoad able to be powerful, but without modules and contributed extensions, it has the same functions that most of tiling windows managers have, Haskell is not enough as “selling point” for xmonad
1 Like
Hello. Let me add my 2c here 
-
From a user perspective, I would ask not to abandon xmonad-on-x11 development once xmonad-on-wayland development will be started. At least I, and very probably a lot of other people, will most probably stay on X11 for as long as it will be remaining possible in debian / ubuntu; I do not like the idea of changing my workflow just because someone somewhere thinks X11 is too old. And when I will have to, I would like to have in Wayland something that will be not too much lacking features compared to xmonad that I have. It is clear that we do not have much resources to support two different albeit similar WMs with the same activity; it will be understandable and okay if xmonad-on-x11 development will become slower than one of xmonad-on-wayland; after all, development of xmonad was never too fast
So, I assume xmonad-on-wayland will have several years to catch up in functionality of xmonad-on-x11. -
Another thing we should probably at least consider is to add a “backend abstraction layer” to xmonad-core. Something like “class Backend where…; instance Backend X11 where…; instance Backend Wayland where…” And gradually port the rest of xmonad, and then xmonad-contrib to it. This obviously will take a lot of efforts, but for users it would create the least painfull experience. Hopefully
2 Likes
| Who cares if ___ is no longer actively developed, I don't like change and nothing will stop me from running it as it is right now | |
|---|---|
| X11 | Yes |
| XMonad, in a hypothetical future in which ‘WMonad’ replaces it | No? |
If by programming language, you mean “the language the window manager is written in”, then I’ll agree it’s irrelevant. If you mean the configuration language for the window manager (which in the case of xmonad happens to be a programming language) then that’s a key part of usability.
I don’t get this. “Haskell” is not why I used to use xmonad, any more than “emacs lisp” is why I use emacs. The selling point is extensibility; without it xmonad-contrib wouldn’t exist.
But going back to what originally caused me to post in this thread; I am not nobody, I am a real living breathing human being. I’m stuck with Wayland, and would welcome xmonad, even if I couldn’t use xmonad-contrib or xmonad-extras. This is not me saying that I belong to a demographic that the xmonad developers should be targeting, merely that I exist.
1 Like
I agree with you that the language of the configuration file is important (I really like Haskell) and that extensibility is also a killer feature (I love xmonad also for its extensibility)
But those things are meaningless if… You have nothing to be configured and nothing to extend it with.
I hope I explained my point.
Without modules and extensions (in this case xmonad-contrib and xmonad-extras) you have nothing to working on to apply the extensibility and the flexibility.
That’s only an inconvenience. Writing an entire window manager is a huge amount of work, but writing any individual component of xmonad-contrib from scratch is only a few hours, and likely quite relaxing. That’s probably not the case for most xmonad users, but it is the case for me, and my priorities here are entirely selfish, and not based on what is best for “xmonad”.
1 Like
Is it ? Then porting the full xmonda-contrib should only take a few weeks …
My actual config import 69 modules from xmonda-contrib, If I have to spend 69x2-3hours to make it working I’ll probably spend a few days instead trying to migrate to another tiling WM (however bad is the configuration language). That is not a mere inconvenience but a deal breaker (for me at least).
Albeit I’m sure that a lot of X11 window managers will continue running even if its code-base will be untouched for many years, every major distro is going to default its graphical stack to Wayland. Eventually, some programs will only be compiled with Wayland support, notably commercial pre-compiled applications. At that point (maybe 5-10 years from now), I would expect that nobody will maintain packages that involves X11 window managers. Regardless, XMonad still be maintained for X11 while its Wayland version is developed.
I’m not sure about the abstraction layer, while it’s a great idea to have some kind of modularity, almost every graphical stack developed nowadays is based on Wayland and/or written in C++, which is a little bit painful to write integrations in Haskell. Workstation users are not that predominant today, so I don’t expect anybody developing another graphical stack, in particular for desktop/workstation usage, and I also cannot see XMonad being predominant at some environments like automobile interfaces or small devices, even if it can do it with some kiosk mode.
What it can relieve some migration pain is great docs, in particular about switching from X11 to Wayland configuration. I’m pretty sure that newcomers didn’t write a thousand-line config their first time with XMonad, so it’s unrealistic to think about changing only a few lines of code and run XMonad in Wayland seamless when actually there are no code written.
But surely the deal you can live with is just to keep using X, after all, you’re already using it. I have applications which are Wayland only, so it’s not like I can go back to X. That said, for comparison, the last time I used xmonad (which was back in 2014), I had 3 modules from xmonad-contib, and a bunch of custom code for non-square windows (it was using the xshape extensions, so nothing fancy; just clipping them).
I wonder about this. Wlroots is an active project, and maintaining a complete set of Haskell bindings, that other people could use, may be a project in and of itself. Maybe the goal should be to maintain the fewest number of bindings necessary, no?
I assume that’s what hsroots is, but I haven’t really looked at it. Maybe the first aim should be to port it to a newer version of wlroots? It would be a starting point, at least.
Yes, hsroots is a wrapper for an old version of wlroots.
The problem with starting over from scratch is that we need to write not just a window manager, but a whole compositor (== display manager). wlroots doesn’t provide a whole display manager, but it provides most of the necessary pieces; as such, it would simplify things considerably. So I’ve been assuming that an updated hsroots would be the first order of business.
I agree: the first step in writing any Haskell Wayland compositor must be to write bindings to wlroots. (This also tremendously improves interoperation with the Wayland ecosystem as it currently exists.)