added a general comment to dwm.h how dwm is basically organized
This commit is contained in:
		
							parent
							
								
									868159fd0a
								
							
						
					
					
						commit
						e6cc22396a
					
				
							
								
								
									
										40
									
								
								dwm.h
									
									
									
									
									
								
							
							
						
						
									
										40
									
								
								dwm.h
									
									
									
									
									
								
							| @ -1,6 +1,46 @@ | ||||
| /*
 | ||||
|  * (C)opyright MMVI Anselm R. Garbe <garbeam at gmail dot com> | ||||
|  * See LICENSE file for license details. | ||||
|  * | ||||
|  * dynamic window manager is designed like any other X client as well. It is | ||||
|  * 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. | ||||
|  * | ||||
|  * Calls to pop 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 | ||||
|  * dispatching in O(1) time. | ||||
|  * | ||||
|  * Each child window of the root window is called a client in window manager | ||||
|  * terminology, except windows which have set the override_redirect flag. | ||||
|  * Clients are organized in a global doubly-linked client list, the focus | ||||
|  * 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. | ||||
|  * | ||||
|  * For each client dwm creates a small title window which is resized whenever | ||||
|  * the WM_NAME or _NET_WM_NAME properties are updated. | ||||
|  * | ||||
|  * 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.  | ||||
|  */ | ||||
| 
 | ||||
| #include "config.h" | ||||
|  | ||||
		Loading…
	
	
			
			x
			
			
		
	
		Reference in New Issue
	
	Block a user
	 Anselm R. Garbe
						Anselm R. Garbe