Re: [dwm] Stats script
On Sat, May 09, 2009 at 11:49:53AM +0200, sta...@cs.tu-berlin.de wrote: I noticed I very rarely look at most of the stuff in this status bar thou= g, so I am thinking of 2 staged status query -- e.g. date/time and temp in t= he dwm status bar; The rest can be queried 'on demand' in the console. Indeed. It's mostly just fun to create, but is never usable. Now I've only got the clock. --=20 cheers stanio_
Re: [dwm] dwm's future
On Wed, Apr 29, 2009 at 06:52:46AM +0100, Szabolcs Nagy wrote: On 4/28/09, Martin Oppegaard mar...@deathaven.com wrote: Are there any BSD-style licensed equivalents? scipy.org And use Ipython!
Re: [dwm] dwm's future
On Wed, Apr 29, 2009 at 10:35:12AM +0200, Preben Randhol wrote: On Wed, 29 Apr 2009 10:25:55 +0200 Martin Oppegaard mar...@deathaven.com wrote: I like free software. But not GPL? It's just another lock in which is getting too big.
Re: [dwm] dwm's future
On Wed, Apr 29, 2009 at 12:58:23PM +0200, Preben Randhol wrote: On Wed, 29 Apr 2009 10:45:35 +0200 Martin Oppegaard mar...@deathaven.com wrote: On Wed, Apr 29, 2009 at 10:35:12AM +0200, Preben Randhol wrote: On Wed, 29 Apr 2009 10:25:55 +0200 Martin Oppegaard mar...@deathaven.com wrote: I like free software. But not GPL? It's just another lock in which is getting too big. Sure, if you want to make proprietary software... If you want to be free from wacko organisations. -- Preben Randhol
Re: [dwm] dwm's future
On Wed, Apr 29, 2009 at 02:08:20PM +0200, Matthias-Christian Ott wrote: On Wed, Apr 29, 2009 at 01:05:40PM +0200, Martin Oppegaard wrote: On Wed, Apr 29, 2009 at 12:58:23PM +0200, Preben Randhol wrote: On Wed, 29 Apr 2009 10:45:35 +0200 Martin Oppegaard mar...@deathaven.com wrote: On Wed, Apr 29, 2009 at 10:35:12AM +0200, Preben Randhol wrote: On Wed, 29 Apr 2009 10:25:55 +0200 Martin Oppegaard mar...@deathaven.com wrote: I like free software. But not GPL? It's just another lock in which is getting too big. Sure, if you want to make proprietary software... If you want to be free from wacko organisations. Are you sure, you know what you are talking about? At least all people I know from Free Software Foundation Europe are quite friendly and really care about Free Software and fight actively against proprietary software. They are by no means wackos. Of course they are! I'm just being sceptical. But as mentioned this discussion could go on and on without a result. -- Preben Randhol Regards, Matthias-Christian
Re: [dwm] dwm's future
On Tue, Apr 28, 2009 at 10:03:47PM +0200, Preben Randhol wrote: On Tue, 28 Apr 2009 22:00:07 +0200 Preben Randhol rand...@pvv.org wrote: That said, in most cases there is now no reason no to choose Matlab over Octave. EDIT That said, in most cases there is now no reason to choose Matlab over Octave. /EDIT Are there any BSD-style licensed equivalents?
Re: [dwm] dwm's future
On Mon, Apr 27, 2009 at 11:47:19AM +0200, Preben Randhol wrote: Personally I would like to have one dwm as is, and one gdwm (or some better name) with more bells and whistles and dependencies. http://wmii.suckless.org/ Or is Wmii dead in the water?
Re: [dwm] dwm's future
On Mon, Apr 27, 2009 at 06:57:13PM +0200, Preben Randhol wrote: On Mon, 27 Apr 2009 13:51:24 +0200 Martin Oppegaard mar...@deathaven.com wrote: On Mon, Apr 27, 2009 at 11:47:19AM +0200, Preben Randhol wrote: Personally I would like to have one dwm as is, and one gdwm (or some better name) with more bells and whistles and dependencies. http://wmii.suckless.org/ Or is Wmii dead in the water? Well actually I wan't thinking of wmii as it behaves differently from dwm. I can't even remember how Wmii feels like anymore, after changing to Dwm less than a year ago.
Re: [dwm] Suckess Code Management
On Thu, Mar 12, 2009 at 03:35:18PM -0400, James Turner wrote: I'm also running 0.4a from packages on openbsd 4.4 without any issues. I haven't seen any characters get eaten. What $TERM are you running? How often do your chars get eaten? What do you mean by eaten? You type and half don't ever make it to the screen? OpenBSD version 4.4. By eaten, I mean that it looks like I'm in replace mode when I type, but the line gets shorter (eaten up buy tmux) when I undo the changes, too! If I can scroll down so that the changes gets out of the screen, the text is correct when I scroll back. I've been setting TERM to xterm-color in .zshrc for some reason, but after some testing, the problem seems to have gone away when I let TERM get set automatically, and it gets set to screen in tmux. Does that make any sense? - Martin
Re: [dwm] Suckess Code Management
On Fri, Mar 13, 2009 at 12:52:14AM -0700, David E. Thiel wrote: On Fri, Mar 13, 2009 at 07:38:24AM +0100, Martin Oppegaard wrote: On Thu, Mar 12, 2009 at 03:35:18PM -0400, James Turner wrote: I'm also running 0.4a from packages on openbsd 4.4 without any issues. I haven't seen any characters get eaten. What $TERM are you running? How often do your chars get eaten? What do you mean by eaten? You type and half don't ever make it to the screen? OpenBSD version 4.4. By eaten, I mean that it looks like I'm in replace mode when I type, but the line gets shorter (eaten up buy tmux) when I undo the changes, too! If I can scroll down so that the changes gets out of the screen, the text is correct when I scroll back. I've been setting TERM to xterm-color in .zshrc for some reason, but after some testing, the problem seems to have gone away when I let TERM get set automatically, and it gets set to screen in tmux. Does that make any sense? Try setting set-window-option -g utf8 on in your .tmux.conf and starting it with tmux -u. I had things getting gobbled all over the place in mutt before I switched to full unicode OpenBSD doesn't support utf8, so would doing this have any effect at all? In any event, I tried, and it didn't change anything. Nvi is fine when TERM is screen, crap when TERM is xterm(-color), but thanks for the tip. - Martin
Re: [dwm] Suckess Code Management
Hi! On Thu, Mar 12, 2009 at 12:30:02PM -0400, James Turner wrote: openbsd, dwm, xterm, nvi, opencvs, tmux, mutt, irssi How are tmux and nvi going along at your place? Here, tmux eat the characters, seemingly at random. mg and vim are not affected. I've tried tmux 0.4a precompiled, and 0.7 from HEAD of ports. -- James Turner BSD Group Consulting http://www.bsdgroup.org On topic: openbsd, dwm, xterm, nvi, tmux/screen, mutt, ircII/bitlbee, mpd/mpc, mplayer, opera. - Martin
Re: [dwm] Cycle urgent windows patch for dwm-4.9
On Tue, Apr 01, 2008 at 08:22:27PM -0400, Jeremy O'Brien wrote: On Sun, Mar 30, 2008 at 03:01:15PM +0200, Martin Oppegaard wrote: Have updated the patch for mercurial tip. I also add a patch which implements one layout per tag. Haven't looked at the old one, so I can't say if it's an update or not. Hi there. I tried your cycleurgent patch, and I like it alot. Only one minor problem. It won't cycle if you are on an empty tag. Not sure if that was intended or not, and I understand people won't typically be on a blank tag, but I figured you'd want to know for robustness and whatnot. Thank you. Indeed it is a design feature. Not hard to change, tho, which I will do while I fix a real bug I found with having mutiple tags selected.
Re: [dwm] Cycle urgent windows patch for dwm-4.9
Have updated the patch for mercurial tip.
I also add a patch which implements one layout per tag. Haven't looked
at the old one, so I can't say if it's an update or not.
On Thu, Mar 27, 2008 at 05:31:22PM +0100, Martin Oppegaard wrote:
Hi,
I've made a function for cycling through the windows with the urgent flag
set. The idea is that when first called, you start a cycle which on
completion will give focus back to the window which had it initially. This
window's prevtags are saved. Each call to focus() breaks the cycle, so
you don't have to complete it to continue using dwm as normal.
To be fair, I've only tested the patch with one urgent window. If you
have any ideas as to how to trigger the urgent flag manually,
please let me know.
Best regards,
Martin Oppegaard
--- dwm-4.8/dwm.c 2008-03-13 17:55:43.0 +0100
+++ mydwm-4.8/dwm.c 2008-03-27 16:34:22.0 +0100
@@ -186,6 +186,7 @@ void updatetitle(Client *c);
void updatewmhints(Client *c);
void view(const char *arg);
void viewprevtag(const char *arg); /* views previous selected tags */
+void cycleurgent(const char *arg);
int xerror(Display *dpy, XErrorEvent *ee);
int xerrordummy(Display *dpy, XErrorEvent *ee);
int xerrorstart(Display *dpy, XErrorEvent *ee);
@@ -219,6 +220,9 @@ Bool *seltags;
Client *clients = NULL;
Client *sel = NULL;
Client *stack = NULL;
+Client *initucycl; /* initialized urgent cycle */
+Bool *iucprevtags; /* the urgent-cycle initiator's previous tags */
+Bool inucycl = False; /* in urgent cycle */
Cursor cursor[CurLast];
Display *dpy;
DC dc = {0};
@@ -661,6 +665,7 @@ focus(Client *c) {
grabbuttons(c, True);
}
sel = c;
+inucycl = False;
if(c) {
XSetWindowBorder(dpy, c-win, dc.sel[ColBorder]);
XSetInputFocus(dpy, c-win, RevertToPointerRoot, CurrentTime);
@@ -1497,6 +1502,7 @@ setup(void) {
/* init tags */
seltags = emallocz(TAGSZ);
prevtags = emallocz(TAGSZ);
+iucprevtags = emallocz(TAGSZ);
seltags[0] = prevtags[0] = True;
/* init layouts */
@@ -1842,6 +1848,36 @@ viewprevtag(const char *arg) {
arrange();
}
+void
+cycleurgent(const char *arg) {
+Client *c;
+
+if(!sel)
+return;
+
+if(!inucycl) {
+initucycl = sel;
+memcpy(iucprevtags, prevtags, TAGSZ);
+}
+
+ for(c = clients; c; c = c-next) {
+if(c-isurgent) {
+memcpy(prevtags, seltags, TAGSZ);
+memcpy(seltags, c-tags, TAGSZ);
+focus(c);
+arrange();
+inucycl = True;
+
+return;
+}
+}
+
+memcpy(prevtags, iucprevtags, TAGSZ);
+memcpy(seltags, initucycl-tags, TAGSZ);
+focus(initucycl);
+arrange();
+}
+
/* There's no way to check accesses to destroyed windows, thus those cases
are
* ignored (especially on UnmapNotify's). Other types of errors call Xlibs
* default error handler, which may call exit. */
diff -r f330c3a2dc76 config.def.h
--- a/config.def.h Tue Mar 25 09:41:14 2008
+++ b/config.def.h Sat Mar 29 10:27:32 2008
@@ -54,6 +54,7 @@
{ MODKEY, XK_r, reapply,NULL },
{ MODKEY, XK_h, setmfact, -0.05
},
{ MODKEY, XK_l, setmfact, +0.05
},
+{ MODKEY, XK_u, cycleurgent,NULL },
{ MODKEY, XK_Return, zoom, NULL },
{ MODKEY, XK_Tab, viewprevtag,NULL },
{ MODKEY|ShiftMask, XK_c, killclient, NULL },
diff -r f330c3a2dc76 dwm.c
--- a/dwm.c Tue Mar 25 09:41:14 2008
+++ b/dwm.c Sat Mar 29 10:27:32 2008
@@ -202,6 +202,7 @@
void updatewmhints(Client *c);
void view(const char *arg);
void viewprevtag(const char *arg); /* views previous selected tags */
+void cycleurgent(const char *arg);
int xerror(Display *dpy, XErrorEvent *ee);
int xerrordummy(Display *dpy, XErrorEvent *ee);
int xerrorstart(Display *dpy, XErrorEvent *ee);
@@ -235,6 +236,9 @@
Client *clients = NULL;
Client *sel = NULL;
Client *stack = NULL;
+Client *initucycle = NULL; /* initiated urgent-cycle */
+Bool *iucprevtags; /* the urgent-cycle initiator's previous tags */
+Bool inucycle = False; /* in urgent-cycle */
Cursor cursor[CurLast];
Display *dpy;
DC dc = {0};
@@ -692,6 +696,7 @@
grabbuttons(c, True);
}
sel = c;
+inucycle = False;
if(c) {
XSetWindowBorder(dpy, c-win, dc.sel[ColBorder]);
XSetInputFocus(dpy, c-win, RevertToPointerRoot, CurrentTime);
@@ -1533,6 +1538,7 @@
/* init tags */
seltags = emallocz(TAGSZ);
prevtags = emallocz(TAGSZ);
+iucprevtags = emallocz(TAGSZ);
seltags[0] = prevtags[0] = True;
/* init
[dwm] Cycle urgent windows patch for dwm-4.8
Hi,
I've made a function for cycling through the windows with the urgent flag
set. The idea is that when first called, you start a cycle which on
completion will give focus back to the window which had it initially. This
window's prevtags are saved. Each call to focus() breaks the cycle, so
you don't have to complete it to continue using dwm as normal.
To be fair, I've only tested the patch with one urgent window. If you
have any ideas as to how to trigger the urgent flag manually,
please let me know.
Best regards,
Martin Oppegaard
--- dwm-4.8/dwm.c 2008-03-13 17:55:43.0 +0100
+++ mydwm-4.8/dwm.c 2008-03-27 16:34:22.0 +0100
@@ -186,6 +186,7 @@ void updatetitle(Client *c);
void updatewmhints(Client *c);
void view(const char *arg);
void viewprevtag(const char *arg); /* views previous selected tags */
+void cycleurgent(const char *arg);
int xerror(Display *dpy, XErrorEvent *ee);
int xerrordummy(Display *dpy, XErrorEvent *ee);
int xerrorstart(Display *dpy, XErrorEvent *ee);
@@ -219,6 +220,9 @@ Bool *seltags;
Client *clients = NULL;
Client *sel = NULL;
Client *stack = NULL;
+Client *initucycl; /* initialized urgent cycle */
+Bool *iucprevtags; /* the urgent-cycle initiator's previous tags */
+Bool inucycl = False; /* in urgent cycle */
Cursor cursor[CurLast];
Display *dpy;
DC dc = {0};
@@ -661,6 +665,7 @@ focus(Client *c) {
grabbuttons(c, True);
}
sel = c;
+inucycl = False;
if(c) {
XSetWindowBorder(dpy, c-win, dc.sel[ColBorder]);
XSetInputFocus(dpy, c-win, RevertToPointerRoot, CurrentTime);
@@ -1497,6 +1502,7 @@ setup(void) {
/* init tags */
seltags = emallocz(TAGSZ);
prevtags = emallocz(TAGSZ);
+iucprevtags = emallocz(TAGSZ);
seltags[0] = prevtags[0] = True;
/* init layouts */
@@ -1842,6 +1848,36 @@ viewprevtag(const char *arg) {
arrange();
}
+void
+cycleurgent(const char *arg) {
+Client *c;
+
+if(!sel)
+return;
+
+if(!inucycl) {
+initucycl = sel;
+memcpy(iucprevtags, prevtags, TAGSZ);
+}
+
+ for(c = clients; c; c = c-next) {
+if(c-isurgent) {
+memcpy(prevtags, seltags, TAGSZ);
+memcpy(seltags, c-tags, TAGSZ);
+focus(c);
+arrange();
+inucycl = True;
+
+return;
+}
+}
+
+memcpy(prevtags, iucprevtags, TAGSZ);
+memcpy(seltags, initucycl-tags, TAGSZ);
+focus(initucycl);
+arrange();
+}
+
/* There's no way to check accesses to destroyed windows, thus those cases are
* ignored (especially on UnmapNotify's). Other types of errors call Xlibs
* default error handler, which may call exit. */
