I grabbed the latest dwm earlier to port various bits of my own into
clean patches against the latest dwm. I hadn't looked at the standard
tile function for a little while, but I notice that the current
incarnation recalculates the window geometries (mw and th) for each
client rather than once in
Anselm R. Garbe [EMAIL PROTECTED] writes:
[Re: embedded windows]
I'd like to keep this complexity out of dwm. I really think to
provide a more flexible way to change the bar position and
geometry.
One simple solution that might be sufficient: here I have two gaps
defined, a top gap and a
pancake [EMAIL PROTECTED] writes:
This way you can achieve any of the possibilities (show the same client in
both
monitors, move a window from one to another, etc..
X doesn't give you a mechanism for showing the same client on both monitors.
Best wishes,
Chris.
Sander van Dijk [EMAIL PROTECTED] writes:
On Dec 6, 2007 11:23 AM, Anselm R. Garbe [EMAIL PROTECTED] wrote:
Ok, but the DWMTAGS idea is ok for everyone?
Would that work? If the new dwm is a child of the old one it would,
but when the dwm restart is controlled by a shell loop such as
Anselm R. Garbe [EMAIL PROTECTED] writes:
If we decide for line-based input reading, one easily could
block dwm from further event processing through running
echo -n foo | dwm
I think that'd be a big disadvantage.
It could append read text to the end of stext[] whenever it successfully
Kai Grossjohann [EMAIL PROTECTED] writes:
On Fri, Oct 26, 2007 at 05:09:06PM +0100, Chris Webb wrote:
One completely different approach to implementing multiple layouts in a
pure tagging context is to introduce a new layout index, completely
independent of the tag toggles. In the same
Sander van Dijk [EMAIL PROTECTED] writes:
No, it shouldn't, for the simple reason that it doesn't fit within the
tagging paradigm.
You're right, it doesn't really. I would characterise this patch (and
variants such as the one I use) as changing the underlying paradigm from
pure tagging to
Jan Christoph Ebersbach [EMAIL PROTECTED] writes:
On Fri 26-10-2007 17:09 +0100, Chris Webb wrote:
Incidentally, something else needed for consistency when implementing
taglayouts-type behaviour is to index all the layout parameters like
mwfact, nmaster (if you have it) and nstack/ncols
Chris Webb [EMAIL PROTECTED] writes:
insert a
free(mwfact);
into cleanup()
You don't need this bit with a static mwfact[NTAGS] of course. D'oh.
Edited my email after writing to reflect the fact that dwm has gone
static but didn't delete the unnecessary free().
Best wishes,
Chris.
Isn't the fundamental problem with all this that you are assuming that
tags are named by their number. You can't do this in the more general case
where you have tags like 'www' or 'scratchpad'.
Best wishes,
Chris.
Anselm R. Garbe [EMAIL PROTECTED] writes:
Agreed, I will change the resize code accordingly. So
RESIZEHINTS will be renamed to INCRESIZE or something like that.
I think the situation is slightly more complex than this. You want full
size hint support (including hints that enlarge the window
Stefano Soffia [EMAIL PROTECTED] writes:
I do not understand what you mean with `more general case'. Note that
currently, the idxoftag() function performs a comparison between
pointers not between strings.
Ah, I've just spotted what you're doing: it's not actually what I thought
you were
Szabolcs Nagy [EMAIL PROTECTED] writes:
there's a typo in in dwm.c in setmwfact():
...
else if(1 == sscanf(arg, %lf, delta)) {
if(arg[0] == '+' || arg[0] == '-')
mwfact += delta;
else
mwfact = delta; // should be -=
...
}
I don't think it should be. The
Anselm R. Garbe [EMAIL PROTECTED] writes:
I know my English is totally crap, so excuse that. Anyway you
describe the problem pretty well.
No, your English is fine; it's my reading that's dodgy! :-)
Cheers,
Chris.
This morning I've been thinking about run time configuration of dwm.
I've never especially liked the compile-time rules table in config.h. The
fact that one or two programs I use happen to be broken and need a rule
with isfloating = 1 doesn't seem like something that the dwm binary
should be
Anselm R. Garbe [EMAIL PROTECTED] writes:
The only questionable issue I don't like is the strsep(3) use,
because of portability concerns.
Failing all else, I guess a strsep() tokeniser
while(tag = strsep(line, \t\n)) {
if(!tag[0])
continue;
Jukka Salmi [EMAIL PROTECTED] writes:
Hmm, why using the ternary operator? Are there systems where
`realloc(NULL, size)' does not behave identically to `malloc(size)'?
I remember some old unix systems that segfault if you pass realloc a null
pointer! I haven't seen anything like that for a
Anselm R. Garbe [EMAIL PROTECTED] writes:
it won't last long that the need arises to also configure the key
bindings, and the terminal command, and the dmenu command, and what not
using such capabilities.
Actually... :-)
What wasn't in that patch, but is in my tree, is a little convenience
Peter Hartlich [EMAIL PROTECTED] writes:
Attached is Jeroen Schot's nmaster patch, ported to dwm (pre-)4.5 and
with incnmaster() renamed setnmaster().
[...]
void
setnmaster(const char *arg) {
int i;
if(!isarrange(tile))
return;
if(!arg)
Xavier [EMAIL PROTECTED] writes:
[rxvt-unicode]
Previously, I had some weird corruptions at the place of this unused
space. This only happened with urxvt though, not xterm. Not sure why..
But I'm happier with urxvt anyway.
I've noticed this behaviour with urxvt when window size hints are
pancake [EMAIL PROTECTED] writes:
Here's my keybindings
{ MODKEY|ShiftMask, XK_l, setncols, +1
}, \
{ MODKEY|ShiftMask, XK_h, setncols, -1
}, \
{ MODKEY|ShiftMask, XK_j, setnmaster,
Below is a patch for the current release (4.4.1) of dwm which enables
multiple columns in the stacking area. It introduces variables nrows and
ncols with corresponding default values NROWS and NCOLS in
config.h.default, and corresponding setnrows() and setncols() for use in
keybindings.
If nrows
22 matches
Mail list logo
