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).
1 Like
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.
1 Like
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.
1 Like
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.)
1 Like
Should we get started with making bindings for wlroots? I’ve been learning Haskell for a little over a year now in my spare time, I want get my hands dirty and try and do something real.
I’m intimidated though because I don’t have experience making a big application.
I started looking at writing bindings for wlroots but I need to learn about how to properly manage the C types on the Haskell side, how to free memory on the c side, how to ensure that C and Haskell are in sync.
HSroots looks dead
Yes, why not! I’m a little intimidated too, to be honest, but you never know until you try.
At this point is it worth creating a separate thread to coordinate things?
1 Like
Yes, we have some things to discuss. Like:
- should we fork hsroots?
- should we start from scratch?
- which version of wlroots should we target releases
- should the bindings be very low-level or should they try to provide a nicer extraction? There are some projects that were started and then looked like they died because of the imperative nature of what they were doing
- I don’t think this involves just wlroots, I think it involves bindings to wayland too, which may already be done.
- there was this project Sudbury, but I’m not sure what happened to it sudbury
I’m still a Haskell beginner, and my xmonad config is super simple, hardly changed from the example. So, I’m an xmonad beginner too.
I’ve only ever used Stack + Nix, so I was trying to see how to do just Cabal + Nix earlier repo. I was thinking Nix Flakes could be nice because Nix can manage our C dependencies for us.
1 Like
OK, I’ve created a new thread, starting with my thoughts on those points: Haskell wlroots bindings
3 Likes
Is there any other work that could be done by a relative beginner to support this effort in addition to working on the Wlroots bindings?
So far, I don’t think so. Practically everything else depends on having a working set of wlroots bindings.
You posted this last October. Are you still looking for paid help? I have been using Linux for the past 20 years, and as of last year switched to Wayland. Due to my large screen workflows, I have been eagar to do something with XMonad – which prompted me to learn Haskell – and would love to work on this.
What sayeth you?
Hi,
I see that the project of writing wlroots bindings is going pretty slow (and in my opinin risks to go nowhere, frankly speaking), I think that in the meantime the focus should be to made xmonad usable maybe under Xwayland.
A new xmonad for wayland should have all the function inluded in xmonad-contrib and xmonad-extras ,because xmonad without the -contrib and the -extars its just another tiling wm , and , considering that the port on Wayland had no great progressions since months from the staring of this thread, emulate all the current function of xmonad of wayland will be very hard
It’s still not possible for a window manager in XWayland to manage native Wayland windows, AIUI. They can only be managed by a compositor plug-in.
1 Like
That make things harder.
Can a point about the current status of the wayland port be made, and also about the future plans for the current xmonad project?
Thank you, I really appreciate your work!
@geekosaur is correct: this is not possible. XWayland is just an implementation of the X server for Wayland: it can display individual windows, but is not designed to do any kind of higher-level management or positioning (which is the responsibility of the compositor).
Work continues… steadily, but slowly. You can follow the discussion in the dedicated thread, and in the GitHub repo. Currently we’re working on Haskell bindings to wlroots, which are boring and laborious to make. Most of the actual work has been done by @anarchymatt and @bullishOnFunctional.
(This reminds me — there was some discussion on the GitHub about how to handle the XML files which specify the wlroots protocols. When I get more time this afternoon, I should make a post about that in the other thread.)
2 Likes