Hey, thanks for the PR. I left a comment with my thoughts let me know what you think. I think your PR is in line with stuff like the xmonad approach. My personal preference is to have config files be as stand alone as possible but I can see the appeal of doing it in Main. I will defer to your opinion on this.
I’ve been doing a lot of work recently, over the holidays trying to get it to a daily driver. This work has been nearly exclusively in C so I haven’t been posting much about it here. I think most people here are not interested and if I’m honest one of the challenges of working on it myself is the C code is uninteresting and will be replace eventually with Haskell.
But still in saying that it has been challenging enough to add the functionality in C with all the available examples and documentation online, trying to do this in Haskell would have slowed me to a crawl. Im happy with the recent progress. So far I have added support for:
- Wayland clients like
- bemenu (this is a wayland equivalent to dmenu)
- yambar (more advanced bars like swaybar still unsupported)
- swaybg (for background images)
- mako (for notifications)
- Keybinding support (configurable via Haskell)
- Startup apps (configurable in Haskell)
- Support for wayland client config (For example adding this removed the bar above the kitty terminal emulator)
Currently I’m trying to add support for borders which will be the last piece in a large PR I worked on over the weekend.
The name of the game is protocol support, for example with the yambar I had to add support for layers and support for the client to request a reserved area based on the client settings (this needs to be done in a wayland protocol comparable way so the support is generic and universal).
With this latest PR I will be start using this as my daily driver but it is still missing crucial support for the following.
- Copy and Paste
- Tiling
- Multi monitor
- Locking
So if it is only at a stage that the creator is starting to use it I think it still unusable for most people, I also think there will be a lot of change to the code base in the coming months.
There are also probably a number of Wayland clients not supported, so far with each that I have added I have had to do a lot of work in C to get them working and add a lot of support.
I have been using this wlr-clients repo to test support wlroots / wlr-clients · GitLab
I think the wayland client stuff is very interesting and there is definitely a need for a Haskell project focused just on creating wayland clients. The nature of the wayland protocol and its communicate mean there are some really cool opportunities possible.
For example, waypipe allows running applications on remote machines but instead of sending the raw graphical information the way I think VNC and RDP work, waypipe sends just the wayland client messages. So to the app running on the client it believes its communicating with a local compositor. Ive been experimenting with this to get a tmux like experience with the servers I run.
There is also the possibility of using wayland clients within clients, so you could perhaps use an image image viewer within your wayland client app, I think this is really promising because it could allow apps that just aggregate other apps into something new.
For me now I think the immediate future will be focused on the C side, adding support for the missing features I listed above. It makes sense to get to a minimum set of must-have features and to start using this daily myself and iron out the bugs.
I foresee a point in the coming months when the above is supported, at that point I want to start moving to a full haskell implementation. Im not sure what form that will take it may be just iteration as I move to a strict and well defined FFI interface that uses a C shared library, or it might require something else.
With regard the topic of this thread, I think the original idea was to create bindings to wlroots, then create a compositor and then the clients. I think because of the complexity It makes more sense to work on all three in parallel and focus on providing a minimum level of support for the most in demand features, instead of trying to provide blanket support from the start.
The learning from working on Wayland clients feeds into working on the compositor and vice-versa and both feed into understanding what bindings are needed.
So for house keeping I think this thread should be kept for the bindings and a discussion on the compositor done here instead Tiny-wlhs, a hybrid haskell and C Wayland compositor - #2 by l-Shane-l