dwm-meillo
changeset 459:3c3f429dca99
made introduction comment in dwm.h shorter
author | Anselm R. Garbe <arg@10kloc.org> |
---|---|
date | Tue, 12 Sep 2006 09:46:19 +0200 |
parents | 81fcd7ddafee |
children | ab4b08d49d24 |
files | dwm.h |
diffstat | 1 files changed, 15 insertions(+), 20 deletions(-) [+] |
line diff
1.1 --- a/dwm.h Tue Sep 12 08:27:11 2006 +0200 1.2 +++ b/dwm.h Tue Sep 12 09:46:19 2006 +0200 1.3 @@ -6,19 +6,14 @@ 1.4 * driven through handling X events. In contrast to other X clients, a window 1.5 * manager like dwm selects for SubstructureRedirectMask on the root window, to 1.6 * receive events about child window appearance and disappearance. Only one X 1.7 - * connection at a time is allowed to select for this event mask by any X 1.8 - * server, thus only one window manager instance can be executed at a time. 1.9 - * Any attempt to select for SubstructureRedirectMask by any connection after 1.10 - * another connection already selected for those events, will result in an 1.11 - * error generated by the server. Such errors are reported through calling the 1.12 - * current X error handler. 1.13 + * connection at a time is allowed to select for this event mask. 1.14 * 1.15 - * Calls to pop an X event from the event queue of the X connection are 1.16 + * Calls to fetch an X event from the event queue of the X connection are 1.17 * blocking. Due the fact, that dwm reads status text from standard input, a 1.18 * select-driven main loop has been implemented which selects for reads on the 1.19 * X connection and STDIN_FILENO to handle all data smoothly and without 1.20 - * busy-loop quirks.. The event handlers of dwm are organized in an array 1.21 - * which is accessed whenever a new event has been popped. This allows event 1.22 + * busy-loop quirks. The event handlers of dwm are organized in an array which 1.23 + * is accessed whenever a new event has been fetched. This allows event 1.24 * dispatching in O(1) time. 1.25 * 1.26 * Each child window of the root window is called a client in window manager 1.27 @@ -27,20 +22,20 @@ 1.28 * history is remembered through a global stack list. Each client contains an 1.29 * array of Bools of the same size as the global tags array to indicate the 1.30 * tags of a client. There are no other data structures to organize the clients 1.31 - * in tag lists, because a single global list is most simple. All clients which 1.32 - * have at least one tag enabled of the current tags viewed, will be visible on 1.33 - * the screen, all other clients are banned to the x-location 2 * screen width. 1.34 - * This avoids having additional layers of workspace handling. 1.35 + * in tag lists. All clients which have at least one tag enabled of the current 1.36 + * tags viewed, will be visible on the screen, all other clients are banned to 1.37 + * the x-location x + 2 * screen width. This avoids having additional layers 1.38 + * of workspace handling. 1.39 * 1.40 * For each client dwm creates a small title window which is resized whenever 1.41 - * the WM_NAME or _NET_WM_NAME properties are updated. 1.42 + * the WM_NAME or _NET_WM_NAME properties are updated or the client is resized. 1.43 + * Keys and tagging rules are organized as arrays and defined in the config.h 1.44 + * file. These arrays are kept static in event.o and tag.o respectively, 1.45 + * because no other part of dwm needs access to them. The current mode is 1.46 + * represented by the arrange function pointer which wether points to dofloat 1.47 + * or dotile. 1.48 * 1.49 - * Keys and tagging rules are organized as arrays as well and defined in the 1.50 - * config.h file. These arrays are kept static in event.o and tag.o 1.51 - * respectively, because no other part of dwm needs access to them. 1.52 - * 1.53 - * The current mode is represented by the arrange function pointer which wether 1.54 - * points to dofloat or dotile. 1.55 + * To understand everything else, start with reading main.c:main(). 1.56 */ 1.57 1.58 #include "config.h"