about summary refs log tree commit diff stats
path: root/dwm.html
blob: f816387cff73c114ece603a282c1ba399f85e70f (plain) (blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
<html>
	<head>
		<title>dwm - dynamic window manager</title>
		<meta name="author" content="Anselm R. Garbe">
		<meta name="generator" content="ed">
		<meta name="copyright" content="(C)opyright 2006 by Anselm R. Garbe">
		<style type="text/css">
			body {
				color: #000000;
				font-family: sans-serif;
				margin: 20px 20px 20px 20px;
			}
		</style>
	</head>
	<body>
		<center>
			<img src="dwm.png"/><br />
			<h3>dynamic window manager</h3>
		</center>
		<h3>Description</h3>
		<p>
		dwm is a dynamic window manager for X11.
		</p>
		<h4>Philosophy</h4>
		<p>
		As founder and main developer of wmii I came to the conclusion that
		wmii is too clunky for my needs. I don't need so many funky features
		and all this hype about remote control through a 9P service, I only
		want to manage my windows in a simple, but dynamic way. wmii never got
		finished because I listened to users, who proposed arbitrary ideas I
		considered useful. This resulted in an extreme <a
		href="http://www.jwz.org/doc/cadt.html">CADT</a> development model,
		which was a mistake. Thus the philosophy of dwm is simply <i>to fit my
		needs</i> (maybe yours as well). That's it.
		</p>
		<h4>Differences to ion, larswm, and wmii</h4>
		<p>
		In contrast to ion, larswm, and wmii, dwm is much smaller, faster and simpler.
		</p>
		<ul>
			<li>
			dwm has no Lua integration, no 9P support, no menu, no editable
			tagbars, no shell-based configuration, no remote control, and comes
			without any additional tools like printing the selection or warping
			the mouse.
			</li>
			<li>
			dwm is only a single binary, it's source code is intended to never
			exceed 2000 SLOC.
			</li>
			<li>
			dwm is based on tagging and dynamic window management (however
			simpler than ion, wmii or larswm). It manages windows in
			tiling and floating modes. Either mode can be applied dynamically,
			depending on the application in use and the task performed.
			</li>
			<li>
			dwm don't distinguishes between layers, there is no floating or
			tiled layer. Wether the clients of currently selected tag are in
			tiled mode or not, you can re-arrange all clients on the fly.
			Popup- and fixed-size windows are treated floating, however. 
			</li>
			<li>
			dwm is customized through editing its source code, that makes it
			extremely fast and secure - it does not process any input data
			which hasn't been known at compile time, except window title names
			and status text read from standard input. You don't have to learn
			Lua/sh/ruby or some weird configuration file format (like X
			resource files), beside C to customize it for your needs,
			you <b>only</b> have to learn C (at least editing header files).
			</li>
			<li>
			Because dwm is customized through editing its source code, it's
			pointless to make binary packages of it. This keeps its userbase
			small and elitist. No novices asking stupid questions.
			</li>
			<li>
			dwm uses 1-pixel borders to provide the maximum of screen real
			estate to clients. Small titlebars are only drawn in front of
			unfocused clients.
			</li>
			<li>
			dwm reads from standard input to print arbitrary status text (like
			the date, load, battery charge). That's much simpler than
			larsremote, wmiir and what not...
			</li>
			<li>
			It can be downloaded and distributed under the conditions
			of the <a href="http://10kloc.org/cgi-bin/hgwebdir.cgi/dwm?f=f10eb1139362;file=LICENSE;style=raw">MIT/X Consortium license</a>.
			</li>
		</ul>
		<h4>Links</h4>
		<ul>
			<li><a href="http://10kloc.org/cgi-bin/man/man2html?query=dwm">Man page</a></li>
			<li><a href="http://10kloc.org/shots/dwm-20060801.png">Screenshot</a> (20060801)</li>
			<li><a href="http://10kloc.org/download/poster.ps">A4 poster (PostScript)</a></li>
			<li>Mailing List: <a href="http://10kloc.org/cgi-bin/mailman/listinfo/dwm">dwm at wmii dot de</a> <a href="http://10kloc.org/pipermail/dwm/">(Archives)</a></li>
			<li>IRC channel: <code>#dwm</code> at <code>irc.oftc.net</code></li>
		</ul>
		<h3>Download</h3>
		<ul>
			<li><a href="http://10kloc.org/download/dwm-0.6.tar.gz">dwm 0.6</a> (14kb) (20060802)</li>
			<li><a href="http://10kloc.org/download/dwm-0.6.tar.gz">dmenu 0.1</a> (7kb) (20060803)</li>
		</ul>
		<h3>Development</h3>
		<p>
		dwm is actively developed in parallel to wmii. You can <a href="http://10kloc.org/cgi-bin/hgwebdir.cgi/dwm">browse</a> its source code repository or get a copy using <a href="http://www.selenic.com/mercurial/">Mercurial</a> with following command:
		</p>
		<p>
		<code>hg clone http://10kloc.org/cgi-bin/hgwebdir.cgi/dwm</code>
		</p>
		<p>
		<code>hg clone http://10kloc.org/cgi-bin/hgwebdir.cgi/dmenu</code>
		</p>
		<h3>Miscellaneous</h3>
		<p>
		You can purchase this <a href="https://www.spreadshirt.net/shop.php?op=article&article_id=3298632&view=403">tricot</a>
		if you like dwm and the dwm logo, which has been designed by Anselm.
		</p>
		<p><small>--Anselm</small></p>
	</body>
</html>
aduates learning abstract algebra. These procedures are written in ISETL, a language designed specifically to resemble formal mathematical notation. They come from an algebra course taught by Uri Leron. The procedures model the definition of a <EM>group</EM>, a mathematical structure made up of a set S and an operation o that satisfy certain requirements. Those requirements are tested by the procedures: <PRE> is_closed := func(S,o); return forall a,b in S | a .o b in S; end; is_associative := func(S,o); return forall a,b,c in S | (a .o b) .o c = a .o (b .o c); end; has_identity := func(S,o); return exists e in S | (forall a in S | e .o a = a); end; identity := func(S,o); return choose e in S | (forall a in S | e .o a = a); end; has_inverses := func(S,o); local e; e := identity(S,o); return is_defined(e) and forall a in S | (exists a' in S | a' .o a = e); end; </PRE> <P>I choose this advanced example to make the point that the difficulties of a ten-year-old learning the parts of speech is not so different from those of a twenty-year-old studying mathematics. In both cases, the curriculum consists of a series of technical terms (adjective in one case, associative in the other) and their meanings. If a teacher recites defnitions for these terms, the student can easily be confused or forget them later. But if each learner develops the ideas through experimentation, they are more likely to form a coherent framework. Programming languages are a vehicle for that experimentation. <H2>GUIs Versus Programming?</H2> <P>In the popular culture, a distinction is made between computer systems for programmers (DOS, Unix) and computer systems for non-programmers (Macintosh, Windows). Fans of the latter category are the ones who most strongly suggest that programming is obsolete as an activity for learners. <P>The dichotomy is false. The best software <EM>combines</EM> a graphical user interface with a powerful extension language. In the early days of Logo, the slogan was "No threshold, no ceiling." In modern vocabulary, this same idea is still relevant: "Simple things should be simple, and difficult things should be possible." <P>Here are my criteria for good interface design: <P>1. Commonly-used capabilities of the program should be accessible through graphical controls (by clicking on a button or moving a slider, for example) without programming. <P>2. Anything that can be done with a graphical control must also be doable from within a program in the extension language. <P>3. The algorithm for each graphical control should be accessible and modifiable using the extension language. <P>4. It should be possible for the user to install new graphical controls, with functions specified in the extension language. <P>5. The extension language should be a real, well designed programming language, not an ad hoc kludge. It should provide the capabilities of serious modern languages, such as dynamic memory allocation, functional programming, and object-oriented programming. <P>There are a few examples of such hybrid programs. AutoCAD, a program used by circuit designers, has a graphical interface with Lisp as an extension language. Michael Eisenberg has developed SchemePaint, a painting program with a conventional graphical interface backed up with Scheme as the extension language. For example, the SchemePaint user can define new brushes to add to the program's tool palette. Microworlds, the latest product from Logo Computer Systems, Inc., is an animated paint program with user extensions programmable in Logo. <P>As programs like these become more and more common, will the people who use them think of themselves as programmers? No doubt some will and some won't, but the ones who do will get the most benefit from their tools. <P><ADDRESS> <A HREF="index.html"><CODE>www.cs.berkeley.edu/~bh</CODE></A> </ADDRESS> </BODY> </HTML>