feat: add a config to control which window to focus on when closing window

[ParaN3xus]

Describe your PR, what does it fix/add?

This PR introduces a new configuration option, input::focus_on_close, which controls the window focus behavior after a window is closed.

Given the existing focus-related settings within the input category, I have placed this configuration there as well.

input::focus_on_close is an integer, and currently supports two values:

• 0: Maintains the current behavior, where focus shifts to the next window candidate as determined by getNextWindowCandidate.
• 1: Changes focus to the window under the cursor, which I believe offers a more intuitive user experience.

The reason for using an integer instead of a boolean is to allow for future extensibility. For example, the option could be extended to focus on the previously focused window, or implement other behaviors, depending on user needs or future contributions.

Is there anything you want to mention? (unchecked code, possible bugs, found problems, breaking compatibility, etc.)

No known issues.

Is it ready for merging, or does it need work?

Yes, it is ready for merging.

[vdawg-git]

This is quite cool. I am not a maintainer nor know C++, but I think using a string like "cursor" and "next" instead of an integer is nicer to understand for the end-user :D

[vaxerski]

clang-format and wiki mr needed :)

[vaxerski]

This is quite cool. I am not a maintainer nor know C++, but I think using a string like "cursor" and "next" instead of an integer is nicer to understand for the end-user :D

pls dont

[vdawg-git]

Pf, strings are nicer

[ParaN3xus]

Apologies for missing the PR guidelines. I've now applied clang-format and updated the wiki(hyprland-wiki/pull/753). Thank you for the feedback!

[ParaN3xus]

@Visual-Dawg
I considered using strings, but chose integers to align with the existing configurations in the project.

Settings like follow_mouse, off_window_axis_events, and emulate_discrete_scrollall use integers to represent different modes of operation. These settings are functionally similar in that they each control various behavioral outcomes.

I agree that strings can be more user-friendly, but in this case, I prioritized consistency with existing configurations.

[vaxerski]

strings will be parsable in the future once the descriptions branch gets merged (I should merge it)

[vaxerski]

ye I merged #7377 can you add your opt to configDescriptions.hpp too? (rebase on main first)

[ParaN3xus]

I've completed the rebase and updated ConfigDescriptions.hpp. Please review the latest changes.
@vaxerski

[vaxerski]

rest ok

[vaxerski]

thanks for the patience!

[vaxerski]

clang-format needed