Re: [dwm] found a nice way to do the setgeom stuff
2008/3/19, Szabolcs Nagy [EMAIL PROTECTED]:
what's wrong with
void growm(const char *arg) {
mw += 20;
}
?
shouldn't it be
void growm(const char *arg) {
mw += 20;
setgeom(NULL);
}
?
But yes, I think this would be the right thing to do. This way we can
even have a check to not have mw waw. Or you could use a mwfact
global variable, so you don't lost its value when you change geoms...
--
- yiyus || JGL .
Re: [dwm] a lone client could be borderless
2008/3/21, Ralph E. Carter [EMAIL PROTECTED]: When only one client is in a workspace (or tagset, or view), it could be borderless. In the default geom, or in bottomstack, the border is unnecessary. In my favorite monocle, any border would remind that something is below. That's a good idea. -- - yiyus || JGL .
Re: [dwm] ii best practices
2008/4/1, Matthias-Christian Ott [EMAIL PROTECTED]: Anselm R. Garbe [EMAIL PROTECTED] wrote: On Tue, Apr 01, 2008 at 03:24:44PM +0200, Matthias-Christian Ott wrote: I want to start using ii for irc. What discouraged me from doing so was a proper input method. Currently I know 2 methods to effectively input text to ii: vim and dinput. I don't like both for some reason. Do you have any best practices for using ii? echo(1), I'm not using ii but sic, but I usually create a fifo for sending input to sic using echo or sometimes cat(1), if I plan to have longer conversations than the usual hello. But this would require me to write something like each time I want to send something to the channel: $ echo 'Hello' fifo # or $ cat fifo Hello^D Of course you could do: $ while true; do cat fifo; done But what about this: +---+ | | | urxvt | |tail -f fifo | | | | | |...| | input | +---+ The basic idea is to embedd the urxvt window in another window which also embedds an input window. The input window could be urxvt running a small programme or small X11 programme reading input and writing to the fifo. This is much nicer for tiling and feels more like an irc client. You could do this with screen of course. Any other ideas? What I do when I use sic is: In one dvtm window: mkfifo /tmp/sicfifo; cat /tmp/sicfifo | sic In another one: cat - /tmp/fifo And you can also write to sic with: echo blabla /tmp/sicfifo Or even have keystrokes like: echo `dmenu /dev/null` /tmp/sicfifo Or something similar, I'm not testing it. hth, -- - yiyus || JGL .
Re: [dwm] Monocle question
2008/4/4, Szabolcs Nagy [EMAIL PROTECTED]: On 4/4/08, Dashing [EMAIL PROTECTED] wrote: Hi I use monocle mode a lot, but I don't like how dialog boxes get maximized. I noticed two versions for going through the clients exist: * for(c = clients; c; c = c-next) * for(c = nexttiled(clients); c; c = nexttiled(c-next)) Why does monocle use the first and not the second? the idea was to use monocle as togglemax() which should work on floating clients as well imho monocle is a perfectly valid layout, not just as a temporary maximize in which case the second is more apropriate (i use it that way too) I also think that the second mode is better. As a matter of fact, that's what I'm currently using. If I want to maximize floating windows I just toggle floating after setting the monocle layout. e.g.: when I'm using gimp (which I do very often) sometimes I want my draw window to be maximized having the toolbars on top of it, but if monocle maximizes the toolbars windows it makes gimp unusable. For me, a floating window means: I don't want the tile algorithm to touch it. my 2 cents, -- - yiyus || JGL .
Re: [dwm] Monocle question
After looking at the 4.9 release I have a suggestion which could satisfy most of the people, in dwm.c:1071 you could change the isvisible(c) condition to (lt-isfloating || !c-isfloating) isvisible(c), this way if you want to just maximize tiled windows you just have to set the float value of monocle in config.h to False, else you will have the current behavior. What do you think? -- - yiyus || JGL .
Re: [dwm] togglemax substiute in 4.9?
2008/4/8, Anselm R. Garbe [EMAIL PROTECTED]: On Mon, Apr 07, 2008 at 01:55:29PM +0200, Joerg van den Hoff wrote: as `togglemax' seems gone in 4.9: I agree, that `monocle' is very useful (and superior). the only problem is (seems?) that one cannot easily toggle back and forth to the previous layout. rather, one needs to cycle through all 4 layouts right now, it seems. this is not so nice... question: is their a chance to get a kind of `togglemonocle' functionality into dwm without writing it myself? this would seem a frequent demand: activate monocle for some time than switch back to tiling (or whatever layout was in effect previously). What about direct layout activation using the layout symbol as setlayout argument? As for setlayout() I consider having (const char *)-1 for the previous layout, (const char *)1 for the next and NULL for toggling between the current and previous one, if any. The same concept might be adapted for setgeom as well. Any complains? I think that using the proposedlayout function as it was done in the past would be a better idea (and like it happens with tags if you use the last patch I've sent to the list), but I don't use different layouts any more, so my opinion is not important. w.r.t. to `floating': I find it always rather annoying that leaving `floating' layout, i.e. going to some tiling layout, there is no way of going back to floating while getting back the previously manually selected arrangements of windows. I admit, I use `floating' rarely, but when I do, the above behaviour comes into the way quite often. the problem with destroying floating arrangements by selecting a diferent layout is, of course, especially severe because layout changes act global. question: any chance of making `dwm' remember any `floating' positioning information on a per-window basis which would enable restoration of positions when coming back to floating layout? Actually, I consider making an exception for floating and monocle alltogether. Monocle in 5.0 will only work on the focused client and restore after each unfocus to the previous geometry. So each client will have two geometries, the current and the previous one. This allows restoring the geometry when switching from tiled to monocle and back, resp. when switching from floating to tiled and back or vice versa. At manage() time I consider, that the previous geometry is the initial geometry as it would be for the floating case. Any complains? If we are coming back to reverse geometries per client, what's the point of resizing clients in focus changes? I think this will add unnecesary complexity. But again, I don't think my opinion is important. Kind regards, -- Anselm R. Garbe http://www.suckless.org/ GPG key: 0D73F361 -- - yiyus || JGL .
Re: [dwm] togglemax substiute in 4.9?
2008/4/8, Anselm R. Garbe [EMAIL PROTECTED]: On Tue, Apr 08, 2008 at 01:35:40PM +0200, yy wrote: 2008/4/8, Anselm R. Garbe [EMAIL PROTECTED]: Any complains? If we are coming back to reverse geometries per client, what's the point of resizing clients in focus changes? I think this will add unnecesary complexity. But again, I don't think my opinion is important. What if monocle is used to work on floating clients as well? I pretty much prefer the solution of only preserving the previous window geometry of a client window and not treating floating and managed geometries differently. If monocle works on all clients, this would lead to unrevertable maximised floating clients, which I dislike. On the other hand, preserving the geometry for each layout seems to be too memory-consuming, especially because the layout algorithms are heavily dynamic. I think I didn't explain myself very well. Let's try again... To restore all the clients to their previous position and size when you change to the floating layout you will need a per client reverse geometry where you store that data, I would call it floating geometry (e.g.: fx, fy, fw, fh), setted to the initial value by manage() like you suggested or by a mouse action. Then, when you change to floating layout, all the clients are resized to that value; when you change to tiled layout, floating clients are resized to that value and tiled clients are tiled; and when you select the monocle layout all the clients (or just the tiled ones, depending on the lt-isfloating value) are resized to mox, moy, mow, moh. As a personal preference, I wouldn't restore x and y values in non floating windows. I hope to have explained my idea better this time, I can write the patch if you want to give it a try. And about the setlayout behaviour, you are right that I was thinking in the maximize toggle with Mod1-m (or the float toggle with Mod1-Space), but as I told I don't really matter. slds, -- - yiyus || JGL .
Re: [dwm] togglemax substiute in 4.9?
Well, this is my proposal in patch form. I'm not sure about the
convenience of setting fx and fy in tileresize, but you get the idea.
--
- yiyus || JGL .
diff -r 595ed1a4447c dwm.c
--- a/dwm.c Tue Apr 08 11:49:35 2008 +0100
+++ b/dwm.c Tue Apr 08 18:59:12 2008 +0200
@@ -66,6 +66,7 @@ struct Client {
struct Client {
char name[256];
int x, y, w, h;
+ int fx, fy, fw, fh;
int basew, baseh, incw, inch, maxw, maxh, minw, minh;
int minax, maxax, minay, maxay;
long flags;
@@ -285,8 +286,11 @@ arrange(void) {
Client *c;
for(c = clients; c; c = c-next)
- if(isvisible(c))
+ if(isvisible(c)) {
unban(c);
+ if(!lt-isfloating c-isfloating)
+resize(c, c-fx, c-fy, c-fw, c-fh, True);
+ }
else
ban(c);
@@ -676,7 +680,7 @@ floating(void) { /* default floating lay
for(c = clients; c; c = c-next)
if(isvisible(c))
- resize(c, c-x, c-y, c-w, c-h, True);
+ resize(c, c-fx, c-fy, c-fw, c-fh, True);
}
void
@@ -996,8 +1000,8 @@ manage(Window w, XWindowAttributes *wa)
/* geometry */
c-x = wa-x;
c-y = wa-y;
- c-w = wa-width;
- c-h = wa-height;
+ c-w = c-fw = wa-width;
+ c-h = c-fh = wa-height;
c-oldbw = wa-border_width;
if(c-w == sw c-h == sh) {
c-x = sx;
@@ -1015,6 +1019,8 @@ manage(Window w, XWindowAttributes *wa)
c-y = wy;
c-bw = BORDERPX;
}
+ c-fx = c-x;
+ c-fy = c-y;
wc.border_width = c-bw;
XConfigureWindow(dpy, w, CWBorderWidth, wc);
@@ -1110,8 +1116,11 @@ movemouse(Client *c) {
ny = wy + wh - c-h - 2 * c-bw;
if(!c-isfloating !lt-isfloating (abs(nx - c-x) SNAP || abs(ny - c-y) SNAP))
togglefloating(NULL);
- if((lt-isfloating) || c-isfloating)
+ if((lt-isfloating) || c-isfloating) {
resize(c, nx, ny, c-w, c-h, False);
+c-fx = nx;
+c-fy = ny;
+ }
break;
}
}
@@ -1273,8 +1282,11 @@ resizemouse(Client *c) {
nh = 1;
if(!c-isfloating !lt-isfloating (abs(nw - c-w) SNAP || abs(nh - c-h) SNAP))
togglefloating(NULL);
- if((lt-isfloating) || c-isfloating)
+ if((lt-isfloating) || c-isfloating) {
resize(c, c-x, c-y, nw, nh, True);
+c-fw = nw;
+c-fh = nh;
+ }
break;
}
}
@@ -1657,6 +1669,8 @@ tileresize(Client *c, int x, int y, int
if((RESIZEHINTS) ((c-h bh) || (c-h h) || (c-w bh) || (c-w w)))
/* client doesn't accept size constraints */
resize(c, x, y, w, h, False);
+ c-fx = x;
+ c-fy = y;
}
void
@@ -1856,6 +1870,8 @@ view(const char *arg) {
memcpy(seltags, tmp, TAGSZ);
arrange();
}
+ else
+ viewprevtag(NULL);
}
void
Re: [dwm] togglemax substiute in 4.9?
2008/4/9, Anselm R. Garbe [EMAIL PROTECTED]: On Tue, Apr 08, 2008 at 07:52:03PM +0200, Matthias-Christian Ott wrote: yy [EMAIL PROTECTED] wrote: Well, this is my proposal in patch form. I'm not sure about the convenience of setting fx and fy in tileresize, but you get the idea. I posted a similar patch on 31st March, so it is wasted effort. Hehe, indeed your both solutions are very close. I'm not a fan of restoring floating geometries, that's why I didn't look at Matthias' patch; I just wanted to show how once you implement it, you don't need to change geometries in focus() to have the wanted behaviour in monocle. The difference between his patch and mine is that mine also restore geometries when coming back from monocle. Anyway, I have already done some changes (but I have them in my laptop, which I don't have at hand now). One is a check to not modify geometries with the mouse while in monocle layout when lt-isfloating is true, the other ones are some little improvements in the previous patch (I think I even removed some loc). If you are interested I will send them to the list this afternoon. greets, -- - yiyus || JGL .
[dwm] fgeom patch
As discussed before, this is the patch with the floating geometry
functionality. I removed some loc in restack, but I had to add more in
other places to correctly manage mouse actions when in monocle layout
(isn't a bug the current possibility of moving and resizing windows
while in monocle layout?).
Basically, the patch makes dwm to remember floating geometries when
you change to tiled or monocle layout.
I'm not sure about setting fx and fy on tileresize(), but note that if
you don't do it you will need to add them in movemouse() and
resizemouse() before togglefloating().
I don't really like the idea of remembering floating geometries (at
least floating positions), as I don't like the idea of resizing
floating clients in the tile layout (as in monocle) but this is how I
would implement it.
I'd like to hear what do you think, greetings,
--
- yiyus || JGL .
PS: The patch adds 15 lines to dwm.c, but 2 of them comes from my
previous patch to viewprevtag() when you try to view the only selected
tag(s).
diff -r 595ed1a4447c dwm.c
--- a/dwm.c Tue Apr 08 11:49:35 2008 +0100
+++ b/dwm.c Wed Apr 09 19:18:24 2008 +0200
@@ -66,6 +66,7 @@ struct Client {
struct Client {
char name[256];
int x, y, w, h;
+ int fx, fy, fw, fh;
int basew, baseh, incw, inch, maxw, maxh, minw, minh;
int minax, maxax, minay, maxay;
long flags;
@@ -285,8 +286,11 @@ arrange(void) {
Client *c;
for(c = clients; c; c = c-next)
- if(isvisible(c))
+ if(isvisible(c)) {
unban(c);
+ if(!lt-isfloating c-isfloating)
+resize(c, c-fx, c-fy, c-fw, c-fh, True);
+ }
else
ban(c);
@@ -676,7 +680,7 @@ floating(void) { /* default floating lay
for(c = clients; c; c = c-next)
if(isvisible(c))
- resize(c, c-x, c-y, c-w, c-h, True);
+ resize(c, c-fx, c-fy, c-fw, c-fh, True);
}
void
@@ -996,8 +1000,8 @@ manage(Window w, XWindowAttributes *wa)
/* geometry */
c-x = wa-x;
c-y = wa-y;
- c-w = wa-width;
- c-h = wa-height;
+ c-w = c-fw = wa-width;
+ c-h = c-fh = wa-height;
c-oldbw = wa-border_width;
if(c-w == sw c-h == sh) {
c-x = sx;
@@ -1015,6 +1019,8 @@ manage(Window w, XWindowAttributes *wa)
c-y = wy;
c-bw = BORDERPX;
}
+ c-fx = c-x;
+ c-fy = c-y;
wc.border_width = c-bw;
XConfigureWindow(dpy, w, CWBorderWidth, wc);
@@ -1068,8 +1074,12 @@ monocle(void) {
Client *c;
for(c = clients; c; c = c-next)
- if((lt-isfloating || !c-isfloating) isvisible(c))
- resize(c, mox, moy, mow - 2 * c-bw, moh - 2 * c-bw, RESIZEHINTS);
+ if(isvisible(c)) {
+ if(lt-isfloating)
+resize(c, mox, moy, mow - 2 * c-bw, moh - 2 * c-bw, RESIZEHINTS);
+ else if(!c-isfloating)
+tileresize(c, mox, moy, mow - 2 * c-bw, moh - 2 * c-bw);
+ }
}
void
@@ -1110,8 +1120,11 @@ movemouse(Client *c) {
ny = wy + wh - c-h - 2 * c-bw;
if(!c-isfloating !lt-isfloating (abs(nx - c-x) SNAP || abs(ny - c-y) SNAP))
togglefloating(NULL);
- if((lt-isfloating) || c-isfloating)
+ if((lt-arrange == floating) || (!lt-isfloating c-isfloating)) {
resize(c, nx, ny, c-w, c-h, False);
+c-fx = nx;
+c-fy = ny;
+ }
break;
}
}
@@ -1273,8 +1286,11 @@ resizemouse(Client *c) {
nh = 1;
if(!c-isfloating !lt-isfloating (abs(nw - c-w) SNAP || abs(nh - c-h) SNAP))
togglefloating(NULL);
- if((lt-isfloating) || c-isfloating)
+ if((lt-arrange == floating) || (!lt-isfloating c-isfloating)) {
resize(c, c-x, c-y, nw, nh, True);
+c-fw = nw;
+c-fh = nh;
+ }
break;
}
}
@@ -1294,16 +1310,11 @@ restack(void) {
if(!lt-isfloating) {
wc.stack_mode = Below;
wc.sibling = barwin;
- if(!sel-isfloating) {
- XConfigureWindow(dpy, sel-win, CWSibling|CWStackMode, wc);
- wc.sibling = sel-win;
- }
- for(c = nexttiled(clients); c; c = nexttiled(c-next)) {
- if(c == sel)
-continue;
- XConfigureWindow(dpy, c-win, CWSibling|CWStackMode, wc);
- wc.sibling = c-win;
- }
+ for(c = stack; c; c = c-snext)
+ if(!c-isfloating isvisible(c)) {
+XConfigureWindow(dpy, c-win, CWSibling|CWStackMode, wc);
+wc.sibling = c-win;
+ }
}
XSync(dpy, False);
while(XCheckMaskEvent(dpy, EnterWindowMask, ev));
@@ -1657,6 +1668,8 @@ tileresize(Client *c, int x, int y, int
if((RESIZEHINTS) ((c-h bh) || (c-h h) || (c-w bh) || (c-w w)))
/* client doesn't accept size constraints */
resize(c, x, y, w, h, False);
+ c-fx = x;
+ c-fy = y;
}
void
@@ -1856,6 +1869,8 @@ view(const char *arg) {
memcpy(seltags, tmp, TAGSZ);
arrange();
}
+ else
+ viewprevtag(NULL);
}
void
Re: [dwm] fgeom patch
2008/4/14, Anselm R. Garbe [EMAIL PROTECTED]:
On Wed, Apr 09, 2008 at 07:41:53PM +0200, yy wrote:
As discussed before, this is the patch with the floating geometry
functionality. I removed some loc in restack, but I had to add more in
other places to correctly manage mouse actions when in monocle layout
I like the restack() simplification.
I have noticed that it lets you to get rid of floating(), saving some
loc. Have a look at the attached patch.
(isn't a bug the current possibility of moving and resizing windows
while in monocle layout?).
I'd like to keep mouse manipulations dependend on
lt-isfloating, instead of performing a hardcoded floating
layout check.
Well, since I have completely removed the floating layout, it is done
in base on lt-isfloating in the new patch.
Basically, the patch makes dwm to remember floating geometries when
you change to tiled or monocle layout.
I'm not sure about setting fx and fy on tileresize(), but note that if
you don't do it you will need to add them in movemouse() and
resizemouse() before togglefloating().
Hmm I don't think that tileresize is the right place for setting
fx, and fy. Instead fx/fy/fw/fh should be used depending on
lt-isfloating in resize and the layout itself, that's why I'd
consider doing the following in struct Client:
typdef struct {
...
int x[2], y[2], w[2], h[2];
...
} Client;
#define BOOLTOIDX(x) (x) ? 1 : 0
And then in resize:
c-x[BOOLTOIDX(lt-isfloating || c-isfloating)] = x;
...
etc.
Kind regards,
I will think about it once you implement it in hg tip, this new
version of the patch doesn't touch the client floating geometry in
tileresize(), I think it works like expected, but I see the possible
simplification with the BOOLTOIDX method. And you would have the
possibility of having a #define REMEMBERFLOATS in config.h and then
BOOLTOIDX(REMEMBERFLOATS (lt-isfloating || c-isfloating)), so
that this is configurable... (just rambling).
slds,
--
- yiyus || JGL .
diff -r 595ed1a4447c config.def.h
--- a/config.def.h Tue Apr 08 11:49:35 2008 +0100
+++ b/config.def.h Mon Apr 14 18:27:12 2008 +0200
@@ -36,7 +36,7 @@ Layout layouts[] = {
/* symbol function isfloating */
{ []=, tilev, False }, /* first entry is default */
{ []|, tileh, False },
- { , floating, True },
+ { , NULL, True },
{ [M], monocle, True },
};
diff -r 595ed1a4447c dwm.c
--- a/dwm.c Tue Apr 08 11:49:35 2008 +0100
+++ b/dwm.c Mon Apr 14 18:27:12 2008 +0200
@@ -66,6 +66,7 @@ struct Client {
struct Client {
char name[256];
int x, y, w, h;
+ int fx, fy, fw, fh;
int basew, baseh, incw, inch, maxw, maxh, minw, minh;
int minax, maxax, minay, maxay;
long flags;
@@ -285,13 +286,17 @@ arrange(void) {
Client *c;
for(c = clients; c; c = c-next)
- if(isvisible(c))
+ if(isvisible(c)) {
unban(c);
+ if(lt-isfloating || !lt-isfloating c-isfloating)
+resize(c, c-fx, c-fy, c-fw, c-fh, True);
+ }
else
ban(c);
focus(NULL);
- lt-arrange();
+ if(lt-arrange)
+ lt-arrange();
restack();
}
@@ -359,7 +364,7 @@ buttonpress(XEvent *e) {
movemouse(c);
}
else if(ev-button == Button2) {
- if((floating != lt-arrange) c-isfloating)
+ if(!lt-isfloating c-isfloating)
togglefloating(NULL);
else
zoom(NULL);
@@ -668,15 +673,6 @@ expose(XEvent *e) {
if(ev-count == 0 (ev-window == barwin))
drawbar();
-}
-
-void
-floating(void) { /* default floating layout */
- Client *c;
-
- for(c = clients; c; c = c-next)
- if(isvisible(c))
- resize(c, c-x, c-y, c-w, c-h, True);
}
void
@@ -996,8 +992,8 @@ manage(Window w, XWindowAttributes *wa)
/* geometry */
c-x = wa-x;
c-y = wa-y;
- c-w = wa-width;
- c-h = wa-height;
+ c-w = c-fw = wa-width;
+ c-h = c-fh = wa-height;
c-oldbw = wa-border_width;
if(c-w == sw c-h == sh) {
c-x = sx;
@@ -1015,6 +1011,8 @@ manage(Window w, XWindowAttributes *wa)
c-y = wy;
c-bw = BORDERPX;
}
+ c-fx = c-x;
+ c-fy = c-y;
wc.border_width = c-bw;
XConfigureWindow(dpy, w, CWBorderWidth, wc);
@@ -1068,8 +1066,12 @@ monocle(void) {
Client *c;
for(c = clients; c; c = c-next)
- if((lt-isfloating || !c-isfloating) isvisible(c))
- resize(c, mox, moy, mow - 2 * c-bw, moh - 2 * c-bw, RESIZEHINTS);
+ if(isvisible(c)) {
+ if(lt-isfloating)
+resize(c, mox, moy, mow - 2 * c-bw, moh - 2 * c-bw, RESIZEHINTS);
+ else if(!c-isfloating)
+tileresize(c, mox, moy, mow - 2 * c-bw, moh - 2 * c-bw);
+ }
}
void
@@ -1110,8 +1112,11 @@ movemouse(Client *c) {
ny = wy + wh - c-h - 2 * c-bw;
if(!c-isfloating !lt-isfloating (abs(nx - c-x) SNAP || abs(ny - c-y) SNAP))
togglefloating(NULL);
- if((lt-isfloating) || c-isfloating)
+ if(lt-isfloating || (!lt-isfloating c-isfloating)) {
+c-fx = nx;
+c-fy = ny;
resize(c, nx, ny, c-w, c-h, False);
+ }
break;
}
}
@@ -1271,10 +1276,16 @@ resizemouse(Client *c) {
nw = 1
Re: [dwm] fgeom patch
2008/4/14, yy [EMAIL PROTECTED]:
2008/4/14, Anselm R. Garbe [EMAIL PROTECTED]:
On Wed, Apr 09, 2008 at 07:41:53PM +0200, yy wrote:
As discussed before, this is the patch with the floating geometry
functionality. I removed some loc in restack, but I had to add more in
other places to correctly manage mouse actions when in monocle layout
I like the restack() simplification.
I have noticed that it lets you to get rid of floating(), saving some
loc. Have a look at the attached patch.
(isn't a bug the current possibility of moving and resizing windows
while in monocle layout?).
I'd like to keep mouse manipulations dependend on
lt-isfloating, instead of performing a hardcoded floating
layout check.
Well, since I have completely removed the floating layout, it is done
in base on lt-isfloating in the new patch.
Basically, the patch makes dwm to remember floating geometries when
you change to tiled or monocle layout.
I'm not sure about setting fx and fy on tileresize(), but note that if
you don't do it you will need to add them in movemouse() and
resizemouse() before togglefloating().
Hmm I don't think that tileresize is the right place for setting
fx, and fy. Instead fx/fy/fw/fh should be used depending on
lt-isfloating in resize and the layout itself, that's why I'd
consider doing the following in struct Client:
typdef struct {
...
int x[2], y[2], w[2], h[2];
...
} Client;
#define BOOLTOIDX(x) (x) ? 1 : 0
And then in resize:
c-x[BOOLTOIDX(lt-isfloating || c-isfloating)] = x;
...
etc.
Kind regards,
I will think about it once you implement it in hg tip, this new
version of the patch doesn't touch the client floating geometry in
tileresize(), I think it works like expected, but I see the possible
simplification with the BOOLTOIDX method. And you would have the
possibility of having a #define REMEMBERFLOATS in config.h and then
BOOLTOIDX(REMEMBERFLOATS (lt-isfloating || c-isfloating)), so
that this is configurable... (just rambling).
slds,
--
Sorry for the noise, but there were some little errors in the previous
patch. Now it only adds 2 loc (plus 2 from my previous patch, plus 3
layout examples in config.def.h, they should be commented).
--
- yiyus || JGL .
diff -r 595ed1a4447c config.def.h
--- a/config.def.h Tue Apr 08 11:49:35 2008 +0100
+++ b/config.def.h Mon Apr 14 20:14:32 2008 +0200
@@ -35,8 +35,11 @@ Layout layouts[] = {
Layout layouts[] = {
/* symbol function isfloating */
{ []=, tilev, False }, /* first entry is default */
+ { =, tilev, True },
{ []|, tileh, False },
- { , floating, True },
+ { |, tileh, True },
+ { , NULL, True },
+ { [m], monocle, False },
{ [M], monocle, True },
};
diff -r 595ed1a4447c dwm.c
--- a/dwm.c Tue Apr 08 11:49:35 2008 +0100
+++ b/dwm.c Mon Apr 14 20:14:32 2008 +0200
@@ -66,6 +66,7 @@ struct Client {
struct Client {
char name[256];
int x, y, w, h;
+ int fx, fy, fw, fh;
int basew, baseh, incw, inch, maxw, maxh, minw, minh;
int minax, maxax, minay, maxay;
long flags;
@@ -285,13 +286,17 @@ arrange(void) {
Client *c;
for(c = clients; c; c = c-next)
- if(isvisible(c))
+ if(isvisible(c)) {
unban(c);
+ if(lt-isfloating || c-isfloating)
+resize(c, c-fx, c-fy, c-fw, c-fh, True);
+ }
else
ban(c);
focus(NULL);
- lt-arrange();
+ if(lt-arrange)
+ lt-arrange();
restack();
}
@@ -359,7 +364,7 @@ buttonpress(XEvent *e) {
movemouse(c);
}
else if(ev-button == Button2) {
- if((floating != lt-arrange) c-isfloating)
+ if(!lt-isfloating c-isfloating)
togglefloating(NULL);
else
zoom(NULL);
@@ -668,15 +673,6 @@ expose(XEvent *e) {
if(ev-count == 0 (ev-window == barwin))
drawbar();
-}
-
-void
-floating(void) { /* default floating layout */
- Client *c;
-
- for(c = clients; c; c = c-next)
- if(isvisible(c))
- resize(c, c-x, c-y, c-w, c-h, True);
}
void
@@ -996,8 +992,8 @@ manage(Window w, XWindowAttributes *wa)
/* geometry */
c-x = wa-x;
c-y = wa-y;
- c-w = wa-width;
- c-h = wa-height;
+ c-w = c-fw = wa-width;
+ c-h = c-fh = wa-height;
c-oldbw = wa-border_width;
if(c-w == sw c-h == sh) {
c-x = sx;
@@ -1015,6 +1011,8 @@ manage(Window w, XWindowAttributes *wa)
c-y = wy;
c-bw = BORDERPX;
}
+ c-fx = c-x;
+ c-fy = c-y;
wc.border_width = c-bw;
XConfigureWindow(dpy, w, CWBorderWidth, wc);
@@ -1068,7 +1066,7 @@ monocle(void) {
Client *c;
for(c = clients; c; c = c-next)
- if((lt-isfloating || !c-isfloating) isvisible(c))
+ if((lt-isfloating || !c-isfloating) isvisible(c)) {
resize(c, mox, moy, mow - 2 * c-bw, moh - 2 * c-bw, RESIZEHINTS);
}
@@ -1110,8 +1108,11 @@ movemouse(Client *c) {
ny = wy + wh - c-h - 2 * c-bw;
if(!c-isfloating !lt-isfloating (abs(nx - c-x) SNAP || abs(ny - c-y) SNAP
Re: [dwm] fgeom patch
There was an error in monocle, and the floating() definition hadn't
been removed... (ok, ok, yesterday it was not my day...). I have also
changed zoom() so that it does an arrange if lt-isfloating or
sel-isfloating; this way, after having manually resized windows while
in [M] (or = or |) you can rearrange your windows without
toggling layouts. I think the changes (which now only adds one loc if
you don't count the example layouts) allows much more flexibility in
dwm, especially in floating layouts (now you can have floating layouts
to arrange your windows in a grid, for example), and I won't need
defines to not remember floating layout (I can use =).
Well, now I will really wait to see what you have to say, going back
to plan9,,, sorry again for all this noise.
--
- yiyus || JGL .
diff -r 595ed1a4447c config.def.h
--- a/config.def.h Tue Apr 08 11:49:35 2008 +0100
+++ b/config.def.h Tue Apr 15 11:38:28 2008 +0200
@@ -35,8 +35,11 @@ Layout layouts[] = {
Layout layouts[] = {
/* symbol function isfloating */
{ []=, tilev, False }, /* first entry is default */
+ { =, tilev, True },
{ []|, tileh, False },
- { , floating, True },
+ { |, tileh, True },
+ { , NULL, True },
+ { [m], monocle, False },
{ [M], monocle, True },
};
diff -r 595ed1a4447c dwm.c
--- a/dwm.c Tue Apr 08 11:49:35 2008 +0100
+++ b/dwm.c Tue Apr 15 11:38:28 2008 +0200
@@ -66,6 +66,7 @@ struct Client {
struct Client {
char name[256];
int x, y, w, h;
+ int fx, fy, fw, fh;
int basew, baseh, incw, inch, maxw, maxh, minw, minh;
int minax, maxax, minay, maxay;
long flags;
@@ -142,7 +143,6 @@ void enternotify(XEvent *e);
void enternotify(XEvent *e);
void eprint(const char *errstr, ...);
void expose(XEvent *e);
-void floating(void); /* default floating layout */
void focus(Client *c);
void focusin(XEvent *e);
void focusnext(const char *arg);
@@ -285,13 +285,17 @@ arrange(void) {
Client *c;
for(c = clients; c; c = c-next)
- if(isvisible(c))
+ if(isvisible(c)) {
unban(c);
+ if(lt-isfloating || c-isfloating)
+resize(c, c-fx, c-fy, c-fw, c-fh, True);
+ }
else
ban(c);
focus(NULL);
- lt-arrange();
+ if(lt-arrange)
+ lt-arrange();
restack();
}
@@ -359,7 +363,7 @@ buttonpress(XEvent *e) {
movemouse(c);
}
else if(ev-button == Button2) {
- if((floating != lt-arrange) c-isfloating)
+ if(!lt-isfloating c-isfloating)
togglefloating(NULL);
else
zoom(NULL);
@@ -668,15 +672,6 @@ expose(XEvent *e) {
if(ev-count == 0 (ev-window == barwin))
drawbar();
-}
-
-void
-floating(void) { /* default floating layout */
- Client *c;
-
- for(c = clients; c; c = c-next)
- if(isvisible(c))
- resize(c, c-x, c-y, c-w, c-h, True);
}
void
@@ -996,8 +991,8 @@ manage(Window w, XWindowAttributes *wa)
/* geometry */
c-x = wa-x;
c-y = wa-y;
- c-w = wa-width;
- c-h = wa-height;
+ c-w = c-fw = wa-width;
+ c-h = c-fh = wa-height;
c-oldbw = wa-border_width;
if(c-w == sw c-h == sh) {
c-x = sx;
@@ -1015,6 +1010,8 @@ manage(Window w, XWindowAttributes *wa)
c-y = wy;
c-bw = BORDERPX;
}
+ c-fx = c-x;
+ c-fy = c-y;
wc.border_width = c-bw;
XConfigureWindow(dpy, w, CWBorderWidth, wc);
@@ -1110,8 +1107,11 @@ movemouse(Client *c) {
ny = wy + wh - c-h - 2 * c-bw;
if(!c-isfloating !lt-isfloating (abs(nx - c-x) SNAP || abs(ny - c-y) SNAP))
togglefloating(NULL);
- if((lt-isfloating) || c-isfloating)
+ if(lt-isfloating || c-isfloating) {
+c-fx = nx;
+c-fy = ny;
resize(c, nx, ny, c-w, c-h, False);
+ }
break;
}
}
@@ -1271,10 +1271,16 @@ resizemouse(Client *c) {
nw = 1;
if((nh = ev.xmotion.y - ocy - 2 * c-bw + 1) = 0)
nh = 1;
- if(!c-isfloating !lt-isfloating (abs(nw - c-w) SNAP || abs(nh - c-h) SNAP))
+ if(!c-isfloating !lt-isfloating (abs(nw - c-w) SNAP || abs(nh - c-h) SNAP)) {
+c-fx = c-x;
+c-fy = c-y;
togglefloating(NULL);
- if((lt-isfloating) || c-isfloating)
+ }
+ if(lt-isfloating || c-isfloating) {
resize(c, c-x, c-y, nw, nh, True);
+c-fw = nw;
+c-fh = nh;
+ }
break;
}
}
@@ -1294,16 +1300,11 @@ restack(void) {
if(!lt-isfloating) {
wc.stack_mode = Below;
wc.sibling = barwin;
- if(!sel-isfloating) {
- XConfigureWindow(dpy, sel-win, CWSibling|CWStackMode, wc);
- wc.sibling = sel-win;
- }
- for(c = nexttiled(clients); c; c = nexttiled(c-next)) {
- if(c == sel)
-continue;
- XConfigureWindow(dpy, c-win, CWSibling|CWStackMode, wc);
- wc.sibling = c-win;
- }
+ for(c = stack; c; c = c-snext)
+ if(!c-isfloating isvisible(c)) {
+XConfigureWindow(dpy, c-win, CWSibling|CWStackMode, wc);
+wc.sibling = c-win;
+ }
}
XSync(dpy, False);
while(XCheckMaskEvent(dpy, EnterWindowMask, ev));
@@ -1856,6 +1857,8 @@ view(const char *arg) {
memcpy(seltags, tmp, TAGSZ);
arrange();
}
+ else
+ viewprevtag(NULL);
}
void
@@ -1903,14 +1906,14 @@ zoom(const char *arg) {
zoom(const char *arg) {
Client *c = sel;
Re: [dwm] faster focus to client
2008/4/17, pancake [EMAIL PROTECTED]:
What do you think about this feature? I think that could be really
interesting.
When you have lot of windows opened it's mostly tedious to focus a desired
window
with the keyboard. So why not tag windows with a key and make them accessible
in a faster way?
My idea is to create this code structure:
void tagclient(char *);
void focustag(char *);
You can setup a keybinding for each function and then store a single char
inside
the Client structure to make it accessible with it. And we can also use the
title
of the window or a property like floating for selecting the next client to be
focused.
For example. Doing focustag(); we will toggle between the first client in
the
list of the selected tags that are floating and non-floating clients. Like
in wmii :)
If we call clienttag(M); we will focus the client tagged as 'M' or with a
title
name starting with 'M' like mplayer.
Another possibility is to call clienttag(-) and make dwm capture the next
key
pressed and use it as argument focus it.
I don't really think this is a good design concept, but derivated ideas are
welcome!
--pancake
Well, we have already got tags in dwm, I don't think we need more. As
a simple solution, you could just add this to the end of view() (you
will need to declare c too):
for(c = clients; c !c-tags[idxoftag(arg)]; c = c-next);
focus(c);
And you could have tags for lots of letter in your keyboard. I never
lose windows (I don't use many of them, and I focus mostly with the
mouse), but I understand it can be a problem for some people. Of
course, it wouldn't always work with my patch to view the previous
tags, but you get the idea.
Another option is having this in config.h:
{ MODKEY|ShiftMask, XK_j,
focusnext, NULL },
{ MODKEY|ShiftMask, XK_j,
focusnext, NULL },
{ MODKEY|ShiftMask, XK_j,
focusnext, NULL },
{ MODKEY|ShiftMask, XK_j,
focusnext, NULL },
so you can advance several clients with only one key stroke.
hth,
--
- yiyus || JGL .
Re: [dwm] Yet another simplification, this time sel/prevtags
2008/4/20, Anselm R. Garbe [EMAIL PROTECTED]: On Sun, Apr 20, 2008 at 06:05:50PM +0200, Premysl Hruby wrote: attached patch makes one array for both sel and prevtags. So there is no need to swap them in memory in view() as we only change seltags pointer to point viewtags[0] or viewtags[1]. It also with little change can support arbitrary number of saved tags set (3 save position can be usable, with modkey-shift-tab going on next state in queue). I like this solution and applied it with a slightly changed order of variable declarations. I intend to declare the variables in groups of same types. Kind regards, -- Anselm R. Garbe http://www.suckless.org/ GPG key: 0D73F361 I like this change, good work Premysl! But once you are using the array, you don't need seltags any more. The attached patch saves 2 or 3 loc. It also includes the functionality of my patch to see prevtags, but if you do the XOR inside memcpy you can save another line of code. I have also changed a little your notation (because I don't like underscores in variable names), but maybe you can think of better names. I think I will like dwm 5.0... -- - yiyus || JGL . tagset.diff Description: Binary data
Re: [dwm] Yet another simplification, this time sel/prevtags
2008/4/20, Premysl Hruby [EMAIL PROTECTED]:
On (20/04/08 21:49), yy wrote:
To: dynamic window manager dwm@suckless.org
From: yy [EMAIL PROTECTED]
Subject: Re: [dwm] Yet another simplification, this time sel/prevtags
Reply-To: dynamic window manager dwm@suckless.org
List-Id: dynamic window manager dwm.suckless.org
I like this change, good work Premysl! But once you are using the
array, you don't need seltags any more. The attached patch saves 2 or
3 loc. It also includes the functionality of my patch to see prevtags,
but if you do the XOR inside memcpy you can save another line of code.
I have also changed a little your notation (because I don't like
underscores in variable names), but maybe you can think of better
names.
I think I will like dwm 5.0...
Hi
- if(memcmp(seltags, tmp, TAGSZ) != 0) {
- seltags = viewtags[viewtags_set ^= 1]; /* toggle tagset */
- memcpy(seltags, tmp, TAGSZ);
- arrange();
- }
+ seltags ^= 1; /* toggle sel tagset */
+ if(memcmp(tagset[seltags ^ 1], tmp, TAGSZ) != 0)
+ memcpy(tagset[seltags], tmp, TAGSZ);
+ arrange();
This doesn't do same thing, as seltags is always toggled, even if
current and new tagset are same. So this will broke that change only if
differ behaviour or I miss something? :)
If we will throw away this behaviour, things can be even more simpler.
We then can substitute whole view with:
void
view(const char *arg) {
seltags ^= 1;
memset(tagset[seltag], (NULL == arg), TAGSZ);
tagset[seltag][idxoftag(arg)] = True;
arrange();
}
(memset can be used, because tags are always only test if they are zero
or nonzero, so it doesn't matter that tagset[i][j] (because Bool is defined
as int) can be something like 0x01010101 on x86)
-Ph
The idea is to have the same behavior that with my patch from April
7th. I like to view the previous tags when there is no difference.
This way you can temporally see one tag (or all of them) in a
convenient way. To sum up, the behavior would be: change if differ,
else viewprevtag Try it, please. This feature has become a must-have
for me. If this is not desired you could do memcpy(tagset[seltags ^=
1], tmp, TAGSZ) and remove the seltags ^= 1; line. I tried to explain
it in my previous message, I hope it is clearer now.
--
- yiyus || JGL .
Re: [dwm] faster focus to client
I have found an useful tip related to this idea, if you are using the patch I submitted yesterday (or any of the previous versions) to see the previous tags when you try to see the currently selected tags. I'll explain it with an example: you have clients with tags 1, 2 and 3, and you are viewing these three tags. Now, if you press Mod1+1 twice you will be focusing the first client with tag 1, if you press Mod2+2 twice you will be focusing the first client with tag 2, etc. This way, if you define enough tags in your config.h for the clients that you want to access quickly, you can focus them with just two key strokes. You can do it now with Mod1+Tab, but it is a bit less comfortable. As a side note, I have always wanted to give it a try to dynamic tags in dwm, and I will probably write a patch once 5.0 is released, just to see how it feels. OTOH, I think the needed complexity won't be well worth, but let's see... hth, -- - yiyus || JGL .
Re: [dwm] [PATCH] Add support for on-start actions
2008/4/26 Jules Villard [EMAIL PROTECTED]:
Hi all,
This patch adds the ability to perform user-defined actions on
startup. In particular, you can launch some applications like a bunch
of terms, a browser, you name it... or select a specific tag. I found
a need for it because I always perform the same actions when I start
X :) As the patch is very small --it only adds a structure and a
small loop in dwm.c, amounting to 9 lines of code-- I'm (perhaps
boldly) hoping that you might find it interesting too and consider it
for inclusion.
For my personal use, I have something similar to the following snippet
of code in config.h:
-8---
/* tagging */
const char tags[][MAXTAGLEN] = { 1, 2, 3, 4, #, zik, www };
Rule rules[] = {
/* classinstancetitle tags ref
isfloating */
{ Firefox,NULL, NULL, tags[6],False
},
{ rxvt, NULL, ncmpc,tags[5],False
},
{ rxvt, NULL, alsamixer,tags[5],False
},
{ rxvt, NULL, start,tags[0],False
},
{ rxvt, NULL, sudo, tags[4],False
},
};
/* actions to be performed on startup */
Start start[] = {
/* function argument */
{ spawn,exec rxvt -e mutt }, /* tagged 1 */
{ spawn,exec rxvt -e screen irssi }, /* same */
{ spawn,exec rxvt -e alsamixer },/* tagged zik */
{ spawn,exec rxvt -e sudo su - },/* tagged # */
{ spawn,exec firefox }, /* tagged www */
/* tagged zik and zoomed */
{ spawn,exec rxvt -e ncmpc },
/* tagged 1 and zoomed */
{ spawn,exec rxvt -ls -title start },
/* now select tag 4 to type my password */
{ view, tags[4]},
};
-8---
This allows me to start my session with 3 terms tagged 1: mutt and
irssi are stacked on the right-hand side and an empty term is readied
on the left-hand side. Timing is important, so the last term is
spawned some time after the first two to be the last term indeed and
get the zoom. Likewise, some applications are launched between the
alsamixer and the ncmpc instances, so that the latter ends up getting
the zoom. Moreover, since I like to start seeing tag 4, which
corresponds to my sudo'd term --otherwise I tend to forget to type my
password-- I force the tagging of the third term I want with tag 1
by assigning that term a special title (rxvt -title start) which I add
to the rules. This term might otherwise end up being spawned with
tag 4.
I think this really is a corner case and that you might not need to
be bothered with such a level of details, e.g. if you do not mind
having to re-tag some windows by hand. I think my main point is that
basic usage --for instance launching two terms, a browser and ncmpc at
startup-- is very intuitive and that you can achieve more complex ones
without heroic efforts, the other point being that the patch ended up
being ridiculously simple.
Thanks for reading this long email, -p1 patch against 4.9 follows.
Cheers,
Jules
I see your point, but IMHO .xinitrc is a better place to start
applications on startup. About tags, for me it would be better a
boolean visibleonstartup variable in the tag definition, but I don't
find too uncomfortable having to toggle 1 or 2 tag when I start the
computer. OTOH your patch is clean and easy to understand.
greets,
--
- yiyus || JGL .
Re: [dwm] Yet another simplification, this time sel/prevtags
2008/4/27 Anselm R. Garbe [EMAIL PROTECTED]:
On Sun, Apr 27, 2008 at 07:41:08PM +0200, Anselm R. Garbe wrote:
On Sun, Apr 20, 2008 at 10:24:32PM +0200, Premysl Hruby wrote:
void
view(const char *arg) {
seltags ^= 1;
memset(tagset[seltag], (NULL == arg), TAGSZ);
tagset[seltag][idxoftag(arg)] = True;
arrange();
}
I simplified view() accordingly.
With the current change in mind, do we still need viewprev()?
Kind regards,
--
Anselm R. Garbe http://www.suckless.org/ GPG key: 0D73F361
After the last change in hg tip, viewprev is the only way to view the
previous tags, the change when trying to view the currently selected
tag is not working any more, if you remove viewprev you can then
remove all the tagset stuff. Another thing, now if you press twice in
a tag to view it you will lose your previous tags, I don't think
that's the expected behavior.
--
- yiyus || JGL .
Re: [dwm] snapping bugs with multiple screens
I don't have a dualhead setup to test, but in case you cannot move the mouse pointer out of the monitor borders you have a very easy solution: wrap the mouse to the nearest window corner at the begining of movemouse() (I wrote a patch for this once), then you will always align your windows with the borders of the monitor. If there is a way to not let the mouse pointer going outside of the window area during mousemove (I know you can limit the pointer to a window, but I don't know if you can define a region of the root window) then you could completely remove snap. The only remaining issue would be positioning a window in the barrier between monitors, but this solution could be better than no snaping at all, and not too complicated. hth, -- - yiyus || JGL .
Re: [dwm] Suggestion float my next window
2008/5/13, Tri PLC [EMAIL PROTECTED]: Hi It's a suggestion to create a float next windows feature. I think this has been discussed before. The problem is that you cannot know who is opening the next window, so if a popup dialog appears in that moment you won't have the expected behaviour (actually the problem is not dwm related, but an old X window problem). -- - yiyus || JGL .
Re: [dwm] wildcard in client rules tags ref
2008/5/15 Eric Davis [EMAIL PROTECTED]:
On Thu, May 15, 2008 at 11:56:02AM +0200, Anselm R. Garbe wrote:
On Tue, May 13, 2008 at 09:06:22PM -0700, Eric Davis wrote:
DWM used to support regular expressions in the tags ref for client
rules. I agree that the feature was overkill but it was nice to be able
to say * so a client is on all tags. I used this for background
notification popups from scripts with gxmessage.
Is it possible to add a simple glob indicator back to DWM that specifies
all tags? Or is there another way to do this that I overlooked...?
See attached patch, however I'm not sure I like this approach
for the mainstream dwm.
If you want the behavior it is possible with the following
approach already in mainstream dwm, but you might not like it:
{ NULL, gxmessage, NULL, tags[0], True },
{ NULL, gxmessage, NULL, tags[1], True },
{ NULL, gxmessage, NULL, tags[2], True },
{ NULL, gxmessage, NULL, tags[3], True },
...
{ NULL, gxmessage, NULL, tags[8], True },
Sometimes the simplest approaches are greatly overlooked! Having the
multiple tag rules works great and I think is a good solution.
Note that, for me, you're patch caused dwm to hang. It wouldn't take
any keyboard input and no gxmessage windows were shown... but dwm did
respond to HUP and came back to life.
Another solution which might be even better is to use dzen.
Thanks,
- e
Of course it crashed, did you correct the typo? The i++ in the for
loop should be j++
--
- yiyus || JGL .
Re: [dwm] Documentation!
While I partly agree with your critics, I think they are not very helpful (with all the respect). The 2 or 3 characters variable names have been there since the beginning to define geometries, I don't understand what the problem is, and I also find the 2kloc limit somewhat stupid, but it has shown itself to be a good limit after all and when we have been near to it in the past, it has been time to remove features. Maybe a reorganization of the code is what is needed. I think it should be more uniform: sometimes you have toggles, sometimes you have set functions, almost every function does different things with NULL arguments (this is the most unpredictable thing, IMO),... I remember when dwm was going in the wrong direction with nmaster and it was discussed in the list what features could be removed, and after getting rid of it, window titles, etc, dwm was prettier than ever. I think it is time to do it again. This is a list of what I don't like/use in dwm: - Geom stuff (already removed, I know), though I'm concerned people with 2 monitors need a solution. - Different layouts, the only one I occasionally use is monocle, but because of it we needed(?) the ugly stuff of lt-isfloating and remember floating geometries. The only use I do of the floating layout is to raise a tiled window... - I don't like at all remembering floating geometries (and I wrote the patch, heh!) - I have never used the reapply thing with Mod+R, but I can live with it. So, to sum up, what I think is stopping dwm is a really good solution for xinerama setups and maximize/monocle (maybe we could try with Anselm's idea of restoring geometries in focus changes? I could give it a try...). Another interesting idea could be a list in the web of past dwm releases with the features of each one, while there are no important bugs I don't see any problem with using an old dwm. Well, enough talking for now, let's write some patches, regards, -- - yiyus || JGL .
[dwm] [patch] domax (was: Documentation!)
As I told in my last message, I have implemented maximizations in a different way. It adds 3 loc and removes some flexibility, but I think it makes the code clearer. With this patch, dwm doesn't remember floating windows any more. Notice that in order to maximize windows you can use Mod+M or the right mouse button in the tile symbol (which will then become inverted). I don't know if it should go into main or not, I just wanted to try it... be care because I didn't have time to do much testing. greets, -- - yiyus || JGL . dwm-5.0-domax.diff Description: Binary data
Re: [dwm] [patch] domax (was: Documentation!)
2008/5/17 yy [EMAIL PROTECTED]: As I told in my last message, I have implemented maximizations in a different way. It adds 3 loc and removes some flexibility, but I think it makes the code clearer. With this patch, dwm doesn't remember floating windows any more. Notice that in order to maximize windows you can use Mod+M or the right mouse button in the tile symbol (which will then become inverted). I don't know if it should go into main or not, I just wanted to try it... be care because I didn't have time to do much testing. greets, -- - yiyus || JGL . I forgot to make you a question: why am I getting EnterNotify events maximizing windows (even if you don't raise them)? Or in other words, why don't you get them when zooming with the cursor in the stack area? -- - yiyus || JGL .
Re: [dwm] [patch] domax (was: Documentation!)
2008/5/17 Anselm R. Garbe [EMAIL PROTECTED]: We did similiar work today ;) Yes :) I'm very happy with your last changes. ( -- I'd like to see your domax patch as patch against the most recent hg tip. Attached, now it is even better, because it doesn't let you to move/resize windows while in domax. But it lets you to zoom windows, maybe you want to change this. The reason why you don't receive the enternotify events in zoom() is because of restack() which performs the following loop at the end: XSync(dpy, False); while(XCheckMaskEvent(dpy, EnterWindowMask, ev)); I recommend doing it this way, instead of counting enternotify's because it enforces our focus policy much cleaner than all this quirky enternotify counting in other WMs. I have tried it this way, but there are 2 problems: 1. If RESIZEHINTS is True you can focus the other windows if you move the pointer to the bottom of the screen, which is annoying. 2. The maximized window is resized when you move the pointer to the bar window, causing some flicker. So, I came back to the check in enternotify(), but feel free to find a better solution. Kind regards, -- Anselm R. Garbe http://www.suckless.org/ GPG key: 0D73F361 salu! -- - yiyus || JGL . dwm-5.0-domax.diff Description: Binary data
[dwm] buttonpress patch
This is the buttonpress patch I have just talked about (incremental to the domax patch). It adds a lot of new functionality, i.e.: - It reverts the old zooming with middle mouse button (or toggling floating if not in tiled layout) with a click inside the window (+ModKey) or in the bar. - With the mouse wheel in the bar you focus prev/next client. - Moving and resizing clients with buttons 1 and 3 also works with a simple click (without modifier key) inside the bar, at the right of the layout symbol. - When moving windows, the pointer is wrapped to the top-left corner of the client, this is also a convenience to go to a window from the bar after focusing it with the wheel. And all this in few lines and without damaging too much the code. I know dwm is by definition keyboard driven, but if there is any interest I will update the patch after the 5.0 release (adding the corresponding patch for the man page). I find it pretty handy. I also have patches to view previous tags when trying to view the current tags (instead of losing the revert state) and to move windows on screen when you focus a partly offscreen client (this one is like having an ultra wide monitor :). With these changes I have everything I want, but I won't send patches for 5.0 to the list if there isn't any interest. Have fun, -- - yiyus || JGL . dwm-5.0-buttonpress.diff Description: Binary data
Re: [dwm] Freedom (was: Re: sic ipv6 patch)
Being pragmatic, I think it is better the MIT style license. e.g.: somebody wants to take the tile algorithm from dwm for some proprietary project (yes, there are projects where the code cannot be shared), if dwm is GPL they will just copy it without telling to anybody, to avoid further legal problems; but if it is MIT they can tell it is your code without any problem (and even report you bugs/improvements, if that's the case). Anyway, I think this whole discussion is pointless, because while Anselm releases under the MIT licenses you can just take it and re-release under GPL, if that makes you feel better. Just my 2 cents, -- - yiyus || JGL .
Re: [dwm] using bitaray for tags (PATCH)
2008/5/20, Premysl Hruby [EMAIL PROTECTED]: Hi, This is realization of Gottox's proposal discuted on IRC today. It handles tags not as Bool [], but as bit-array saved in int. There's only one problem, as I don't find easy solution (in compile time) for check if there's no more tags than sizeof(int)*8. Maybe it can be asserted with someting like (possibly global, compiler take it away as it's not used anywhere): static char too_many_tags_test[sizeof(int)*8 - LENGTH(tags)]; Has anyone better solution? -Ph -- Premysl Anydot Hruby, http://www.redrum.cz/ But, why so many macros? I don't see TMASK(p) better than 1 (p), the same with TOGGLE and ISSET, and I don't understand SET at all, you are not using the v for anything (it is always 1), why not t = 1 (p) ? And about the int size, I think that since tags are defined in source code it shouldn't be a problem. The only problem I see is that the style doesn't fit too much with the rest of the dwm code, but global Bools could also be changed to a global bitarray with some Enum. -- - yiyus || JGL .
Re: [dwm] bitarray and void *arg (was: using bitaray for tags (PATCH))
2008/5/22, Anselm R. Garbe [EMAIL PROTECTED]:
Applied.
Thanks a lot!
void
-toggletag(const char *arg) {
- unsigned int i, j;
+toggletag(void *arg) {
+ int i, m = *(int *)arg;
+ for(i = 0; i sizeof(int) * 8; i++)
+ fputc(m 1 i ? '1' : '0', stdout);
+ puts();
+ for(i = 0; i sizeof(int) * 8; i++)
+ fputc(TAGMASK 1 i ? '1' : '0', stdout);
+ puts(aaa);
Debug party? :)
--
- yiyus || JGL .
[dwm] tags definition
I was too tired of defining 4 different keys for each tag inside
config.h, so I created a TAGKEYS macro. I vote for its inclusion in
main dwm. I was thinking about having the (uint[]){ 1 Tag} inside
the macro, or even (uint[]){ 1 (Key - 1)} , but since it is in
config.h all that is up to you and I think this is the most standard
way (the idea is having some consistency with the other key
definitions).
Attached is a modified config.def.h, I hope you like it,
--
- yiyus || JGL .
config.h
Description: Binary data
[dwm] domax (again)
domax is much better this way, using XMoveResizeWindow. I have removed ban/unban and merged it into arrange and added my tagkeys macro, so at the end it removes 25 lines to the dwm source. Some questions: 1. wouldn't it be a good idea moving the tagset definition to config.h? So everybody can chose the initial tags he wants. 2. has anybody tried any of my patches? greets, -- - yiyus || JGL . dwm-5.0-domax+tagkeys Description: Binary data
Re: [dwm] Bug in zoom()
2008/5/29, Anselm R. Garbe [EMAIL PROTECTED]: - if(!lt-arrange || sel-isfloating) + if(!sel || !lt-arrange || ismax || sel-isfloating) return; Just a little remark. Now that maximizations are done in arrange() the || ismax check here is not neccessary any more (it will never happen: if(ismax) ... else if(ismax) ...). Is there any pending questions about dwm 5.0 or can we consider current hg tip as a release candidate? -- - yiyus || JGL .
[dwm] getting rid of viewprev()
Writing my patch to automatically see previous tags (attached, extremely simple) I have noticed that you can get rid of viewprev() at the same time that you simplify view(). The diff is attached too (the only difference between both patches is an additional check in the if statement in autoviewprev.diff). -- - yiyus || JGL . noviewprev.diff Description: Binary data autoviewprev.diff Description: Binary data
Re: [dwm] getting rid of viewprev()
2008/5/31 Anselm R. Garbe [EMAIL PROTECTED]: On Sat, May 31, 2008 at 05:43:36PM +0200, yy wrote: Writing my patch to automatically see previous tags (attached, extremely simple) I have noticed that you can get rid of viewprev() at the same time that you simplify view(). The diff is attached too (the only difference between both patches is an additional check in the if statement in autoviewprev.diff). So the autoviewprev patch is equal to Mod1-Tab if the same view() is called twice? I tend to prefer the noviewprev.diff. Kind regards, -- Anselm R. Garbe http://www.suckless.org/ GPG key: 0D73F361 Well, that's the idea. I find it very useful to temporarily see one tag (mainly with the mouse). I realize that it is not an evident feature and could cause some confusion and, though I have really get used to it, this could be one of those things that fit better in a patch (but I'd suggest everybody to give it a try). -- - yiyus || JGL .
Re: [dwm] center scaling
2008/6/4, pancake [EMAIL PROTECTED]: btw...mouse-related patches are not easy to be modular on current dwm. Do you plan to do it for the next release? together with the 'mouse-clicks' patch? --pancake I have written a patch to generalize mouse actions in the same way that keys. I was waitting for the 5.0 release before submitting it to the list, but if you are interested I can send it this evening. -- - yiyus || JGL .
Re: [dwm] patch
2008/6/10, Anselm R. Garbe [EMAIL PROTECTED]: On Tue, Jun 10, 2008 at 10:58:40AM +0200, Premysl Hruby wrote: On (10/06/08 10:51), Anselm R. Garbe wrote: To: dynamic window manager dwm@suckless.org From: Anselm R. Garbe [EMAIL PROTECTED] Subject: Re: [dwm] patch On Tue, Jun 10, 2008 at 10:38:55AM +0200, Premysl Hruby wrote: - reintroducion of union Arg I don't like this, because intialization gets slightly cumbersome, I really prefer void * here. Imho it's much more cleaner then these const void *, is it don't hinder the type etc. And initialization looks cleaner too. And union has been created just for this usage, as replace for type magic. Well for the predifined builtin key handlers this is right. However, const void * allows extensions to use structs of certain kinds directly as input, whereas the union needs to be redefined in such cases. However a solution to this problem is of course introducing void * as part of the union. So I'm open for introducing this change. The problem is, we should do that before 5.0 to keep updates to config.h at a minimum after 5.0. Kind regards, -- Anselm R. Garbe http://www.suckless.org/ GPG key: 0D73F361 If ther is plans to add mouse actions definitions after 5.0 I'm in favor of this change, since it will simplify it in config.h too. Greets, -- - yiyus || JGL .
Re: [dwm] feature freeze, please test
About the mouse warping issue we have discussed in #dwm, forget it, I
can get the desired behavior with a little config.h modifications.
I add:
void
warptosel(const Arg *arg) {
if(sel)
XWarpPointer(dpy, None, sel-win, 0, 0, 0, 0, 0, 0);
}
and then, in buttons definitions:
{ ClkWinTitle, 0, Button1,warptosel,
{0} },
{ ClkWinTitle, 0, Button1,movemouse,
{0} },
{ ClkWinTitle, 0, Button3,resizemouse,
{0} },
{ ClkWinTitle, 0, Button4,focusstack,
{.i = -1 } },
{ ClkWinTitle, 0, Button5,focusstack,
{.i = +1 } },
and that's all. So I'd suggest to not touch dwm.c any more, and this
message will stay here as a reference for other people if they are
interested.
greets,
--
- yiyus || JGL .
Re: [dwm] click to focus no longer works
2008/6/14 Johannes Hofmann [EMAIL PROTECTED]:
Hi,
with current tip (118ea4f4f554) it seems no longer possible to focus
a client by clicking it with the left mouse button.
To reproduce move the mouse over the stack, focus the main window
using MODKEY-k, close that window e.g. using Ctrl-d. Now it is not
possible to focus the window under the mouse by clicking on it.
Regards,
Johannes
It's true, this is something I changed in my dwm after sending the
patch to the list (I didn't know it was going to be applied). This (in
buttonpress()) will do the trick:
else if((c = getclient(ev-window))) {
click = ClkClientWin;
focus(c);
}
--
- yiyus || JGL .
Re: [dwm] dwm-5.0 / dmenu-3.7
I don't know how nobody found this one sooner. It has happened to me just after the announcement, but there is a bug in 5.0. You shouldn't be able to toggle tags when there is only one selected (a client without tags will be lost for ever after an arrange...). In other words, toggleview and toggletag need one more check. OTOH, I have been using it for some time without even noticing it. I'm attaching my config.h, just in case somebody is interested in the pointer wrapping function. -- - yiyus || JGL . config.h Description: Binary data
Re: [dwm] New layout
2008/7/2, Anselm R. Garbe [EMAIL PROTECTED]:
Looking into your patch I more and more come to the conclusion
to add an extra void *aux field to Client for extensions like
this (or the previous extensions proposed in the toggle{vert,horiz} patches.
With this in 5.1 you could easily keep your patchset upwards
compatible if you use Client-aux to store all the extensions to
Client.
What do you think?
Then you could separate all your functions into dwmii.c which is
included in config.h instead.
Kind regards,
Anselm
I like the idea, I think it would be well worth to give it a try.
--
- yiyus || JGL .
Re: [dwm] New layout
2008/7/2, Anselm R. Garbe [EMAIL PROTECTED]:
Another thing:
I don't think that the design of dwm fits well with the
layouting concept of wmii. This is because dwm depends on the
assumption that the layout algorithm in use is dynamic enough to
deal with arbitrary amounts of windows which are singly-linked,
whereas wmii basically has more high-level data structures to
organize windows and assumes the column concept in its
definition. Thus its layout algorithm is less dynamic
unfortunately.
An algorithm I have in mind is more dwm-wmii like is somethink
like:
AACCBB
CC
DDCCEE
This layout only shows 5 windows at maximum, and it uses slight
overlapping to achieve a better screen real estate, the amount
of overlapping could depend on mfact. The focused window is C
and any focusstack() action will end up in a re-arrange().
C is always the list center. It scales for less than 5 windows
as well.
Just a random idea.
--
Anselm R. Garbe http://www.suckless.org/ GPG key: 0D73F361
Well, if we start with random ideas, I have one: we could have a new
lt[sellt]-restack (probably renamed to some better name I cannot
imagine now) and if it is NULL the floating behaviour will be used.
This way it would be easy to have layouts where focusstack rearrange
windows, or having a monocle where floating windows are resized.
Just an idea, but I would be glad to write tha patch if somebody finds
a better name than restack for the function.
--
- yiyus || JGL .
Re: [dwm] Being not so elitist
From The Free On-line Dictionary of Computing (27 SEP 03) : elite 1. A term used to describe skilled crackers or hackers, or their deeds. In the last sense, compare to elegant. So, I think we can tell this community is elitist, and dunno why it should be a problem. OTOH it could be a bit arrogant too, but that's the way I like it. -- - yiyus || JGL .
Re: [dwm] Tiled window moved/resized with mouse misbehaves. Bug?
2008/8/8 RCarter [EMAIL PROTECTED]: 5.1, with or without the patches I'm using: If a tiled window is resized or moved with the mouse, it stops obeying layout changes, remaining where it is and on top of other windows until the application is restarted. The other windows obey, but remain underneath. This is an unexpected behavior; shouldn't it be prevented? In the past, wasn't an automatic switch to floating layout done on these mouse-actions? If a tiled window is resized or moved with the mouse it becomes floating, so not obeying layout changes is the expected behaviour. I think it makes sense, and is correctly documented in the man page. BTW, you don't need to restart dwm in order to make that window tiled again, you can toggle the isfloating flag of the client with Mod+Space or with Mod+Button2. -- - yiyus || JGL .
[dwm] some proposed changes
Attached there is a patch with some changes to dwm.c. It uses XLowerWindow and XMoveResizeWindow instead of configure functions in restack() and resize() respectively. I suposse there is a good reason to use configure here, but since Anselm is on holidays I ask here if somebody knows the reason. I'm using it this way and have found no problems so far but they could appear with tricky programs. It removes some loc and I think the code is a bit more consistent this way. The other change is a new click option: ClkTagButton, this way you can have buttons in the tags to see previous tags or to see all of them. Anyway, the comment in config.def.h should be corrected to explain the current behaviour with ClkTagBar. My config.h is attached too, with some interesting custom functions. Greets, -- - yiyus || JGL . noconfigure.diff Description: Binary data config.h Description: Binary data
Re: [dwm] some proposed changes
2008/8/10 Premysl Hruby [EMAIL PROTECTED]: Hi, reason for using XConfigureWindow in restack() is setting border_width of client (and this is the only reason for not using XMoveResizeWindow as you propose). Any of my windows change window border width since it is setted in manage(), but anyway we could use XSetWindowBorderWidth() here. I don't know if it would be better (it saves some loc, but nothing significant), but I wonder why not. XLowerWindow was used in past, but it makes windows flickering in monocle layout, as windows are pushed to the bottom of the stack. Solution currently in use prevent flickering. I hadn't noticed the flickering, and though I could really live with it I see the point now. -Ph -- Premysl Anydot Hruby, http://www.redrum.cz/ Thanks for your answers, -- - yiyus || JGL .
[dwm] Custom functions
I have found the way to highly customize dwm to my taste just adding some custom functions to config.h, without touching dwm.c. Since some of this functions could be interesting for somebody I have added my config.h to the wiki, in the customisation section. (With this configuration, dwm is the most usable with the mouse window manager I have never tried). http://www.suckless.org:8000/dwm/customisation/customfuncs.html I hope somebody will find this useful. Have a nice weekend, -- - yiyus || JGL .
Re: [dwm] Feature request: any way to change default values in config
In my opinion, moving the seltags definition to config.h would be the right thing to do. This way, with the right mouse and keys configuration you could achieve things like, for example, having a tag always visible. It is not something I'm gonna use myself, but moving the definition of the variable won't hurt anybody ;) hth, -- - yiyus || JGL .
Re: [dwm] dwm: request to discuss
2008/8/28 Maxim Vuets [EMAIL PROTECTED]:
I think that mouse is not really important for dwm status bar.
Well, I think it is. I use dwm exclusively with the mouse without any
changes to dwm.c (have a look at the customisation/customfunctions
section in the wiki to see my config.h)
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.
You don't need any changes in dwm.c to achieve this functionality. You
just have to define your keys your way. e.g. (not tested) :
#define WORKSPACEKEYS(KEY,TAGS, LAYOUT, FACT) \
{ MODKEY, KEY, view, {.ui = TAGS}
}, \
{ MODKEY, KEY, setlayout, {.v =
layouts[LAYOUT]} }, \
{ MODKEY, KEY, setmfact, {.f = 1.FACT}
},
And later:
WORKSPACEKEYS( XK_q, 1 0 | 1
1 | 1 2, 0, 55)
WORKSPACEKEYS( XK_w, 1 2 | 1
3, 1, 70)
...
This way you could chose workspaces with q, w,...
You could also write a little function to set this parameters and call
arrange just once to avoid flickering, or use a variable to be able to
cycle through them or change the values per workspace. I just want to
show that you can add all this without any complication.
OTOH, I have tried some similar approachs in the past (patching dwm)
and at the end I always come back to the original dwm tagging. If it
is easy enough choosing any set of tags (with view or tag), change
layouts, etc. having artifacts to remember the different states will
just complicate things.
Look, one of the reasons why you want to keep status bar is that it's more
simple to interact with it via mouse. It uses only mouse. But there is no way
to manage windows using only mouse, because you need to hold some meta
key, you know. Such title bars bring a possibility to manage windows
w/o keyboard (;
--
Hoc est simplicissimum!
maxim.vuets.name
As I have told before I completely use dwm _only_ with the mouse. I
use the clicks in the window title (or the root window) to call
move/resize window functions. Again, have a look at my config.h in the
customisation section if you want an example.
Why does everybody think dwm is not configurable? ;)
hth,
--
- yiyus || JGL .
Re: [dwm] dwm: request to discuss
Just to show you (and all the people who come here asking for workspaces from time to time) I have attached a config.h with a workspaces implementation. It hasn't been tested very much, but I think it works. Now you can change workspace with Mod+Tab (and Mod+Shift+Tab) or with the mouse wheel on the tags. But as I have told in my previous message in this thread I think this is over complicated. You will probably have problems to remember what the different workspaces are (since you will probably modify it), and you will finish changing your tags and layout instead of going to another workspace. Anyway, I think it is a good reference to have in the ml. If somebody uses it, please report me any problems because I'm going to add it to the wiki (maybe this weekend). Though I won't maintain it for future releases, as I told IMO this is not a good idea, but it is a good example of how easy is to extend dwm. rgds, -- - yiyus || JGL . config.h Description: Binary data
Re: [dwm] dwm: request to discuss
2008/8/30 Maxim Vuets [EMAIL PROTECTED]: 2008/8/29, yy [EMAIL PROTECTED]: Just to show you (and all the people who come here asking for workspaces from time to time) I have attached a config.h with a workspaces implementation. It hasn't been tested very much, but I think it works. Now you can change workspace with Mod+Tab (and Mod+Shift+Tab) or with the mouse wheel on the tags. Cool patch. Thank you. Almost that I want (: Add to the wiki. -- Hoc est simplicissimum! maxim.vuets.name http://www.suckless.org:8000/dwm/patches/workspaces.html There was a bug in the config.h that I attached to my other message, it was not setting mfact to 0 for non tiled layouts. -- - yiyus || JGL .
[dwm] Re: [patch] arguments for ClkTagBar functions
and this is the patch :) sorry, -- - yiyus || JGL . dwm-5.2-tagbararg.diff Description: Binary data
Re: [dwm] what about 'st'?
2008/9/5 Donald Chai [EMAIL PROTECTED]: 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. My display looked like a farmland some time ago. I just had key bindings in dwm to open xterms with a given background color in a given screen window. It looked like this: http://y-i-y-u-s.deviantart.com/art/dwm-4-4-1-65928966 -- - yiyus || JGL .
Re: [dwm] slowness in moving windows OR vlc/mplayer crash
2008/9/9 Anselm R Garbe [EMAIL PROTECTED]: The window moving/resizing code might be changed after dwm-5.2 which I plan to release tonight. My favorite is just keeping a server grab during the resize/move to prevent clients from redrawing since they won't receive any events during that time. The current code however has been implemented as is on purpose, because I kind of liked the idea to see terminal refreshing themselves during resizals. But I might never actually used this, since I'm normally in tiled mode only... Kind regards, --Anselm I really need the redraw to manage gimp windows, sometimes I just have to see what they are doing to know the size I want, I have the same problem with image viewers, openoffice, etc, but if the server grab solution is simpler I won't matter maintaining a patch for that, maybe a patch where you can define in rules if you want incremental resizes for a given window class or something... BTW, I think 5.2 will be a great release (and I haven't had any problems with mplayer so far). Greets, -- - yiyus || JGL .
Re: [dwm] How to detect TAG activity?
2008/11/4 Premysl Hruby [EMAIL PROTECTED]: On (04/11/08 16:37), yy wrote: To: dwm mail list dwm@suckless.org From: yy [EMAIL PROTECTED] Subject: Re: [dwm] How to detect TAG activity? Reply-To: dwm mail list dwm@suckless.org List-Id: dwm mail list dwm.suckless.org 2008/11/4 markus schnalke [EMAIL PROTECTED]: I think it is worth to add this script (or an improved version) with explanations to the wiki. Any volunteer? (I don't have time atm.) meillo I could do it. I can submit it today or tomorrow, but then I think wmu should be included in the hg repository (the script could go inside the tarball). This is up to Anselm, of course. -- - yiyus || JGL . In which repository do you mean that wmu should be included? I can add this script to wmu's repo, as it is pretty handy. -Ph -- Premysl Anydot Hruby, http://www.redrum.cz/ There are 2 possible solutions: 1. Include the script in your repo, and we link to it from some dwm wiki page. 2. Move wmu repository to suckless hg, with the other tools. I just want to avoid having the script and description in the suckless wiki and the code in your own repository. I'd choose number 2, though it is not a big deal anyway ;) -- - yiyus || JGL .
Re: [dwm] make setlayout toggle
After a quick look, I think the last check in the first if should be arg-v != lt[sellt^1] -- - yiyus || JGL .
Re: [dwm] questions about DWM source
2008/11/10 robert hickman [EMAIL PROTECTED]: Then I came across this pese of code in the manage function: Window trans = None; if(XGetTransientForHint(dpy, wind, trans)) t = getclient(trans); if(t) clien-tags = t-tags; else applyrules(clien); what exactly does this do? and why is it doing it? Thanks. The XGetTransientForHint function will tell us if the window to be managed (wind) is a child window, in such a case the parent client is stored in t. When the window has a parent, parent's tags will be applied to the child (clien-tags = t-tags), else rules are applied (as defined in config.h). And btw, wx, wy, etc. comes from wax, way, etc for window area. It is perfectly documented in dwm.c. Using sort names for geometric variables is a common rule in many coding style guides. hth, -- - yiyus || JGL .
Re: [dwm] patch to hide sticky indicators, and add nofocus windows
You could do something very similar just caling unmanage. The problem
is you can't call functions from the rules definition (though you
could use a keybinding to unmanage windows).
It could be interesting to modify applyrules and the Rule definition
in order to call functions, like buttons and keys:
typedef struct {
const char *class;
const char *instance;
const char *title;
void (*func)(const Arg *);
const Arg arg;
} Rule;
Of course, you would also have to tweak manage in order to make it work.
I'm not sure it would be a very good idea, but it probably is not
difficult to try. As a side effect, somebody could control dwm
creating windows with well chosen names (and probably somebody would
write a program to do it), I would find such a hack very unelegant...
--
- yiyus || JGL .
[dwm] urgent windows border
The attached patch set a different border color for windows with the urgency hint flag set. The flag will be removed when the client is focused (instead of when it is visible). It saves some lines of code (and can save some more moving clearurgent() to focus(), since it is used only there). have fun, -- - yiyus || JGL . urgentborder.diff Description: Binary data
[dwm] Re: urgent windows border
It had a bug. We don't want to set as urgent the sel client. Sorry for the noise. -- - yiyus || JGL . urgentborder.diff Description: Binary data
Re: [dwm] Re: urgent windows border
2008/12/4 Anselm R Garbe [EMAIL PROTECTED]: I have mixed feelings about this patch. Does someone has strong arguments that this would be a good idea for upstream dwm? I also have mixed feelings... I wrote it because I didn't see urgent windows when they were visible (I know this sentence looks stupid, I know, but you get it), and since the implementation resulted simpler I decided to post it here. There is another middle-way solution which you could be interested in: move the clearurgent() call to focus(), like in my patch, but forget about the urgent border color (which is what makes the patch uglier). This way, you could save some loc while getting the functionality of notifying urgent clients in viewed tags. If you have no time or whatever I can modify my patch and send it to the list tomorrow. OTOH, I will probably maintain the patch for the border color, at least for the moment. But I won't post it here or anything if nobody else is interested. hth, -- - yiyus || JGL .
Re: [dwm] Re: urgent windows border
2008/12/4 Tinou [EMAIL PROTECTED]: On Thu, Dec 4, 2008 at 9:31 PM, yy [EMAIL PROTECTED] wrote: Besides the border color, I think this patch is really useful when using the monocle layout. As clearing the urgent flag one could miss that not visible urgent window. Though it's only visible viewing another tag... Not really. Maybe I didn't explain myself very well in my last mail, but although you remove the border color from the patch I submitted you will still be able to see it in the status bar. In fact, no code needs to be added to current dwm to do this, since what it does is invert the color. Leaving the flag set until the window is focused is everything you need. Of course, the inverted color in the tag label doesn't give you so much information as your taskbar idea (which looks nice), but is probably more than enough for the common use case. -- - yiyus || JGL .
Re: [dwm] dwm-5.3
2008/12/5 Guillaume Quintin [EMAIL PROTECTED]: On Fri, 5 Dec 2008 08:33:44 + Here is my .xinitrc : while true do echo `date` sleep 1 done | dwm A bit off-topic, but, why the echo? A simple date should do it. -- - yiyus || JGL .
[dwm] applyrules()
Great 5.3.1 release!
What about this little change in applyrules?
@@ -259,7 +259,7 @@
(!r-class || (ch.res_class
strstr(ch.res_class, r-class)))
(!r-instance || (ch.res_name
strstr(ch.res_name, r-instance {
c-isfloating = r-isfloating;
- c-tags |= r-tags TAGMASK;
+ c-tags |= r-tags TAGMASK ? r-tags
TAGMASK : tagset[seltags];
}
}
if(ch.res_class)
This way you can define rules like:
{ MPlayer,NULL, NULL, 0,True },
{ MPlayer,NULL, NULL, 1 6, True },
and have mplayer tagged to the currently selected tags and to the 6th
tag, for example. This trick is very convenient to group windows by
categories, I do it with image viewers, music players... and I think
it makes clearer the rules definition. With the current
implementation, if r-tags is 0 the result of applying that rule is
undefined depending on the previous rules. The only problem I can see
is that somebody could be doing:
{ NULL, NULL, NULL, 0,True },
to treat new windows like float by default, by I doubt there's anybody
here doing such a thing...
--
- yiyus || JGL .
applyrules.diff
Description: Binary data
Re: [dwm] Re: urgent windows border
There is little error here. It is not working as expected in 5.3.1. This patch fixes it. -- - yiyus || JGL . urgencyfix.diff Description: Binary data
Re: [dwm] Re: urgent windows border
2008/12/6 yy [EMAIL PROTECTED]: There is little error here. It is not working as expected in 5.3.1. This patch fixes it. Be care if you apply this, I forgot to remove my PREFIX (which is /usr) in config.mk -- - yiyus || JGL .
Re: [dwm] DWM 5.3.1 and Xinerama
2008/12/7 Donald Chai [EMAIL PROTECTED]: 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. I have a projector at home (best thing for movies since dolby and they are cheaper every day) and this is basicly what I do. I just mirror the screen in the laptop and the proyector and close the laptop, actually that's one of the reasons I control everything in dwm with the mouse. But you don't have to worry about xinerama or xandr, dwm will adapt to the new situation because the root window will be resized if resolution changes. If you want to do something fancier than duplicating the screen that's another question. -- - yiyus || JGL .
Re: [dwm] dwm-5.3
2008/12/9 Szabolcs Nagy [EMAIL PROTECTED]: On 12/8/08, Neale Pickett [EMAIL PROTECTED] wrote: I sort of like the idea of using X properties. You could use xprop to one of the most ununixy interfaces man XGetWindowProperty I agree 100%. The idea of X properties can seem appealing at first, but it is a pain to use them. I really doubt you can remove loc with it. Anyway, I feel curiosity for a patch in this direction, it could be good to have it for reference, to compare. If you don't try, you'll never know for sure. -- - yiyus || JGL .
Re: [dwm] xprop patch
2008/12/9 Anselm R Garbe [EMAIL PROTECTED]: 2008/12/9 Neale Pickett [EMAIL PROTECTED]: I very much like this patch. I realized right away that I would never again need to restart dwm when I work on my status script. When it dies, I can just start it up again without restarting DWM. Someone could even have multiple programs running to update the status text. It removes the need for the readin variable: you either set the property or you don't. I dislike X properties, however I like your patch a lot and consider it making mainstream, since it simplifies dwm a lot and fixes a lot of issues. dwm depends on X anyways, so for the status text mechanism to happen, it's the simpler method. This would be 40 if the property were hard coded to XA_WM_NAME. I left in a comment to use a property named DWM_STATUS instead of XA_WM_NAME, so people could play with it easily, but I think XA_WM_NAME is ultimately the right way to do it. XA_WM_NAME is the way to go. I have the same opinion. Now that I see the patch it looks so clear that I also vote for its inclusion in main. I was completely wrong about this, my apologies to Mr.Pickett ;) -- - yiyus || JGL .
Re: [dwm] dwm and dualhead
The problem with xinerama is that no general implementation is possible. You can have a tile algorithm for both screens or two different ones, you can share tags or they can be different, it could be possible for the user to move windows between screens or not, etc. And what do you do with the status bar? two different bars, just one bar in one screen, or an special bar which for example has tags, tile symbol and window title in one screen and use the other one for status text? This lack of generality is a good reason to drop xinerama from dwm at first. It actually is quite easy to get screens info with very few modifications to updategeom() and then work on your own implementation from there. In an ideal world, some good patches would have appeared on this list and, if somebody finds a great _general_ solution (which seems difficult, but I would be love to be wrong), I'm sure Anselm would be glad to include it in the official release. Just my 2cts, -- - yiyus || JGL .
Re: [dwm] dwm and dualhead
2008/12/11 Mate Nagy [EMAIL PROTECTED]: Hiho, On Thu, Dec 11, 2008 at 09:39:19AM +0100, yy wrote: on this list and, if somebody finds a great _general_ solution (which seems difficult, but I would be love to be wrong), I'm sure Anselm would be glad to include it in the official release. Just my 2cts, I don't see anything difficult about this. In fact, awesome generally gets this right. This is what I want from dwm: - handle each xrandr screen separately including all data structures, so different layout, client set, tagging, etc. You could have a tile algorithm for two screens, where you have the zoomed client in one of them and the stack in the other screen arranged in a grid layout, for example; or something similar to tile in one screen and two more columns of stack on the other one, the possibilities are endless. And if you want to completely change your whole workspace with tagging having to set tags in both screens would be a pain. - draw statusbar everywhere (from the same input text) I don't understand why you would want the same status text in two adjacent screens. - have a key-bindable function for: - changing between screens just warp the pointer to the client. - move window to another screen which could simply be done by having different tags in both screens, something like 1.1 1.2 2.1 2.2 etc. - do something semi-intelligent when a screen with clients goes away, e.g. put clients in previous/next screen oslt. Basically, it should behave as multiple separate dwms, except that clients can be sent from screen to screen and all dwms have the same configuration. This is an use-case, but I don't see it like a general approach. Having said this, I don't think it would be difficult to implement, as far as I can remember dwm did something similar at some point and it wasn't satisfactory to everybody, but it can definitively be done and, if everybody (using dual-head, my opinion doesn't count) agrees this is the perfect behavior, it should be included in main, IMO. -- - yiyus || JGL .
Re: [dwm] dwm and dualhead
What about moving XineramaScreenInfo *info = NULL; out of updategeom()? if you make info a global variable it is easy for people to have custom tile algorithms which make use of it. If you also define custom functions to view tags, change layouts, etc you will be able to have plenty of different xinerama configurations without messing up with dwm.c. People could easily add their custom dual.c files. You wouldn't be possible to achieve all of the different configurations which were mentioned in this thread, but I think you could get most of them. Just an idea... -- - yiyus || JGL .
Re: [dwm] Border hater, border lover
2008/12/17 Anselm R Garbe garb...@gmail.com: It's in. Please recheck if there are any issues. Otherwise I'm going to release 5.4 tomorrow. Two things (of not too much importance, anyway): 1. What about the applyrules modification discussed in http://lists.suckless.org/dwm/0812/7057.html ? 2. IMO the issingle variable name in adjustborder() should be changed, e.g. to hasborder. I will elaborate on #2: I'm using a modified monocle where the border is removed when the status bar is not visible, so that I have some kind of fullscreen layout (very useful for firefox video windows from some sites). When I have seen this new function I thought that it would perfectly fit in this function (maybe it could even go into main? I think it will be just one more line), but issingle doesn't make too much sense then. Anyway, as I told, nothing important... -- - yiyus || JGL .
Re: [dwm] Border hater, border lover
2008/12/17 yy yiyu@gmail.com: 2008/12/17 Anselm R Garbe garb...@gmail.com: It's in. Please recheck if there are any issues. Otherwise I'm going to release 5.4 tomorrow. Two things (of not too much importance, anyway): 1. What about the applyrules modification discussed in http://lists.suckless.org/dwm/0812/7057.html ? 2. IMO the issingle variable name in adjustborder() should be changed, e.g. to hasborder. I will elaborate on #2: I'm using a modified monocle where the border is removed when the status bar is not visible, so that I have some kind of fullscreen layout (very useful for firefox video windows from some sites). When I have seen this new function I thought that it would perfectly fit in this function (maybe it could even go into main? I think it will be just one more line), but issingle doesn't make too much sense then. Anyway, as I told, nothing important... -- - yiyus || JGL . I have just realized it wouldn't need a single line of code to remove the border in fullscreen layout (i.e.: monocle + !showbar). Inside monocle, doesn't adjustborder(c, n == 1 || !showbar) make sense to you? Maybe you could also have a new define in config.h, so people can choose: #define MONOCLEBORDER n == 1 #define MONOCLEBORDER n == 1 || !showbar #define MONOCLEBORDER True Anyway, having borders in monocle is probably a matter of taste, but it is so easy adding your own layout that I doubt it is even a matter... PS: I will stop rambling now and will wait for tomorrow release. Good night! -- - yiyus || JGL .
[dwm] dio-0.1.3
I have been experimenting with user interfaces concepts lately. My first aim was a simple mp3 player. The code has been adapted later to do other tasks, and now it is some sort of generic list manager, where items can be played. It was initially based on dmenu-3.9 (that's the reason it is announced here), though it has evolved to be much more complicated (too much, actually). Probably the next step will be a complete rewrite, which could use libixp and the plan9port plumber, with several simplifications (and, maybe, completely different). I have set up a project page on google: http://code.google.com/p/dynamic-io/ so, no more announcements will be done on this list. If you are curious, a screenshot featuring dwm and several dio applications (terminal, calendar, rpn calculator, irc client, text viewer, file browser and music player) is available at: http://y-i-y-u-s.deviantart.com/art/dio-0-1-3-108171356 Don't expect the terminal to replace uxterm, it just wraps rc stdin/out, but doesn't understand escape sequences. I'm using on a daily basis the rpn calculator, the irc client, the file browser and the music player: it fails from time to time, but is usable. Any comments by private email or the google page will be welcomed. Kind regards, -- - yiyus || JGL .
Re: [dwm] dio-0.1.3
2009/1/2 Christoph Lohmann 2...@r-36.net: You are recreating acme(1) with less features. Maybe, acme is probably the user interface which has inspired me more in the last years. OTOH, using acme (or libframe, I don't know very much about the internals) would probably be the right way to implement these artifacts. I would give it a try if it was possible to open acme windows in different X windows. Anyway, I do this only for fun (and because I wanted a simple mp3 player), and replacing acme is out of my scope. dio is much more modest software than acme and, in simple words, much worse. It is only a toy, to experiment with my (sometimes stupid) ideas. -- - yiyus || JGL .
Re: [dwm] dio-0.1.3
2009/1/5 Anselm R Garbe garb...@gmail.com: 2009/1/4 Yoshi Rokuko yoshi.rok...@yokuts.org: On Fri, Jan 02, 2009 at 06:53:10PM +0100, yy wrote: I have been experimenting with user interfaces concepts lately. My first aim was a simple mp3 player. The code has been adapted later to do other tasks, and now it is some sort of generic list manager, where items can be played. It was initially based on dmenu-3.9 (that's the reason it is announced here), though it has evolved to be much more complicated (too much, actually). I like the idea. A while ago I was thinking about a xlib gui file-opener, your `launcher' dio script reminds me on that ... It would be cool to have more nice xlib apps to create some sort of dwm desktop, I have to try your stuff ;-) My still secret project is about the foundation for that -- a collection of libraries which should enable writing such apps, mainly window/event abstractions and a decent font API -- this is code which emerged from my st code base which is subject to be published soon as well. I was a little bit shocked, that yiyus went into a similiar direction already ;) But I'm in the middle of yet another move currently, so I will postpone any announcements, otherwise I won't be able to be of any support... Kind regards, --Anselm I'm glad to hear that. Since I'm also semi-moving too, dio development is stalled ATM (I was on holidays in Spain, but will be back in Belgium the day after tomorrow). So, I will wait to see what Anselm comes with and maybe we can join efforts or re-use some code. PS: I suppossed that it was possible that both projects were related, but probably Anselm code will be better so... -- - yiyus || JGL .
Re: [dwm] how to float all gui programs
2009/1/9 Szabolcs Nagy nszabo...@gmail.com:
On 1/9/09, bill lam cbill@gmail.com wrote:
On Fri, 09 Jan 2009, markus schnalke wrote:
Make floating the default and add rules for your terminal emulators.
Thank markus, I patched dwm as per your suggestion and it now works
use {0,0,0,0,True} as first rule in config.h, editing dwm.c is not
necessary for this
But with current tip doing this won't let you to tag clients with
rules to a specific tags (because every client will be tagged to the
current tagset, though you can do an OR with them) as discussed in
http://lists.suckless.org/dwm/0812/7057.html , Anselm told in the same
thread he didn't worry too much about that corner case and, in fact,
nobody complained. It looks like things are different now.
If there is interest in both features maybe negative numbers could be
used in the rules definition and applyrules() for current visible or
no tags. Anyway, hardcoding in dwm.c what to do with new clients is
straightforward.
--
- yiyus || JGL .
Re: [dwm] What happened here?
2009/1/20 andrew alindb...@gmail.com:
I've spent a lot of time with awesome in the past months, since it
had, at the time, a sensible tiling system and some of the features I
wanted that dwm lacked. Unfortunately, with the progression to the
latest major revision, lua integration has ruined its usability. And
so I came back to poke around at the dwm project and see if it had
progressed into something usable for me.
All I can say is: Yikes.
Specify commands as a list of argument strings?
This isn't any weird trick. Have a look at exec(3).
I don't even recognize the key array as C code ... {.v = dmenucmd} },
... (??)
It is C code. Not less recognizable than any config file parser.
Tagmasks? Why are we forcing the user to do this in binary?
I would argue about other global booleans moved to a bit mask, but
tags... c'mon! They are a bit mask! Having an array of booleans for
this seems wrong. If the user has any problem with bit operations in C
the wikipedia page about it is quite enlightening. I don't think any
user capable of compiling dwm will have any problem to add or remove
tags, IMO looking at config.def.h the operation is straightforward,
even if you don't understand what you are doing. I think if you search
for it you can find macros in this list to not having to touch bit
masks at all.
The website lists clarity as a feature. Clarity!
As for only having to learn C code to edit the config, I know C
reasonably well, but I get bad vibes from config.h, I think I'd rather
try to learn Lua.
I understand that a core tenet of the suckless development is
efficiency.. but it seems to me that at some point between 3.x and 5.3
this usurped usability in its entirety. The concept of the header
file is the config file has appeared to outlive it's sensibility.
Let's face it, a C header was never meant to be a scalable
configuration file for something as flexible as a tagging, tiling
window manager.
Anyway. I don't mean to start a huge fuss, just wanted to make an
observation as a previous user, and maybe encourage taking a step back
and looking at the sensibility of how the whole program hangs together
now, for the user. Because, to me, dwm was primarily about getting the
window manager out of my way, but looking at the most recent config.h,
I can tell it won't fit that bill for me anymore.
Really, I don't think making the usual changes to config.h (setting
your rules, tags, keys and buttons) would have taken you longer than
writing this email.
Regarding efficiency, I don't think that was the reason for any of
these changes. I would tell it was simplicity of the code (for
reference, have a look at the example in
http://www.scklss.org/common/index.html). I don't think config.h is
any more complicated now, if you tell any specific problem you found
I'm sure somebody in this list will be glad to help you.
Sadly going back to the tiling wm dole,
Good luck!
Andrew
--
- yiyus || JGL .
Re: [dwm] Re: What happened here?
2009/1/20 hiro 23h...@googlemail.com: [snip] Still, dwm somehow seems very much not unix alike for me. Well, X doesn't look like UNIX neither, however you look at it. -- - yiyus || JGL .
Re: [dwm] Layers
I use the floating layout just for this. I have hacked dwm in several ways in the past: keys to raise clients*, different stack algorithms (in the lt structure), and what not. At the end, in the case I want to bring front a tiled client the easiest way is to change to floating layout**, no complications are necesary and it makes quite sense to me. * I think they are named clients because a client can have several windows (reparenting; eg if you have window decorations). Another good reason is the confusing it would result to mix that Window with the Window already present in dwm _code_ (they are called windows in the man page, for example). ** In order to make this task easier, I have defined my keys and mouse in a way that a Mod+Space (or B1 on the symbol) set tile or (if tile is set) floating and Mod+Shift+Space (or B2) set monocle or floating in the same way. So, with a double Mod+Space - or Mod+Shift+Space, or double clicks - I can re-tile tiled clients while in floating layout. (It doesn't sound so great as the feeling is once you get used to it.) hth, -- - yiyus || JGL .
Re: [dwm] floating rule when only WM_NAME defined?
2009/2/16 Adam adam.listm...@gmail.com:
WM_NAME property should be the title
is that window have any title? (check the status bar)
yes, GREG is also the title in the status bar. I thought that:
{ NULL, NULL, GREG, 0,True },
would be the proper way to make it float, but this does not work.
Your problem probably is that the title is set once the rules have
been applied by dwm. IMO you will have to call applyrules() manually
(or you could call it in every arrangement, for example).
--
- yiyus || JGL .
Re: [dwm] dmenu - how to autoconfirm selection in case of exact match?
Another option, if you don't want to patch, is to add those letters to dmenu input (with simples echoes in dmenu_path, or even processing an aliases file). Personally, I don't use dmenu_path, I just have a list with no more than 10 items so I can launch everything with only one or two letters. hth, -- - yiyus || JGL .
Re: [dwm] dmenu - how to autoconfirm selection in case of exact match?
2009/2/16 Jeremy Jay dinkuma...@gmail.com: OP doesn't want to hit enter every time, dmenu won't return unless you do, so a patch is necessary... Jeremy On Mon 16 Feb 2009 - 07:32PM, yy wrote: Another option, if you don't want to patch, is to add those letters to dmenu input (with simples echoes in dmenu_path, or even processing an aliases file). Personally, I don't use dmenu_path, I just have a list with no more than 10 items so I can launch everything with only one or two letters. hth, -- Yes, you're right, my apologies. I misread the question and didn't even look at the patch. I thought his problem was that dmenu was selecting an item instead of his input. Sorry for the noise. -- - yiyus || JGL .
[dwm] [OT] Wheel designs
I find your current discussion very relevant to what I'm doing with dio[1] now. It would really be great to share ideas and, eventually, join efforts. I will try to explain the different ideas I had with dio development, it's a long history. This is what I have now: The main idea behind dio was a very simple player of items which could be used for music and video. I took dmenu and extensively modified it to display items in scrollable windows and manage button events, depending on the command line options different actions are done when items are clicked, added, etc. Several bash scripts run dio in different ways: The player reads its items from stdin, displays them and launch child proccess to actually play the file. A directory browser is done redirecting ls output to dio stdin and relaunching itself when directories are selected. It is convenient to add files to the player. Keyboard input was already supported from dmenu, it allows to search for items. Giving the option to redirect this input to stdout added the possibility to turn dio into a very basic terminal emulator. I never implemented a ptty or anything, it just redirected a shell stdin/out, but it was pretty usable with simple programs like dc or sic. Smaller applications like the calendar or terminal history were straightforward. In its current state, dio has been a test bed for ui ideas, but its implementation lacks any kind of design, it just came up like this. In particular, the idea of turning command line arguments into a new language sounded like some kind of aberration to me. So, I started to think in how to rewrite dio from scratch. The most difficult decission is where you want to put the line of what it will do and what you will leave to the applications. I thought in several possibilities: 1. Make dio simpler, so that it just displays input and sends output (events are sent as output too). In some way, this is in the path of what Matthias is proposing. All the logic of the player, for example, would be done by external programs and would tell dio that how to represent the list. The problem here is that you would have to kept two different lists of items, and process management can be tricky. Some kind of language for communication would be needed. All the simplicity would be gone. 2. Turn dio into a library and have different applications (which make use of popen()) instead of scripts. It has the advantage you don't need any new language. It could even be the right approach, in fact the biggest problem I found with it was that libgt seemed to me like something similar from the few informantion we have and I was waiting to se what it exactly was. 3. Develope a small language similar to awk (a subset of) and add to it special patterns and fields to manage events and make some formating (bg color, fg color and maybe bold font, no more) and turn dio into an interpreter. I don't have any strong fundation to suggest this, new languages should be added only when they are really needed, but I have been looking at yacc and lex documentation these last days and, dude, it would be so funny... 4. Rewrite everything in the acme way. The idea to give dio more text editing capabilities crosses my mind from time to time. acme is almost perfect as an user interface for me, but it is an user interface for programmers and when it comes to play music for example and all those desktop tasks it just isn't the right tool. I have grasped the code and I have to admit is too much for me, although it is a great way to learn I'm not the right person to improve Pike's work, it is out of my possibilities. I started to rewrite dio from scatch and what I have now is a small program that displays its stdin in a scrollable window and prints to stdout the clicked items on the form Button3 Item 1. Just that, no more, but everything can be done from there. As you see, this is a total rambling, but I really think we could have something here, your ideas also look very interesting to me, and every comment will be appreciated. Nacht, [1] http://code.google.com/p/dynamic-io/ -- - yiyus || JGL .
Re: [dwm] Google Summer of Code 2009
Great news :) I would love to take part on this. I'm PhD student and was thinking about some Plan9 related project, if the suckless project will also be a mentoring organization maybe there is some good project involving both things which could be done (I remember a Plan9 port of dwm - mentored by Anselm - was a propossed idea in the Plan9 GSoC wiki last year, for example). Other vague ideas I have could be something st/libgt related (see my wheel designs post, I'm really willing to put my hands on this) or some work to try to fit better plan9port/9vx/inferno with X: I would like to use plan9/inferno applications in a more transparent way, now I have the feel of running it inside a box, this is an idea that has crossed my mind some times: write a rio substitute which multiplexes /dev/draw to different x windows (clients), modify acme to use separate windows too, and use dwm/wmii to control everything. It sounds complicated, but it would just be a matter of moving code from one place to another, something in these lines should be doable. Of course, these are just some rough ideas, and I am open to any suggestion from possible mentors. Though I would apply as a student, if you need any help to prepare the application as mentoring organization, just drop me a line, maybe I could help. BTW, I think it would be interesting to add to the wiki page the candidates to mentors/students. I hope we can find some good projects to work on. Regards, -- - yiyus || JGL .
Re: [dwm] This question is probably beneath you all--but I will ask anyway
2009/2/28 I. Khider cont...@ikhider.com: Greeting fellow DWM users I noticed with certain applications like Gimp, k3b, etc. it is very difficult to maximize a work screen--I have yet to figure it out. Also for Gimp, I have tried to move my tools applications around the workspace and apart from toggling between them, I canot move them around. I tried the man page and to google the problem and IRC on some channels but nobody knows, hence my appeal to you. Perhaps someone knows of a document I could consult to get on my way? Thank you in advance for your patience. -I- What do you mean by maximizing a work screen? -- - yiyus || JGL .
Re: [dwm] [PATCH] remove sizehints argument in resize()
2009/3/2 Enno Boland (Gottox) got...@gmail.com: I wrote a patch which removes the last argument from resize(). This is handled now directly in applysizehints(). What do you think about it? I love this patch. It looks like the right thing. -- - yiyus || JGL .
Re: [dwm] Wiki date format
2009/3/11 markus schnalke mei...@marmaro.de: /mm/dd is not worst but still worse than -mm-dd. The latter one is a standard, and it is usable in filenames. Think about it. I'm thinking about it, but really, if slashes are not the standard FS in dates we are probably living in different worlds. OTOH, a /mm/dd structure is convenient to organize months and years in a tree structure, i.e. directories (as God intended when he created time). -- - yiyus || JGL .
Re: [dwm] key bindings
2009/4/4 Steven Blatchford dollarsign...@gmail.com:
A few months ago I tried yiylus's idea of workspaces to cut down on
the keystrokes when pulling in other apps (eg modkey+1 modkey+ctrl+2).
Now, since I rarely use XK_{1,2,3...9} I thought of moving those to the
function keys thus freeing up XK_{1,2,3...9}.
(I had to check the ml archives, because I didn't remember it, and
then I see I even wrote a wiki page about it... My memory is getting
worse every day)
How would one bind XK_1 to 'C-a 1'? I'm hoping this will select a
screen buffer for the terminal which has the focus.
Wouldn't it be much easier configuring screen?
--
- yiyus || JGL .
Re: [dwm] Low Power Fanless Computer
While I really like Asus products (I'm very happy with my eee), maybe the msi catalog is also worth a look. Both windbox and windnettop look like interesting fanless desktop replacements in the same line than the eeebox. If you want to have your own server the idea of accompanying one of these devices with plug computers and/or some cheap NAS looks funny, but given the current price of VPS I don't think home-servers are well worth any more. PS[OT]: you would not get rich this way, but I would buy such a thing for a reasonable price: 1. find the right (cheap) plug computers to run plan9 cpu servers, the right nas device to run venti, and the right eee/wind/whichever terminal. 2. preconfigure everything and package it in a cute box. 3. sell it. 4. profit! 5. goto 1 -- - yiyus || JGL .
Re: [dwm] dwm's future
You could add an option to print the window title to stdout. This way if somebody wants to pipe it to an external program to show window titles (like dzen on top of the dwm bar), they can. -- - yiyus || JGL .
Re: [dwm] [idea] mwm - minimal/minimun/monocle window manager
2009/4/26 Leandro Chescotta leandro.chesco...@gmail.com: - no tags, only a list of opened windows, that you can cycle with one keybinding or Alt+number - no bottom bar, just the window list that you can show/hide - no layouts, only a monocle-like one, and a floating layer for mplayer/feh/gimp - lol, an arch linux AUR package with the config.h ready to customize the few font/colors/keybindings/apps you could just run dwm without the bar, with only one tag, and with only the monocle layout. -- - yiyus || JGL .
Re: [dwm] dwm's future
2009/4/27 Matthias-Christian Ott o...@mirix.org: At least you didn't loose your dignity, carried out your principles and proofed that Free Software is as powerful as an expensive proprietary software. But it is not always possible. I can give you a (quite long) list of software that doesn't have a free equivalent. Between other things, my work involves a lot of mechanical testing, and even if developing your own easy solution would be straightforward you have to use the nonsense 1gb of ram proprietary (and usually windows) application because it is the industry standard. The argument about free software is a non-end disucssion. The matter is: there are broken applications, do we want to use dwm to manage their windows? I would prefer keeping it as suckless as possible, as somebody else suggested. dwm makes a great job managing windows, it is not its job to fix font handling or work around broken applications. However, I liked the idea of a suckless font library, but it will have to suck a lot (i.e. include pango) to work perfectly with every language on earth. -- - yiyus || JGL .
Re: [dwm] musca wm
2009/5/15 pancake panc...@youterm.com: A friend of me is writing a pkgsystem that builds everything inside a chroot and allows to create a full usable distribution, the pkgsystem itself is not yet finished, but is pretty fast , written in C and shellscript and I really think it is a good project. But actually it is a single-man project. We can use this project as a tool to build the base system. http://repo.or.cz/w/xbps.git/ Actually i'm happy with arch linux, but, i really miss a non-gnu linux and minimalistic distribution. We should get a look on alternatives for glibc (google one? uclibc? ..) but maybe the biggest rock we will face it will be the X server...this is probably one of the interesting projects to work on, but without keeping the X compatibility. (just as an emulation layer) X11 is bloat. (as we have already discussed, we can reuse the drivers of xorg) but designing a better and simpler API. But this is probably a long topic to talk about, and we're of course not the first ones to claim for an X11 replacement. --pancake I'd like to agree with you, and I would be glad to help in such an effort, but it would not give me any real benefit. There is a suckless alternative to GNU: Plan9. If I still run (arch)linux is because I often need things like a full featured web browser, pdflatex, the gimp, or ardour, for example, so I will need all the gnu-x-crap anyway. The same thing happens with that pkgsystem: it looks good, but what I really need from a pkgsystem is pre-packaged software, IMO compatibility with pacman (or any other widely used pm) would be better. But if you - or anybody else - go for it, every iniciative to remove GNU from the world has my vote. I have also listened good things about http://www.tinycorelinux.com, but have not tried the real thing myself. -- - yiyus || JGL .
Re: [dwm] musca wm
2009/5/15 Leandro Chescotta lchesco...@banelco.com.ar: 2009/5/15 yy yiyu@gmail.com : There is a suckless alternative to GNU: Plan9. I don't know that, there are apps under Plan9 like GNU? Why make it suckless comparative to GNU? In the sense that GNU aims to be a similar to UNIX operating system, but not UNIX, it is almost the same thing than Plan9. But now I was talking about glibc and the GNU tools, you could read http://harmful.cat-v.org/cat-v/ to get the idea, or some info pages. every initiative to remove GNU from the world has my vote. I have also listened good things about http://www.tinycorelinux.com, but have not tried the real thing myself. Why you don't like GNU? I only ask because I don't know, I only want to know what's wrong with it, I only use it, and thinked it was great, I mean, I love open source software, but I really don't know the license thing I cannot understand GNU software. ls or cat source in GNU is scary, glibc is even worse. The old UNIX utilities or Plan9 ones have a simplicity which GNU lacks. I don't have anything against the GPL license, but I prefer less restrictive licenses. And, of course, I don't like rms. -- - yiyus || JGL .
Re: [dwm] Re: New mailing list
2009/5/20 Szabolcs Nagy nszabo...@gmail.com: On 5/20/09, Anselm R Garbe garb...@gmail.com wrote: Let's have hackers@ be some meta list which sends to dwm@ and wmii@, and those subscribed to hackers will receive dwm@ and w...@. Those who are only interested in dwm@ or wmii@ specifically could just stay on dwm@ resp. w...@. That should be technically possible. dwm, wmii - hackers hackers - dwm, wmii so one sends a mail to dwm@ then it goes to hackers@ then someone replies there and the reply goes to w...@? Maybe I'm being naive, mailing lists are not my strong point. But IMO you can send the messages to the people subscribed to hackers with the corresponding FROM: field (dwm or wmii). So, if one sends a mail to dwm, you recive it as coming from dwm. Since hackers subscribed recive mail from both lists, the reply will arrive to dwm and hackers subscribers. Only if you specifically send an email to hackers it will be received by both lists (and you could, for example, change the TO: field when the discussion goes off-topic). Maybe somebody knows if I'm right or absolutely wrong. -- - yiyus || JGL .
