Proposal for significant overhaul and potential integration of herbstluftwm

[ghost]

I wanted to discuss the current state of herbstluftwm development and gather some insights. After reviewing previous issues (#79), it appears that a significant overhaul of the codebase may be necessary, given the asynchronous nature of Wlroots compared to the synchronous nature of xlib.

Considering this, I am contemplating forking the project and dedicating my efforts to address these challenges. However, before proceeding, I wanted to assess the potential interest and practicality of integrating this fork into the main branch. Otherwise, it could be an alternative option similar to i3's existing i3-gaps and i3.

My primary concern lies in ensuring that the work I contribute serves a purpose within the community. If there is a genuine demand for such modifications and if it aligns with the vision of the project's contributors, I am more than willing to invest my time and efforts.

[t-wissmann]

Hi, my vision is to have a single code-base that works for both xlib and wlroots, and I'm happy about help! I'm reluctant to fork the project because I fear that we can never merge the two again. This would imply that I have either double the maintainance work or one of the branches will die.

In the past, I tried to separate general hlwm concepts from xlib-specific code parts, but there is also still much work to be done. I accomplish the separation using signals: instead of the hlwm algorithm calling xlib-functions, the xlib-specific parts listen for signals from a self-contained hlwm that indicate some change.
For example:

• 'the keybindings have changed' (see e.g. the KeyManager class).
• there's a (simplified) css engine that defines visuals and so the actual x11 rendering is only 250 LOC (x11-widgetrender.cpp)

[ghost]

To make sure I understand you correctly. Do you mean the code has been modularized where specific pieces could be rewritten to be drop in? i.e the keymanager class? If so first thing to do would be to modularize the codebase further? Otherwise begin doing that? Make it independent on X, then implement separate classes for wlroots?

[t-wissmann]

Yes, you're absolutely correct :-). And my vision is that the 'drop in' can happen at run-time when starting hlwm :-)

[ghost]

I'd be more than willing to help out with decoupling the wm from xlib. I could start a branch today and begin doing that. I'm unfamiliar with your codebase so it'd take a bit of time.

[t-wissmann]

In order to keep things mergable, I highly recommend to start with only small changes. E.g. what I wanted to do soon is to create subdirectories (hlwm/, hlx/ and then hlway/) in order to divide the source files into the parts that are generally hlwm and the parts that are specific to X.

[ghost]

For the first change, would creating hlwm. hlx and organizing everything be a good start? Then make a bunch of small changes over time? Or start with small changes and organize later?

[ghost]

Yes, you're absolutely correct :-). And my vision is that the 'drop in' can happen at run-time when starting hlwm :-)

Would you want it to be compile time switchable too?

[t-wissmann]

For the first change, would creating hlwm. hlx and organizing everything be a good start? Then make a bunch of small changes over time? Or start with small changes and organize later?

yes, the smaller the PRs the better. E.g. just moving a couple files and adjusting the #include-directives is a good start

Yes, you're absolutely correct :-). And my vision is that the 'drop in' can happen at run-time when starting hlwm :-)

Would you want it to be compile time switchable too?

instead of a compile time switch, two executables are probably easier to use (with two main() functions).

[ghost]

I am going to work on reading your source code to begin doing this, keep a lookout for new PRs. I have absolutely zero understanding though of the wm. Let me know if you have any tips for understanding it better.

[ghost]

@t-wissmann Apologies for the delay. After looking over the project briefly I've determined that we will need to at some point overhaul the IPC since it's dependent on X11. I'd be willing to do the work, but what would you want to replace it with? I think supporting multiple IPC solutions would be unnecessary.

[t-wissmann]

It's better to start with small changes. Even though the IPC isn't a very big change, one needs to be very careful when designing it, because one needs to be aware of the concurrency and avoid blocking (e.g. hlwm must not freeze even if 'hc' sends an incomplete request). I'm not familiar with wayland, but maybe they support some way of message interchange.

[ghost]

Of course could start sorting the sources out to hlwm and xorg first. Wlroots implements an IPC solution we could use that or use something like dbus to avoid maintaining two implementations of the IPC.

[ypnos]

Compositor Modules should be considered as a backend for porting HLWM to Wayland instead of Wlroots.

Advantages:

1. Works both with X11 and Wayland, can port the whole codebase of HLWM once instead of introducing a new divergency in the code
2. Provides high-level abstraction which should significantly reduce amount of new code to be written and might even reduce HLWM codebase by a bit
3. Is a C++ library

Drawbacks:

1. Although the code base is old and battle tested (KWin), the library by itself is very young
2. It is a one-man project so far (a similar thing might be said about wlroots, but Como depends on wlroots, so it only adds an uncertainty)

[gyreas]

What's the current state of this effort? (That person's account is deleted.)

[t-wissmann]

Beside the messages in this thread, I have never received any kinds of contributions from this person. (I already found it quite suspicious that the person's github profile was almost empty...)

The current state of the effort is unfortunately rather unchanged, because I have essentially no time for hlwm at the moment because of family and my job.

[gyreas]

I'd like to contribute to this effort esp their suggestion about incremental separation of concerns; however, I can't promise anything tho mostly because I'm not familiar with C++ (but C) and the codebase.
I'm going work on those and submit a draft PR when I get a basic understanding of both.

How does that sound?

PS: Was there a time when hlwm considered itself the wm for hackers by specifying so on the homepage? Do you have idea which wm did at some point? I kinda vaguely remember some wm did but don't which

[ypnos]

Hello Saheed, I believe you are referring to DWM, which is notable for being configured by editing a C source file. Apr 12, 2024 10:43:34 Saheed Adeleye ***@***.***>:

…

I'd like to contribute to this effort esp their suggestion about incremental separation of concerns; however, I can't promise anything tho mostly because I'm not familiar with C++ (but C) and the codebase. I'm going work on those and submit a draft PR when I get a basic understanding of both. How does that sound? PS: Was there a time when hlwm considered itself the wm for hackers by specifying so on the homepage? Do you have idea which wm did at some point? I kinda vaguely remember some wm did but don't which — Reply to this email directly, view it on GitHub[#1569 (comment)], or unsubscribe[https://github.com/notifications/unsubscribe-auth/ACAWVPQP7YBT5EUDJD7ULZLY46NDJAVCNFSM6AAAAAA7ZNYNTSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANJRGMYDIOBUGE]. You are receiving this because you commented. [Tracking image][https://github.com/notifications/beacon/ACAWVPVBNVAV426GGHEB2EDY46NDJA5CNFSM6AAAAAA7ZNYNTSWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTT2IRWYS.gif]

[gyreas]

@ypnos

while I'm not too sure about that, I think it's fitting for dwm.