Re: [dwm] Problem with notify-send from acpi events
On May 3, 2009, at 3:12 PM, Preben Randhol wrote: I have setup my Asus Eee to run commands when I press the function keys (like power up/down etc...) In these scripts I'm running notify-send to get a small window to give a message (like touchpad off etc...). The scripts are run from acpid. For some strange reason when I use dwm, the notify window doesn't show up. If I program dwm to run the script, I get the window. If I run the script manually from xterm as either user or root I get the window. If I start xfce4 in stead of dwm I get the window when acpid starts the script. Maybe you need to launch notification-daemon from .xsession or make sure you run notify-send as the correct user from acpid? I assume that DBus messages are handled separately for each user... Also, if you are only using libnotify to respond to keypresses, you may want to check out dzen2. The code sucks somewhat (I think there's at least one function with 1k LOC), but it doesn't suck up 3M of RAM at all times like notification-daemon does.
Re: [dwm] [ANNOUNCE] dvtm-0.5
On Jan 29, 2009, at 8:54 PM, bill lam wrote: On Thu, 29 Jan 2009, Donald Chai wrote: You can replace that line with: ESCDELAY = esc_delay; Thanks! I found 2 further issues 1. on my ubuntu, $TERM is xterm (actually it is 256 color), but dvtm cannot detect it and makes it a 8 (or 16?) color rxvt. You probably need to set TERM to xterm-256color. If 'infocmp xterm' says you have 8 colors, ncurses and dvtm will think your terminal only supports 8 colors. If you don't have the proper terminfo files, then be prepared for some fun with 'infocmp' and 'tic'. 2. if start dvtm from dmenu typing xterm -e dvtm there is always an extra ^Z placed in ttyin so that when I start to type any character, the ^Z appear and I have to delete it, However if I start dvtm from xterm, it is OK. Change config.mk to use ncursesw (LIBS_UTF8).
Re: [dwm] [ANNOUNCE] dvtm-0.5
On Jan 30, 2009, at 6:43 AM, bill lam wrote:
On Fri, 30 Jan 2009, Donald Chai wrote:
On Jan 29, 2009, at 8:54 PM, bill lam wrote:
1. on my ubuntu, $TERM is xterm (actually it is 256 color), but
dvtm
cannot detect it and makes it a 8 (or 16?) color rxvt.
You probably need to set TERM to xterm-256color. If 'infocmp xterm'
says you have 8 colors, ncurses and dvtm will think your terminal
only
supports 8 colors. If you don't have the proper terminfo files,
then be
prepared for some fun with 'infocmp' and 'tic'.
After install terminfo for xterm-256color,
echo $TERM inside xterm now gives xterm-256color, but after enter
dvtm,
echo $TERM now gives rxvt-256color, why not xterm-256color?.
Moreover colors are displayed incorrectly. This is worse than using
the previous xterm setting.
So you mean that if you run the following shell command both outside
and inside dvtm, you get different results?
for i in `seq 1 64`; do echo -e \e[38;5;${i}mXXX; done
The colors *should* match. If not, that's a bug.
TERM is set to rxvt or rxvt-256color because those are the escape
sequences interpreted by madtty.c. If you have code that absolutely
must have TERM=xterm, I think it's sufficient to modify keytable in
that file.
2. if start dvtm from dmenu typing xterm -e dvtm there is always
an
extra ^Z placed in ttyin so that when I start to type any
character, the ^Z appear and I have to delete it,
However if I start dvtm from xterm, it is OK.
Change config.mk to use ncursesw (LIBS_UTF8).
I already built with unicode
$ldd dvtm
linux-vdso.so.1 = (0x7fffa7ffe000)
libc.so.6 = /lib/libc.so.6 (0x7f869f99c000)
libutil.so.1 = /lib/libutil.so.1 (0x7f869f799000)
libncursesw.so.5 = /lib/libncursesw.so.5 (0x7f869f552000)
/lib64/ld-linux-x86-64.so.2 (0x7f869fd0e000)
libdl.so.2 = /lib/libdl.so.2 (0x7f869f34e000)
There seems to be some sort of race condition between SIGWINCH being
raised and some other magic. I personally use rxvt-unicode (which
works fine with urxvt -e dvtm) and only ever use dvtm on remote
computers, so I'm not inclined to dig any deeper into this.
Re: [dwm] [ANNOUNCE] dvtm-0.5
On Jan 29, 2009, at 12:49 AM, bill lam wrote: In commit sha1 a107d3 it added a call to an undeclared set_escdelay, and it fails to compile. Is that a known issue? You can replace that line with: ESCDELAY = esc_delay; By default, ncurses waits a long time to interpret escape sequences, which causes problems if you use vi and type faster than a snail, so this call reduces this delay. A more portable fix is to simply use the ESCDELAY environment variable when running dvtm: $ ESCDELAY=1 ./dvtm
Re: [dwm] dwm and dualhead
On Dec 11, 2008, at 2:32 AM, Kai Großjohann wrote: Anselm R Garbe wrote: I tried different multihead approaches in between 4.9 and 5.1 with dwm. I remember the following: [...] You haven't mentioned my favorite approach: Currently, each tag is visible or hidden. Change this so that a tag can be visible on a specific screen. Showing a tag on a screen that is already visible on another screen hides it from that other screen. Thus, a tag is visible on at most one screen. This relates to the difference between dwm-gtx and awesome that I noted earlier. You're suggesting that each screen view a different set of tags, while currently dwm uses the same tag for all screens. Windows can freely move between screens by just showing its tag on another screen. This might be suitable for a dynamic window manager, but I personally find that it's too dynamic for my taste, cf. Mate's comment about windows jumping between screens. Matches my mental model of tags: a tag is a collection of windows that are semantically related and needed for a task. Sometimes I wish to work on a task on one screen, sometimes on the other. For example: I have a development task and a information reading task (web browser + mail client). If I am currently focusing on development, then it might be useful to browse the web or read some mail on the secondary screen. However, when I am actively working on email, then I might wish to do that on the primary screen. What if a single task requires two screens? I'm doing some writing right now, and I use one screen for gvim and the other for xpdf (the LaTeX output). I have multiple writing tasks to switch between, so for me, it makes sense to associate both screens with a single tag. I don't think there will be a consensus over multihead behavior. I propose that we just agree on a few structs and global variables, and then just supply our own layouts (as we've already been doing for the singlehead case). To simplify the code for those not blessed with multiple monitors, maybe we should assume a single tagset and layout to be used for both screens?
Re: [dwm] dwm and dualhead
On Dec 10, 2008, at 9:05 AM, Johannes Wegener wrote: is there anybody who has experience with dwm and dualhead setups? I tried to use dwm with a xrandr dualhead but it seemed quite useless becouse I could just drag floating windows into the second screen. Xinerama seems no more supported by xorg 7.4 and the intel driver. I think people on this have lately been confusing dualhead with Xinerama. Someone asked about this earlier, and he just wanted to clone screens. In any case, suppose we have two 1024x768 monitors, we can use them in two ways: MODE 1 - Two X displays, :0.0 and :0.1, each 1024x768 - This is sometimes called Zaphod mode. - This mode sucks because you can't move windows from one screen to the other. - This mode is not supported by the intel driver. MODE 2 - One merged display, :0.0 which is 2048x768 or 1024x1536 (your choice) - If I understand correctly, this is Xinerama or mergedFB or TwinView mode. - This requires help from the window manager. - Xrandr lets you switch between 2048x768 and 1024x1536 without restarting X. It's fantastic. You can compile dwm without Xinerama support (#undef XINERAMA) and use Xorg with MODE 2. You end up with one giant display. If you compile with -DXINERAMA, you have what you've described, where the second screen is used for floating windows. Xinerama support just means that dwm knows that the giant display consists of two screens, and can avoid using dead space if the screens are different sizes. When people say that xorg is dropping Xinerama support, I believe it's the Xinerama implementation that's being dropped, not the API or wire protocol. XineramaQueryScreens() works correctly on my netbook with xorg 7.3 and intel driver. With that out of the way, I'd suggest you look at dwm-gtx. I tried it on my Acer Aspire One (with intel 945), and it worked well. The difference between dwm-gtx and awesome (besides code bloat) is that awesome manages tags for each screen independently. If I press MOD-1 in awesome, it switches the tag on the current screen. In dwm-gtx, it switches both screens.
Re: [dwm] dwm-5.3
On Dec 6, 2008, at 10:20 AM, Guillaume Quintin wrote: Why don't we change the way dwm gets its status text ? For example we could use the SIGALRM signal to call a spawn2 : --snip-- This will take only a few LOC, because all the reading p[0] part will be in fact the reading-stdin code from the run() function which will not be needed anymore. This has the advantages that one can change the status when dwm is running and there are no more quitting problem. This is just an idea, forgive me not to propose some real code. Well tell me what you think of this idea. I'm not sure that changing the status script when dwm is running is a big advantage. I'm already used to recompiling if I want to change any setting. :) The disadvantage of this approach is that the status script would have to do a lot of work to maintain any state. Most people run date, acpi and other commands once a second, this would be fine for them. My status text includes the weather (updated only every 15min to avoid hammering their servers), and the time (updated once a minute, on the minute, to reduce my wakeups-per-second in PowerTOP). For me, this SIGALRM and spawn2 would require that I store some temporary data somewhere between invocations. Here's my status script in case anyone would be interested. It basically merges different status areas with arbitrary update intervals for each. status.lua Description: Binary data
Re: [dwm] dwm-5.3
On Dec 6, 2008, at 1:02 PM, Guillaume Quintin wrote: This is a little very basic patch that does what I asked above. I tried this using the SIGALRM signal but I randomly got fatal errors about memory (un)locks. Your code looks like an idle loop; I recommend you read the man page for select(). The last argument is a timeout, which is what you want to use instead of alarm(1), and will avert the random errors.
Re: [dwm] DWM 5.3.1 and Xinerama
On Dec 6, 2008, at 10:32 PM, Amit Uttamchandani wrote: On Sun, 7 Dec 2008 01:14:45 -0500 Jeremy Jay [EMAIL PROTECTED] wrote: If you are using a recent version of xorg, and don't have your screen resolution hardcoded in xorg.conf, it should be autodetected. For example, the last time I had to do a presentation, I plugged in the projector, restarted X, and it auto-detected the right resolution to use. Jeremy Yeah I think its quite recent. I'm using debian lenny and xorg 7.3 and xserver-xorg-core 1.4.2. I will try what you said and restart xserver...And how does dwm behave in this case? does it just mirror the screen? BTW, restarting X is not necessary: the *whole purpose* of Xrandr is to avoid doing this. Just plug in your external display and run xrandr --output VGA --auto or whatever your external display is called. dwm is already set up to receive configure events, and will do The Right Thing.
Re: [dwm] make setlayout toggle
On Wed, Nov 5, 2008 at 1:39 AM, Anselm R Garbe [EMAIL PROTECTED] wrote: Ok, are there any concerns making this upstream again? (Yes I know, we had this already in earlier versions, by that time it was called togglelayout())... There were reasons for not toggling, basically it was confusing to toggle the layout after a long period of time, because one forgets about what the previous layout was. I think the behavior in vanilla dwm sucks less: - press MOD+1 to view tag 1 - press MOD+1 again = no-op - press MOD+TAB to view previously selected tag - press MOD+m to set monocle layout - press MOD+m again = no-op - press MOD+space to use previously selected layout The proposed change would add inconsistency, unless if people want the second MOD+1 to jump to the previously selected set of tags or do some other weird thing. Then again, I only ever switch between two layouts, and only use MOD+space.
Re: [dwm] patch to not reparent children to init
On Tue, Nov 4, 2008 at 9:09 AM, Neale Pickett [EMAIL PROTECTED] wrote: Reparenting everything to init with the double-fork is a nightmare on a many-user machine, especially when I'm logged in more than once. pstree becomes useless. This sets up a SIGCHLD handler and only forks once. Adds 2 SLOC, but surely there's some reason the double-fork is there that I'm just missing... If you quit dwm, what happens to any programs that you've launched? Are they killed? What happens if you suddenly decide to manage all your windows with a different window manager?
Re: [dwm] [dvtm] testing current git HEAD aka dvtm-0.5-rc1
On Oct 10, 2008, at 1:36 AM, Marc Andre Tanner wrote: On Wed, Oct 08, 2008 at 05:44:31PM -0700, Donald Chai wrote: On Wed, Oct 8, 2008 at 4:44 PM, Charlie Kester [EMAIL PROTECTED] wrote: I assume the question concerns the new scripting support in dvtm. Originally I was excited by the addition of this feature and downloaded the tip right away. But since then, I've scarcely used it. So I won't object if the default is to leave it disabled. Maybe if there were a list of sample scripts... The only usage that I can think of is to have VIM open a manpage in a new window using the 'K' key, as opposed to in the same window. I agree that the main usage is opening new windows. For example when mutt displays an email which contains a url it could launch a text browser in a new window. I was also asked if there is a way to detect whether the shell startup script is running within dvtm. So i might introduce an envrionment variable DVTM which contains the current version. Or the PID of the innermost dvtm instance? GNU screen lets me run commands without me having to specify a FIFO. I just run screen -X cmd. It seems they use variables PPID and STY.
Re: [dwm] [dvtm] testing current git HEAD aka dvtm-0.5-rc1
On Wed, Oct 8, 2008 at 4:44 PM, Charlie Kester [EMAIL PROTECTED] wrote: I assume the question concerns the new scripting support in dvtm. Originally I was excited by the addition of this feature and downloaded the tip right away. But since then, I've scarcely used it. So I won't object if the default is to leave it disabled. Maybe if there were a list of sample scripts... The only usage that I can think of is to have VIM open a manpage in a new window using the 'K' key, as opposed to in the same window.
Re: [dwm] Floating children
On 9/28/08, Carlos Pita [EMAIL PROTECTED] wrote: I use a vanilla dwm, without any layout per tag facility. I like it this way but still some clients are cumbersome to manage. Which version of dwm? For example fluid, the gui designer for fltk, which follows the gimp and gaim ugly paradigm of presenting a number of floating windows. I can add a rule for floating its main window, based on its class. But the child windows has no class or instance properties that can be ruled as floating, and the titles are unmatcheable without regexp Is this fluid or fluid2? Fluid2 and dillo-fltk seem to work ok with dwm5.2, except for an annoying tendency to not give up focus if the pointer is over them. Under awesomewm (and older dwms), transient windows stick around like zombies.
Re: [dwm] move/resize keyboard control
On Sep 28, 2008, at 6:50 AM, bill lam wrote: On Sat, 27 Sep 2008, Donald Chai wrote: On Sep 27, 2008, at 5:26 AM, Tinou wrote: awesomewm (and my dwm) move windows within the clients list instead of turning on 'floating', and I very much prefer it that way. Interesting feature, could you send a patch ? This patch is against dwm-5.2. Excuse me, I'm not quite understand what patch will do. Does it related to keyboard control of window? Would anyone give more detail? Try moving tiled windows with the mouse. (Make sure there are multiple windows on screen.) It should look like this: http:// en.wikipedia.org/wiki/Sliding_puzzle
Re: [dwm] Help with grid layout
On Sep 28, 2008, at 12:37 PM, Valentin wrote: Hi, can somebody tell me how to change the latest grid layout patch to put the clients in two columns and one row instead of two rows and one column when there are only two clients in a tag? [1] The current way of doing it isn't very nice on widescreen monitors... Change the follow block in grid(): + /* grid dimensions */ + for(rows = 0; rows = n/2; rows++) + if(rows*rows = n) + break; + cols = (rows (rows - 1) * rows = n) ? rows - 1 : rows; Where it says 'rows', it should say 'cols', and vice versa. But really, this also sucks if you have 100 windows, as it forces a 10x10 grid regardless of screen dimensions. Something like: k= some constant, maybe mfact? rows = (int) floor(sqrt(n * k)); cols = (int) ceil((double) n / rows); is both cleaner and more general, IMHO.
Re: [dwm] move/resize keyboard control
On Sun, Sep 28, 2008 at 4:26 PM, Claudio [EMAIL PROTECTED] wrote: It's a more logical and useful approach, indeed. Though i rarely use layouts other than monocle. Since i use dvtm i don't have more than a terminal in a tiled tag anymore but all the terminals has been moved to one dvtm session and the rest (iceweasel, aMSN, etc.) is floating or maximized, so i don't need such feature at all. OTOH i wouldn't have its opposite feature: auto-floating when move a tiled client. This mean that i prefer to have this patch in mainstream instead of the current implementation. I'm perfectly happy keeping this out of the trunk, but I think the auto-floating behavior really needs to go. BTW, changeset 1213:368a80dcf5bd makes auto-float active only when snap is nonzero, which I believe is a mistake. (offtopic) I find it strange how many people use dwm mostly for monocle-mode. I used Ratpoison for years because I assumed that any alternative would require that I install gkrellm, turn on fake transparency in my xterms, and use some sci-fi wallpaper. Finally I got fed up with Ratpoison because you need to deal with its awkward frames if you don't want a monocle-mode. The irony is that it's 16k lines of code, but has fewer useful (to me) features than dwm. Anyway, thanks Anselm, for keeping dwm clean and hackable!
Re: [dwm] move/resize keyboard control
On Sep 26, 2008, at 12:00 AM, Claudio wrote: Your version of the function works properly, it's better to use array of integers, indeed, and the focus is now under control. Though i don't want to toggle the window floating automatically and i prefer to check for arg and arg-v before to use it. --snip-- I still use moveresize since it's a wrapper for the resize() function not strictly related to the keyboard. Isn't? THX for your help, dwm is going to be perfect for me. I concur, and would go as far as to suggest that maybe: 1) if the window is not floating, move it around the clients list or update mfact, and 2) this all get unified with movemouse and resizemouse. awesomewm (and my dwm) move windows within the clients list instead of turning on 'floating', and I very much prefer it that way.
Re: [dwm] classname of java
On Sep 23, 2008, at 2:55 AM, bill lam wrote: Hello, I want to set java programs to float in config.h, Does anyone know what the classname of sun java/openjdk java as that reported by XGetClassHint? You can get classnames (and other useful information) using the 'xprop' program.
Re: [dwm] dvtm suggestion
On Sep 16, 2008, at 9:16 AM, [EMAIL PROTECTED] wrote: --snip-- The best way to cope with this seems to me to be a key binding for switching on/off grabbing MOD in dwm. Say, MOD-g, like in - MOD-3 // goto tag 3, where the dvtm terminal is running - MOD-G // stop grabbing MOD - MOD-j,k,... // do what I want in dvtm with the dwm/dvtm key bindings - MOD-G // (uppercase G!=g dvtm grid layout) start grabbing MOD - MOD-. // back in dwm world Well, _not grab_ is perhaps better said _pass through_, I don't know ... Does this sound meaningful? Is it doable without much overhead? Probably, but it's most likely unnecessary. All you really need to do is set dwm up to use Mod4 and MODKEY, and add two keybindings: Mod4+G - xmodmap -e remove mod4 = Alt_L -e add mod1 = Alt_L Mod1+G - xmodmap -e remove mod1 = Alt_L -e add mod4 = Alt_L Replace Alt_L with whatever key(s) you want to multiplex.
Re: [dwm] dwm + xft
On Sep 12, 2008, at 1:38 AM, Antoni Grzymala wrote: Donald Chai dixit (2008-09-11, 22:34): Just specify multiple font patterns in config.h, separated by commas: static const char font[] = -*-fixed-medium-r-normal-*-12-*-*-*-*-*-*-*,-*-ukai-*-r-normal--*- *-*-*-*-* ; What does this syntax actually mean? Does it mean that X will look for glyphs in the following two fonts and stop whenever it will find a font with a necessary glyph? Yes, basically. The manpage for XCreateFontSet provides more details. (I only figured this out yesterday after I already implemented my pango patch.) I hope http://theka.tk/fuckup-1.png gets fixed. Caveat: if any of the patterns doesn't exist on the system, X may just revert to some default. E.g. I tried font[] = -*-terminus-*-*-*- *-12-*-*-*-*-*-*-*,-*-ukai-*-r-normal--*-*-*-*-*-* and I think X completely ignored 'ukai' because I don't have 'terminus' on my system. Filippo, if you're listening: This probably would be good to put in http://www.suckless.org/dwm/ customisation/font.html
Re: [dwm] dwm + xft
On Sep 11, 2008, at 8:14 PM, bill lam wrote: On Thu, 11 Sep 2008, Donald Chai wrote: I tried adding pango+xft support because bitmap CJK fonts suck, and also Sorry for my ignorance. The chinese font on my FF3 now looks ugly while it previously looks quite good using ukai under gnome. Does this patch fix all related font issue for programs run under dwm, or this patch only fix the font issue that appeared in the top statusbar? I hope the font in your statusbar looks okay, at least. :) The patch is to improve the fonts in the statusbar, and isn't supposed to affect fonts in other applications. If it does, then it's probably a bug. By looks ugly do you mean it's rendered with a different font, or that the font is improperly rendered? I've checked with rxvt-unicode and FF2 (Iceweasel), and everything looks fine. If I go to http://zh.wikipedia.org/wiki/孙燕姿, the statusbar and the FF2 text look fine. I can't run FF3 without upgrading all my libraries. I'll try to check again when I get to my machine running Debian testing. Note: 1) I only cracked open the Pango/Xft manuals yesterday. 2) My LANG is set to en_US.UTF-8 3) Arphic UKai is the only Chinese font I have installed Unfortunately, I can't do much to help you. Firefox doesn't seem to respond to the XFT_DEBUG environment variable, and I still can't figure out why FreeType renders Lucida Console differently on Mac and Linux.
Re: [dwm] dwm + xft
On Sep 11, 2008, at 9:54 PM, bill lam wrote: On Thu, 11 Sep 2008, Donald Chai wrote: bug. By looks ugly do you mean it's rendered with a different font, or that the font is improperly rendered? look like 15x16 character printed on an old dot-matrix printer. I've checked with rxvt-unicode and FF2 (Iceweasel), and everything looks fine. If I go to http://zh.wikipedia.org/wiki/孙燕姿, the statusbar and the FF2 text look fine. Not yet applied your patch, dwm display this on the statusbar Ko1m;Q - N,4pI42J!$+3E*I42JA4Ji I use en_HK.UTF8, I tried use some X11 chinese font but it still display rubbish on the statusbar for chinese title. Is there any method to display cjk font on the statusbar just using the X11 fonts? Just specify multiple font patterns in config.h, separated by commas: static const char font[] = -*-fixed-medium-r-normal-*-12-*-*-*-*-*- *-*,-*-ukai-*-r-normal--*-*-*-*-*-* ; They will look like characters printed on an old dot-matrix printer, which is why I bothered using pango. Try using awesome wm: http://awesome.naquadah.org/download/ If that works fine, then maybe I can try to learn from them.
Re: [dwm] patch: fix screen flicker with monocle
On Sep 8, 2008, at 2:09 AM, Anselm R Garbe wrote: 2008/9/8 Donald Chai [EMAIL PROTECTED]: Actually, this is a totally unrelated problem. The problem is that XGrabKeyboard generates focus events (XGrabKeyboard is called by the X server after establishing the passive grab with XGrabKey). So, all keyboard shortcuts cause the window under the mouse to briefly get focus. I've used Metacity (the GNOME WM) with focus-follows-mouse, and it doesn't have this behavior when I Alt-Tab. I can't see why grabbing keys is an issue here. focus() only triggers a button grab on the old and new client which might causing this issue here. In Gnome WM you don't see this, because button grab's aren't necessary on a focus() basis, since it reparents the client windows and hence can keep the passive button grab for the whole lifetime of a client window on the frame window. So I fear, you/we have to live with this side effect. I find it strange that the extra focus events only happen for me; or maybe I'm just the only one who's bothered by it. (I see the same thing in wmii and awesome too.) From looking at the ion2 code, I figured out that XGrabKey with grab_window=root is the cause of the problem. If I instead call XGrabKey on all of root's children, no spurious focus events are generated. The following patch seems to fix things. I add my own background layer to capture keypresses, so xsetroot - bg will no longer work. :( grabkeyfix.patch Description: Binary data
Re: [dwm] patch: fix screen flicker with monocle
On Sep 6, 2008, at 1:25 AM, Anselm R Garbe wrote: 2008/9/3 Donald Chai [EMAIL PROTECTED]: I'm sure there might be other problems I created...I don't understand the X11 event model at all. Yes you did. It is important to showhide() before focus and restack handling. I also slightly changed your initial showhide() version. See hg tip for reference. You're right. For example, if my pointer is located over window A, and I use the keyboard to switch between windows B and C, window A briefly gets focus. Yes, this was because you performed showhide() after restack(). At the end of restack all enternotify's are flushed. Actually, this is a totally unrelated problem. The problem is that XGrabKeyboard generates focus events (XGrabKeyboard is called by the X server after establishing the passive grab with XGrabKey). So, all keyboard shortcuts cause the window under the mouse to briefly get focus. I've used Metacity (the GNOME WM) with focus- follows-mouse, and it doesn't have this behavior when I Alt-Tab.
Re: [dwm] what about 'st'?
I have found something quite useful when working with lot of terminals that is having different background colors depending on the task they are designed to be. But currently i just change the background color of vim and use this to differentiate them. another stuff would be like changing the background color of the terminal depending on the focus. I also like when my display looks like farmland when viewed from above. :) I see no terminal able to do this in a simple way. rxvt-unicode does this in a simple way. Look for resources 'fading' and 'fadeColor'. Unfortunately, XGrabKey(board) generates FocusOut and FocusIn events. If your mouse pointer is over window A, and you switch between windows B and C, window A will briefly change its background color like a visual bell (argh). The only workaround I can think of is to park the pointer over the statusbar when not in use. :(
[dwm] patch: fix screen flicker with monocle
Hi! The current arrange() procedure hides and shows windows in the order specified by clients. This causes a lot of flicker and unnecessary screen redraws when there are many overlapping windows whose stacking order is different from clients, i.e. when using monocle or floating layouts. This patch fixes that behavior. monoclefix.patch Description: Binary data
Re: [dwm] dvtm suggestion
- The implementation of tagging is contrary to the suckless philosophy: http://www.suckless.org/common/ I agree, however this is because the various functions take char* arrays instead of an Arg union. This makes it impossible to specify bit masks. We could of course change this but it would break the new command interface[1]. umm...atoi()? :) - The focusn procedure takes away valuable key bindings that I use for tagging. I personally find this fast selection quite useful, but it's probably true that when your working with tags you have less windows per view and the quick selection is no longer that important. Another thing is that since I use dvtm when I can't use dwm, I have ALT-j cycle through windows, rather than CTRL-g j. So I don't ever have to punch in CTRL-g j CTRL-g j :) An unrelated comment: there's some code in madtty.c to work around some issue in PuTTY. It doesn't seem to make a difference for me (I use PuTTY), but perhaps a better solution is to call define_key from the frontend (i.e dvtm.c). Does this mean the keypad works for you within putty? The keypad works just fine without any hacks in dvtm. PuTTY just happens to be set up incorrectly by default. TERM is set to xterm, so one should just go to Terminal - Keyboard and set The Function keys and keypad to Xterm R6.
Re: [dwm] dwm: request to discuss
On Aug 28, 2008, at 1:12 PM, Maxim Vuets wrote:
The reason for the built-in status bar is simplicity. In theory it
would be
possible to externalize it, but then you would end up with adding
some
kind of command interface to dwm to aim the mouse interaction from
the bar. In the end externalizing the bar won't really be a
benefit, because
the modularized result will be more complex, and dwm might be
more complex.
Even if one considers a bar externalization as a shared object,
which is
loadable, this would introduce the need of a plugin API, which
won't provide
the same level of flexibility as hooking into the source code,
which allows
you everything.
I like simplicity. I like simple applications. But few LOCs don't
mean that
application is simple. It means only that it has few LOCs.
To be simple application must be simple in use, simple in
extensioning,
simple in hacking, simple in configurating. Application can be small
but sucks and vice versa.
I think that mouse is not really important for dwm status bar.
So we can neglect of such feedback.
I can not agree we you that shared libraries and some ABI is so bad.
But agree that it is too heavy for such program as dwm. It is useless
here. On the other hand, extending via code patching is wierd.
Especially when you need to apply more than one patch.
You might enjoy reading this interview with Don Knuth:
http://www.informit.com/articles/article.aspx?p=1193856
Basically, re-editable code is better than reusable code (to him).
In any case, an application can be: simple to extend, simple to hack,
simple to configure (can configure without patching/recompiling).
Pick two.
Why you trying to escape just two optional operations of nav.?
I'll try to explain my vision on an expamle.
You have such tags: www, mail, irc, im, dev.
The most time you spend on developing something.
But from time to time you want to check irc and mail, maybe serf smth.
And all the time you want to see your im client.
What you do? Untag www, mail, irc; tag dev; change layout; change
order of windows... ouch.
Now you have two workspaces/desktops: one for the Internet (irc, im,
www, mail), another one for a work (dev, im). The first has rstack
layout
with corresponding master width and windows order. The second has
bstack layout with an editor in master area and two terminals on the
bottom: one is tagged as dev (for output, debug...), another one is
tagged as im. Now you use just one key to change between these
desktops. Each one is comfortable for its purposes.
No need to rearrange windows and so on.
What version of dwm are you using?
dwm has had two workspaces/desktops since I've been using it
(admittedly not very long). Press MOD-Tab to switch between them.
This patch to hg tip will get you one layout per workspace:
--- a/dwm.c Wed Aug 27 12:52:44 2008 +0100
+++ b/dwm.c Thu Aug 28 14:06:07 2008 -0700
@@ -1280,8 +1280,6 @@
void
setlayout(const Arg *arg) {
- if(!arg || !arg-v || arg-v != lt[sellt])
- sellt ^= 1;
if(arg arg-v)
lt[sellt] = (Layout *)arg-v;
if(sel)
@@ -1657,7 +1655,7 @@
view(const Arg *arg) {
if((arg-ui TAGMASK) == tagset[seltags])
return;
- seltags ^= 1; /* toggle sel tagset */
+ sellt = seltags ^= 1; /* toggle sel tagset */
if(arg-ui TAGMASK)
tagset[seltags] = arg-ui TAGMASK;
clearurgent();
Re: [dwm] [dvtm] scrollback and 256color support
Thanks for the patches, scrollback is probably the most requested
dvtm feature. You introduced a separate buffer for the scrollback
data, did you consider allocating more space for the main buffer and
just adjusting the scroll_{top,bot} pointers and using them in
madtty_draw to draw only the currently visible area?
I did consider that, actually. Several reasons why I use a separate
buffer:
- From what I understand of vt100/xterm behavior, you can use
DECSTBM to set the scrolling region. If the top line of the screen is
*not* in the scrolling region, you'd need to do some extra work to
have text scroll offscreen.
- The scrollback buffer is a circular buffer for runtime efficiency,
while the screen is a regular array.
- I'd like to add some kind of compression for the scrollback buffer
(e.g. run length encoding for character attributes, convert from
wchar_t using wcsrtombs).
Re: [dwm] dvtm suggestion
- tags/workspaces are a straightforward addition to dvtm, since it was derived from dwm. (I have it mostly working for myself, but I had to rip out a lot of dvtm-specific things like 'minimize') Why had you to rip out these things? There is a git branch which should mostly work but i so far failed to find acceptable keybindings for all the tag actions. http://repo.or.cz/w/dvtm.git?a=shortlog;h=refs/heads/tagging I didn't see the git branch when I made that comment. But now that I've seen it, I've got to say, I don't like it. I use dvtm when I can't use dwm, and for various reasons prefer that they share as much code as possible. - The ability to minimize windows is mostly useless when you have tags and workspaces. The exception is if one is using the window title as another status bar. - The implementation of tagging is contrary to the suckless philosophy: http://www.suckless.org/common/ - The focusn procedure takes away valuable key bindings that I use for tagging. An unrelated comment: there's some code in madtty.c to work around some issue in PuTTY. It doesn't seem to make a difference for me (I use PuTTY), but perhaps a better solution is to call define_key from the frontend (i.e dvtm.c).
[dwm] [dvtm] scrollback and 256color support
Hi, the following two patches add support for a scrollback buffer and enhanced color in dvtm. scrollback: - Simply set up some keybinding to scrollback(), passing in -1 or 1 to scroll up or down. 256color: - Allows the use of nice VIM color schemes - Ncurses doesn't allow more than 256 fg/bg color pairs on screen at the same time. - 8 or 256 colors only. If your terminal supports 88 colors, you need to set up your own variant of rxvt, e.g. rxvt-88color scrollback.diff Description: Binary data 256color.diff Description: Binary data
Re: [dwm] dvtm suggestion
What about the ability to run different dvtm instances on different virtual terminals that share a common session? This could be seen as the tag/workspace concept. You could detach a window on /dev/tty1 and reattach it in your other dvtm on /dev/tty3. The only thing that comes to my mind is that in order to get six workspaces you'd have to log in manually six times on different consoles. Or perhaps there is a getty out there that supports multi-logins... Are you simply looking for a tag/workspace mechanism, or do you want the ability to detach and reattach sessions? - tags/workspaces are a straightforward addition to dvtm, since it was derived from dwm. (I have it mostly working for myself, but I had to rip out a lot of dvtm-specific things like 'minimize') - GNU Screen does detach/reattach.
Re: [dwm] rationale for resizehints=False?
On Aug 7, 2008, at 12:35 AM, Sander van Dijk wrote: On 8/6/08, Donald Chai [EMAIL PROTECTED] wrote: I have the inside border set up to follow resize hints (this packs more text onscreen if my display's number of rows is not a multiple of 3). The outside border does not follow resize hints, because I have them set up to be rendered exactly 1px offscreen (I don't want to see them). Any reason why the current setup is all-or-nothing? I'm not sure what you mean by having the inside border setup to follow resizehints, but the outside border does not follow resizehints? Handling resizehints doesn't have an effect on borders, it has an effect on the window. An application can for instance say I want to be resized in steps of 5 pixels only or I want to be precisely this size. When resizehints handling is enabled, dwm will honor those requests, otherwise it'll simply say this is your size, deal with it. I believe there's not much between all or nothing there (other than being able to handle/ignore specific hints, but I doubt that's what you meant). Sorry, I think I don't think I was very precise. I have my setup as follows. For the following layout, tile assigns sizes to windows A,B,C,D (in that order). +--+---+ | | B | | +---+ | A | C | | +---+ | | D | +--+---+ I have tile set the height of A *precisely* to wh (A-h = wh). Resize hints are used for the width (A-w = A-basew + n*A-incw for some n such that |A-w - mfact*ww| A-incw). For B and C, the width is set precisely (B-w = ww - A-w), and resize hints are used for the height. So I believe there is something between all or nothing (i.e. something :)), which is to follow resize hints for one dimension only. I was just wondering why others would prefer one setting over another.
Re: [dwm] DWMII layout with a more better integration
@pancake :
I dont see any point for having a function called
dwmiinoinfiniteloop
Well this function is necessary, I didn't know how to call it,
though its name is relevant... If you don't like its name feel free
to change it but I won't. The important thing is that it does its job.
I think what pancake meant is that code that needs a function
called dwmiinoinfiniteloop can usually be rewritten to not require
it, improving maintainability. From what I can tell, it unsets the
second dwmii bit it finds, merging the second column of windows into
the first column. Why?
--snip--
void dwmiinoinfiniteloop(void)
{
Client* firstclients = nexttiled(clients),*t = firstclients;
for( ; t !t-dwmii ; t = nexttiled(t-next) );
firstclients-dwmii = 1;
if ( t (t != firstclients) ) { t-dwmii = 0; }
}
The code below contains lots of if's that seem to be always true
(or should be). Why check them? You don't call dwmiilayoutcol unless
if (lt[sellt]-arrange == dwmiilayoutcol). Also, the line
if (t-dwmii)
should always be true. Otherwise, you'll get an infinite loop. I
think it'd be better to remove this check (and not explicitly set
firstclients-dwmii=1). This might work better for the case of
windows having multiple tags...
void dwmiilayoutcol(void)
{
Client *firstclients = nexttiled(clients);
if ( !firstclients || (lt[sellt]-arrange != dwmiilayoutcol) )
{ return; }
dwmiinoinfiniteloop();
Client *t = nexttiled(firstclients-next);
int n = 1;
for( ; t ; n += ( t-dwmii ? 1 : 0 ),t = nexttiled(t-next) );
int x = wx,dw = ww / n;
for ( t = firstclients ; t ; )
{
if ( t-dwmii )
{
n = 1;
Client *s = nexttiled(t-next);
for( ; s !s-dwmii ; n++,s = nexttiled(s-next) );
int dh = wh / n,y = wy + dh;
resize(t,x,wy,dw - 2 * t-bw,dh - 2 *
t-bw,resizehints);
for( t = nexttiled(t-next) ; t !t-dwmii ; t = nexttiled(t-
next) )
{
resize(t,x,y,dw - 2 * t-bw,dh - 2 *
t-bw,resizehints);
y += dh;
}
x += dw;
}
}
}
Re: [dwm] fibonacci layout patch [update for dwm-5.0.1]
Attached is a slightly different implementation of the fibonacci()
function that respects `mfact' for the master window [and lets you
resize your master window with M-j M-k] This worked under hg tip
(1314). Comments, insights welcome. --Madhu
--snip--
Here's one that uses 'mfact' throughout. (I was annoyed that the
original code used a divisor of 2 rather than the golden ratio.)
void
fibonacci(int shape) {
unsigned int i, n, nx, ny, nw, nh;
Client *c;
nx = wx;
ny = wy;
nw = ww;
nh = wh;
for(n = 0, c = nexttiled(clients); c; c = nexttiled(c-next))
n++;
for(i = 0, c = nexttiled(clients); c; c = nexttiled(c-next)) {
unsigned thish=nh, thisw=nw;
if((i % 2 nh * mfact 2 * c-bw)
|| (!(i % 2) nw * mfact 2 * c-bw))
{
if(i n - 1) {
if(i % 2)
thish *= mfact, nh -= thish;
else
thisw *= mfact, nw -= thisw;
if((i % 4) == 2 !shape)
nx += nw;
else if((i % 4) == 3 !shape)
ny += nh;
}
i++;
}
resize(c, nx, ny, thisw - 2 * c-bw, thish - 2 * c-
bw, False);
if((i % 4) == 0) {
if (shape)
ny += thish;
else
ny -= nh;
}
else if((i % 4) == 1)
nx += thisw;
else if((i % 4) == 2)
ny += thish;
else if((i % 4) == 3) {
if (shape)
nx += thisw;
else
nx -= nw;
}
}
focus(NULL);
restack();
}
Re: [dwm] Status text clock patch
Any help would be appreciated, and also how could i do the same
without using threads?
This seems to work fine for me...
--- a/dwm.c Thu Jul 03 17:05:56 2008 +0100
+++ b/dwm.c Fri Jul 11 00:26:08 2008 -0700
@@ -1313,11 +1313,28 @@ setmfact(const Arg *arg) {
arrange();
}
+#include time.h
+
+void
+updatestatus(int signum) {
+time_t t = time(0);
+struct tm *ctm = localtime(t);
+
+strftime(stext, sizeof(stext), %T, ctm);
+drawbar();
+
+signal(SIGALRM, updatestatus);
+alarm(1);
+}
+
void
setup(void) {
uint i;
int w;
XSetWindowAttributes wa;
+
+ signal(SIGALRM, updatestatus);
+ alarm(1);
/* init screen */
screen = DefaultScreen(dpy);
Re: [dwm] patch to store layouts per tagset
- shows all windownames in the statusbar (this is nice for the
maximized layout, as you wouldnt see there are multiple windows on
that tag otherweise). that stuff is a little bit messy, id like to
see suggestions how to make that better. it uses a defined maximum
length for the title, and if the length of all windownames gets too
long, the title will not be drawn.
IMHO, it looks like most of the messiness is due to the 1px
separators: the code is much cleaner without them. The version below
omits them, and divides the available space if the length of all
windownames gets too long.
If you really like the 1px separators, maybe you should draw a big
box before anything else, and add
dc.x++
wherever you want one?
void
drawbar(void) {
int i, x;
Client *c;
dc.x = 0;
for(i = 0; i LENGTH(tags); i++) {
dc.w = TEXTW(tags[i]);
if(tagset[seltags] 1 i)
drawtext(tags[i], dc.norm, True);
else if(isurgent(i))
drawtext(tags[i], dc.sel, False);
else
continue;
dc.x += dc.w;
}
if(blw 0) {
dc.w = blw;
drawtext(lt[sellt]-symbol, dc.norm, issaved());
x = dc.x + dc.w;
}
else
x = dc.x;
dc.w = TEXTW(stext);
dc.x = ww - dc.w;
if(dc.x x) {
dc.x = x;
dc.w = ww - x;
}
drawtext(stext, dc.norm, False);
if((dc.w = dc.x - x) bh) {
int nvis = 0;
int cw = 0;
int w;
dc.w = dc.x - x;
dc.x = x;
drawtext(NULL, dc.norm, False);
w = dc.w;
/* get the number of visible clients */
for(c = clients; c; c = c-next) {
if(ISVISIBLE(c)) {
nvis++;
cw += TEXTW(c-name);
}
}
for(c = clients; c; c = c-next) {
if(!ISVISIBLE(c))
continue;
dc.w = (cw w) ? (w / nvis) : TEXTW(c-name);
drawtext(c-name, dc.norm, sel == c);
dc.x += dc.w;
}
}
XCopyArea(dpy, dc.drawable, barwin, dc.gc, 0, 0, ww, bh, 0, 0);
XSync(dpy, False);
}
Re: [dwm] patch for 5.0.1: interior borders only
I evaluated this border style some time ago. And I must say I still prefer the original behavior of dwm. The problem about you're borderstyle is, that my brain needs more time to identify the selected window. Also I don't use resizehints, as some clients really start to fuck up if it's set to false, which is even more counterproductive with this patch. Oh, I'm new here and didn't realize that someone already tried this before. I didn't see it in any patches or screenshots. I only have terminal sessions managed by dwm, and rxvt-unicode is set to dim windows that are out of focus, so it works for me. I'm typing this in Apple Mail, and I'm thinking that maybe what I really want is a drop shadow around the active window instead of borders...
[dwm] patch for 5.0.1: interior borders only
This patch makes X draw window borders offscreen, so that you see
|
|
|
|
|
instead of
++
| ||
| ||
| ||
| ||
| ||
++
I find the outside borders to be a bit jarring when in black-
backgrounded xterms. As a side effect, no superfluous border is drawn
when ismax==True.
Set resizehints=False for best results.
diff -r de2e0c431cf2 dwm.c
--- a/dwm.c Sun Jul 06 03:27:01 2008 -0700
+++ b/dwm.c Sun Jul 06 16:16:46 2008 -0700
@@ -206,7 +206,7 @@ static void zoom(const Arg *arg);
/* variables */
static char stext[256];
static int screen, sx, sy, sw, sh;
-static int by, bh, blw, wx, wy, ww, wh;
+static int bx, by, bw, bh, blw, wx, wy, ww, wh;
static uint seltags = 0;
static int (*xerrorxlib)(Display *, XErrorEvent *);
static uint numlockmask = 0;
@@ -513,10 +513,10 @@ drawbar(void) {
else
x = dc.x;
dc.w = TEXTW(stext);
- dc.x = ww - dc.w;
+ dc.x = bw - dc.w;
if(dc.x x) {
dc.x = x;
- dc.w = ww - x;
+ dc.w = bw - x;
}
drawtext(stext, dc.norm, False);
if((dc.w = dc.x - x) bh) {
@@ -528,7 +528,7 @@ drawbar(void) {
else
drawtext(NULL, dc.norm, False);
}
- XCopyArea(dpy, dc.drawable, barwin, dc.gc, 0, 0, ww, bh, 0, 0);
+ XCopyArea(dpy, dc.drawable, barwin, dc.gc, 0, 0, bw, bh, 0, 0);
XSync(dpy, False);
}
@@ -1187,7 +1187,7 @@ restack(void) {
if(!sel)
return;
if(ismax || sel-isfloating || !lt-arrange)
- XRaiseWindow(dpy, sel-win);
+ XRaiseWindow(dpy, sel-win), XRaiseWindow(dpy, barwin);
if(!ismax lt-arrange) {
wc.stack_mode = Below;
wc.sibling = barwin;
@@ -1364,7 +1364,7 @@ setup(void) {
wa.background_pixmap = ParentRelative;
wa.event_mask = ButtonPressMask|ExposureMask;
- barwin = XCreateWindow(dpy, root, wx, by, ww, bh, 0,
DefaultDepth(dpy, screen),
+ barwin = XCreateWindow(dpy, root, bx, by, bw, bh, 0,
DefaultDepth(dpy, screen),
CopyFromParent, DefaultVisual(dpy, screen),
CWOverrideRedirect|CWBackPixmap|CWEventMask,
wa);
XDefineCursor(dpy, barwin, cursor[CurNormal]);
@@ -1579,6 +1579,15 @@ updategeom(void) {
/* bar position */
by = showbar ? (topbar ? wy - bh : wy + wh) : -bh;
+ bx = wx;
+ bw = ww;
+
+ {
+ wy -= borderpx;
+ wx -= borderpx;
+ ww += 2*borderpx;
+ wh += 2*borderpx;
+ }
}
void
