nferhat/fht-compositor

The current implementation of blur in the compositor right now is pretty bad. Notably: It relies on optimized blur (aka. X-Ray blur) by default, which is a sane default but many people want to have "true blur" True Blur (when enabled) destroys any damage tracking done by us. My initial implementation was extremely naive and I didn't bother to test it further, however this must change as more people are picking up the compositor and leaving such a lackluster implementation bothers me. The implementation breaks on scaled monitors. The implementation can potentially break on monitors that are not logically placed at (0, 0) (IE. the "origin" of the global space) A new implementation would rely on #100, and new advancements, notably Smithay/smithay#1946 and Smithay/smithay#1910, to accurately track damage. Implementations are going to be heavily inspired from Niri's and cosmic-comp's, even though they are based on this one, they figured out a lot of the details I skipped.

(Kinda) supersedes #44 Right now, the layout system in the compositor is extremely rigid and is pretty hostile to work on. If you want to introduce a new layout, you would have to write a lot of logic that's deeply intertwined with the Workspace type. Moreover, some layouts (such as the #77) might need to store some sort of data (for BSP it would be a cache of a computed window tree). Right now the only solution is to recompute all the data whenever layout data is requested. The proposed solution would be to separate layout into a Layout trait. This trait would implement common functions like Associating each window with a position and size Pre-computing the size of a window if inserted at position i Access to state of the layout that needs to be stored. ... and more Another thought that crossed my mind is to not rely on math hand-written by me (or layout authors) but instead delegate that to some existing layouting library like Taffy. We would create some custom nodes to pass into t

As of right now, windows get rendered in the following order: The windows marked with the rules.ontop = true property. The active/focused window, IE the one received keyboard input All the other windows, rendered in their order in the workspace window list. This causes a lot of problems regarding accessibility, for example see #129. There's also the confusion of "where is this window gotta end up after". A lot of times, a window can just happen to jump all the way behind another window that could be tiled, meaning you'd have to focus it with the keyboard. These issues are accentuated when general.focus-follows-mouse = true, where window focus changes really often. This can give pretty annoying scenarios. The proposed solution is to introduce the concept of Z-index to windows (which was present in an older release of fhtc before the first ever release). Handling of window rendering order would be done as follows: Get all the windows by Z-index Sort the window render list by Z-index

The purpose of this protocol is to enable the creation of taskbars and docks by providing them with a list of opened applications and letting them request certain actions on them, like maximizing, etc. https://wayland.app/protocols/wlr-foreign-toplevel-management-unstable-v1