added a general comment to dwm.h how dwm is basically organized
e6cc2239
1 file(s) · +40 −0
| 1 | 1 | /* |
|
| 2 | 2 | * (C)opyright MMVI Anselm R. Garbe <garbeam at gmail dot com> |
|
| 3 | 3 | * See LICENSE file for license details. |
|
| 4 | + | * |
|
| 5 | + | * dynamic window manager is designed like any other X client as well. It is |
|
| 6 | + | * driven through handling X events. In contrast to other X clients, a window |
|
| 7 | + | * manager like dwm selects for SubstructureRedirectMask on the root window, to |
|
| 8 | + | * receive events about child window appearance and disappearance. Only one X |
|
| 9 | + | * connection at a time is allowed to select for this event mask by any X |
|
| 10 | + | * server, thus only one window manager instance can be executed at a time. |
|
| 11 | + | * Any attempt to select for SubstructureRedirectMask by any connection after |
|
| 12 | + | * another connection already selected for those events, will result in an |
|
| 13 | + | * error generated by the server. Such errors are reported through calling the |
|
| 14 | + | * current X error handler. |
|
| 15 | + | * |
|
| 16 | + | * Calls to pop an X event from the event queue of the X connection are |
|
| 17 | + | * blocking. Due the fact, that dwm reads status text from standard input, a |
|
| 18 | + | * select-driven main loop has been implemented which selects for reads on the |
|
| 19 | + | * X connection and STDIN_FILENO to handle all data smoothly and without |
|
| 20 | + | * busy-loop quirks.. The event handlers of dwm are organized in an array |
|
| 21 | + | * which is accessed whenever a new event has been popped. This allows event |
|
| 22 | + | * dispatching in O(1) time. |
|
| 23 | + | * |
|
| 24 | + | * Each child window of the root window is called a client in window manager |
|
| 25 | + | * terminology, except windows which have set the override_redirect flag. |
|
| 26 | + | * Clients are organized in a global doubly-linked client list, the focus |
|
| 27 | + | * history is remembered through a global stack list. Each client contains an |
|
| 28 | + | * array of Bools of the same size as the global tags array to indicate the |
|
| 29 | + | * tags of a client. There are no other data structures to organize the clients |
|
| 30 | + | * in tag lists, because a single global list is most simple. All clients which |
|
| 31 | + | * have at least one tag enabled of the current tags viewed, will be visible on |
|
| 32 | + | * the screen, all other clients are banned to the x-location 2 * screen width. |
|
| 33 | + | * This avoids having additional layers of workspace handling. |
|
| 34 | + | * |
|
| 35 | + | * For each client dwm creates a small title window which is resized whenever |
|
| 36 | + | * the WM_NAME or _NET_WM_NAME properties are updated. |
|
| 37 | + | * |
|
| 38 | + | * Keys and tagging rules are organized as arrays as well and defined in the |
|
| 39 | + | * config.h file. These arrays are kept static in event.o and tag.o |
|
| 40 | + | * respectively, because no other part of dwm needs access to them. |
|
| 41 | + | * |
|
| 42 | + | * The current mode is represented by the arrange function pointer which wether |
|
| 43 | + | * points to dofloat or dotile. |
|
| 4 | 44 | */ |
|
| 5 | 45 | ||
| 6 | 46 | #include "config.h" |