Re: [dwm] [dwm+ow...@suckless.org: Messages from dwm@suckless.org to you have been bouncing]
thanks a lot. I'll forward this to central IT (which control the mail server). joerg On Fri, Mar 06, 2009 at 05:53:23PM +0100, Premysl Hruby wrote: On (06/03/09 17:24), Joerg van den Hoff wrote: To: dwm mail list dwm@suckless.org From: Joerg van den Hoff j.van_den_h...@fzd.de Subject: Re: [dwm] [dwm+ow...@suckless.org: Messages from dwm@suckless.org to you have been bouncing] Reply-To: dwm mail list dwm@suckless.org List-Id: dwm mail list dwm.suckless.org User-Agent: Mutt/1.5.18 (2008-05-17) On Thu, Mar 05, 2009 at 09:35:43AM +0100, Szabolcs Nagy wrote: On 3/5/09, Szabolcs Nagy nszabo...@gmail.com wrote: 7587 messages: Starting Wed Jul 19 2006 - 06:39:23 UTC, Ending Thu Mar 05 2009 - 08:03:46 UTC so i wonder which is the no. 7600 if there is only 7538.. 7587 (sorry) well the last one I've got ( Fri, 06 Mar 2009 00:00:09 + ) reads: ==CUT== Hi, this is the mlmmj program managing the mailinglist dwm@suckless.org Some messages to you could not be delivered. If you're seeing this message it means things are back to normal, and it's merely for your information. Here is the list of the bounced messages: 7617 ==CUT== right now the archive counts 7610 mails. I presume this is updated only once a day or something? so I can wait a day or so before looking which mail bounced, but still: is there an easy way to find, e.g, message no. 4321? until a few weeks ago I've never seen such bouncing messages. it does'nt occur with any other list, too. regards, joerg Hi, sorry for such a late reply, first: yes, web archive is not updated live but twice a day. That messages you are receiving are just bounce test as reaction to mlmmj receiving bounce message (itself as consequnce of mlmmj trying to send you a message from mail-list). I had saved one bounce message mlmmj received from your MX, and it looks like your MX is acting very strangely (bounce message attached to this email). I hope that it will help you to solve the problem, because from what I can get from bounce message and mail-logs, it looks like problem on your side. Regards, -Ph -- Premysl Anydot Hruby, http://www.redrum.cz/ X-Original-To: dwm+bounces-7527-j.van_den_hoff=fzd...@suckless.org Delivered-To: dwm+bounces-7527-j.van_den_hoff=fzd...@suckless.org X-Greylist: delayed 1324 seconds by postgrey-1.27 at epona; Wed, 18 Feb 2009 23:52:35 UTC Received: from smtpout.fz-rossendorf.de (ix2.fz-rossendorf.de [149.220.4.86]) by code.suckless.org (Postfix) with ESMTP id C66E141C0 for dwm+bounces-7527-j.van_den_hoff=fzd...@suckless.org; Wed, 18 Feb 2009 23:52:35 + (UTC) Received: from localhost (localhost [127.0.0.1]) by smtpout.fz-rossendorf.de (Postfix) with ESMTP id 9C1B6936C6 for dwm+bounces-7527-j.van_den_hoff=fzd...@suckless.org; Thu, 19 Feb 2009 00:30:30 +0100 (CET) Received: from smtpout.fz-rossendorf.de ([127.0.0.1]) by localhost (ix2 [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 14521-05-2 for dwm+bounces-7527-j.van_den_hoff=fzd...@suckless.org; Thu, 19 Feb 2009 00:30:30 +0100 (CET) Received: from fz-rossendorf.de (cg.fzd.de [149.220.4.66]) by smtpout.fz-rossendorf.de (Postfix) with ESMTP id 655E3936C3 for dwm+bounces-7527-j.van_den_hoff=fzd...@suckless.org; Thu, 19 Feb 2009 00:30:30 +0100 (CET) Subject: Delivery report: Re: [dwm] [OT] Personal Website and CSS From: mailer-dae...@fz-rossendorf.de To: dwm+bounces-7527-j.van_den_hoff=fzd...@suckless.org Date: Thu, 19 Feb 2009 00:30:30 +0100 Message-ID: receipt-2044...@cg2.fz-rossendorf.de X-MAPI-Message-Class: REPORT.IPM.Note.DR Precedence: list Reply-To: dwm mail list dwm@suckless.org List-Id: dwm mail list dwm.suckless.org List-Unsubscribe: mailto:dwm+unsubscr...@suckless.org List-Subscribe: mailto:dwm+subscr...@suckless.org List-Help: mailto:dwm+h...@suckless.org List-Post: mailto:dwm@suckless.org MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary=_===2044759cg2.fz-rossendorf.de===_ X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at fz-rossendorf.de --_===2044759cg2.fz-rossendorf.de===_ Content-Type: text/plain; charset=utf-8 Message delivered to 'j.van_den_h...@cg.fzd.de' LOCAL module(account v...@fzd.de) reports: Delivered to the user mailbox --_===2044759cg2.fz-rossendorf.de===_ Content-Type: message/delivery-status Reporting-MTA: dns; cg2.fz-rossendorf.de Original-Recipient: rfc822;j.van_den_h...@cg.fzd.de Final-Recipient: LOCAL;v...@fzd.de Action: delivered Status: 2.0.0 --_===2044759cg2.fz-rossendorf.de===_ Content-Type: text/rfc822-headers Received: from mx1.fz-rossendorf.de ([149.220.142.11] verified) by cg2.fz-rossendorf.de (CommuniGate Pro SMTP 5.2.12) with ESMTP
Re: [dwm] [dwm+ow...@suckless.org: Messages from dwm@suckless.org to you have been bouncing]
On Fri, Mar 06, 2009 at 09:17:26PM -0700, Neale Pickett wrote: Premysl Hruby dfe...@gmail.com writes: I had saved one bounce message mlmmj received from your MX, and it looks like your MX is acting very strangely (bounce message attached to this email). thanks for looking into this. Wow, his MTA (or maybe MUA) is sending out a delivery status notification, saying that the message was delivered. I didn't think any MTAs actually did that, it can create many problems (like the current one). Joerg, you should check your mail client to see if it's sending out delivery status notifications (DSNs). What's happening is that your mail client, or your mail server, is responding back to the message I presume, it's our IMAP server in central IT. I'll forward your message. I'm using `mutt' (which at least claims to suck less than other mail clients) and AFAICS should have nothing to do with the delivery notification, right? saying I got it! mlmmj (the list software used at suckless.org, which I happen to have contributed to) treats any response to the envelope sender address as a bounced message. naive question: would it harm if mlmmj would treat the DSN has harmless/irrelevant instead of 'bounced'? I'm guessing there's some sender on the list who requests delivery status notifications on their outbound messages, and this is why you only see the bounces occasionally. I start to get the picture. I'll refrain from expounding on my opinion of DSNs. Check the Internet if you're curious. I always am. thanks again, joerg
Re: [dwm] [dwm+ow...@suckless.org: Messages from dwm@suckless.org to you have been bouncing]
On Sat, Mar 07, 2009 at 12:40:35PM +0100, Premysl Hruby wrote: On (07/03/09 11:50), Joerg van den Hoff wrote: To: dwm mail list dwm@suckless.org Cc: Premysl Hruby dfe...@gmail.com From: Joerg van den Hoff j.van_den_h...@fzd.de Subject: Re: [dwm] [dwm+ow...@suckless.org: Messages from dwm@suckless.org to you have been bouncing] ... Wow, his MTA (or maybe MUA) is sending out a delivery status notification, saying that the message was delivered. I didn't think any MTAs actually did that, it can create many problems (like the current one). Joerg, you should check your mail client to see if it's sending out delivery status notifications (DSNs). What's happening is that your mail client, or your mail server, is responding back to the message I presume, it's our IMAP server in central IT. I'll forward your message. I'm using `mutt' (which at least claims to suck less than other mail clients) and AFAICS should have nothing to do with the delivery notification, right? I'm using mutt too, and have no problem. Do you use any other program/device to access that IMAP account? quite generally, no. very rarely, I've to use a web-browser interface to the mail server. but I'm quite sure this has no relation to the current problems (which have appeared only rather recently -- maybe related to some update on the server side, I'll try to check with IT). saying I got it! mlmmj (the list software used at suckless.org, which I happen to have contributed to) treats any response to the envelope sender address as a bounced message. naive question: would it harm if mlmmj would treat the DSN has harmless/irrelevant instead of 'bounced'? No, that's not possible. If you look on that bounce message carefully you will see that your MX is sending it as MAILERDAEMON ( address to be precise) so that's fully featured bounce message. I'm guessing there's some sender on the list who requests delivery status notifications on their outbound messages, and this is why you only see the bounces occasionally. Well, I searched dwm archive and there's no email with header from disposition-notification-* family -- one responsible for requesting that I read your email thingie. meaning it's mysterious, _why_ our server spills out his DSNs? anyway, since I know (next to) nothing of mail protocol internals I'll have to wait what central IT is going to say and let you know their answer. regards, joerg I start to get the picture. I'll refrain from expounding on my opinion of DSNs. Check the Internet if you're curious. I always am. thanks again, joerg regards -- Premysl Anydot Hruby, http://www.redrum.cz/
Re: [dwm] [dwm+ow...@suckless.org: Messages from dwm@suckless.org to you have been bouncing]
On Thu, Mar 05, 2009 at 09:35:43AM +0100, Szabolcs Nagy wrote: On 3/5/09, Szabolcs Nagy nszabo...@gmail.com wrote: 7587 messages: Starting Wed Jul 19 2006 - 06:39:23 UTC, Ending Thu Mar 05 2009 - 08:03:46 UTC so i wonder which is the no. 7600 if there is only 7538.. 7587 (sorry) well the last one I've got ( Fri, 06 Mar 2009 00:00:09 + ) reads: ==CUT== Hi, this is the mlmmj program managing the mailinglist dwm@suckless.org Some messages to you could not be delivered. If you're seeing this message it means things are back to normal, and it's merely for your information. Here is the list of the bounced messages: 7617 ==CUT== right now the archive counts 7610 mails. I presume this is updated only once a day or something? so I can wait a day or so before looking which mail bounced, but still: is there an easy way to find, e.g, message no. 4321? until a few weeks ago I've never seen such bouncing messages. it does'nt occur with any other list, too. regards, joerg
[dwm] [dwm+ow...@suckless.org: Messages from dwm@suckless.org to you have been bouncing]
hi, I still get sporadically (about once a week) messages of this kind. our sysadmin tells me that he can't see any mails rejected by our server. I now want to check _which_ messages exactly have bounced (if at all). question: how can I identify the mail in the mail archive from the message number given in the bounce message? there seems to be no way (except counting myself...) to deduce the incremental message index. so which message is no. 7600? thanks, joerg ---BeginMessage--- Hi, this is the mlmmj program managing the mailinglist dwm@suckless.org Some messages to you could not be delivered. If you're seeing this message it means things are back to normal, and it's merely for your information. Here is the list of the bounced messages: 7600 ---End Message---
[dwm] [dwm+ow...@suckless.org: Messages from dwm@suckless.org to you have been bouncing]
hi there, some days ago I've started to receive mails like the attached one (about 3 up to now). so I have a few questions: -- does anybody else see this? -- what exactly does the message mean (list of bounced messages: 7257)? -- is this a problem upstream on the mailing list machine or a local problem of my mail server? what can I do about it? thanks a lot joerg ---BeginMessage--- Hi, this is the mlmmj program managing the mailinglist dwm@suckless.org Some messages to you could not be delivered. If you're seeing this message it means things are back to normal, and it's merely for your information. Here is the list of the bounced messages: 7527 ---End Message---
Re: [dwm] cycling through tags?
On Tue, Nov 18, 2008 at 07:53:35PM -0500, James Turner wrote:
Epic fail on the diff, left some stuff in there that shouldn't be. Try
the new attached one.
I did: works perfectly. thanks a lot, this is really appreciated.
best regards,
joerg
--
James Turner
BSD Group Consulting
http://www.bsdgroup.org
--- config.def.h Tue Sep 9 15:46:17 2008
+++ config.def.h Tue Nov 18 19:26:53 2008
@@ -61,6 +61,8 @@ static Key keys[] = {
{ MODKEY, XK_l, setmfact, {.f = +0.05}
},
{ MODKEY, XK_Return, zoom, {0} },
{ MODKEY, XK_Tab,view, {0} },
+ { MODKEY, XK_Right, viewnext, {0} },
+ { MODKEY, XK_Left, viewprevious, {0} },
{ MODKEY|ShiftMask, XK_c, killclient, {0} },
{ MODKEY, XK_t, setlayout, {.v =
layouts[0]} },
{ MODKEY, XK_f, setlayout, {.v =
layouts[1]} },
--- dwm.c Tue Sep 9 15:46:17 2008
+++ dwm.c Tue Nov 18 19:31:55 2008
@@ -198,6 +198,8 @@ static void updatesizehints(Client *c);
static void updatetitle(Client *c);
static void updatewmhints(Client *c);
static void view(const Arg *arg);
+static void viewnext(const Arg *arg);
+static void viewprevious(const Arg *arg);
static int xerror(Display *dpy, XErrorEvent *ee);
static int xerrordummy(Display *dpy, XErrorEvent *ee);
static int xerrorstart(Display *dpy, XErrorEvent *ee);
@@ -1667,6 +1669,40 @@ view(const Arg *arg) {
if(arg-ui TAGMASK)
tagset[seltags] = arg-ui TAGMASK;
clearurgent();
+ arrange();
+}
+
+void
+viewnext(const Arg *arg) {
+ unsigned int i;
+
+ for(i = 0; i LENGTH(tags); i++) {
+ if((1 i TAGMASK) == tagset[seltags]) {
+ seltags ^= 1;
+ if(i == LENGTH(tags) - 1)
+ tagset[seltags] = 1 0 TAGMASK;
+ else
+ tagset[seltags] = 1 (i + 1) TAGMASK;
+ break;
+ }
+ }
+ arrange();
+}
+
+void
+viewprevious(const Arg *arg) {
+ unsigned int i;
+
+ for(i = 0; i LENGTH(tags); i++) {
+ if((1 i TAGMASK) == tagset[seltags]) {
+ seltags ^= 1;
+ if(i == 0)
+ tagset[seltags] = 1 (LENGTH(tags) - 1)
TAGMASK;
+ else
+ tagset[seltags] = 1 (i - 1) TAGMASK;
+ break;
+ }
+ }
arrange();
}
[dwm] cycling through tags?
hi,
I want to be able to cycle through all tags using some key combination
(instead of explicitely jumping to tag no. xxx).
in 4.9 someone on this list helped me getting this right:
void
goto_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();
}
was the function needed. this obviously does not work any longer in 5.2.
looking at the 5.2 source code I was not able to see immediately
the neccessary modifications to make it work again.
can somebody help me with this?
thanks,
joerg
Re: [dwm] Need a small image resize program
On Fri, Jun 13, 2008 at 10:43:46AM +0200, markus schnalke wrote: Hoi community, I feel the need for a image resize program that matches the Unix and suckless philosophy. Currently I'm using ImageMagick, which is just fine, if it is already installed. But I was shocked, when I had to install it on a clean system: I has that many dependencies! The only thing I wanted was a program to resize images and I had to install about 80 megabyte! Does anyone know a small program that can resize JPEG and PNG images? meillo not exactly what you are looking for, but maybe good old `xv' is a step in the right direction. for one thing it's much faster for certain things (e.g. edge detection) than ImageMagick. don't forget to use floating layout when using `xv'... joerg
Re: [dwm] way towards 5.0
On Sat, May 17, 2008 at 04:05:16PM +0200, Anselm R. Garbe wrote:
Here are the most recent changes I did to the codebase today
(most stuff towards 5.0 is done now).
- DEFGEOM is replaced by a function updategeom(), and a function
pointer updategeom in each layout definition
- removed Client-{fx,fy,fw,fh}
- removed reapply()
- removed tileh*, counttiled(), etc stuff
- moved all tile-related stuff to tile.c, which is included in
config.h. tile.c contains tile(), setmfact(), zoom() and a new
updatetilegeom() function. tile.c also includes the definition
of mfact, m{x,y,w,h} and t{x,y,w,h}
- renamed nexttiled() into nextunfloating()
- removed monocle (temporarily until I write this monocle
meta-layout which will be toggled when Mod1-m is pressed)
I vote for essentially keeping current (4.9) monocle functionality as a
poor men's appoximation to tabbing. It's _much_ better than
maximization on a per-window basis. consider, e.g., the following
scenario: use of numerical software producing a modest number (say 3-4)
of 2D-plots in separarte windows (think `octave' or `R'). inspecting
such output sensibly is at the very least tedious in tiled layout (what
with moving back and forth to the master area). `monocle' is just fine
for such tasks: cycling through a number of equally important windows
rapidly and with ease.
I generally would argue for a middle way between support every
imaginable fancy layout and support only one layout which is THE LAW
and optimal by definition. currently I feel `standard tiling', 'floating',
`monocle' are important, but multi-column tiling does not make much
sense to me (but it's availability does'nt harm either). being to
restrictive w.r.t. layouts is, for me, definitely as bad as making it
infinitely configurable.
I further think switching back and forth between floating and tiling
should be conservative in the sense that the floating configuration
which has been arranged manually should be restored as far as possible
on the next visit to floating layout. alternatively, the switch
between layouts should (optitionally?) occur on a per-tag basis instead
globally in order to avoid unintentional destroy of a manually optimized
floating layout in another tag.
- renamed setlayout() into togglelayout()
This means, that if tile.c isn't included in config.def.h, dwm
can be used as a floating wm, which provides all core
functionality and our tagging approach.
This also means, that for people like me, who use a multihead
setup sometimes, can include a hacked version of tile.c which
provides a different updatetilegeom() and maybe a slightly
different tile() algorithm itself.
Conceptually this is now rather clean, because we also get rid
of Bool dozoom/domfact due to the code organization, that all
tile-related functions are in tile.c now and can check if
lt-arrange == tile, and then perform the necessary function or
decline.
The Layout interface hasn't changed much in this regard.
I plan to add some more convenience toggles to config.def.h to
influence the default updategeom() function a little bit for the
bar geometry/position.
Do people prefer having a fine-grain bar positioning setup or is
it more preferred to have a bar setup in the sense top or
bottom? I still believe the latter idea is nicer, if someone
wants to use dzen, patch updategeom on you own.
Let me know how welcome do you feel about those changes. Bug
reports are also welcome.
Kind regards,
--
Anselm R. Garbe http://www.suckless.org/ GPG key: 0D73F361
Re: [dwm] togglemax substiute in 4.9?
On Tue, Apr 08, 2008 at 10:50:56AM +0200, Anselm R. Garbe wrote: 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? yes, exactly what I do at the moment as a workaround. still this means hitting two different keys to go back and forth between two layouts. 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. maybe too fast for me. meaning what from the user side? if I bind a key to setlayout(NULL) it toggles layouts, right? that would be perfect. Any complains? 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 again too fast. `client' means what in this context? a screen? a tag-workspace? 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. tiling implying `monocle' in the last sentence? At manage() time I consider, that the previous geometry is the initial geometry as it would be for the floating case. Any complains? as far as I get it I think your proposal sounds good. perfect in my view would be the following behaviour: each client (correct word?) remembers _permanently_ it's last floating geometry (if `floating' has been activated at all, yet). if I come back to floating from a different layout, most of the time probably directly, (i.e. this would be toggling back and forth) but probably only after switching to several different tiling layouts, the last floating geometry is restored. in other words this would single out `floating' as the only exceptional case. If furthermore apart from the current global change of layout _and_ `mwfact'an _optional_ change of these settings on a per- tag/workspace would be implemented in mainstream I probably would stop upgrading anymore, since nothing remains to be wished :-) Kind regards, -- Anselm R. Garbe http://www.suckless.org/ GPG key: 0D73F361 same to you, joerg
[dwm] togglemax substiute in 4.9?
hi, 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). 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? regards, joerg
Re: [dwm] togglemax substiute in 4.9?
On Mon, Apr 07, 2008 at 02:07:04PM +0200, Julien Barnier wrote:
Hi Joerg,
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).
I had a similar demand, and I solved it by using a custom defgeom, as
the following in config.h :
DEFGEOM(full, 0, sh,sw, 0, 0, sw,sh, wx, wy, sw, sh, mx+mw, wy,
ww-mw, wh, wx, wy, ww, wh)
Geom geoms[] = {
/* symbol function */
{ [], single }, /* first entry is default */
{ [f],full },
};
With this configuration, I got something similar to togglemax() by
using Ctrl+Mod+Space.
HTH,
--
Julien
julien,
thanks for responding. I've not dived into the new `geom'
stuff yet, but tried your patch simply as is. I find that it
always maximizes the master area, irrespective of current
focus (but keeps the focused window in the foreground). is
that as it should be?
so, this patch helps some, but a real `togglelayout' would
be nicer :-)
joerg
Re: [dwm] Different window modes on different workspaces
On Sat, Mar 15, 2008 at 10:01:43AM +0100, Sander van Dijk wrote:
On Sat, Mar 15, 2008 at 4:50 AM, Jonny Gerold [EMAIL PROTECTED] wrote:
Hello,
I have a very simple question. I just upgraded to 4.8. And I would like
to know if there is a simple way to assign one workspace to be say tiled
mode, and another to be float mode. I would like to use tiling on some
of my workspaces, but am always pissed when I move to another desktop
with a float that gets moved out of place.
Thanks, Jonny
There are no different desktops/workspaces, there is only one.
Applying one or more tags to a window, and selecting one or more tags
for viewing influences what is displayed on that _single_ workspace
(to which the currently selected layout always applies).
I suggest you search the archives, the differences between tags and
workspaces have been discussed many, many times before (basically, as
long as you never select more than one tag for viewing, tags can be
(ab)used as workspaces, but when you select multiple tags for viewing
it becomes obvious that things like 'layout per workspace' have no
meaning in the tagging paradigm).
Also, should you come to the conclusion that the workspaces paradigm
fits you better than the tags paradigm, xmonad (xmonad.org) might be
worth looking at.
Greetings, Sander.
another 2c: afaics the `tags' vs. `workspaces' dispute is essentially a
matter of terminology. simply two different words for more or less the
same thing, namely being able to view subgroups of all existing windows while
hiding all the others. that not all (but anyway some) window managers
calling their subgroups-of-visible-windows workspaces or desktops
allow simultaneous visibility of a window on more than one workspace
seems the main difference to `dwm'.
if you use (not abuse!) the one-window-one-tag approach their is _no_
difference to the usual workspace paradigm, not from the user
perspective.
there sure is no reason which would prevent coupling the layout to the
tags ('layout per tag'). apart from the ability to look at several
tags at the same time, that is. this 'tag merging' of course is only sensible
if
one has a common layout for all tags... but that could be handled by
allowing it only if all layouts of all affected tags are currently equal.
even if a window has more than one tag this could be done. how
much overhead the additional bookkeeping would produce is a question
for anselm or the guys who seem to have provided patches in this
direction.
but coming to think of it: _if_ the layouts could be made a tag-specific
thing (i.e. alowing a different layout for each tag)
and if at the _same_ time the positions of a window in a floating
layout could be memoized to enable restoration of the position if the
layout is becoming 'floating' again, that would be really nice. I
presume without remembering the 'floating position' one would not be
happy if a window actually has two tags and one switches from tag one
(floating) to tag two (tiling) and than again to tag one...
this of course is the same problem one sees right now when switching floating
to tiling and back: loss of previously manually arranged floating layout. it's
not a bug, but sure it's not a feature, too...
joerg
Re: [dwm] still simplicity or featureitis?
On Fri, Mar 14, 2008 at 02:07:55PM +0100, Anselm R. Garbe wrote: On Fri, Mar 14, 2008 at 01:56:58PM +0100, Giorgio Lando wrote: Actually 4.7 has been for me feature complete and subjectively bug free. In 4.8 there are new things for which I am unable to imagine a scenario of use (both monocle and vertical tile) and one thing which I miss (the possibility to toggle the bar). But this is not a real problem for me, vanilla dwm-4.7 is actually quite the perfect wm for me, there is no improvement I can think of, so I will simply stay with it indefinitely. Well development is going on and there are chances that some general screen geometry manipulation functions will appear in mainstream dwm which replace setmwfact and togglebar. For now I decided against such an attempt, because I'm curios about what people come up with. at least with a please keep/restore both :-). `togglebar` mainly to have a real full screen presentation mode, `mwfact' since it _never_ will be right all the time for all users if hardcoded. the latter (having `mwfact') seems quite important to me. I like especially the ease of use. cf., e.g., with `ion3' where such adjustments are quite a pain in the back (first activate resize; than adjust all 4 borders if you like -- achieving the simple equivalent of `mwfact' takes much more time/effort). of course if you think of completely different strategies to manipulate the geometry (instead of removing the ability to do so), forget immediately what I've said (apart from: keep ease of use). and contrary to the initial post I'd say `monocle' is very useful indeed. but 'vertical tile' does not make sense, at least not on a single monitor, not for me in any case. (by- the-by, if 'vertical' is the 'new' tile and 'horizontal' is the standard tile, I'd say the names are swapped: in the standard tile the windows are vertically tiled one above the other, so why is this the 'horizontal tiling' ...) joerg
Re: [dwm] recent changes
On Thu, Mar 06, 2008 at 08:20:00PM +0100, Anselm R. Garbe wrote:
I investigated further today and refactored a lot. First of all
I got rid of dozoom, I extended Layout to contain a Bool
isfloating flag as well, which roughly tells dwm that the
layout algorithm is floating (hence there are no layers of tiled
windows being treated differently if isfloating is True in Layout).
I also refactored tile(), which consists of 5 functions now,
tilev(), tileh(), tilemaster(), tilevstack(), tilehstack().
Due to the change yesterday, I believe that with some testing
and bug fixing the bstack layout is a special config.h setting
now with different M{X,Y,W,H} and T{X,Y,W,H} settings .
I decided to add a tileh() layout which does the following in my
multiscreen setup (and which is pretty much similiar to
bstack, except that it expands on my second bigger screen), see
this screenshot:
http://www.suckless.org/shots/dwm-hstack.png
I also changed setlayout that it toggles to the previous layout,
if it is called twice. Due the fact of tileh, I changed the
setlayout keybindings slightly as you will notice on the
screenshot.
Also, monocle() now works like a floating layout, except that it
maximizes all windows to MOX, MOY, MOW, MOH. I decided against
rectangle restoring, this is a dynamic WM anyways.
I will be offline till Tuesday. Please test the stuff, report
bugs and feedback on this list, I will have a look then and
consider releasing the stuff next week.
Btw. I also changed dmenu yesterday, -b is gone, instead I
introduced -x x -y y -w w as command line options.
Kind regards,
--
Anselm R. Garbe http://www.suckless.org/ GPG key: 0D73F361
hoping not to interfere. just a few thoughts from a pure user perspective
(mine...):
-- multiscreen, even Xinerma support is nice to have as long as single screen
operation is not compromised. it seems some beloved things might be left behind?
I, too, think `setmwfact' is quite useful, e.g.. multiscreen setups (hopefully)
will remain a rather small niche, I'd say: large desktop monitors are already
available at affordable prices and the other big use case will be labtops.
so I'd say optimal support of single screen operation is _much_ more important
than multi-screen.
-- coming from ion3 I see some nice advantages of dwm (not the least a main
author not permanently on war with something/someone or other).
-- the multitude of patches/opionions of what is an indispensable layout says
something important: one size fits all does not work so well.
enforcing that every user should go and patch dwm to his/her liking?
well, user's usually can't do that either for reasons of capabilities or time
or both...
so what I would really like to see is a small(!) number of good
layouts to choose from. monocle plus standard stack seem to come
with 4.8, which is good. my question here would be, whether not consensus could
be reached on, say, 4-5 sensible layouts which should be available. e.g. a nice
functionality
in `ion3' is to transpose the current layout, meaning reflection
along the screen diagonal (top right to bottom left). this would, e.g.
bring standard stack to vertical stack, if I understand the intention
of the latter right. so, instead of introducing vertical stack via a patch
or additional standard layout should a 'transpose' option not be preferred? I
personally would be perfectly content with the following layouts,
which should be available by default:
- floating
- standard stack
- monocle
- a tiling layout which always splits the currently largest subwindow
keeping new windows as 'near square' as
possible (i.e. implicit decision whether to split horizontally
or vertically). (up to three this is identical to standard stack, but
with 4 windows one would get 4 equal size windows and after that
further splitting seems usually not to make that much sense).
augmenting this by a 'transpose' (and maybe mirroring left/right and up/down)
option should cover almost any imaginable desire (in this area, I mean :-))
-- the greatest shortcoming of `dwm' in my view is the absense of tabbing
support. I would value something like this much more than sophisticated
multiscreen support. monocle essentially provides this in 'full screen'
mode but it would be great to have it on a per-window basis.
-- another point (patches seem around, but again: this should be done upstream,
I believe): switching between floating and stacking and back does not restore
window sizes. but this would be extremly helpful: without memorizing the window
sizes/positions of the floating layout a switch to stacking destroys any
arrangment of windows of the previous floating layout
(especially on workspaces/tag groups which you are currently _not_ viewing ...)
being able to go back to the floating layout as it was when
last visited would really be nice.
-- a related point: a per-workspace/tag layout approach (having some floating,
some stacking views) would
Re: [dwm] I like Dmenu a little simpler
On Sat, Mar 08, 2008 at 10:35:46PM +0100, Henrik Holst wrote:
Date: Fri, 7 Mar 2008 16:40:22 +0100
From: Joerg van den Hoff [EMAIL PROTECTED]
Subject: Re: [dwm] I like Dmenu a little simpler
To: dynamic window manager dwm@suckless.org
Message-ID: [EMAIL PROTECTED]
Content-Type: text/plain; charset=us-ascii
On Fri, Mar 07, 2008 at 01:11:33PM +0100, Szabolcs Nagy wrote:
On 3/7/08, Joerg van den Hoff [EMAIL PROTECTED] wrote:
I was expecting that the selected entry is fed to `exec' or
whatever. simple question: what is supposed to happen and
how do I use `dmenu' sensibly?
have you edited dmenu_run? how do you call dmenu_run in dwm config.h?
I'm mostly using 4.7 right now and there (contrary to what's
in the repository) is no `dmenu_run'. rather, `mod1-p' has
it's default binding, namely essentially (deleting the color
settings stuff):
exe=`dmenu_path | dmenu` exec $exe
I confess guilty of not having looked at the source code
before posting, but it seems that the above actually should
do what I expected: (attempt to) execute the selection.
but, e.g., selecting `gv' and hitting return has no visible
consequences. using the above binding in a shell yields
correct behaviour, though.
so I repeat my question: might the problem have to do with
the BUGS section of the `dwm' manpage (I seee this 'EOF'
at the r.h.s. of the statusbar)?
joerg
Hi!
I had the same problem with dwm 4.7 in Solaris.
This solution works for me and is not so complex:
{ MODKEY, XK_p, spawn,
$SHELL -c `dmenu_path | dmenu -fn 'FONT' -nb
'NORMBGCOLOR' -nf 'NORMFGCOLOR'
-sb 'SELBGCOLOR' -sf 'SELFGCOLOR'` },
(Should work as good with zsh, bash and dash.)
--
Henrik Holst
thanks a lot. I've taken over this approach, but explicitely call sh -c in
order
to enforce use of `sh' even if my interactive default shell is something
different
(tcsh in my case). it works now...
I would think a similar modification should be done upstream: enforcing
`sh' explicitly seems much better than assuming everybody has set SHELL to `sh'.
joerg
Re: [dwm] I like Dmenu a little simpler
On Fri, Mar 07, 2008 at 11:56:53AM +0100, Antoni Grzyma??a wrote: On Fri, 07 Mar 2008 11:14:59 +0100, Enno Gottox Boland [EMAIL PROTECTED] wrote: this is not be done by dmenu but by dmenu_path. This is a simple Yes, dmenu is totally dumb in that respect, it just shows what you feed to it. Try running `echo -e ls\npwd\nwhoami | dmenu` from a shell. [a] sorry for intruding on this thread. I've ignored `dmenu' up to now completely. I tried now (mod1-p), but when I select some entry and hit return, nothing happens at all. the manpages of `dwm' and `dmenu' don't enlighten me (beyond doing something silly like your shell example above). I was expecting that the selected entry is fed to `exec' or whatever. simple question: what is supposed to happen and how do I use `dmenu' sensibly? thanks, joerg PS: I'm on MacOS and the statusbar shows the EOF bug mentionend in the `dwm' manpage, i.e. stdout is closed already before `dwm' executes. is that the problem?
Re: [dwm] I like Dmenu a little simpler
On Fri, Mar 07, 2008 at 01:11:33PM +0100, Szabolcs Nagy wrote: On 3/7/08, Joerg van den Hoff [EMAIL PROTECTED] wrote: I was expecting that the selected entry is fed to `exec' or whatever. simple question: what is supposed to happen and how do I use `dmenu' sensibly? have you edited dmenu_run? how do you call dmenu_run in dwm config.h? I'm mostly using 4.7 right now and there (contrary to what's in the repository) is no `dmenu_run'. rather, `mod1-p' has it's default binding, namely essentially (deleting the color settings stuff): exe=`dmenu_path | dmenu` exec $exe I confess guilty of not having looked at the source code before posting, but it seems that the above actually should do what I expected: (attempt to) execute the selection. but, e.g., selecting `gv' and hitting return has no visible consequences. using the above binding in a shell yields correct behaviour, though. so I repeat my question: might the problem have to do with the BUGS section of the `dwm' manpage (I seee this 'EOF' at the r.h.s. of the statusbar)? joerg
Re: [dwm] I like Dmenu a little simpler
On Fri, Mar 07, 2008 at 07:05:30PM +0300, Alexander Polakov wrote: * Joerg van den Hoff [EMAIL PROTECTED] [080307 19:00]: On Fri, Mar 07, 2008 at 01:11:33PM +0100, Szabolcs Nagy wrote: On 3/7/08, Joerg van den Hoff [EMAIL PROTECTED] wrote: I was expecting that the selected entry is fed to `exec' or whatever. simple question: what is supposed to happen and how do I use `dmenu' sensibly? have you edited dmenu_run? how do you call dmenu_run in dwm config.h? I'm mostly using 4.7 right now and there (contrary to what's in the repository) is no `dmenu_run'. rather, `mod1-p' has it's default binding, namely essentially (deleting the color settings stuff): exe=`dmenu_path | dmenu` exec $exe I confess guilty of not having looked at the source code before posting, but it seems that the above actually should do what I expected: (attempt to) execute the selection. but, e.g., selecting `gv' and hitting return has no visible consequences. using the above binding in a shell yields correct behaviour, though. what shell are you using? try starting dwm like this SHELL=/bin/sh dwm interactively I use tcsh (i.e. SHELL is set to this, too), but dwm is started from within .xinitrc which has `#!/bin/sh' in the first line, so is executed as bourne shell script. that should do, right? so I repeat my question: might the problem have to do with the BUGS section of the `dwm' manpage (I seee this 'EOF' at the r.h.s. of the statusbar)? no mmh. anyone using `dwm' with MacOS without this problem?
Re: [dwm] visibility of focused windows
On Wed, Mar 05, 2008 at 11:00:49PM -0500, John S. Yates, Jr. wrote:
I have not looked at the code in a good while but wanted to suggest
the following code concept. My thought sprang from Anselm writing
I propose using setlayout([M]) and setlayout([]=)
and then later
I plan to introduce 3 additional key bindings:
Mod1-f (Apply floating layout)
Mod1-m (Apply monocle layout)
Mod1-t (Apply tiled layout)
There already is a notion of the current layout. Imagine that
there is also a saved layout and the following function:
char *resolvelayout(char *proposed)
{
if (proposed == current)
proposed = saved;
else
saved = current;
current = proposed;
return proposed;
}
With this function I can have every target layout toggle:
setlayout( resolvelayout([M]) );
setlayout( resolvelayout([]=) );
setlayout( resolvelayout() );
Just a thought,
/john
john,
thanks for bothering. I'll have a look at this. I believe that
toggling back and forth is frequently much better than explicit
selection of the desired layout, even for the price of a few lines of
code :-).
joerg
Re: [dwm] visibility of focused windows
On Tue, Mar 04, 2008 at 05:11:02PM +0100, Anselm R. Garbe wrote: On Tue, Mar 04, 2008 at 04:44:34PM +0100, Joerg van den Hoff wrote: On Tue, Mar 04, 2008 at 05:51:30PM +0300, Alexander Polakov wrote: * Joerg van den Hoff [EMAIL PROTECTED] [080304 17:21]: question 1: should not the focused window be always brought to the foreground irrespective of whether it is currently maximized or not? it's even more irrating when you already have a few maximized windows and then open another one: the new window again will never be visible if you cycle the focus with mod1-j as long as it is not maximized first. Just use monocle layout for that. thanks for this hint. I'll have a look at that. question remains, whether, if the current behaviour is seen as not desirable, it can't be fixed in the main branch of `dwm', instead. monocle will be in mainstream dwm tonight. -- Anselm R. Garbe http://www.suckless.org/ GPG key: 0D73F361 thanks a lot! this works nicely. question: why is `togglemax' gone? it sure is useful (despite 'monocle') in the standard tiling layout for maximizing/restoring a single window in turn. joerg
Re: [dwm] visibility of focused windows
On Wed, Mar 05, 2008 at 01:21:14PM +0100, Anselm R. Garbe wrote: On Wed, Mar 05, 2008 at 12:54:33PM +0100, Joerg van den Hoff wrote: On Tue, Mar 04, 2008 at 05:11:02PM +0100, Anselm R. Garbe wrote: On Tue, Mar 04, 2008 at 04:44:34PM +0100, Joerg van den Hoff wrote: On Tue, Mar 04, 2008 at 05:51:30PM +0300, Alexander Polakov wrote: * Joerg van den Hoff [EMAIL PROTECTED] [080304 17:21]: question 1: should not the focused window be always brought to the foreground irrespective of whether it is currently maximized or not? it's even more irrating when you already have a few maximized windows and then open another one: the new window again will never be visible if you cycle the focus with mod1-j as long as it is not maximized first. Just use monocle layout for that. thanks for this hint. I'll have a look at that. question remains, whether, if the current behaviour is seen as not desirable, it can't be fixed in the main branch of `dwm', instead. monocle will be in mainstream dwm tonight. -- Anselm R. Garbe http://www.suckless.org/ GPG key: 0D73F361 thanks a lot! this works nicely. question: why is `togglemax' gone? it sure is useful (despite 'monocle') in the standard tiling layout for maximizing/restoring a single window in turn. Well, I propose using setlayout([M]) and setlayout([]=) instead. yes, I discovered this already (and without pestering the list...). it sure helps do avoid the cycling through all three layouts. but that was not my point. sorry, if I have not been clear enough: I really mean the old 'mod1-m' functionality in the tiled layout: toggle maximization status of the focused window. this is still desirable, despite availability of monocle, I'd say: maximize a _single_ window, do something and shrink it back to its position in the tiling. it depends on circumstances whether this is more (or less) suitable than monocle. I personally think a maximize window option should always be available in addition to maximize all (a.k.a. monocle). I know you are approaching the self-imposed 2000 loc limit, but maybe this can be relaxed a bit? :-). best regards, joerg Kind regards, -- Anselm R. Garbe http://www.suckless.org/ GPG key: 0D73F361
Re: [dwm] visibility of focused windows
On Wed, Mar 05, 2008 at 02:18:25PM +0100, Anselm R. Garbe wrote: On Wed, Mar 05, 2008 at 01:47:16PM +0100, Szabolcs Nagy wrote: On 3/5/08, Joerg van den Hoff [EMAIL PROTECTED] wrote: but that was not my point. sorry, if I have not been clear enough: I really mean the old 'mod1-m' functionality in the tiled layout: toggle maximization status of the focused window. this is still desirable, despite availability of monocle, I'd say: maximize a _single_ window, do something and shrink it back to its position in the tiling. it depends on circumstances whether this is more (or less) suitable than monocle. I personally think a maximize window option should always be available in addition to maximize all (a.k.a. monocle). can you please describe a common scenario when the two is different? (eg if you only want a quick maximize+revert then it can be achieved by toggling layout between monocle and tile) Another possibility is, use some tag as max tag, e.g. 5, then toggletag(tags[4]) and do view(tags[4]) for a temporarily maximised window, viewprev() can be used now as togglemax()-replacement. The decision to remove togglemax is related to the fact, that there should only be one way to achieve a certain functionality. And togglemax is a special case of using tagging in a powerful way. yes, I see that this could be a work-around. but still it complicates things. maybe you think this over again? I see your point that monocle does not solve the issue at all. Btw. I plan to introduce 3 additional key bindings: Mod1-f (Apply floating layout) Mod1-m (Apply monocle layout) Mod1-t (Apply tiled layout) very good. did'nt dare to ask for this and was prepared (with clenched teeth) to patch this into config.h myself :-). and without reiterating my complaints about not having a config file: what do you think could be a user-friendly and minimal invasive strategy to add certain patches to the core of `dwm' without getting completely locked to a specific version (or being forced to continually recreate the patches for every release)? e.g., some helpful soul showed me how to implement cycling through tags. since prototypes _and_ definition of the corresponding function(s) are deep inside dwm.c, migration to the upcoming 4.8 means manual intervention again (and again and again...). could not this simple-minded strategy help: insert (once and forever) #include dwm_addons.h below the standard prototypes in dwm.c into `dwm.c' and provide and (initially empty) file dwm_addons.h. and further insert #include dwm_addons.c (again provided as empty file initially) immediately before `int main(...' (or modify the Makefile to always link `dwm_addons.c'). and finally the same approach for config.h to define keybindings for the additional functions. of course this won't be adquate for patches which really mess with the `dwm' code, but for a certain sup-group of patches (those which actually are independent functions providing some functionality, e.g. the cycling through tags mentioned above) it would suffice. migration to a new release would then not necessitate _any_ modifications to the newly arrived `dwm.c'. is this nonsense? joerg Kind regards, -- Anselm R. Garbe http://www.suckless.org/ GPG key: 0D73F361
Re: [dwm] visibility of focused windows
On Wed, Mar 05, 2008 at 03:45:09PM +0100, Szabolcs Nagy wrote: On 3/5/08, Jeremy O'Brien [EMAIL PROTECTED] wrote: Do you have a quick solution for maximizing floating windows? an ugly solution would be a key binding for: togglefloat() monocle() togglefloat() tile() but this way you cannot restore the original size to restore the original state you should save the size before maximizing and the current client struct has no space for that if you want to implement a correct togglemax for floating windows then you have to extend the client struct (i guess floating win maximization is a rare use case among dwm users so it doesn't worth the extra attributes in client, but i can be wrong) depends. I, too, usually avoid floating layout, but sure there are situations where you want it (otherwise it would'nt be there in the first place). and _if_ you use it, it sure would be really good to have correct togglemax (including size/position restoration). and I firmly believe that layout should be a per-tag property (at least if the user decides this), not global: while using `ion3' I usually had a few tiled/tabbed workspaces and a single floating one for things like scribus, e.g.. that worked very well. but no misunderstanding: `dwm' is very good right now. joerg
Re: [dwm] visibility of focused windows
On Wed, Mar 05, 2008 at 02:18:25PM +0100, Anselm R. Garbe wrote: On Wed, Mar 05, 2008 at 01:47:16PM +0100, Szabolcs Nagy wrote: On 3/5/08, Joerg van den Hoff [EMAIL PROTECTED] wrote: but that was not my point. sorry, if I have not been clear enough: I really mean the old 'mod1-m' functionality in the tiled layout: toggle maximization status of the focused window. this is still desirable, despite availability of monocle, I'd say: maximize a _single_ window, do something and shrink it back to its position in the tiling. it depends on circumstances whether this is more (or less) suitable than monocle. I personally think a maximize window option should always be available in addition to maximize all (a.k.a. monocle). can you please describe a common scenario when the two is different? (eg if you only want a quick maximize+revert then it can be achieved by toggling layout between monocle and tile) Another possibility is, use some tag as max tag, e.g. 5, then toggletag(tags[4]) and do view(tags[4]) for a temporarily maximised window, viewprev() can be used now as togglemax()-replacement. The decision to remove togglemax is related to the fact, that there should only be one way to achieve a certain functionality. And togglemax is a special case of using tagging in a powerful way. I see your point that monocle does not solve the issue at all. Btw. I plan to introduce 3 additional key bindings: Mod1-f (Apply floating layout) Mod1-m (Apply monocle layout) Mod1-t (Apply tiled layout) on second thought: could'nt `mod1-m' be made to toggle between monocle and tiling, instead (omitting `mod1-t' completly, maybe)? this would more or less emulate the old `mod1-m'. such rapid switching back and forth with one key would seem useful. joerg
[dwm] visibility of focused windows
dear list,
consider the following scenario:
1. open at least two windows, e.g. xterms, in a previously
empty view. these appear in the standard tiling layout of
`dwm'.
2. maximize ('full screen') the window which currently has
the focus (main window or the other one).
3. set focus (mod1-j) to next window. here comes the first
annoying point: the second window now is focused but does
not come to the front, i.e. it remains hidden behind the
first one.
4. maximize the now focused second window. only now it is
brought to the front and becomes visible. undoing the
maximize again hides it behind the other one. as long as the
second (or further) window(s) remain in the maximized state,
changing focus with mod1-j brings the newly focused window
to the front, which is fine and as it should be.
question 1: should not the focused window be always brought
to the foreground irrespective of whether it is currently
maximized or not? it's even more irrating when you already
have a few maximized windows and then open another one: the
new window again will never be visible if you cycle the
focus with mod1-j as long as it is not maximized first.
my interest in this scenario is mainly driven by the attempt
of getting an approximation to tabbing (such as provided by
`ion'): changing focus between several maximized windows
achieves this to some extent but its not a very good
approximation (e.g. no status information except for focused
window).
question 2: is there a chance for real tabbing support (this
would seem more important than xinerama support to me)? or
at least a workspace (tag) specfic decision whether tiling
_or_ tabbing is used for arranging windows? and, if tabbing
is on, some information in the status bar about _all_
windows in the current tab?
I previously have used `ion3' (which I still think is a very
nice wm, but the license war initiated by it's author and
the not-so-straightforward compile of the thing got on my
nerves). so what I noted when switching to `dwm'that I
usually need about 2 times more workspaces/tags (8 instead
of 4) simply because there is no tabbing available. I think
a strong argument for tabbing is the fact that at least on
small monitors, especially labtops, one usually needs all
the available space for a single window. the tiling-only
policy of `dwm' means that one either has to maximize even
the main window in order to work or one has to use `dwm'
more or less in a one window per tagapproach. it's
different with some cinemascope monitor, of course.
question 3: a related point is whether the layout
(floating/tiling, partitioning between main window and
stacking area could not be changed on a per-tag basis?
currently these settings are global. (I think there are
patches around doing this but why not integrate it in the
main branch?)
just questions, no demands (and no proposed solution...)
all the best
joerg
Re: [dwm] visibility of focused windows
On Tue, Mar 04, 2008 at 05:51:30PM +0300, Alexander Polakov wrote: * Joerg van den Hoff [EMAIL PROTECTED] [080304 17:21]: question 1: should not the focused window be always brought to the foreground irrespective of whether it is currently maximized or not? it's even more irrating when you already have a few maximized windows and then open another one: the new window again will never be visible if you cycle the focus with mod1-j as long as it is not maximized first. Just use monocle layout for that. thanks for this hint. I'll have a look at that. question remains, whether, if the current behaviour is seen as not desirable, it can't be fixed in the main branch of `dwm', instead. question 2: is there a chance for real tabbing support (this would seem more important than xinerama support to me)? or at least a workspace (tag) specfic decision whether tiling _or_ tabbing is used for arranging windows? and, if tabbing is on, some information in the status bar about _all_ windows in the current tab? Like this http://omploader.org/vZHZz ? I posted a patch some time ago, you can google for it. yes, exactly. but googling (e.g. for `dwm tabbing polakov') did not yield anything useful, I'm afraid (or my vision is impaired). joerg
Re: [dwm] cycling through tags?
andrew,
I think I owe you this feedback (coming a bit late for different reasons):
thanks again for your patch which does exactly what I had in mind. I added
the prevtag function as well:
void
goto_prevtag(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)) % LENGTH(tags);
seltags[i] = False;
}
seltags[j] = True;
arrange();
}
and I'm quite happy now after binding these functions to MODKEY plus
XK_comma and XK_period (a bit of `ion' heritage shining through here).
I would think your solution could be a useful patch for many people -- why
not make it available on the dwm homepage?
thanks again,
joerg
On Thu, Jan 31, 2008 at 10:02:18PM +, Andrew Oakley wrote:
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] xterm resizing
On Thu, Feb 14, 2008 at 05:41:43AM -0500, Joseph Xu wrote: Hi: I have an annoying problem with xterm where it does not reflow my text whenever I change the main window width. So say I have an xterm with some text as the main window. If I shrink and then increase the main window width, it looks like the end of all the lines in the xterm just got cut off. I found something about eval `resize` on google, but I'm not sure how to use this with dwm. Anyone have a solution? Thanks a lot. Joseph I only see this with `xterm'. `urxvt' behaves more benign. and is a much nicer terminal emulator (smaller, faster, unicode support, etc.) than `xterm' in my opinion. regards, joerg
Re: [dwm] cycling through tags?
On Thu, Jan 31, 2008 at 10:02:18PM +, Andrew Oakley wrote:
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.
I'm thinking of the workspace-like situation where you view
one tag-group of a certain index 1..9. then 'next' and 'prev'
is rather well defined.
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.
only very recently I gave `dwm' a closer look (having used `ion' for
quite some time now). without question the minimalistic approach
and economic implementation is attractive. I especially appreciate
that `dwm' compiles just so on different platforms (quite the
contrary with `ion'). having said this, I
definitely don't believe in configuring a window manager by
editing the source code. at the very least, this seems to imply
that one starts over and over again with each new release (or
one has to verify that the config header default layout has not
changed. I would stil be in favour of some simple(-minded)
configuration file of the keyword/value variety (or even activating
this by a compile flag only, leaving the defaults defined in config.h).
w.r.t. hacking it to your needs: it probably is nice that it's
easy to do so. but I'm conservative here: I believe in canonical
offifical releases (which might include of course the sensible patches
from the users). the same holds true here as it did above: if I start
(and am able) to mess with the source code, get some desired functionality
running (such as, e.g. the cycling through tags), it will be gone
with the next release and I have to start thinking about putting
my additions in a separate source file (or lib), check that
the function interfaces are unmodified in the next release etc etc.
that's no good if I'm actually only a user of a nice window manager
who needs to get other things done.
while I absolutely appreciate the striving for a small code base, maybe
one could think about adding a modular aspect (added functionality
in optitional (small!) libraries), where `dwm' still compiles and works
without the libs but including them adds stuff (like the current
example of cycling through tags). if this were supported by the author
there would be some guarantee of working interfaces across releases.
if I look at the home page there a quite a few nice extensions to `dwm'
which are tied to specific releases and are simply left behind while
dwm is developed further. I think this is a pity.
is all this wrong?
If the suggestion I've made doesn't work, I could do it properly, test,
and post a patch if you like.
thanks a lot so far. I'll keep this and test it when I find
the time (too busy right now) and let you know. if I read the
code right the cycling enacted by the modulo expression is exactly
what I mean.
thanks again,
joerg
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
[dwm] cycling through tags?
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] Nice suckless password manager
On Fri, Jan 25, 2008 at 09:40:07AM -0800, Amit Uttamchandani wrote:
On Fri, 25 Jan 2008 16:46:47 +0100
Antoni Grzyma??a [EMAIL PROTECTED] wrote:
On Fri, 25 Jan 2008 16:24:20 +0100, Amit Uttamchandani [EMAIL PROTECTED]
wrote:
1. vim + encfs
2. Revelation - GTK app
3. pwsafe - CLI solution but looks like it hasn't been updated in a
while
4. KWallet
After DWM, I've been in a suckless mindset. So from the above
list...it looks like vim + encfs is a good solution.
What do DWM users use?
I just keep a GnuPG-encrypted file and edit it with vim (somewhat
transparently with relevant vim configuration).
Regards,
Thanks for the input.
That actually might be a good and simple way to do it. So when using gpg,
there is some sort of a key and passphrase involved correct?
Can you post your steps on how to get the encrypt/decrypt the file?
Thanks,
Amit
you must set up `gpg' correctly first, of course. look, e.g. at
http://www.gnupg.org/gph/en/manual.html
generating a new keypair
if you've set it up, it's simple:
`gpg -e {your_passwords_file}'
for encrypting it (you might also pass your user-id (the recipient) directly
via `-r', otherwise gpg asks)
and
`gpg {you_passwords_file}.gpg'
for recovering the clear text.
try it out with some copy first :-)
hth
joerg
Re: [dwm] problem with move window while dragging (mod1-button1)
On Wed, Dec 19, 2007 at 08:43:42PM -0500, Jeremy O'Brien wrote: On Wed, Dec 19, 2007 at 06:48:12PM +0100, Joerg van den Hoff wrote: hi, I want to give `dwm' a serious try (used it only sporadically on my labtop up to now). so far everything seems to work except window movement which mod1-button1 mouse dragging. nothing happens. floating windows always pop up in the upper left corner of the screen and stay there. resizing with mod1-button3 works, though. I even installed some patches from the home page enabling keyboard based movement of windows, which works more or less. I search Gmane but did'nt see anything relating to this. this is under MacOSX. what am I doing wrong? any help appreciated, joerg You've tried both alt/option and the command key? This is probably an OS X issue. I've had mixed results from running X on OS X. -- mod1 (alt) is recognized correctly (in all keyboard commands as well as in mod1-button3 + dragging, i.e. window resize). maybe it is an mac related X11 issue, but I'm not sure. I still use the (old) Xfree86 version coming with macos 10.4 and it works correctly AFAICS. but what I realized only now is that mod1-button1-click anyway does usually insert previously selected text in an xterm (i.e. this combination emulates a sole button2 click). and it does this still, so maybe this function masks the `dwm' definition. anyway, thanks for bothering, joerg
Re: [dwm] problem with move window while dragging (mod1-button1)
On Thu, Dec 20, 2007 at 09:50:15AM -0500, Jeremy O'Brien wrote: On Thu, Dec 20, 2007 at 10:47:10AM +0100, Joerg van den Hoff wrote: On Wed, Dec 19, 2007 at 08:43:42PM -0500, Jeremy O'Brien wrote: On Wed, Dec 19, 2007 at 06:48:12PM +0100, Joerg van den Hoff wrote: hi, I want to give `dwm' a serious try (used it only sporadically on my labtop up to now). so far everything seems to work except window movement which mod1-button1 mouse dragging. nothing happens. floating windows always pop up in the upper left corner of the screen and stay there. resizing with mod1-button3 works, though. I even installed some patches from the home page enabling keyboard based movement of windows, which works more or less. I search Gmane but did'nt see anything relating to this. this is under MacOSX. what am I doing wrong? any help appreciated, joerg You've tried both alt/option and the command key? This is probably an OS X issue. I've had mixed results from running X on OS X. -- mod1 (alt) is recognized correctly (in all keyboard commands as well as in mod1-button3 + dragging, i.e. window resize). maybe it is an mac related X11 issue, but I'm not sure. I still use the (old) Xfree86 version coming with macos 10.4 and it works correctly AFAICS. but what I realized only now is that mod1-button1-click anyway does usually insert previously selected text in an xterm (i.e. this combination emulates a sole button2 click). and it does this still, so maybe this function masks the `dwm' definition. anyway, thanks for bothering, joerg That would more than likely be your problem. There is the option Emulate three button mouse in X11's preferences. You may try turning that off. -- Jeremy O'Brien aka neutral_insomniac right, that's it. I think, I did'nt look in these preferences for ages... sorry for the noise and thank's a lot. joerg
