Re: [dwm] Updated bottom stack patch
Opps, there was a minor offset issue with the second part of the patch, it should still patch cleanly but just in case a new patch is available at http://bsdgroup.org/files/dwm-4.8-bstack.diff or attached once again. dwm-4.8-bstack.diff Description: Binary data On Jan 14, 2008, at 10:33 PM, James Turner wrote: Hi all, Although I don't have more than one monitor, I've added xinerama support to the bottom stack patch. Again, I worked off of the built in tile layout. Those of you with multiple monitors please feel free to give the patch a go and let me know if you run into any problems, thanks. You can find the patch at http://bsdgroup.org/files/dwm-4.8-bstack.diff or attached.
[dwm] Updated bottom stack patch
Hi all, Although I don't have more than one monitor, I've added xinerama support to the bottom stack patch. Again, I worked off of the built in tile layout. Those of you with multiple monitors please feel free to give the patch a go and let me know if you run into any problems, thanks. You can find the patch at http://bsdgroup.org/files/dwm-4.8-bstack.diff or attached. dwm-4.8-bstack.diff Description: Binary data
Re: [dwm] Updated bottom stack patch
On Mon, Sep 17, 2007 at 07:43:34PM +0200, Szabolcs Nagy wrote: > On 9/17/07, Anselm R. Garbe <[EMAIL PROTECTED]> wrote: > > On Mon, Sep 17, 2007 at 12:25:40PM +0100, Chris Webb wrote: > > > One question: why do you explicitly declare all dwm.c functions static > > > given that you only have a single source file anyway? > > > > Yeah, that's unnecessary. I remove that - it will also consume > > less disk space then ;) > > i feel static to be nicer > maybe i'm used to library writing where you declare local functions as static > > i looked into the c-faq and interestingly i could not find anything > about this kind of convention > even standard unix tools use both convention in a mixed way (static > and non static) Afaik not using static makes all variables and functions usable in an extern context. I agree with you if there is more than a single source file to enforce using static whenever possible to reduce name clashes and side effects in a global scope. But with a micromized dwm.c or dmenu.c I can live without explicit static declarations. Regards, -- Anselm R. Garbe >< http://www.suckless.org/ >< GPG key: 0D73F361
Re: [dwm] Updated bottom stack patch
On 9/17/07, Anselm R. Garbe <[EMAIL PROTECTED]> wrote: > On Mon, Sep 17, 2007 at 12:25:40PM +0100, Chris Webb wrote: > > One question: why do you explicitly declare all dwm.c functions static > > given that you only have a single source file anyway? > > Yeah, that's unnecessary. I remove that - it will also consume > less disk space then ;) i feel static to be nicer maybe i'm used to library writing where you declare local functions as static i looked into the c-faq and interestingly i could not find anything about this kind of convention even standard unix tools use both convention in a mixed way (static and non static)
Re: [dwm] Updated bottom stack patch
On Mon, Sep 17, 2007 at 04:28:38PM +0200, Anselm R. Garbe wrote: > On Mon, Sep 17, 2007 at 12:25:40PM +0100, Chris Webb wrote: > > Szabolcs Nagy <[EMAIL PROTECTED]> writes: > > > > > On 9/16/07, Julien Danjou <[EMAIL PROTECTED]> wrote: > > > > Except for people applying multiple patch on the now same and uniq file. > > > > Everything will be fuzzy. > > > > > > that's why you should put your modifications in a separate .c file if > > > possible > > > > Hmm. Speaking personally, I think including a .c file in a header file is > > a stylistically hideous hack---something I could never bring myself to do > > in public! Patches which aren't just additional layouts or convenience > > functions will probably non-trivially touch existing code anyway. > > It's definately a stylistic hack. But I can't think of a more > simple way to allow access to all dwm-stuff without the need to > hack together yet another .h file and patch config.mk > accordingly - and to declare all variables and functions as > extern's - which does the same in the end, but in a more > complicate way. > > > However, I suspect maintaining a local tree descended from a single > > upstream dwm.c will be nicer than descending from multiple file dwm. In > > particular, noise from variables moving from static to extern (e.g. in > > taglayouts and pertag where previously local structures suddenly need > > initialising) in patches goes away. > > > > One question: why do you explicitly declare all dwm.c functions static > > given that you only have a single source file anyway? > > Yeah, that's unnecessary. I remove that - it will also consume > less disk space then ;) Well, I thought about this further and notice, that I I replace SRC = dwm.c with SRC += dwm.c in Makefile, you are able to access anything with dwm.c through including your foo.h in config.h and accessing all referenced functions and variables from dwm.c using extern's. So you can choose wether to use the hackish style or the clean old-C-school style ;) Regards, -- Anselm R. Garbe >< http://www.suckless.org/ >< GPG key: 0D73F361
Re: [dwm] Updated bottom stack patch
On Mon, Sep 17, 2007 at 12:25:40PM +0100, Chris Webb wrote: > Szabolcs Nagy <[EMAIL PROTECTED]> writes: > > > On 9/16/07, Julien Danjou <[EMAIL PROTECTED]> wrote: > > > Except for people applying multiple patch on the now same and uniq file. > > > Everything will be fuzzy. > > > > that's why you should put your modifications in a separate .c file if > > possible > > Hmm. Speaking personally, I think including a .c file in a header file is > a stylistically hideous hack---something I could never bring myself to do > in public! Patches which aren't just additional layouts or convenience > functions will probably non-trivially touch existing code anyway. It's definately a stylistic hack. But I can't think of a more simple way to allow access to all dwm-stuff without the need to hack together yet another .h file and patch config.mk accordingly - and to declare all variables and functions as extern's - which does the same in the end, but in a more complicate way. > However, I suspect maintaining a local tree descended from a single > upstream dwm.c will be nicer than descending from multiple file dwm. In > particular, noise from variables moving from static to extern (e.g. in > taglayouts and pertag where previously local structures suddenly need > initialising) in patches goes away. > > One question: why do you explicitly declare all dwm.c functions static > given that you only have a single source file anyway? Yeah, that's unnecessary. I remove that - it will also consume less disk space then ;) Regards, -- Anselm R. Garbe >< http://www.suckless.org/ >< GPG key: 0D73F361
Re: [dwm] Updated bottom stack patch
Szabolcs Nagy <[EMAIL PROTECTED]> writes: > On 9/16/07, Julien Danjou <[EMAIL PROTECTED]> wrote: > > Except for people applying multiple patch on the now same and uniq file. > > Everything will be fuzzy. > > that's why you should put your modifications in a separate .c file if > possible Hmm. Speaking personally, I think including a .c file in a header file is a stylistically hideous hack---something I could never bring myself to do in public! Patches which aren't just additional layouts or convenience functions will probably non-trivially touch existing code anyway. However, I suspect maintaining a local tree descended from a single upstream dwm.c will be nicer than descending from multiple file dwm. In particular, noise from variables moving from static to extern (e.g. in taglayouts and pertag where previously local structures suddenly need initialising) in patches goes away. One question: why do you explicitly declare all dwm.c functions static given that you only have a single source file anyway? Cheers, Chris.
Re: [dwm] Updated bottom stack patch
On 9/16/07, Julien Danjou <[EMAIL PROTECTED]> wrote: > Except for people applying multiple patch on the now same and uniq file. > Everything will be fuzzy. that's why you should put your modifications in a separate .c file if possible
Re: [dwm] Updated bottom stack patch
At 1189952943 time_t, James Turner wrote: > Thanks for the great example, that will especially make things > easier while the code is still being changed. I think before 4.4 was > released I probably rewrote my patch at least a dozen times to work with > the changing source tree. This of course will eliminate that need all > together. Except for people applying multiple patch on the now same and uniq file. Everything will be fuzzy. -- Julien Danjou // Λ̊ <[EMAIL PROTECTED]> http://julien.danjou.info // 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD signature.asc Description: Digital signature
Re: [dwm] Updated bottom stack patch
On Sun, Sep 16, 2007 at 01:18:24PM +0200, Anselm R. Garbe wrote: > Hi James, > > cool, I want to give an example how your patch should be > reorganized that it works with less of a hassle beginning with dwm-4.5: [snip] Thanks for the great example, that will especially make things easier while the code is still being changed. I think before 4.4 was released I probably rewrote my patch at least a dozen times to work with the changing source tree. This of course will eliminate that need all together. -- James Turner BSD Group Consulting http://www.bsdgroup.org
Re: [dwm] Updated bottom stack patch
Hi James,
cool, I want to give an example how your patch should be
reorganized that it works with less of a hassle beginning with dwm-4.5:
Imagine bstack.c:
/* by James */
static void
bstack(void) {
unsigned int i, n, nx, ny, nw, nh, mh, tw, th;
Client *c;
for(n = 0, c = nexttiled(clients); c; c = nexttiled(c->next))
n++;
/* window geoms */
mh = (n > 1) ? (wah * mwfact) / 1 : wah / (n > 0 ? n : 1);
th = (n > 1) ? (wah * (1 - mwfact)) / 1 : 0;
tw = (n > 1) ? waw / (n - 1) : 0;
for(i = 0, c = nexttiled(clients); c; c = nexttiled(c->next), i++) {
c->ismax = False;
nx = wax;
ny = way;
if(i < 1) {
ny += i * mh;
nw = waw - 2 * c->border;
nh = mh - 2 * c->border;
}
else {
nx += (i - 1) * tw;
ny += mh * 1;
if(i + 1 == n) { /* remainder */
nw = (wax + waw) - nx - 2 * c->border;
}
else {
nw = tw - 2 * c->border;
}
nh = th - 2 * c->border + 1;
}
resize(c, nx, ny, nw, nh, RESIZEHINTS);
}
}
static void
bzoom(const char *arg) {
Client *c;
if(!sel || (!isarrange(tile) && !isarrange(bstack)) || sel->isfloating)
return;
if((c = sel) == nexttiled(clients))
if(!(c = nexttiled(c->next)))
return;
detach(c);
attach(c);
focus(c);
arrange();
}
EOF
And imagine the following config.h.diff
/* layout(s) */
+#include "bstack.c"
static Layout layouts[] = {
/* symbol function */
{ "[]=",tile }, /* first entry is default */
{ "><>",floating },
+ { "TTT",bstack},
};
#define RESIZEHINTSTrue/* False - respect size hints in tiled
resizals */
#define MWFACT 0.6 /* master width factor [0.1 .. 0.9] */
@@ -48,7 +50,7 @@ Key keys[] = { \
{ MODKEY, XK_h, setmwfact, "-0.05"
}, \
{ MODKEY, XK_l, setmwfact, "+0.05"
}, \
{ MODKEY, XK_m, togglemax, NULL },
\
- { MODKEY, XK_Return, zoom, NULL },
\
+ { MODKEY, XK_Return, bzoom, NULL },
\
{ MODKEY|ShiftMask, XK_space, togglefloating, NULL },
\
{ MODKEY|ShiftMask, XK_c, killclient, NULL },
\
{ MODKEY, XK_0, view, NULL },
\
As you see, no patches necessary at all, except including that
bstack.c file and to changing the zoom call with bzoom.
Regards,
--
Anselm R. Garbe >< http://www.suckless.org/ >< GPG key: 0D73F361
Re: [dwm] Updated bottom stack patch
On Sat, Sep 15, 2007 at 06:24:35PM -0400, James Turner wrote:
> I've updated the bottom stack patch to work with the new "micromizied"
> version of dwm. It includes my previous main patch as well, so if your
> operating system doesn't support strlcpy you will need to remove that
> part from the patch. Let me know if you experience any issues.
>
> --
> James Turner
> BSD Group Consulting
> http://www.bsdgroup.org
Oops, forgot to attach the actual patch.
--
James Turner
BSD Group Consulting
http://www.bsdgroup.org
--- config.hSat Sep 15 18:10:36 2007
+++ config.hSat Sep 15 18:12:32 2007
@@ -26,6 +26,7 @@ static Layout layouts[] = {
/* symbol function */
{ "[]=",tile }, /* first entry is default */
{ "><>",floating },
+{ "TTT",bstack },
};
#define RESIZEHINTSTrue/* False - respect size hints in tiled
resizals */
#define MWFACT 0.6 /* master width factor [0.1 .. 0.9] */
--- dwm.c Sat Sep 15 18:10:36 2007
+++ dwm.c Sat Sep 15 17:53:58 2007
@@ -177,6 +177,7 @@ static void tag(const char *arg);
static unsigned int textnw(const char *text, unsigned int len);
static unsigned int textw(const char *text);
static void tile(void);
+static void bstack(void);
static void togglebar(const char *arg);
static void togglefloating(const char *arg);
static void togglemax(const char *arg);
@@ -479,7 +480,7 @@ initbar(void) {
XDefineCursor(dpy, barwin, cursor[CurNormal]);
updatebarpos();
XMapRaised(dpy, barwin);
- strcpy(stext, "dwm-"VERSION);
+ strlcpy(stext, "dwm-"VERSION, sizeof(stext));
dc.drawable = XCreatePixmap(dpy, root, sw, bh, DefaultDepth(dpy,
screen));
dc.gc = XCreateGC(dpy, root, 0, 0);
XSetLineAttributes(dpy, dc.gc, 1, LineSolid, CapButt, JoinMiter);
@@ -1723,7 +1724,7 @@ static void
setmwfact(const char *arg) {
double delta;
- if(!isarrange(tile))
+ if(!isarrange(tile) && !isarrange(bstack))
return;
/* arg handling, manipulate mwfact */
if(arg == NULL)
@@ -1780,11 +1781,48 @@ tile(void) {
}
}
+void
+bstack(void) {
+unsigned int i, n, nx, ny, nw, nh, mh, tw, th;
+Client *c;
+
+for(n = 0, c = nexttiled(clients); c; c = nexttiled(c->next))
+n++;
+
+/* window geoms */
+mh = (n > 1) ? (wah * mwfact) / 1 : wah / (n > 0 ? n : 1);
+th = (n > 1) ? (wah * (1 - mwfact)) / 1 : 0;
+tw = (n > 1) ? waw / (n - 1) : 0;
+
+for(i = 0, c = nexttiled(clients); c; c = nexttiled(c->next), i++) {
+c->ismax = False;
+nx = wax;
+ny = way;
+if(i < 1) {
+ny += i * mh;
+nw = waw - 2 * c->border;
+nh = mh - 2 * c->border;
+}
+else {
+nx += (i - 1) * tw;
+ny += mh * 1;
+if(i + 1 == n) { /* remainder */
+nw = (wax + waw) - nx - 2 * c->border;
+}
+else {
+nw = tw - 2 * c->border;
+}
+nh = th - 2 * c->border + 1;
+}
+resize(c, nx, ny, nw, nh, RESIZEHINTS);
+}
+}
+
static void
zoom(const char *arg) {
Client *c;
- if(!sel || !isarrange(tile) || sel->isfloating)
+ if(!sel || (!isarrange(tile) && !isarrange(bstack)) || sel->isfloating)
return;
if((c = sel) == nexttiled(clients))
if(!(c = nexttiled(c->next)))
[dwm] Updated bottom stack patch
I've updated the bottom stack patch to work with the new "micromizied" version of dwm. It includes my previous main patch as well, so if your operating system doesn't support strlcpy you will need to remove that part from the patch. Let me know if you experience any issues. -- James Turner BSD Group Consulting http://www.bsdgroup.org
