patched dwm
parent
ed41473634
commit
eb184e02ea
|
@ -8,7 +8,7 @@ MANPREFIX = ${PREFIX}/share/man
|
|||
X11INC = /usr/X11R6/include
|
||||
X11LIB = /usr/X11R6/lib
|
||||
|
||||
VERSION = 0.2
|
||||
VERSION = 0.3
|
||||
|
||||
# includes and libs
|
||||
LIBS = -L${PREFIX}/lib -L/usr/lib -lc -L${X11LIB} -lX11
|
||||
|
|
2
dwm.1
2
dwm.1
|
@ -90,7 +90,7 @@ Lock
|
|||
.B Control-[0..n]
|
||||
Append
|
||||
.B nth
|
||||
tag to cureent
|
||||
tag to current
|
||||
.B window
|
||||
.TP
|
||||
.B Control-Button1
|
||||
|
|
74
dwm.html
74
dwm.html
|
@ -28,58 +28,74 @@
|
|||
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.
|
||||
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>
|
||||
<h3>Differences to wmii</h3
|
||||
<h3>Differences to ion, larswm, and wmii</h3>
|
||||
<p>
|
||||
In contrast to wmii, dwm is only a window manager, and nothing else.
|
||||
Hence, it is much smaller, faster and simpler.
|
||||
In contrast to ion, larswm, and wmii, dwm is much smaller, faster and simpler.
|
||||
</p>
|
||||
<ul>
|
||||
<li>
|
||||
dwm has no 9P support, no editable tagbars, no shell-based
|
||||
configuration and remote control and comes without any additional
|
||||
tools like printing the selection or warping the mouse.
|
||||
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 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.
|
||||
</li>
|
||||
<li>
|
||||
dwm is based on tagging and dynamic window management (however simpler
|
||||
than wmii or larswm).
|
||||
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
|
||||
managed layer. Wether the clients of currently selected tag are
|
||||
managed or not, you can re-arrange all clients on the fly. Popup-
|
||||
and fixed-size windows are treated unmanaged.
|
||||
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.
|
||||
</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.
|
||||
estate to clients. Small titlebars are only drawn in front of
|
||||
unfocused clients.
|
||||
</li>
|
||||
<li>
|
||||
dwm reads from <b>stdin</b> to print arbitrary status text (like the
|
||||
date, load, battery charge). That's much simpler than larsremote,
|
||||
wmiir and what not...
|
||||
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>
|
||||
Anselm <b>does not</b> want any feedback to dwm. If you ask for support,
|
||||
feature requests, or if you report bugs, they will be <b>ignored</b>
|
||||
with a high chance. dwm is only intended to fit Anselms needs.
|
||||
However you are free to download and distribute/relicense it, with the
|
||||
conditions of the <a href="http://wmii.de/cgi-bin/hgwebdir.cgi/dwm?f=f10eb1139362;file=LICENSE;style=raw">MIT/X Consortium license</a>.
|
||||
dwm is only intended to fit Anselms needs. That means, Anselm
|
||||
<b>does not</b> want feedback to dwm. If you ask for support,
|
||||
feature requests, or if you report "bugs" (<i>real bugs are welcome
|
||||
though</i>), they will be <b>ignored</b> with a high
|
||||
chance. However you are free to download and distribute/relicense
|
||||
it, with the conditions of the <a
|
||||
href="http://wmii.de/cgi-bin/hgwebdir.cgi/dwm?f=f10eb1139362;file=LICENSE;style=raw">MIT/X Consortium license</a>.
|
||||
</li>
|
||||
</ul>
|
||||
<h3>Documentation</h3>
|
||||
There is a <a href="http://wmii.de/cgi-bin/man/man2html?query=dwm">man page</a>.
|
||||
<h3>Screenshot</h3>
|
||||
<p>
|
||||
<a href="http://wmii.de/shots/dwm-20060714.png">Click here for a screenshot</a> (20060714)
|
||||
|
|
Loading…
Reference in New Issue