Re: [dwm] irssi + screen + urxvt in dwm -> window hint urgent not working
> i have a little problem regarding window hint urgent with my setup. > I run a screen with irssi inside on my server and use urxvt as terminal for > access. I have basically the same problem, I've _never_ gotten it to work even partially. I'm using screen 4.00.03 and rxvt 2.7.10 I'd really like to figure out how to make this work also. -Andrew
[dwm] What happened here?
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?
I don't even recognize the key array as C code ... {.v = dmenucmd} },
... (??)
Tagmasks? Why are we forcing the user to do this in binary?
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.
Sadly going back to the tiling wm dole,
Andrew
Re: [dwm] dwm-5.2 / dmenu-3.9
On Wed, 10 Sep 2008 07:58:21 +0200 "Enno \"Gottox\" Boland" <[EMAIL PROTECTED]> wrote: The tarball for dwm-gtx seems to be lacking tile.c, deck.c, and monocle.c. > Hi there! > > I want to announce that dwm-gtx-5.2 is released too. It can be > downloaded as tarball as well as patchset to vanilla dwm. It extends > dwm with better Xinerama support, automaticle pointer movement > (wmii-2.5 style) and an additional Layout called deck to work better > with small screens (<= 1024x768) > > Tarball: > http://s01.de/~gottox/files/dwm/dwm-gtx-5.2.tar.gz > > Diff: > http://s01.de/~gottox/files/dwm/dwm-gtx-5.2.diff > > Mercurial: > hg clone https://s01.de/~gottox/hg/dwm > > Projectpage: > http://s01.de/~gottox/index.cgi/proj_dwm > > I try to keep my branch synchronous to vanilla dwm and merge changes > from mercurial back to my repository asap. > > regards > Gottox > > 2008/9/9, Anselm R Garbe <[EMAIL PROTECTED]>: > > Hi there, > > > > I'm glad to announce dwm-5.2 and dmenu-3.9. You can download the > > new releases from: > > > > http://code.suckless.org/dl/dwm/dwm-5.2.tar.gz > > http://code.suckless.org/dl/tools/dmenu-3.9.tar.gz > > > > Both releases contain various bug fixes and code polishings. > > > > Many thanks go to all geeks who have been involved in the > > development during the last weeks. > > > > Kind regards, > > > > --Anselm > > > > > >
Re: [dwm] Documentation!
On Fri, May 16, 2008 at 3:39 PM, Enno Gottox Boland <[EMAIL PROTECTED]> wrote: > That's what I still think too. Fortunally DEFGEOM is gone in dwm-tip. > > Nevertheless there is a trend in dwm to "overoptimise" the code. I > think dwm-4.7 was the simplest. That's why my branch is still based on > 4.7. > > 2008/5/16, Steffen Liebergeld <[EMAIL PROTECTED]>: >> Hi folks, >> >> after some time in proprietary environments I tried to get back to dwm. >> Unfortuately I was somewhat disappointed. >> >> Although I really appreciate your effort to simplify and reduce the code, it >> is now my impression that you drove it too far. The code is small as hell, >> and it might even be somewhat clever, but it is anything than >> self-documentary. >> >> Just have a look at that line: >> DEFGEOM(single, 0, 0, sw, 0, bh, sw, sh-bh, wx, wy, mfact*sw, wh, mx+mw, >> wy, ww-mw, wh, wx, wy, ww, wh) >> >> This is a true "wtf"! What the could that be? Could you at least >> document what this creature is? Do I have to read all the code, and >> understand it just to get the meaning of this single cryptic line. >> >> >> I am looking forward to get an explanation about this. And maybe someone >> could start documenting the code, to make it useful again. >> >> >> Thanks in advance. >> >> Greetings, Steffen >> >> >> > > > -- > http://www.gnuffy.org - Real Community Distro > http://www.gnuffy.org/index.php/GnuEm - Gnuffy on Ipaq (Codename Peggy) > > I'm glad to see i'm not alone. The over-emphasis on stripping the code down is getting ridiculous. Even if fewer LOC is a goal, two and three character variable names are over the top. It affects the binary in no way, and only serves to obscure the code. The LOC goal itself is really silly in my mind anyway. while it might be an interesting relative metric to track, arbitrary limits (2000 SLOC) seem like a silly exercise at best; the goal should be to "do one thing and do it well". Why should a window manager only be 2000 LOC, it may only require so many lines, but it may require more, limiting functionality (or worse, code clarity) for LOC goals is a terrible trade-off. Regards, -Andrew
Re: [dwm] A rather radical thought
On Wed, Apr 2, 2008 at 10:11 AM, Anselm R. Garbe <[EMAIL PROTECTED]> wrote: > Here is what I have exactly in mind from a user perspective: > ... ... > So the whole layout concept consists of basically 4 keys with 3 > kinds of modifiers. 4x3 = 12 (TWELVE!) combos to remember/learn to manage windows? Currently I have (i think) only three: mwresize (left and right) and zoom. I would reiterate that the whole appeal of dwm is to manage my windows in a predictable way and get out of my way. All this capability to move windows around is exactly why i abandoned wmii (not to mention non-tiling WMs) in the first place, wasting to much time organizing windows "just so". And I would like to echo that the ability to mix and match what tags I am viewing is the real "dynamic" backbone in dwm. I separate applications by tag and then view the tags I need for the job at hand, whether thats a text editor and www for reference, web and chat on the side, I pull in email periodically to check it and then dismiss it. Without the ability to quickly bring in windows not in the current view, whats the point of tags? Regards, -Andrew
Re: [dwm] cycling through tags?
There is some question of what it would mean to move to the next tag
when there are multiple tags selected. However, for a given definition
of "next tag" it shouldn't be too hard to code.
I don't think code like this should really be included in dwm - the
question of what "next tag" means really is debatable, and people can
easily hack it if they want.
At the top of dwm.c, with the other declarations:
void nexttag(const char *arg);
Somewhere further down (doesn't really matter where) in dwm.c:
void
nexttag(const char *arg) {
unsigned int i, j;
memcpy(prevtags, seltags, sizeof seltags);
for (i = 0; i < LENGTH(tags); i++) {
if (seltags[i])
j = (i + 1) % LENGTH(tags);
seltags[i] = False;
}
seltags[j] = True;
arrange();
}
In your config.h keybindings:
{ MODKEY, XK_n, nexttag, NULL },
Obviously you would want to write a prevtag function as well, and
probably make sure my code works (I can't say that I've actually tested
it). In any case, this is the beauty of dwm - it really doesn't take
long to hack it to do what you want.
If the suggestion I've made doesn't work, I could do it properly, test,
and post a patch if you like.
Joerg van den Hoff wrote:
> simple question:
>
> there seems to be no pre-defined way to cycle forward/backward
> through tag-groups (still essentially a.k.a. workspaces to
> me, though I understand there's a difference). only mod1+[1..9] and
> mod1+tab seem to be in place for navigation. from my experience
> with `ion' I find the cycling (next/previous) between workspaces most useful,
> especially when searching for a certain window.
>
> question: can (and should) it be done?
>
> joerg
>
>
Re: [dwm] Xinerama support
> - aim multihead setup (distinct bars, tag sets and layouts for > each screen) I think I like this idea, but can you explain how the tags will interact between the screens? it seems possible to tag a window to appear on both screens. the need for distinct layouts per head is a must i think, to be able to accommodate everyone. I think one interesting and useful function might be the ability to swap all the windows and tags between the physical heads, while retaining layout. this way I can swap in the things on my secondary screen if i need to address them for a short time, and then push them back to the second head afterwards. -Andrew
