Re: Shape Hyprland

[rszyma]

@vaxerski, regarding your last blog post about wanting more contributors:

I think, that just asking for help alone is not enough. There also
should be put some effort towards making developer experience better,
especially because there seems to be a lot of room for improvements.
Here's a list of key areas to work on to improve the situation:

• Decrease incremental compilation times. This would be huge improvement for newcoming devs, because to understand some piece of code you sometimes want to ask yourself "will this still work if I change this line?" and recompile with a single change and see the result. But this strategy can't be used when single-line change causes full recompilation. There's been some effort from @memchr in refactor: only include what you use #3398 regarding this issue, though nothing came out of it so far.

• Add a base for automated testing, and some testing guidelines. There are currently 0 tests in Hyprland. Tests can be really helpful to prevent introducing regressions while adding/refactoring existing code. I'm not asking to add test coverage for every existing piece of code (because that would be impossible in the current state of the codebase), but adding basic test framework to even incentivize people to think about writing code in a way that makes it more testable.

• Make Hyprland more modular. Decoupled code is a lot easier to test, harder to break, and easier to reason about. There are currenly a lot of global variables used in Hyprland, which doesn't help modularity at all.

• Add more helpful info to "Contributing-and-Debugging" section on Hyprland website. To be specific, more info in IDE setup would be great to have.

Disclaimer: I'm not C++ dev, and not even professional dev, I just wanted to share my opinion on the topic, that's all.

[vaxerski]

Re: 1

Recompiling almost the entire thing only happens if you edit headers.

Re: 2

Tests for hyprland are not easy to write at all. I've thought about it a lot, trust me. There's a reason nobody has those.

Re: 3

Hyprland is already pretty modular. The only global variables are the singletons themselves

Re: 4

It has a bunch of useful info, but I also have been thinking about making a youtube video with more tips and tricks on how 2 develop dor hyprland

[i509VCB]

Point 1: is this concern because people haven't setup their environment properly for incremental compilation? Although still I'd make sure clean builds don't take too long.

For point 2: a wlcs runner could be a partial solution to the protocol frontend for clients, but is by no means a full test suite. A form of integration test could work but if hyprland's behavior changes then a bunch of tests need to be rewritten

Point 3: modularity can come at a cost of course, so be reasonable

[rszyma]

Point 1: is this concern because people haven't setup their environment properly for incremental compilation?

Why would people need to set it up themselves? It's wasted effort. This should be baked into makefile, ready to use out-of-the-box. Or at least mentioned on somewhere in section for devs on the website/readme.

[vaxerski]

see re:4