[dev] [PATCH] Sets _NET_WM_PID on startup
This sets _NET_WM_PID on startup. Not sure if any error handling's needed. I
used this for quite a while before I switched back to urxvt (for scrollback)
for the same purpose as the recent in $PWD thread.
---
st.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/st.c b/st.c
index 50b58a7..e3a7719 100644
--- a/st.c
+++ b/st.c
@@ -399,6 +399,7 @@ static int xsetcolorname(int, const char *);
static int xloadfont(Font *, FcPattern *);
static void xloadfonts(char *, int);
static int xloadfontset(Font *);
+static void xsetnetwmpid(void);
static void xsettitle(char *);
static void xresettitle(void);
static void xsetpointermotion(int);
@@ -3028,6 +3029,7 @@ xinit(void) {
xresettitle();
XMapWindow(xw.dpy, xw.win);
xhints();
+ xsetnetwmpid();
XSync(xw.dpy, 0);
}
@@ -3347,6 +3349,13 @@ xdrawcursor(void) {
}
}
+void
+xsetnetwmpid(void) {
+ Atom _NET_WM_PID = XInternAtom(xw.dpy, _NET_WM_PID, False);
+ pid_t pid = getpid();
+ XChangeProperty(xw.dpy, xw.win, _NET_WM_PID, XA_CARDINAL, 32,
+ PropModeReplace, (unsigned char *)pid, 1);
+}
void
xsettitle(char *p) {
--
1.8.4.1
Re: [dev] [st] new features
On Wed, 29 Aug 2012, Christoph Lohmann wrote: some changes were made to st. These include: [...] * two ways of setting the title in X11 * OSC 0 $title * OSC 2 $title * OSC 2 settitle $title /* I still don't know why vim uses both */ Where are you seeing OSC 2 settitle $title? Vim doesn't hardcode that anywhere. Is it a bad 'titlestring' option? a bad terminfo setting? -- Best, Ben
Re: [dev] [dwm] X autologin and startup applications
On Mon, 14 May 2012, Ethan Grammatikidis wrote: On Sun, 6 May 2012 22:49:17 -0700 Amit Uttamchandani wrote: [...] hash surf surf http://localhost/ [...] hash is a shell feature. bash and others cache the path - all the names - and sometimes when you've installed something since starting the shell, the shell won't find it. I think it only happens when you've removed it from one $PATH dir and installed it to another, in bash at least. Using hash in a just-started shell like the one running .xinintrc is pointless. :) `hash [cmd-name]` is an idiom to determine whether a command exists in $PATH. I've been seeing it a lot recently as `hash [cmd-name] 2-` to suppress the errors when the cmd's not found. On my current system with only a few shells, the idiom works in bash, sh (symlink to bash), and zsh, but not in ksh (nor in csh ... but whocares): bash$ hash dwm ; echo $? 0 bash$ hash nonexistent ; echo $? bash: hash: nonexistent: not found 1 -- Best, Ben
Re: [dev] xid of a current window
On Sun, 25 Mar 2012, Swiatoslaw Gal wrote: -- From Ivan Kanakarakis 25-03-2012 at 15:20 -- $ xdotool getactivewindow XGetWindowProperty[_NET_ACTIVE_WINDOW] failed (code=1) xdo_get_active_window reported an error You could use the focused window instead (which was what you originally asked about): $ xdotool getwindowfocus 48234505 dwm doesn't (or didn't? - depending on today's patches) set _NET_ACTIVE_WINDOW, but there's still a focused window. -- Best, Ben
Re: [dev] [st] 0.2 is out
On Wed, 8 Feb 2012, ilf wrote: On 02-08 00:14, Aurélien Aptel wrote: As I said previously somewhere on the list, I've tagged the last changeset of the default branch as 0.2. Checking it out for the first time since 0.1.1. I am running the same tmux session in both rxvt-unicode and st next to each other. The drawing speed of st does indeed feel better than before, but it's still way slower than rxvt in everything I have tried. This is one of the issues still holding me back from switching to st as my main terminal emulator. Do other terms have magic in their rendering code for extra speed? rxvt-unicode uses the wonderful optimization of not really caring whether everything gets displayed. As a test, simulate some command that produces output that can't actually be read -- like from a noisy makefile, the non-error output of TeX, or an accidental `find`: find / | sed 1q ~/find1 time cat ~/find1 uxterm takes 2.6 seconds to display text I can't possibly read. urxvt finishes instantly, only taking 0.04 seconds of wall time. st takes 50.1 seconds. Obviously, this isn't the primary use case for a terminal emulator. But in a term with scrollback, sometimes it's quicker to just dump the data and scroll back up to the part you care about. And if the interesting portion is the tail, all the better if it finishes instantly. Second thing to notice is the font height. st displays six more lines than rxvt, with tmux padding them. I changed $FONT in config.h: -#define FONT -*-*-medium-r-*-*-*-120-75-75-*-60-*-* +#define FONT -*-terminus-*-*-*-*-*-*-*-*-*-*-*-* But it has no effect. Where do I change this? I used: #define FONT -*-terminus-medium-r-*-*-16-*-*-*-*-*-*-* If you're on the 'xft' branch, you'll need a different format, e.g.: #define XFT_FONT Bitstream Vera Sans Mono-13 -- Best, Ben
Re: [dev] [st] 0.2 is out
On Wed, 8 Feb 2012, ilf wrote: On 02-08 09:39, Benjamin R. Haskell wrote: rxvt-unicode uses the wonderful optimization of not really caring whether everything gets displayed. I don't know if every one of those output lines is rendered on screen once. But it doesn't need to, since I can't read it anyways, no matetr if it takes 1, 3 or the 28 seconds takes here. What's more important is that everything is in the scrollback, which always seems to be the case, even in rxvt. (Although I consider this bad style. If you really need 10k lines and want to look at them, that's what less is for.) I agree it's bad style. Often it's unintentional (`find` on too broad a path, very verbose Makefiles). So I don't see the problem with rxvt's way of things. Why not do it? As Aurélien pointed out, `st` at least behaves similarly (if not identically). Didn't realize what hg rev I was on on that machine. Prior test was w/ 187. With current non-xft tip (rev 228), I get similar results: 0.2s wall time. -- Best, Ben
Re: [dev] cat unique deice identifier e.g. serial number
On Thu, 9 Feb 2012, hiro wrote: mhm, so there's no native way on a linux? Depending on your kernel, the DMI information may be available via sysfs. You asked for the serial number before. I have that at: /sys/class/dmi/id/board_serial Contents are equivalent to `dmidecode -s baseboard-serial-number`. The equivalent of Christoph's suggestion (dmidecode -s system-uuid) is available at: /sys/class/dmi/id/product_uuid -- Best, Ben
Re: [dev] [st] font help
On Mon, 23 Jan 2012, Benjamin R. Haskell wrote: I had similar results until I compiled the st terminfo file by running: tic st Sorry: tic st.info
Re: [dev] dwm and Xwindow
On Wed, 16 Nov 2011, Pascal Wittmann wrote: On 11/16/2011 10:30 PM, Justin Pogue wrote: On Wed, Nov 16, 2011 at 3:20 PM, Guilherme Lino wrote: hello Is there any way to dim the brightness or gamma of dwm unfocused windows?? cumps Not that I know of for *all* windows, but if I remember right rxvt has an option like this that you can put in your .Xdefaults Something like urxvt.shading or urxvt.tint or I think. It's: urxvt.fading : 20% 'fading' is also supported by Xterm (proper, not sure about most xterm-alikes). To cover both, you can use: *fading: 20% -- Best, Ben
Re: [dev] DWM Xinerama
On Thu, 10 Nov 2011, Roger wrote: I'm using dwm-5.9. I'd love to get a dwm-.ebuild into Gentoo, but some hate cvs/svn/git ebuilds and I have a tough time getting them into Gentoo. It doesn't make a whole lot of sense to have an ebuild in the first place for a piece of software that requires you to alter its source in order to configure it. Depending on what patches (if any) you apply, dwm consists of two source files (on the non-draw.c branch). Clone the hg sources, compile it, copy `dwm` into ~/bin, and be happier not fighting with an ebuild and/or bureaucracy. If you really want an ebuild for it, just create it yourself in a local repository. -- Best, Ben
Re: [dev] [tabbed] how focusing is handled
On Thu, 22 Sep 2011, Roman Z. wrote: On Wed, Sep 21, 2011 at 09:48:11PM +0200, Roman Z. wrote: Currently, if you run a program in tabbed and move the mouse away from that window, the program will not respond anymore. Since this is much like how X behaves when you run no window manager, I've been looking in dwm code for solutions to this problem but to no avail. Maybe you can tell me what part of dwm handles this and I can apply it to tabbed? Or do you have other ideas? To reproduce: 1. open xterm in tabbed. This hasn't worked for me with the newest version, I use revision 142. 2. put the mouse inside the tabbed window and type a. It works. 3. move the mouse out of the window and type a. Nothing happens. One solution is to revert the changeset 138. It has the commit message: removing XSetInputFocus() calls to be ICCCM compliant again. Thanks to Thomas Adam. Please consider reverting this changeset in upstream since you now know that it introduced a bug. Confirming that reverting 138 worked here, too: changeset: 138:5eff0bc41822 user:Enno Boland (tox) t...@s01.de date:Mon Apr 26 22:30:27 2010 +0200 summary: removing XSetInputFocus() calls to be ICCCM compliant again. Thanks to Thomas Adam fixes tabbed for me, too, under dwm. It'd also be nice if the 'command' of 'tabbed [-d] [-v] command' were optional. Not sure how hard that'd be. It was weird to have to test it differently based on what version I was testing. I'll look at it later (instead of just complaining) if someone doesn't do it first. -- Best, Ben
Re: [dev] [dwm] sloppy focus
On Mon, 4 Jul 2011, Bjartur Thorlacius wrote: Þann mán 4.júl 2011 15:14, skrifaði Connor Lane Smith: Interesting, those on IRC were very 'for' this idea. Different demographics? Oh you silly ML people! So people who use mice prefer laggy ML communications over IM? I hate mice, but I also can't stand the constant interruptions model of IRC. Email without notification-style popups lets you deal with (or ignore) stuff at your own pace instead of letting others dictate control of your attention. (i.e. I prefer laggy) That said, what do people here use for IRC and how do you deal with it in dwm? Without a systray, I don't understand where one gets the spare screen real estate to dedicate to IRC. And w/o dedicated space for it, I end up forgetting it's there (to the annoyance of people who want responses). -- Best, Ben
Re: [dev] [dwm] sloppy focus
On Mon, 4 Jul 2011, Josh Rickmar wrote: Um, why is a systray needed for IRC? It's not necessary for IRC, per se. I wrote: Without a systray, I don't understand where one gets the spare screen real estate to dedicate to IRC. I don't understand how to effectively use IRC without doing one of the following: 1. keeping it on-screen (which seems impractical to me, partly because I still don't quite get dwm) or 2. having some kind of indication that you've been addressed (urgent hints or whatever). In other wm's, #2 is often handled by having a little flashing systray icon. So, broadening: what (if anything) do dwm users use for notifications or indicating urgency? -- Best, Ben
Re: [dev] [dwm] sloppy focus
On Mon, 4 Jul 2011, Christoph Lohmann wrote: Hello, Benjamin R. Haskell wrote: In other wm's, #2 is often handled by having a little flashing systray icon. So, broadening: what (if anything) do dwm users use for notifications or indicating urgency? my IRC client is sending a bell character to my terminal, which is setting the urgent bit on that window. The urgent bit tells dwm to highlight that tag in the statusbar. Just set in your X resources: xterm.bellIsUrgent: true or urxvt.urgentOnBell: true , depending on your favourite X terminal emulator. Reload the X resourced and start one terminal emulator using them. Then run % echo -e '\a'; in an unattended tag and watch the result. Ah, thanks. Halfway there. So, that's roughly what I was looking for, but it's not very noticeable. Does anyone have a 'dwm-urgent-blink' patch? The one I found¹ didn't work (makes dwm unresponsive to input after something gets the urgent bit set, and I don't know enough about pthreads to know what's going wrong). -- Best, Ben ¹: http://www.mail-archive.com/dev@suckless.org/msg00997.html
Re: [dev] [dwm] sloppy focus
On Mon, 4 Jul 2011, Benjamin R. Haskell wrote: On Mon, 4 Jul 2011, Christoph Lohmann wrote: Hello, Benjamin R. Haskell wrote: So, broadening: what (if anything) do dwm users use for notifications or indicating urgency? [...] urxvt.urgentOnBell: true Ah, thanks. Halfway there. So, that's roughly what I was looking for, but it's not very noticeable. Does anyone have a 'dwm-urgent-blink' patch? The one I found didn't work [...] I've got a workable other half with this urgentcolor patch¹ I found. Now urgent tags are noticeable. -- Thanks again, Ben ¹: http://www.mail-archive.com/dwm@suckless.org/msg06657.html
[dev] Mailing list instructions?
The mailing list page¹ mentions that message 'N' can be fetched by sending a message to dev+get-N@MAILHOST. I tried to get the dwm-urgent-blink patch I mentioned before as an email (possibly message #997, based on the URL: http://www.mail-archive.com/dev@suckless.org/msg00997.html ) by sending to dev+get-997. I also tried dev+get-00997 and dev+get-1, but nothing generated a response. Is that feature still available? -- Best, Ben ¹: http://suckless.org/community
Re: [dev] Mailing list instructions?
On Mon, 4 Jul 2011, Connor Lane Smith wrote: On 4 July 2011 22:36, Benjamin R. Haskell wrote: possibly message #997, based on the URL: http://www.mail-archive.com/dev@suckless.org/msg00997.html I don't why you're looking there and not at the actual suckless archive,[1] which shows that it's message #986.[2] [1] http://lists.suckless.org/dev/ [2] http://lists.suckless.org/dev/0908/0986.html Only out of laziness (...I did write possibly). I was already at www.mail-archive.com as the first google result for: dwm urgent blink Looking back at the results, the actual archive was result #5. But I didn't get a reply from dev+get-0986 either. So I guess it's not working? Thanks for testing. -- Best, Ben
Re: [dev] [dwm] segfault
On Wed, 22 Jun 2011, Arian Kuschki wrote: hg summary shows parent: 1560:e181c9cf318e tip [...] How can I diff my local version against tip? Sorry am more of a git user. [Later] On Wed, 22 Jun 2011, Arian Kuschki wrote: On 22 June 2011 15:44, Andrew Hills wrote: On Wed, Jun 22, 2011 at 9:32 AM, Arian Kuschki wrote: How can I diff my local version against tip? Check out tip: hg clone http://hg.suckless.org/dwm Then diff: diff /path/to/your/dwm.c /path/to/tip/dwm.c yeah, I guess I was being stupid there.. I was looking for something analogous to git diff, but obviously this works and is very simple, thanks. Err. Perhaps Andrew trimmed too much context. Since you already have an hg repo, it's much simpler to just run `hg diff`. Even if you wanted to diff against the latest version from the hg.suckless.org repo, you still shouldn't have to reclone the whole thing: hg pull¹ hg diff -r tip -- Best, Ben ¹: Since you mentioned being more of a git user, keep in mind that 'pull' and 'fetch' are reversed in git and mercurial: git fetch = fetch the changes from the remote repo (fetch = retrieve) git pull = git fetch + git merge (pull = fetch and merge the changes into the branch) hg pull = pull the changes from the remote repo (pull = retrieve) hg fetch = hg pull + hg update (differs depending on whether new branch head found)
Re: [dev] ideas on suckless file manager
On Tue, 7 Jun 2011, Le Tian wrote: On Tue, Jun 7, 2011 at 11:25 AM, Connor Lane Smith wrote: [...] (I find inverting the colours actually helps to a worrying degree.) Interesting... Yeah, I find inverting the colours actually helps to a worrying degree. I think this should be a default in all linux distros, due a phycological factor.) Inverting the colors = light text on dark background? And the dark background is less scary? I'd have expected the opposite, but maybe I've been conditioned by movies to think that dark terminals are 'leet'. To me, light backgrounds feel warmer and more natural, dark ones feel more cold and mechanical. -- Best, Ben
Re: [dev] TermKit
On Fri, 20 May 2011, Andrew Hills wrote:
On Fri, May 20, 2011 at 12:16 PM, Suraj N. Kurapati wrote:
history | xmessage -file -
I keep this ugly mess around in for convenience:
h()
{
`history | perl -e 'while(STDIN){s/\s+\d+\s+//;push
@o,$_;}for($i=$#o-1;$i=0;$i--){print $o[$i];}' | dmenu -b`
}
Yikes. Ugly indeed. Unsolicited (sort of... something wrong on the
internet 'n all), but:
'for($i=$#o-1;$i=0;$i--){print $o[$i];}'
is better written:
'pop @o; print for reverse @o'
or
'print for reverse @o[0..$#o-1]'
Plus it's easier to reverse the whole thing outside of Perl (via tac),
and you can use '-n' to avoid the 'while(STDIN){}', so the whole thing
becomes:
h()
{
`history | perl -nwe 's/\s+\d+\s+//; print unless eof' | tac | dmenu -b`
}
Don't have `tac` installed? (I think it's in linux-utils or core-utils,
but maybe it's linux- and/or GNU-centric.)
tac () { perl -nwe 'unshift @o, $_; END { print for @o }' }
--
Best,
Ben
Re: [dev] TermKit
On Fri, 20 May 2011, Andrew Hills wrote: Thanks for the Perl-readability tip. No prob. On Fri, May 20, 2011 at 12:58 PM, Benjamin R. Haskell wrote: Don't have `tac` installed? (I think it's in linux-utils or core-utils, but maybe it's linux- and/or GNU-centric.) I do most of my work on Solaris, and it's not really worth the effort to install tac to use it in one place. Agreed. I might drop the substitute I listed into ~/.zsh/autoload/tac (can't live w/o syncing at least my shell startup files to systems I use). The wikipedia article on `tac` (first result when googling to see if it was indeed linux-specific) mentioned `tail -r` as a possible substitute. Anyone know what `tail`s support '-r' ( == reverse? )? or more generally, anyone have a good reference for differences in common commands across posix-like O/S'es? -- Best, Ben
Re: [dev] TermKitjkjkjn
Subject: Re: [dwm] TermKitjkjkjn dwm's focus rules still surprise me sometimes (mainly in monocle mode where urxvt doesn't occupy the entire screen, due to the screen not being evenly divisible by character cells). The jkjkjn tacked on to the subject there was me trying to 'shake' an apparently-frozen vim session, which inadvertently sent email from the window I couldn't see...
Re: [dev] TermKitjkjkjn
On Fri, 20 May 2011, Connor Lane Smith wrote: On 20 May 2011 19:58, Benjamin R. Haskell wrote: dwm's focus rules still surprise me sometimes (mainly in monocle mode where urxvt doesn't occupy the entire screen, due to the screen not being evenly divisible by character cells). static const Bool resizehints = False; ;) Awesome. Never knew what that was about. -- Thanks, Ben
Re: [dev] [surf] [PATCHES] (1) GConf URL schema handlers (2) delete _SURF_GO xprop (3) close stdout sending XID
On Sat, 9 Apr 2011, Bjartur Thorlacius wrote: Adam Strzelecki wrote: It is safer to remove this atom just after it is set in case we send some URL containing passwords or auth tokens I'm confused as to the state between setting _SURF_GO and removing it. It smells like a race condition to me, but then again I don't understand X11 properties. I'd like a clarification as to how security is kept in the meantime (between setting and removal of _SURF_GO). Security isn't kept. This seems like more of a prevention of accidental disclosure than real security. (And therefore pointless...?) As an example, with this patch applied, run the following: # start surf, grabbing its ID $ surf -x 52428803 # in a 'spy' terminal $ xprop -spy -id 52428803 _SURF_GO # elsewhere, update _SURF_GO: $ sprop 52428803 _SURF_GO asdf The output in the spy terminal is: _SURF_GO: not found _SURF_GO(UTF8_STRING) = 0x61, 0x73, 0x64, 0x66 == asdf _SURF_GO: not found -- Best, Ben
Re: [dev] Panels and Touch support
On Wed, 6 Apr 2011, Christoph Lohmann wrote: Hello comrades, attached is a patch for dwm, which will add real support for the _NET_WM_WINDOW_TYPE. What is this patch against? I wanted to try this out, but even the first hunk of the patch doesn't apply against hg tip. And the parent listed in the header: # Parent d92f9b65f85f19122ccc0e19ee7dca089644bd81 doesn't exist, AFAICT. -- Best, Ben
Re: [dev] Panels and Touch support
On Sun, 10 Apr 2011, Benjamin R. Haskell wrote: On Wed, 6 Apr 2011, Christoph Lohmann wrote: Hello comrades, attached is a patch for dwm, which will add real support for the _NET_WM_WINDOW_TYPE. What is this patch against? I wanted to try this out, but even the first hunk of the patch doesn't apply against hg tip. Nevermind. Found your March 24 message with the 'toolbar and focus' patch. Adding that first fixed it. That other patch doesn't live in a branch of any sort, does it? I never remember how hg does branches. -- Best, Ben
Re: [dev] Sup and dmc
On Fri, 1 Apr 2011, hiro wrote: I just looked at the source and what is this shit?!?! Yikes. I thought hiro was overreacting, until I looked at the source of the HTML MIME part. Wow. That's Office-grade shit. Horribly verbose, and only aimed at a specific subset of browsers: span class=Apple-style-span style=-webkit-tap-highlight-color: rgba(26, 26, 26, 0.296875); -webkit-composition-fill-color: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-color: rgba(77, 128, 180, 0.230469); font-size: medium;
Re: [dev] Re: [dwm] reload configuration?
On Sat, 26 Mar 2011, Marcin Cieslak wrote: Benjamin R. Haskell wrote: But beyond that, looping or manually launching dwm doesn't solve the problem that all the tag information is lost between restarts. wmii gets around it by dumping the tag information into X props (still loses layout info, but keeping the tags is far better than dumping everything onto a single tag). Has anyone patched dwm to do something similar? Why don't you start dwm somewhere as dwm in your .xinitrc/whatever and use xterm as the last resort application to keep the X server running? dwm xterm I was running for a long time for this - you just kill dwm (from xterm or otherwise) and then I do whatever I want from the xterm (launch dwm again). I used this mode to hack .h files a lot. The only downside is that you have all the windows again on the screen. Right... which was my original question... :-) Nonetheless, combining your answer with Anselm's, my .xinitrc now roughly does: while true ; do _setup_wm_command # usually sets cmd=( consolekit-session dbus-session dwm ) $cmd || urxvt done So, it'll repeatedly restart dwm or wmii or whatever. If the wm crashes, it falls back to just a terminal where I can either fix it or start an alternate wm. -- Thanks, Ben
[dev] [dwm] reload configuration?
So, in the early stages of trying out dwm, the thing I'm finding most frustrating is the need to restart after changing config.h. My first attempt was to modify spawn such that if arg-v[0] is dwm, it doesn't fork, just exec's. But, when doing that, all the windows' tag information is lost, so I end up with 50 windows jumbled onto tag 1 on one monitor. Anyone have suggestions? -- Best, Ben
Re: [dev] [dwm] reload configuration?
On Fri, 25 Mar 2011, Anselm R Garbe wrote: On 25 March 2011 12:46, Benjamin R. Haskell wrote: So, in the early stages of trying out dwm, the thing I'm finding most frustrating is the need to restart after changing config.h. My first attempt was to modify spawn such that if arg-v[0] is dwm, it doesn't fork, just exec's. But, when doing that, all the windows' tag information is lost, so I end up with 50 windows jumbled onto tag 1 on one monitor. Anyone have suggestions? Just launch dwm from a while loop in .xinitrc (or launch dwm manually from an xterm as WM): while true do dwm done [OT] Where did everyone pick up this shell scripting style with the extra newline? (while x\ndo\n instead of while x ; do\n?) I omitted too many details. One reason I don't do that is that it's not just dwm that I'm doing this for. I'm migrating (possibly/probably) from wmii, so I'd also like to be able to respawn into wmii (or ion3 or ...). I modified spawn() to handle any of those cases by not forking. But beyond that, looping or manually launching dwm doesn't solve the problem that all the tag information is lost between restarts. wmii gets around it by dumping the tag information into X props (still loses layout info, but keeping the tags is far better than dumping everything onto a single tag). Has anyone patched dwm to do something similar? -- Best, Ben
Re: [dev] [dwm] reload configuration?
On Fri, 25 Mar 2011, Anselm R Garbe wrote: On 25 March 2011 13:47, Benjamin R. Haskell wrote: [OT] Where did everyone pick up this shell scripting style with the extra newline? (while x\ndo\n instead of while x ; do\n?) Old plain sh required the newline style (not sure if heirloom sh supports the semicolon list terminator). Of course pdksh or bash support both styles. So just a matter of style. Interesting to know. Thanks. I omitted too many details. One reason I don't do that is that it's not just dwm that I'm doing this for. I'm migrating (possibly/probably) from wmii, so I'd also like to be able to respawn into wmii (or ion3 or ...). I modified spawn() to handle any of those cases by not forking. But beyond that, looping or manually launching dwm doesn't solve the problem that all the tag information is lost between restarts. wmii gets around it by dumping the tag information into X props (still loses layout info, but keeping the tags is far better than dumping everything onto a single tag). Has anyone patched dwm to do something similar? In dwm this is usually done pre-actively through rules, not post-actively through state dumps Huh. Okay. In the same way that wmii was a departure for me from normal/mainstream wm's I guess I just have to get used to the local idioms. (another reason why I named dwm dynamic rather than static). Seems slightly backwards to me (static set of rules, rather than dynamically-assigned set of tags). But I can see what you mean. I'll stop trying to drive my nail in with a screwdriver, so to speak. -- Thanks much, Ben
Re: [dev] [wmii] running script on 'desktop'?
On Tue, 22 Mar 2011, Benjamin Cathey wrote:
Just curious if it is possible to run a script on the background image
(sort of conky-ish)? I'm thinking not due to the nature of wmii,
however I thought it couldn't hurt to ask.
The root window's still there, and you can still draw on it.
I'd never heard of conky (I have GKrellM pegged to tag /./ with
-geometry -0+0), but trying it, I had to change 'own_window' from 'yes'
to 'no' in the config, and then it worked fine.
If you want 'real' transparency, you'll need something to do that for
you, IIRC.
Another stupid example drawing to the 'background':
Under 'zsh' (not sure if other shells have '=(cmd)'):
while {true} {qiv -n -y =(convert -size 120x16 xc:none -gravity NorthWest -pointsize 10
-fill Red -draw text 0,0 '$(date)' png:-)}
(constantly updates the 'desktop' with the current time tiled.)
Well in wmii, I use terminator set to transparent so that my
background image shows through (set using 'feh' in my wmiirc). I was
wondering if there was a way to have a script running and have the
output display over the background displayed by feh and under the
terminator window (or any other window really).
If you want something *between* root and a background, you'll have to
draw it yourself. If it's textual, I think xrootconsole[1], as
mentioned in the other fork of this thread should be useful. Otherwise
you'd need to combine whatever images you want and update it that way.
e.g. my stupid ImageMagick date command from above, overlaid onto your
background:
while {true} {qiv -n -x =(convert your-normal-background.png \( -size 120x16 xc:none
-matte -channel A -fx .5 -channel RGBA -gravity NorthWest -pointsize 10 -fill Red -draw
text 0,0 '$(date)' \) -composite png:-)}
I'm only using 'qiv' because I had it in my zsh history. Don't really
know much about qiv vs. feh, except that neither seems to accept an
image on stdin.
--
Best,
Ben
[1] http://sf.net/projects/xrootconsole
Re: [dev] wmii hardware keyboard shortcut layout at boot problem
On Mon, 21 Mar 2011, Eitan Goldshtrom wrote: I set the keyboard layout to Dvorak with the KEYBOARD variable in rc.conf. When I start wmii though all my keyboard shortcuts are set to the hardware keys, which are QWERTY. I'm using Arch Linux and I installed xbindkeys, or at least some X package, to get the shortcuts to bind to the software layout. It works, but I have to run wmiirc through the actions menu in order for it to work. I have to do it every single time I start up wmii -- it's kind of annoying. Anyone know how to fix this? I've not used Arch Linux, but it sounds like the KEYBOARD variable sets the keyboard layout for the console, and that you need to set the layout for your X11 server. I use a custom keyboard layout based on an old version of the XFree86 us-intl that has AltGr stuff and CapsLock as Compose. To set it up, I add (a script that calls) the following to my .xinitrc: setxkbmap -model pc104 -layout benizi -variant intl -keycodes evdev -option '' -option lv3:ralt_switch -option altwin:super_win for your case, maybe this would do: setxkbmap -model pc104 -layout dvorak -variant intl -keycodes evdev Putting it somewhere in 'startup()' as recently discussed on-list might also make sense. (Of course, based on the fact that I find setxkbmap useful, Xorg has probably deprecated the mechanism behind it. YMMV,etc,etc) -- Best, Ben
Re: [dev] Re: How do you cope with OSX? (if at all)
On Sat, 19 Mar 2011, pancake wrote: On 18/03/2011, at 18:42, Kurt H Maier wrote: I'll stick with thinkpads. The keyboards are nicer, I don't have to paw at a touchpad, [...] Paw at touchpad? What do 'paw' means? Paw is the word used for most animal's feet. Used as a verb, it implies that the action is somehow primitive or basic. So, perfectly appropriate for a touchpad (blech). Personally, I completely disable the touchpad on any laptop I use whenever possible. Otherwise my wrists always unintentionally activate it. I don't think I've ever met a ThinkPad owner who didn't prefer the nipple over a touchpad once they were used to it. -- Ben
Re: [dev] wmii status bar config
On Thu, 17 Mar 2011, Le Tian wrote:
Hi again, I'm trying to find out how to make a custom status bar in
wmii. I have found status() lines in /home/wmii.rc file(hmmm what is
it doing here?!)
Maybe your '$HOME' env var was unset or improperly set at some point?
these is what I found:
status() {
Action status
if wmiir remove /rbar/status 2/dev/null; then
echo $WMII_NORMCOLORS | wmiir create /rbar/status
while status | wmiir write /rbar/status; do
Action status
I can barely understand it.
Posting a 'grep' without context is pretty worthless. The only section
you should care about is the part starting at 'status() {'.
So if anyone had an experience in setting up his custom bar, could you
please tip me how to do it, cause I don't know where to look else.
Look in the actual file, not the grep, and you should see something
like:
# Status Bar Info
status() {
echo -n $(uptime | sed 's/.*://; s/,//g') '|' $(date)
}
(I think that's the default for some version or another...)
The point is that whatever's in the function is what gets run each time
the status is updated.
If the custom script you mentioned in the first post is called
do-the-thing, and it's in your $PATH and executable, just change those
four lines to:
# Status Bar Info
status() {
do-the-thing
}
--
Best,
Ben
Re: [dev] wmii noob key binding help
On Fri, 25 Feb 2011, Eitan Goldshtrom wrote: I've put the following directly into the events() function of my wmiirc script in the KeyGroup Other section Key $MODKEY-z amixer sset PCM 4+ Key $MODKEY-v eval wmiir setsid amixer sset PCM 4+ I've since quit wmii, logged out, logged back in, and started X and wmii again. Still the key bindings don't work. When I test each of those commands in a terminal it has the desired effect. I'm at a loss at this point as to why it doesn't work. Is there a way for me to check and see if anything is happening at all, even though my volume isn't actually changing? Try something interactive to see that keys are being reloaded (maybe you're editing the wrong wmiirc?): Key $MODKEY-z xmessage blahblah or something that creates an obvious change: Key $MODKEY-z wmiir xwrite /ctl view CHANGED Maybe amixer isn't in your $PATH by the time wmii starts: Key $MODKEY-z $HOME/local-stuff/amixer sset PCM 4+ Or just log the errors, and go from there: Key $MODKEY-z amixer sset PCM 4+ $HOME/amixer.stdout 2$HOME/amixer.stderr -- Best, Ben
Re: [dev] wmii: Tagging from .wmiirc not working
On Tue, 22 Feb 2011, Steve Ryan wrote: Hello all, I just downloaded wmii the other day and have been so far loving it. Dynamic tagging is a wonderful idea! However, I've had one main problem. Using the default sh version of .wmiirc, I haven't been able to get it so that when I run, say, Thunderbird it's automatically tagged 'web'. Here's the relvent part of my .wmiirc: # Tagging Rules wmiir write /rules ! Do any of your tagging rules work? If you're using a version of wmii that supports the 'keyword=value' syntax you used in your example, I think these should be in /tagrules, rather than /rules. So, change the above line to: wmiir write /tagrules ! -- Best, Ben
Re: [dev] wmii: Tagging from .wmiirc not working
On Tue, 22 Feb 2011, Steve Ryan wrote: On 02/22/2011 12:40 PM, Benjamin R. Haskell wrote: On Tue, 22 Feb 2011, Steve Ryan wrote: Hello all, I just downloaded wmii the other day and have been so far loving it. Dynamic tagging is a wonderful idea! However, I've had one main problem. Using the default sh version of .wmiirc, I haven't been able to get it so that when I run, say, Thunderbird it's automatically tagged 'web'. Here's the relvent part of my .wmiirc: # Tagging Rules wmiir write /rules ! Do any of your tagging rules work? If you're using a version of wmii that supports the 'keyword=value' syntax you used in your example, I think these should be in /tagrules, rather than /rules. So, change the above line to: wmiir write /tagrules ! The ones that were in the default file (pidgin, vlc|mplayer, ROX) work perfectly fine. It is only ones that I write in myself that don't work. I tried using /tagrules, however, this shows up: wmiir: fatal: Can't open file '/tagrules': file not found witray: Replacing currently running system tray. wmiir: fatal: Can't open file '/rbar/status': file not found and trying to do the command manually reports the same error. Oops, had the history backwards. /tagrules was removed in favor of /rules. In wmii 3.6 (not using hg version here at work) your Thunderbird rule works okay for me. (Had to use sel+web instead of +web to get it to also show up on the current tag.) Based on the wmii(1) manpage from the hg version on my home pc, I think you may need to add tags= and remove the '-' for later versions: So, /Thunderbird/ - +web becomes: /Thunderbird/ tags=+web or maybe /Thunderbird/ tags=sel+web There's also a note in the 'rules PROVISIONAL' section (not running a particularly new hg version) that mentions 'force-tags=', so might also try: /Thunderbird/ force-tags=+web or /Thunderbird/ force-tags=sel+web -- Best, Ben
Re: [dev] wmii noob key binding help
On Tue, 22 Feb 2011, Eitan Goldshtrom wrote:
Hi. So I read through as much as I could find on the subject of
defining my own keybindings. I can see how to do it from the 9P
virtual filesystem that wmii has setup, but I am under the impression
that it can be done moreproperly?...via wmiirc_local and the
local_events() function. Unfortunately, whatever I try to put in
there causes wmii to not watch for any input whatsoever, and I get
locked out from doing anything. Could someone show me an example of
how to, say, change volume with amixer? I have the cli commands:
amixer sset PCM 4+
amixer sset PCM 4-
and I would like to bind those commands to Mod-Control-bracketright
and Mod-Control-bracketleft respectively, or at this point any key
combination really. Could someone show me how to bind those, for
example?
E.g.:
Before:
local_events() { true;}
After:
local_events() {
cat '!'
Key XF86AudioRaiseVolume# raise the volume
amixer sset PCM 4+
Key XF86AudioLowerVolume# lower the volume
amixer sset PCM 4-
!
}
Since volume control programs should be of the
return-almost-immediately variety, I didn't bother with the `eval
wmiir setsid [cmd] ` that most of the default commands seem to use.
(What's the point of the `eval` there?). Makes sense to use the setsid
portion in this example:
local_events() {
cat '!'
Key $ALTKEY-slash# open SSH on a host I frequently use
eval wmiir setsid $WMII_TERM -e ssh remote.example.com
!
}
--
Best,
Ben
Re: [dev] st font change
On Wed, 17 Nov 2010, MItchell Church wrote: On Wed, Nov 17, 2010 at 5:36 PM, Aurélien Aptel wrote: On Wed, Nov 17, 2010 at 10:10 PM, MItchell Church wrote: Is anyone else having trouble getting st to accept font changes? I've tried numerous strings using xfontsel, many of which work fine in other terminal programs. Is st support for this limited at the moment? Thanks. Could you be more specific? Which font are you trying to use and what's exactly the problem? Sorry for being vague. I was under the impression I could use xfontsel to create an X font name that could then be plugged into config.def.h. I tried several fonts including inconsolata, terminus, and dejavu but none of the strings produced by xfontsel are working. St recompiles successfully, but when starting up after the change I get a could not load font error and st fails to start. You're still being vague. What's the exact error message and/or exact font string you're trying to use? I just used xfontsel to pick a terminus variant: -*-terminus-*-*-*-*-14-*-*-*-*-*-iso10646-1 Changing the line in config.h from: #define FONT -misc-*-medium-r-semicondensed-*-13-*-*-*-*-*-iso10646-* to: #define FONT -*-terminus-*-*-*-*-14-*-*-*-*-*-iso10646-1 changed the font to terminus. -- Best, Ben
Re: [dev] Stripping html from email
On Mon, 23 Aug 2010, Suraj Kurapati wrote: On Mon, Aug 23, 2010 at 8:46 PM, Anthony J. Bentley wrote: Is there currently a tool or script that I can use to strip html from emails? mhshow-show-text/html: lynx -dump %F | less Lynx sucks but it sorta works well enough here, I guess. I find that w3m does a much better job of HTML to plain-text conversion than Lynx. It even renders HTML tables using Unicode box-drawing characters! http://w3m.sourceforge.net/ Wow. Thanks for that. I've always preferred 'links' to 'lynx', but 'w3m' just dethroned it. For the crappy HTML emails I deal with at work that assume everyone uses HTML-based email, I had to add an explicit type: w3m -dump -T text/html -- Best, Ben
