aewl

changeset 460:ab4b08d49d24

some more simplifications of intro comment in dwm.h, this should suffice for comments in dwm
author Anselm R. Garbe <arg@10kloc.org>
date Tue, 12 Sep 2006 09:50:06 +0200
parents 3c3f429dca99
children 9d23330a5268
files dwm.h
diffstat 1 files changed, 14 insertions(+), 20 deletions(-) [+]
line diff
     1.1 --- a/dwm.h	Tue Sep 12 09:46:19 2006 +0200
     1.2 +++ b/dwm.h	Tue Sep 12 09:50:06 2006 +0200
     1.3 @@ -5,30 +5,24 @@
     1.4   * dynamic window manager is designed like any other X client as well. It is
     1.5   * driven through handling X events. In contrast to other X clients, a window
     1.6   * manager like dwm selects for SubstructureRedirectMask on the root window, to
     1.7 - * receive events about child window appearance and disappearance.  Only one X
     1.8 + * receive events about window appearance and disappearance.  Only one X
     1.9   * connection at a time is allowed to select for this event mask.
    1.10   *
    1.11 - * Calls to fetch an X event from the event queue of the X connection are
    1.12 - * blocking.  Due the fact, that dwm reads status text from standard input, a
    1.13 - * select-driven main loop has been implemented which selects for reads on the
    1.14 - * X connection and STDIN_FILENO to handle all data smoothly and without
    1.15 - * busy-loop quirks. The event handlers of dwm are organized in an array which
    1.16 - * is accessed whenever a new event has been fetched. This allows event
    1.17 - * dispatching in O(1) time.
    1.18 + * Calls to fetch an X event from the X event queue connection are blocking.
    1.19 + * Due reading status text from standard input, a select-driven main loop has
    1.20 + * been implemented which selects for reads on the X connection and
    1.21 + * STDIN_FILENO to handle all data smoothly and without busy-loop quirks. The
    1.22 + * event handlers of dwm are organized in an array which is accessed whenever a
    1.23 + * new event has been fetched. This allows event dispatching in O(1) time.
    1.24   *
    1.25 - * Each child window of the root window is called a client in window manager
    1.26 - * terminology, except windows which have set the override_redirect flag.
    1.27 - * Clients are organized in a global doubly-linked client list, the focus
    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. All clients which have at least one tag enabled of the current
    1.32 - * tags viewed, will be visible on the screen, all other clients are banned to
    1.33 - * the x-location x + 2 * screen width.  This avoids having additional layers
    1.34 - * of workspace handling.
    1.35 + * Each child of the root window is called a client, except windows which have
    1.36 + * set the override_redirect flag.  Clients are organized in a global
    1.37 + * doubly-linked client list, the focus history is remembered through a global
    1.38 + * stack list. Each client contains an array of Bools of the same size as the
    1.39 + * global tags array to indicate the tags of a client.  For each client dwm
    1.40 + * creates a small title window which is resized whenever the WM_NAME or
    1.41 + * _NET_WM_NAME properties are updated or the client is resized.
    1.42   *
    1.43 - * For each client dwm creates a small title window which is resized whenever
    1.44 - * the WM_NAME or _NET_WM_NAME properties are updated or the client is resized.
    1.45   * Keys and tagging rules are organized as arrays and defined in the config.h
    1.46   * file. These arrays are kept static in event.o and tag.o respectively,
    1.47   * because no other part of dwm needs access to them.  The current mode is