Re: [dwm] Making it a million and one
Dwm makes you understand what a wm is. Dwm is simple, practical, extremely fast and easy to use (with some hint). Dwm is pocket-sized and fashionable. Dwm is C and the rest. But I bet someone uses it 'cause it reminds ppl about those good ol' days. Dwm is the best. God save Dwm and Garbe. ... * yawhn * Goodnight Wyrmo 2009/2/18 Dusan : > It's C and I finally can understand what I do with window manager. You > should see me modifying xmonad and coding in haskell :( > Could not understand half of the stuff I pasted there. > > On Tue, 2009-02-17 at 17:37 -0600, Neale Pickett wrote: > > On 2/17/2009, "I. Khider" wrote: > >>I will say this, I love DWM though I do not completely understand it >>yet. It makes me feel like a man. > > Bwahahaha. Sometimes I wonder if that's the real reason any of us use > it. > > Neale "Chest Beatin'" Pickett > > >
Re: [dwm] android sloccount ~11 million
"omg" Wyrmskull 2008/11/7 Kai Hendry <[EMAIL PROTECTED]> >>Total Physical Source Lines of Code (SLOC)= 10,961,980
Re: [dwm] DWM as a front end for a test machine
If you realease it as a "live distro" we could have a minimal dwm environment under VirtualBox Xen or QEmu. You could run this environment even inside Windows, just to show a faster comparison. I always liked the idea of a minimal system with dwm to make people really feel the difference. Wyrmskull 2007/11/22, Amit Uttamchandani <[EMAIL PROTECTED]>: > Hey guys, > > I am preparing a presentation that would introduce a full Free Software Linux > system as a test machine for testing network devices. Right now, our company > is using windows based system with software such as HyperTerminal (yeah I > know), FileZilla ftp/ssh, firefox+bugzilla, tftp server. > > After using DWM, I realize Windows XP or even Mac OS X for that matter are > very inefficient for these kinds of testing (multiple windows open at once). > So I am planning to propose DWM on top of a simple Debian Etch system. Here > are the ideas I plan to put out: > > * DWM has multiple "desktops" (a.k.a tags) > - tags could include: bugzilla, syslog, com1, com2, ftp/ssh client, etc. > * Tiled mode provides a very effective work environment when working with > multiple applications at once. > * DWM is lightweight, secure, and fast... > > > I plan to do some comparisons on the cluttered XP desktop compared to an > efficient DWM desktop. > > Any other ideas or thoughts on getting this to be successfully implemented? > > Thanks, > Amit > >
[dwm] fluxbox like dmenu
I really like the classic fluxbox menu http://www.selflinux.org/selflinux/bilder/fluxbox_fluxbox-menu-ausschnitt.png Mouse support + appears under the mouse on rightclick on root or middleclick anywhere. I don't think I need any support for submenus. Is there any ready patch for dmenu to make it work like this? If there is not, I think I'll work it out myself somehow. It shouldn't be too complex. Wyrmskull
Re: [dwm] [PATCH] An experiment with X resources
Anselm R. Garbe wrote That's exactly the proposal I had sometime ago, but it scares me that it will bring unecessary complexity Rules already have to be written manually - instead of those you could use bash scripts. xterm --> echo "tag Xterm,2" | dwm This could cut the "rules" parts out. Keybindings could be moved to an external program too (xkeybind?). xkeybind ---> key ---> echo "tag focused_client,2" | dwm xkeybind ---> key ---> exec program Is this too much a radical change? I honestly think so. Nevermind, was just an idea. Wyrmskull
Re: [dwm] [PATCH] An experiment with X resources
Is there a way to make dwm execute commands at runtime through standard input? Would that be too complex? All functions should be there, it's just a matter of parsing user input. echo "set_statusbar string" | dwm normal behavior echo "tag XTerm,1,2,5" | dwm XTerm gets tags 1,2,5 DWM restart problem would be solved: you could save current state in a .dwmrc, then "cat .dwmrc" | dwm Wyrmskull
Re: [dwm] [PATCH] An experiment with X resources
I prefer the fast recompile-reload approach than the .Xresources one. It also works if you edit other source files. All config.h files could be put in a "theme" directory and let a (su) bash script (+zenity,dmenu,gtk or whatever) select which is to be compiled. If the compile process goes wrong, the old DWM binary could be saved (28532 bytes) by the script to restore the old configuration, then prompt an error message - if you like this kind of automation. Should the process go well, the saved DWM is deleted. DWM launch time is almost unnoticeable to me, and I don't care if I have to wait a 7-8 seconds compile to change "theme". DWM relies on being short and simple - easy and fast to be compiled. What about having some default bash scripts keybinding? MODKEY | ShiftMask, XK_(F1 to F10), spawn, "exec bash_script_(01 to 10).sh" 0 byte files don't take too much space, 0 LOC, and can be edited runtime. You can add "edit_keybind_(F1 to F10)" dmenu entries and a "change theme" one. I think that DWM is ready to face those problems. You just need the right external tools. Wyrmskull
Re: [dwm] arguments don't work with default dmenu command
I label the dmenu entries, then I write a oneliner for each from my config.h (bound to a keyboard shortcut) exec /home/wyrmskull/scripts/dmenu.sh from ~/scripts/dmenu.sh #!/bin/bash RESULT=$( cat /home/wyrmskull/scripts/.dmenu | dmenu ) case "$RESULT" in "appwithargs")exec app with args and whatever;; [...] esac from ~/scripts/.dmenu firefox [...] Wyrm Xavier wrote: In config.arg.h and config.default.h , dmenu is run like this : exe=`dmenu_path | dmenu` && exec $exe This doesn't work for commands with arguments, eg "xterm -e top" or "import -w root root.png" or whatever. But running dmenu like this works fine (thanks to rob__ on #dwm for that hint ;) : exe=`dmenu_path | dmenu` && eval "exec $exe" Does it have any downsides? If not, maybe it could be done in both config.h examples.
Re: [dwm] start maximized patch
LordKrandel is my email account Wyrmskull 2007/7/27, Lord Krandel <[EMAIL PROTECTED]>: > I personally use my patch and I don't use the > separate-layout-for-each-tag patch. > > With my setup, I am free to open (ex.) a not maximized xcalc > in the xterm tag. > > I also thought of eradicating the tiled layout in a wipe-everything > raptus but I need that too much to text edit and code. > > > 2007/7/27, Szabolcs Nagy <[EMAIL PROTECTED]>: > > On 7/27/07, Jeremy O'Brien <[EMAIL PROTECTED]> wrote: > > > Do you use this personally? Just curious. I couldn't find a logical > > > place I'd ever need to use such a layout. For me, it became hard to > > > manage all the windows I might have open on one view while only being > > > able to switch between them one at a time. Just looking for insight into > > > this. :) > > > > yes i use a fullscreen layout a lot > > i also have separate layout for each tag and almost always have a few > > tags with fullscreen layout > > > > fullscreen layout proved to be very useful when i have two windows on > > a tag (eg an editor and a shell) and i can quickly switch between them > > with focusnext() (mod+tab) > > similar feeling as in mc switching between the filemanager and the > > shell with ctrl-o (except mc has some anoying bugs there) if you know > > what i mean :) > > > > nsz >
