Bump to 44adafe.

Make floating windows spawn within the monitor's window area

This is a follow-up on this thread:
https://lists.suckless.org/hackers/2208/18462.html

The orginal code had constraints such that if a window's starting
attributes (position and size) were to place the window outside of
the edges of the monitor, then the window would be moved into view
at the closest monitor edge.

There was an exception to this where if a top bar is used then the
window should not obscure the bar if present, which meant to place
the window within the window area instead.

The proposed change here makes it the general rule that floating
windows should spawn within the window area rather than within the
monitor area. This makes it simple and consistent with no
exceptions and it makes the intention of the code clear.

This has the benefit of making the behaviour consistent regardless
of whether the user is using a top bar or a bottom bar.

Additionally this will have an effect on patches that modify the
size of the window area. For example if the insets patch is used to
reserve space on the left hand side of the monitor for a dock or a
vertical bar then new floating clients will not obscure that area.

Ref.
https://git.suckless.org/dwm/commit/44adafe0069e73aa03a3829d7bb39591cd8b3f1d.html

README.md

@@ -1,4 +1,4 @@
-This dwm 6.3 (e0dee91, 2022-08-08) side project has a different take on dwm patching. It uses preprocessor directives to decide whether or not to include a patch during build time. Essentially this means that this build, for better or worse, contains both the patched _and_ the original code. The aim being that you can select which patches to include and the build will contain that code and nothing more. Due to the complexity of some of the patches dwm-flexipatch has diverged from mainstream dwm by making some core patches non-optional for maintenance reasons. For the classic dwm-flexipatch build refer to branch [dwm-flexipatch-1.0](https://github.com/bakkeby/dwm-flexipatch/tree/dwm-flexipatch-1.0).
+This dwm 6.3 (44adafe, 2022-08-11) side project has a different take on dwm patching. It uses preprocessor directives to decide whether or not to include a patch during build time. Essentially this means that this build, for better or worse, contains both the patched _and_ the original code. The aim being that you can select which patches to include and the build will contain that code and nothing more. Due to the complexity of some of the patches dwm-flexipatch has diverged from mainstream dwm by making some core patches non-optional for maintenance reasons. For the classic dwm-flexipatch build refer to branch [dwm-flexipatch-1.0](https://github.com/bakkeby/dwm-flexipatch/tree/dwm-flexipatch-1.0).
 
 For example to include the `alpha` patch then you would only need to flip this setting from 0 to 1 in [patches.h](https://github.com/bakkeby/dwm-flexipatch/blob/master/patches.def.h):
 ```c

dwm.c

@@ -2465,14 +2465,12 @@ manage(Window w, XWindowAttributes *wa)
 		#endif // SWALLOW_PATCH
 	}
 
-	if (c->x + WIDTH(c) > c->mon->mx + c->mon->mw)
-		c->x = c->mon->mx + c->mon->mw - WIDTH(c);
-	if (c->y + HEIGHT(c) > c->mon->my + c->mon->mh)
-		c->y = c->mon->my + c->mon->mh - HEIGHT(c);
-	c->x = MAX(c->x, c->mon->mx);
-	/* only fix client y-offset, if the client center might cover the bar */
-	c->y = MAX(c->y, ((!c->mon->bar || c->mon->bar->by == c->mon->my) && (c->x + (c->w / 2) >= c->mon->wx)
-		&& (c->x + (c->w / 2) < c->mon->wx + c->mon->ww)) ? bh : c->mon->my);
+	if (c->x + WIDTH(c) > c->mon->wx + c->mon->ww)
+		c->x = c->mon->wx + c->mon->ww - WIDTH(c);
+	if (c->y + HEIGHT(c) > c->mon->wy + c->mon->wh)
+		c->y = c->mon->wy + c->mon->wh - HEIGHT(c);
+	c->x = MAX(c->x, c->mon->wx);
+	c->y = MAX(c->y, c->mon->wy);
 
 	wc.border_width = c->bw;
 	XConfigureWindow(dpy, w, CWBorderWidth, &wc);