MCorange/dwm
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

patched dwm

Browse Source
This commit is contained in:
Anselm R. Garbe 2006-07-17 11:36:07 +02:00
parent ed41473634
commit eb184e02ea
3 changed files with 47 additions and 31 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
config.mk
View File

@ -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
View File

@ -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
View File

@ -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)