Windows dont get restacked properly and or are resized incorrectly

Due to my lack of knowledge of Makefiles, and their overall confusing nature (to me). The file structure isn't the best.

It would be wise to update this and have separate directories for each component, src, include, tools...

Due to no floating method every window is resized to fit which breaks some application's focus, such as audacity

EDIT: Meant to say Cursor breaking, and focus too

Normal Xlib behaviour results in the focused window still receiving the (button) event but as of now that is not the case.

Some windows like picture-in-picture (firefox) seem to warp to the side of the screen when changing video (autoplay) in a seperate desktop when changing back to the desktop in which picture-in-picture is in.

Extremely slow grid tiling when switching from monocle -> grid when compilingon -O3, this issue doesnt exist when compiling in debug mode.

Sometimes due to threads not being killed fast enough, Address Sanitizer may trigger due to "unfree" data.

Not sure what is wrong but anything past v2.0.1 is slower in restacking

Not sure where this is coming from, but memory isn't being freed for some reason?

Due to the fact that we probably shouldnt re-manage a window after managing, (unless unmapped) I propose a hash map hashing the atoms, and jumping to the correct update function for their properties.

Some apps refuse to have input if focused, more than once. Issue appears to be related to focusing of windows/grabbuttons()

Due to arrange being called when ever a client is mapped/unmapped we are required to send thousands of events to xcb to proccess which is bad as xcb is pretty slow (due to latency), rather X11 is slow (latency). So I propose we calculate the window dimentions and calculate restacking to make as little calls to XCB as possible.

Due to the current usage of X's windowing grab/ungrab features it is impossible for clients to grab certain types of events, this could be used for data sanitation (keyloggers...).

But Xinput would still be preferable, as it seems to have better developer tooling

While the stack is correctly updated showing the windows (technically). It seems that it doesnt raise or put up the currently selected client for some reason, this seems to occur on layouts like monocle

Should save about ~12bytes per list type, so about ~48bytes in total per client.

Assuming we use uint16_t(s), limiting max client creation to UINT16_MAX which shouldnt really be a problem as it is unlikely any user would make that many clients, consistently

For some reason, clicking on multiple windows at the same time triggers arrange() in an inconvenient manner that causes Janky window movement,

As it stands getprop.c kinda sucks, mainly in its lack luster thread implementation.

It would stand to improve this as to make these threads more independent and more reponsive rather than a somewhat bare bones funtionality

For some reason when resizing the monitor (Xephyr) the clients seem to stop receiving events that were "below" them relative to the starting point of the original x/y coordinates of the window.

This seems to mostly be a y coordinate issue as the x coordinate seems to be mostly fine.

While we can do it synchronously it would not be particular great for regular windows, we should use xkb for this

No idea why this occurs?

Some windows like thunar dont set their icon until mapped? I think.

Either that or XCB is too fast, which I dont believe, perhaps we can update in property notify.

Implement Soft Restarts, (currently in use), with Hard restarts as a separate optional method (execvp, previous restart method)

MAIN ISSUE: It works most of the time but when it fails (somewhat often) it throws a couple errors.

dont know how but ill prob look in the Xlib source to see how they do it

Currently some windows may become floating when tiling them such as firefox.

Aside from using a toolkit, this task seems, difficult to say the least

Monocle seems to break the restacking of windows somehow?

Some windows like polybar seem to act strangely when grabbing buttons, grabbutons();

And seem to cause a starvation that causes the XServer connection to never send back ANY form of event, seemingly stuck in poll(), or "XCBNextEvent".

HOWEVER: It seems that the XServer still receives events that we send, this is notable as wakeupconnection() still seems to be able to allow for process termination.

Sometimes when you move the bar, kill the bar, and switch desktops the window manager exists due to memory violation, it's apparently focused? Somehow.
This is somewhat finicky, but you can force trigger it via quitting early most of the time.

Steps.
1.) Spawn a bar-window in the first desktop (desktop 0)
2.) Switch to another desktop.
3.) Spawn a window (doesnt matter what window)
4.) Drag the bar-window around.
5.) While still dragging the kill/terminate the window.
6.) Switch back to the first desktops.

Affected version 2.4.0

It seems that restarting doesnt seem to work (for the most part after the self restart changes).

Some windows like steam startup arent centered, for whatever reason.

TODO

Due to the fact that some windows may invoke these operations, they also can often be accidentally clicked/pressed, this while good for responsive UI, isn't so good when they are moved very slightly ~1-5 pixels, which causes the window to be marked as “floating” which users may not want

Not sure how this happened, but after using alt-tab the Event handler broke? It seemed to endlessly be stuck at "poll", This likely is from some sort of malformed request to or from XCB.

Due to focus causing windows to teleport back resizing/moving those windows break functionality a bit.