GopherProxy

	tmade introduction comment in dwm.h shorter - dwm - [fork] customized build of …
	git clone git://src.adamsgaard.dk/dwm
	Log
	Files
	Refs
	README
	LICENSE
	---
	commit cbfc69e310e41cf0d9d4ae7529856014f2b88822
	parent 1d7674bb22088c5dae110751bd57e75c141e3afb
	Author: Anselm R. Garbe <[email protected]>
	Date: Tue, 12 Sep 2006 09:46:19 +0200

	made introduction comment in dwm.h shorter
	Diffstat:
	M dwm.h \| 35 +++++++++++++----------------…

	1 file changed, 15 insertions(+), 20 deletions(-)
	---
	diff --git a/dwm.h b/dwm.h
	t@@ -6,19 +6,14 @@
	* driven through handling X events. In contrast to other X clients, a window
	* manager like dwm selects for SubstructureRedirectMask on the root window, to
	* receive events about child window appearance and disappearance. Only one X
	- * connection at a time is allowed to select for this event mask by any X
	- * server, thus only one window manager instance can be executed at a time.
	- * Any attempt to select for SubstructureRedirectMask by any connection after
	- * another connection already selected for those events, will result in an
	- * error generated by the server. Such errors are reported through calling the
	- * current X error handler.
	+ * connection at a time is allowed to select for this event mask.
	*
	- * Calls to pop an X event from the event queue of the X connection are
	+ * Calls to fetch an X event from the event queue of the X connection are
	* blocking. Due the fact, that dwm reads status text from standard input, a
	* select-driven main loop has been implemented which selects for reads on the
	* X connection and STDIN_FILENO to handle all data smoothly and without
	- * busy-loop quirks.. The event handlers of dwm are organized in an array
	- * which is accessed whenever a new event has been popped. This allows event
	+ * busy-loop quirks. The event handlers of dwm are organized in an array which
	+ * is accessed whenever a new event has been fetched. This allows event
	* dispatching in O(1) time.
	*
	* Each child window of the root window is called a client in window manager
	t@@ -27,20 +22,20 @@
	* history is remembered through a global stack list. Each client contains an
	* array of Bools of the same size as the global tags array to indicate the
	* tags of a client. There are no other data structures to organize the clients
	- * in tag lists, because a single global list is most simple. All clients which
	- * have at least one tag enabled of the current tags viewed, will be visible on
	- * the screen, all other clients are banned to the x-location 2 * screen width.
	- * This avoids having additional layers of workspace handling.
	+ * in tag lists. All clients which have at least one tag enabled of the current
	+ * tags viewed, will be visible on the screen, all other clients are banned to
	+ * the x-location x + 2 * screen width. This avoids having additional layers
	+ * of workspace handling.
	*
	* For each client dwm creates a small title window which is resized whenever
	- * the WM_NAME or _NET_WM_NAME properties are updated.
	+ * the WM_NAME or _NET_WM_NAME properties are updated or the client is resized.
	+ * Keys and tagging rules are organized as arrays and defined in the config.h
	+ * file. These arrays are kept static in event.o and tag.o respectively,
	+ * because no other part of dwm needs access to them. The current mode is
	+ * represented by the arrange function pointer which wether points to dofloat
	+ * or dotile.
	*
	- * Keys and tagging rules are organized as arrays as well and defined in the
	- * config.h file. These arrays are kept static in event.o and tag.o
	- * respectively, because no other part of dwm needs access to them.
	- *
	- * The current mode is represented by the arrange function pointer which wether
	- * points to dofloat or dotile.
	+ * To understand everything else, start with reading main.c:main().
	*/

	#include "config.h"