Re: [dwm] rationale for resizehints=False?
On 8/6/08, Donald Chai [EMAIL PROTECTED] wrote: I have the inside border set up to follow resize hints (this packs more text onscreen if my display's number of rows is not a multiple of 3). The outside border does not follow resize hints, because I have them set up to be rendered exactly 1px offscreen (I don't want to see them). Any reason why the current setup is all-or-nothing? I'm not sure what you mean by having the inside border setup to follow resizehints, but the outside border does not follow resizehints? Handling resizehints doesn't have an effect on borders, it has an effect on the window. An application can for instance say I want to be resized in steps of 5 pixels only or I want to be precisely this size. When resizehints handling is enabled, dwm will honor those requests, otherwise it'll simply say this is your size, deal with it. I believe there's not much between all or nothing there (other than being able to handle/ignore specific hints, but I doubt that's what you meant). Greetings, Sander.
Re: [dwm] rationale for resizehints=False?
On 8/7/08, Donald Chai [EMAIL PROTECTED] wrote: On Aug 7, 2008, at 12:35 AM, Sander van Dijk wrote: I'm not sure what you mean by having the inside border setup to follow resizehints, but the outside border does not follow resizehints? Handling resizehints doesn't have an effect on borders, it has an effect on the window. An application can for instance say I want to be resized in steps of 5 pixels only or I want to be precisely this size. When resizehints handling is enabled, dwm will honor those requests, otherwise it'll simply say this is your size, deal with it. I believe there's not much between all or nothing there (other than being able to handle/ignore specific hints, but I doubt that's what you meant). Sorry, I think I don't think I was very precise. I have my setup as follows. For the following layout, tile assigns sizes to windows A,B,C,D (in that order). +--+---+ | | B | | +---+ | A | C | | +---+ | | D | +--+---+ I have tile set the height of A *precisely* to wh (A-h = wh). Resize hints are used for the width (A-w = A-basew + n*A-incw for some n such that |A-w - mfact*ww| A-incw). For B and C, the width is set precisely (B-w = ww - A-w), and resize hints are used for the height. So I believe there is something between all or nothing (i.e. something :)), which is to follow resize hints for one dimension only. I was just wondering why others would prefer one setting over another. So you did mean being able to handle/ignore specific hints after all. I personally think that that doesn't belong in config.h. Applications that set resizehints usually do this for a reason, and not handling them often leads to crappy behaviour. Setting it to False is a bad idea in general, and complicating matters by allowing the configuration for specific sizehints in config.h isn't going to help (what sizehints do you want to be able to configure? inc-handling/min and max size/aspect ratio?). I think such specific wishes should be dealt with in the source, not in config.h. Greetings, Sander.
Re: [dwm] dwm with dzen status bar
On 7/3/08, Oliver Heins [EMAIL PROTECTED] wrote:
Just a little remark about your netmon.sh script:
,
| ~$ time (n=0; for i in {1000..1}; do n=`echo $n+$i|bc`; done; echo $n)
| 500500
|
| real0m15.812s
| user0m0.532s
| sys 0m15.449s
| ~$ time (n=0; for i in {1000..1}; do n=$(($n+$i)); done; echo $n)
| 500500
|
| real0m0.015s
| user0m0.016s
| sys 0m0.000s
`
I don't know if arithmetic evaluation is a bashism, but I think the
costs for using bc are quite high. However, I the let syntax (e.g.,
»let n = n +i«) should work with all posix-shells and therefore be
portable.
I wouldn't be surprised if using bc the smart way is actually faster,
but the machine I'm testing on is too fast to measure the difference
between the various approaches; could you test how fast this is?
bc !
for(i = 1000; i 0; i--)
n = n + i
print n
!
Greetings, Sander.
Re: [dwm] dmenu - simplification of cistrstr and kpress
On 6/26/08, Premysl Hruby [EMAIL PROTECTED] wrote: Hi, it also defines feature macro _BSD_SOURCE, so usleep and strdup is declared. patch attached. return (char *)1;? cistrstr(s, sub) is supposed to return a pointer to the first occurence of sub in s, or NULL if there is none; not some fixed pointer to memory that's probably not even allocated to the process. Greetings, Sander.
Re: [dwm] dmenu directory test
On 6/14/08, James Turner [EMAIL PROTECTED] wrote: Doesn't it make more sense to do a test, then just redirect error output? Then you'd have to test more than your patch does: right now, your patch only tests if we're dealing with a directory; whether or not the user running the script has permission to cd into that directory is not taken in consideration. I agree with the others here that the cd itself is the safest test.
Re: [dwm] Freedom (was: Re: sic ipv6 patch)
On Tue, May 20, 2008 at 11:03 PM, Szabolcs Nagy [EMAIL PROTECTED] wrote: i deliberately used an alternative definition of freedom (and included all the dictatorship), because it makes sense to me. Well, I guess that sums it all up nicely. I think that at this point further argument is obviously useless, so I'm calling it quits. Gr. Sander.
Re: [dwm] Freedom (was: Re: sic ipv6 patch)
On Tue, May 20, 2008 at 11:10 AM, Szabolcs Nagy [EMAIL PROTECTED] wrote: most likely everyone would agree that public domain provides more freedom than GPL, but whether GPL is free or not is just a terminological question The discussion wasn't about whether or not GPL provides freedom, the discussion was about the amount of freedom. If most likely everyone would agree that public domain provides more freedom than GPL, then I'd think that the same people would also agree that MIT/BSD fit between PD and GPL in the amount of freedom they provide. Any other conclusion would seem odd to me.
Re: [dwm] Freedom (was: Re: sic ipv6 patch)
On Tue, May 20, 2008 at 3:43 PM, Matthias Kirschner [EMAIL PROTECTED] wrote: Why do you think a user who gets DWM in a binary on some device knows a) that this is DWM and b) knows that DWM is licensed under MIT? So this user does not have the freedom to use, study, share and improve the software. So now software is only free when each and every distributor is forced to educate his customers about all the wonderful things they are allowed to do with it? This is just another display of your misunderstanding of the concept freedom. Really, buy a dictionary...
Re: [dwm] Freedom (was: Re: sic ipv6 patch)
On Tue, May 20, 2008 at 3:43 PM, Matthias Kirschner [EMAIL PROTECTED] wrote: Why do you think a user who gets DWM in a binary on some device knows a) that this is DWM and b) knows that DWM is licensed under MIT? So this user does not have the freedom to use, study, share and improve the software. This has absolutely NOTHING to do with the licensing of the original product. Just because someone can use it without telling others where it came from does NOT in any way make the original product less free.
Re: [dwm] Freedom (was: Re: sic ipv6 patch)
On Tue, May 20, 2008 at 7:22 PM, Szabolcs Nagy [EMAIL PROTECTED] wrote: you missed my point the analogy is to show that removing a restriction may cause more restriction globally in some way (which also shows the flaw in your interpretation of freedom) i thougth this was trivial, but here is a less abstract analogy: - remove restriction 'copyright notice should be included' - one can sell dwm, with different copyright notice - he may restrict * (include some evil, anti-freedom restrictrions here) Up until here you're making sense. - ppl won't know about original source because it's not named, so they will face evil restrictions Here's where you're wrong. The reason ppl will face evil restrictions here, is not because of a lack of freedom, but because of a lack of knowledge. You basically say so yourself: the reason is because the original source is not named. Hence, the problem here is not the freedom of the original source, but the receivers ignorance of what the original source is, and the rights it gives him. How to deal with that is an interesting question, but it is _not_ a freedom issue. Ignorance != lack of freedom (which demonstrates, again, how some people try to attribute an incorrect meaning to the word freedom). - restrictions == less freedom You're talking about restrictions of the new product, not of the original source (see my comments above). - so removing restriction might mean less freedom _Never_ for the original source. Btw, I really hope that you can see the contradiction in your own statement. To reitterate: MIT/BSD just make software free. GPL on the other hand is not just trying to make software free, but also to govern in what way the receiver can use it. Now this may or may not be morally right, but that's a discussion all in itself. What isn't a discussion is that it's a restriction of freedom. In some situations, a benevolent dictator may be better for the people than total freedom, perhaps even better than democracy. Regardless of the level of benevolence though, a benevolent dictator is still a dictator, no matter what way you put it. Greetings, Sander.
Re: [dwm] way towards 5.0
On Sat, May 17, 2008 at 4:05 PM, Anselm R. Garbe [EMAIL PROTECTED] wrote: 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. Top or bottom would be enough for me. If that's the way it's going to be, I'd like to see dmenu's -y -x -w stuff replaced with the good old -b as well (however, if you do that, make sure to let the wmii guys know in time; they've had a lot of bugreports about the menu not working with dmenu 3.4 since the change from -b to -y -x -w). Greetings, Sander.
Re: [dwm] sic ipv6 patch
On Mon, May 19, 2008 at 5:17 PM, Sylvain Bertrand [EMAIL PROTECTED] wrote: Freedom which does not defend itself *will* be abused again and again, Define abuse? According to MIT/BSD, using the code in closed source products is not abuse, it's simply use. Since that does not in any way affect the freedom of the original MIT/BSD licensed code, it shouldn't be a problem. Unless, of course, you want to restrict the users of your code in what they can and can't do with it. If you want that, fine, that's your choice, but please don't try to sell it as freedom, since that's simply not what it is. Greetings, Sander.
Re: [dwm] Freedom (was: Re: sic ipv6 patch)
On Mon, May 19, 2008 at 8:31 PM, Matthias Kirschner [EMAIL PROTECTED] wrote: There are people (like) you who say modified BSD/MIT licenses are more free, because users/developers have the freedom to make the software unfree. (More a freedom of the individual.) No no, it's not just people saying that, but also every dictionary in the world; some examples of dictionary definitions of freedom: - the power to determine action without restraint. - the absence of or release from ties, obligations, etc. - the power to exercise choice and make decisions without constraint from within or without; autonomy; self-determination. Since the GPL puts more restrictions on the user, it provides less freedom. Period. There's no arguing about that, at least not without maiming the definition of freedom. Now don't get me wrong: I agree that for some developers/projects the extra restrictions of the GPL are necessary, or at least desirable; what annoys me is that these extra restrictions are all too often advocated as freedom. Restrictions are NOT freedom, no matter how morally justified they are. I'm not arguing against the GPL, I'm arguing against the abuse of the word freedom for its cause. We have dictionaries for a reason, and when people start inventing their own definitions of words because it makes what they're doing sound better, we'll soon have Babel all over again. Greetings, Sander.
Re: [dwm] Documentation!
On Fri, May 16, 2008 at 9: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. I'm still running 4.7 for similar reasons.
Re: [dwm] Java patch
On Sun, Apr 27, 2008 at 2:45 PM, Anselm R. Garbe [EMAIL PROTECTED] wrote: Does this really work for everyone? I remember I evaluated a similiar solution last year without success. ;( If it does, I'm all for it, provided that it goes between some clear #ifdef UGLY_JAVA_HACK ... #endif or something similar. Greetings, Sander.
Re: [dwm] dmenu, slock patches; slock DPMS crash
On Tue, Apr 8, 2008 at 6:40 PM, Matthias-Christian Ott [EMAIL PROTECTED] wrote: It's POSIX conform [1], so I don't see the whole point of the discussion. POSIX was created to make it easier to write portable apps. When one, knowingly, writes a non-portable app, and then says hey, but it's POSIX compliant, one is missing the point. POSIX is a means to an end, not an end in itself. Basically, the point of the discussion is the same as the point of POSIX itself: portability. Greetings, Sander.
Re: [dwm] A rather radical thought
On Wed, Apr 2, 2008 at 2:59 PM, Anselm R. Garbe [EMAIL PROTECTED] wrote: What about getting rid of supporting the selection of multiple tags at a time and celebrating the revival of the column layout of wmii again in dwm 5.0? What about getting rid of all the tiled layout flavors in favor for the column layout? You're one day late! If you're serious though, what exactly do you mean? wmii-3/acme like (as in: dynamic amount of columns, and three modes per column)? Gr. Sander.
Re: [dwm] A rather radical thought
On Wed, Apr 2, 2008 at 3:34 PM, Anselm R. Garbe [EMAIL PROTECTED] wrote: On Wed, Apr 02, 2008 at 03:23:39PM +0200, Sander van Dijk wrote: If you're serious though, what exactly do you mean? wmii-3/acme like (as in: dynamic amount of columns, and three modes per column)? Exactly. Hm, would that mean you'd have to introduce titlebars for stack mode?
Re: [dwm] Different window modes on different workspaces
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.
Re: [dwm] Some things about dmenu...
On Tue, Mar 11, 2008 at 11:06 PM, Anselm R. Garbe [EMAIL PROTECTED] wrote: Ok, makes sense to me/I will change the code accordingly tomorrow. Thanks! Gr. S.
Re: [dwm] Some things about dmenu...
On Tue, Mar 11, 2008 at 11:06 PM, Anselm R. Garbe [EMAIL PROTECTED] wrote: Ok, makes sense to me/I will change the code accordingly tomorrow. Hg tip also needs an fstrncmp function pointer to point to either strncmp or strncasecmp (right now, match() is hardcoded to use strncasecmp; this should only be the case when -i is given). Greetings, Sander.
Re: [dwm] Some things about dmenu...
On Wed, Mar 12, 2008 at 7:53 PM, Sander van Dijk [EMAIL PROTECTED] wrote: On Tue, Mar 11, 2008 at 11:06 PM, Anselm R. Garbe [EMAIL PROTECTED] wrote: Ok, makes sense to me/I will change the code accordingly tomorrow. Hg tip also needs an fstrncmp function pointer to point to either strncmp or strncasecmp (right now, match() is hardcoded to use strncasecmp; this should only be the case when -i is given). Here's a patch. Aside from implementing what I described, it also removes some no-longer-needed stuff and simplifies the loop in match() (and, to top it off, makes sure that the order of items is preserved when narrowing the set, something that unfortunately wasn't the case with 3.4...). Gr. Sander. dmenu.icasefix.udiff Description: Binary data
[dwm] Some things about dmenu...
Hi, Two things about dmenu: 1. Case insensitive string matching should be optional; right now, when I have an entry 'Foo' and an entry 'foo', I can't put the cursor on 'foo' without using the arrow keys, not even when I type exactly 'foo'. Quite annoying. While I understand that case insensitive string matching is useful to some (many?) people, it's a pain in the ass for me, and quite ununixy on top of that. Hence I propose to make case insensitivity optional through an cmdline argument, like (for instance) grep does as well. 2. '-i' would be a sensible choice for point 1, but apparently we already have that. It makes dmenu match strings 'ignoring intermediate characters', so that for instance 'fifo' matches 'firefox'. If someone can explain to me why this is a good thing please do so, cause I can't think of a single thing, it looks like a misfeature to me. I'd rather see the current '-i' functionality be replaced with what I described under point 1. Greetings, Sander.
Re: [dwm] Some things about dmenu...
On Sat, Mar 8, 2008 at 2:25 PM, Antoni Grzymala [EMAIL PROTECTED] wrote: dmenu is case sensitive here and works as expected, are you running some exotic OS? No. Considering that dmenu uses strncasecmp, I'd say you'd have to be running a rather exotic OS to have it case sensitive instead :-). What version of dmenu are you using? As far as I can tell, 3.4 and hg tip both use use strncasecmp, which compares the two strings s1 and s2, ignoring the case of the characters, according to man strncasecmp(3). Greetings, Sander.
Re: [dwm] Some things about dmenu...
On Sat, Mar 8, 2008 at 6:38 PM, hiro [EMAIL PROTECTED] wrote: Well, thanks for pointing that out, then. I'm happy you don't want it. So that makes three of us that want it removed from dmenu (at least as default). Anyone out there who has a different oppinion? Greetings, Sander.
Re: [dwm] dmenu_run problem
On Feb 12, 2008 9:31 AM, Daniel Bainton [EMAIL PROTECTED] wrote: Sure, dmenu_path is run with /bin/sh, but the whole exe=`dmenu_path | dmenu $*` exec $exe isn't. If you'd look at the source code of dwm, you'd see it takes the shell from the SHELL environmental variable and runs the line with that. Au contraire, it is. Take a look at hg tip, you'll see that: 1. config.def.h executes dmenu_run (_that_ statement is indeed run through the shell from the SHELL env var). 2. dmenu_run contains a #!/bin/sh line, and the whole exe=`dmenu_path | dmenu $*` exec $exe. 3. Hence, the whole exe=`dmenu_path | dmenu $*` exec $exe is run with /bin/sh. Like I said before, the problem the set is trying to fix, was already fixed before by taking the exe=`dmenu_path | dmenu $*` exec $exe out of config.h and putting it in a separate script dmenu_run to make sure it is run with a Bourne compatible shell. Gr. Sander.
Re: [dwm] dmenu_run problem
On Feb 11, 2008 4:58 PM, Anselm R. Garbe [EMAIL PROTECTED] wrote: On Mon, Feb 11, 2008 at 12:08:20PM +0100, Szabolcs Nagy wrote: - exe=`dmenu_path | dmenu $*` exec $exe + set exe=`dmenu_path | dmenu $*` exec $exe I'm not sure about this proposal either, but I applied your change this morning. That shouldn't be necessary in the place you put it (in fact, it shouldn't have any noticeable effect at all there), since that script starts with #!/bin/sh, which should imply it will run in a Bourne compatible shell, which means the var=value command syntax should be understood. This my shell doesn't understand 'var=value command' only was a problem when that line was hardcoded in config.h, which would cause the entire command to be passed to the user's default shell, rather than to the current /bin/sh. In fact, that problem is the sole reason the dmenu_run script was created in the first place. Anyway, the 'set' won't hurt, so it's no big deal, but I'm quite sure it won't fix anything here either. Greetings, Sander.
Re: [dwm] Xinerama support
On Jan 11, 2008 5:16 PM, Stefan Maerkl [EMAIL PROTECTED] wrote: On the second head, one could display just an empty window labelled On head 1. Maybe in a special colour or so. You're joking, right?... Right?
Re: [dwm] [announce] sltar-0.2.1
On Dec 20, 2007 7:09 AM, Enno Gottox Boland [EMAIL PROTECTED] wrote: searched for a name... I thought about simple tar but star sounds really ugly... Star already exists btw, see http://cdrecord.berlios.de/old/private/star.html. Gr. Sander.
Re: [dwm] dwm wish, a tidy-up function
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 while true do dwm done I believe this wouldn't work, right? Gr. Sander.
Re: [dwm] 4.7 is delayed
On Nov 5, 2007 11:01 AM, Ritesh Kumar [EMAIL PROTECTED] wrote: I have a few comments... Do you want to keep LENGTH(), seltags and prevtags in config.def.h? My configuration doesn't need them and I doubt if somebody else's will. I think prevtags doesn't belong in config.h at all, seltags is arguably a nice thing to have though. I guess LENGTH() could be in dwm.c as well, as long as it appears before the inclusion of config.h. I think the best option is to double buffer this thing. So while the input is being read (till we encounter a \n), we keep displaying the old string. So long as there is a pause between the read()ing of any two \n's we won't have flicker or incomplete string display. Although I haven't looked at the patch yet, so I can't comment on the implementation, I definitely agree with the approach you suggest. Greetings, Sander.
Re: [dwm] 4.7 is delayed
On Nov 5, 2007 6:41 PM, Szabolcs Nagy [EMAIL PROTECTED] wrote: fwiw, i don't use prevtags at all, but those who use viewprevtags() may use it. I use viewprevtags() sometimes, but I don't think prevtags should be in config.h anyway. Prevtags contains the previously selected tags, and there aren't any at startup time. Anyway, since dwm would probably misbehave when a client is created when no tag is selected, it should at least be clear that there has to be at least one selected and one prev tag configured. It may be safer to remove both from config.h (does anybody set them to something else than their default values?). Greetings, Sander.
Re: [dwm] viewprevtag bug
On Nov 3, 2007 5:29 PM, pancake [EMAIL PROTECTED] wrote: This should work with my patch. Post your patch and I give it a try :-) Gr. Sander.
Re: [dwm] input status text bug?
On Nov 2, 2007 6:37 PM, Anselm R. Garbe [EMAIL PROTECTED] wrote: On Fri, Nov 02, 2007 at 05:21:36PM +0100, Enno Gottox Boland wrote: It doesn't work at all... Sorry, but I can't reproduce. It works correctly for me so far. It seems to me that the call to fgets() blocks, that is, when it's reading for example from a fifo, and data is coming in over that fifo, it will ignore any events until it encounters a newline (the statusbar isn't updated until it does, and it doesn't respond to keypresses and such). I'm not sure if that is what we want, but if it is, than I think it should at least be explicitly documented somewhere (probably both in the README and in the BUGS section of the manpage). Greetings, Sander.
Re: [dwm] input status text bug?
On Nov 2, 2007 10:02 PM, Anselm R. Garbe [EMAIL PROTECTED] wrote: Hmm, if that's the reason I tend to write a read()-based getline function which does not block ;) Try doing this: for i in `seq 1 10` do echo -n bla if test $i = 5 then echo fi sleep 3 done | dwm Than dwm will be unresponsive for a while, after some time it'll update the statustext as blablablablabla and continue to be unresponsive. Greetings, Sander.
Re: [dwm] [patch] old-new mouseresize behavior
On Nov 1, 2007 11:44 AM, Enno Gottox Boland [EMAIL PROTECTED] wrote: Hi! I wrote a little patch which brings the old resizing behavior. It reduces code complexibility and doesn't cost a single line of code. Hi Gottox, Is this pixel-perfect? If I recall correctly, we removed this way of resizing because the code got too complex when doing it exactly right. The + 1 at the nd of the n? = abs(... is there to make sure that the mouse pointer is just on the lower right corner of the window, instead of one pixel right and below of it. That way, it is possible to drag the bottom right corner of a window exaclty to the bottom right of the screen, instead of being one pixel of. I believe the issue back then was that the +1 had to be there for resizes in the positive directions, but messed things up in the negative direction (meaning, you couldn't resize a window to the top left of the screen)... Greetings, Sander.
Re: [dwm] [patch] old-new mouseresize behavior
On Nov 1, 2007 12:58 PM, Enno Gottox Boland [EMAIL PROTECTED] wrote: this is why I use abs()+1. The only possibility where this can be = 0 is an integer overflow. Yes, of course, sorry for the noise. Gr. Sander.
Re: [dwm] RESIZEHINTS gone in 4.6, how to get the old behaviour?
On Oct 31, 2007 10:00 AM, Pieter Verberne [EMAIL PROTECTED] wrote: On Tue, Oct 30, 2007 at 04:59:53PM +0100, Sander van Dijk wrote: However, ignoring sizehints will only make your term *occupy* more space, it won't actually make it *use* more space, so you could just as wel xsetroot -solid black to get the same visual effect *and* have sizehints-needing apps work correctly. How can I initialize xsetroot so that it will run every time I start X? Approximately the same way as you make dwm run every time you start X. Greetings, Sander.
Re: [dwm] RESIZEHINTS gone in 4.6, how to get the old behaviour?
On Oct 31, 2007 3:55 PM, Antoni Grzymala [EMAIL PROTECTED] wrote: pancake dixit (2007-10-31, 15:43): btw I understand that this is a personal opinion that can't beat against all your opinions, so don't bother. I can continuely patching this issue release after release. :) Yes, it's a question of likeing on which side of the line space is being wasted. And of how much space is being wasted. When space is being wasted inside of the window, it's gone, but when it's being wasted outside of the window, at least other windows can make use of it. As I've said before: with sizehint handling, *less* space is wasted than without it. Gr. Sander.
Re: [dwm] RESIZEHINTS gone in 4.6, how to get the old behaviour?
On Oct 31, 2007 3:43 PM, pancake [EMAIL PROTECTED] wrote: About the xsetroot 'fix' it's ugly as shit, the select border marks the window borders remarking the 10-20px hole. btw i usually have a black root on my Xwindows. It wasn't intended to be a fix, since there's no problem. The only thing it was intended to do was making things visually more appealing, which it does for the topic starter, since his bordercolor is the same as his xterm background color, as can be seen on the screenshot he provided. Gr. Sander.
Re: [dwm] RESIZEHINTS gone in 4.6, how to get the old behaviour?
On Oct 30, 2007 4:53 PM, Vasil Dimov [EMAIL PROTECTED] wrote: How do I get the 4.5 RESIZEHINTS False behaviour in 4.6? This has been discussed before, look in the archives for possible answers to your question. However, ignoring sizehints will only make your term *occupy* more space, it won't actually make it *use* more space, so you could just as wel xsetroot -solid black to get the same visual effect *and* have sizehints-needing apps work correctly. Greetings, Sander.
Re: [dwm] RESIZEHINTS gone in 4.6, how to get the old behaviour?
On Oct 30, 2007 4:59 PM, Sander van Dijk [EMAIL PROTECTED] wrote: On Oct 30, 2007 4:53 PM, Vasil Dimov [EMAIL PROTECTED] wrote: How do I get the 4.5 RESIZEHINTS False behaviour in 4.6? This has been discussed before, look in the archives for possible answers to your question. However, ignoring sizehints will only make The thread you want is dwm 4.6 / dmenu 3.4, it's got a patch and some other suggestions as well. Gr. Sander.
Re: [dwm] dwm-4.6 / dmenu-3.4
On 10/27/07, Antoni Grzymala [EMAIL PROTECTED] wrote: Thanks arg (and all contributors), unfortunately the new dwm segfaults on my computer. Since I don't know much about debugging C programs I cannot provide a backtrace or what not (unless instructed). $ ulimit -c unlimited $ dwm crash, creates dwm.core $ gdb dwm dwm.core (gdb) bt full That should do it as far as I know. If you don't start dwm from a shell, you should put the ulimit -c unlimited somewhere in your profile (it makes sure that core files are created when a program crashes). Greetings, Sander.
Re: [dwm] dwm-4.6 / dmenu-3.4
Btw. Anselm, I just noticed that the debug options aren't disabled in config.mk in 4.6. If Antoni's problem is going to cause a 4.6.1, I'd like to see that fixed as well. Gr. Sander.
Re: [dwm] dwm-4.6 / dmenu-3.4
On 10/27/07, Arun G Nair [EMAIL PROTECTED] wrote: Hi, I just upgrade to 4.6 and I see the resizehints problem again. The wallpaper shows up at the right side of the screen. A maximized $TERM doesn't fill the screen. Is there a way around it ? Yes, hacking tile(). But I think it's better to face the fact that some apps need this. As has been mentioned before by others, clients that request inc-handling are going to waste space one way or the other (in or outside their window), and this way they at least behave correctly (also, thanks to Arg's tile() algoritm, I wouldn't be surprised if there's actually *less* space wasted now than before). Greetings, Sander.
Re: [dwm] dwm-4.6 / dmenu-3.4
On 10/27/07, Arun G Nair [EMAIL PROTECTED] wrote: Yes, hacking tile(). But I think it's better to face the fact that some apps need this. Do you know which ones need this ? I just have Firefox, pidgin (which still steals focus) and xpdf. All of these maximize filling the screen. Its just xterm. If anyone has a patch, please send it. Most terminals do, gvim does, mplayer uses it to make sure that it's aspect ratio stays correct. There are many more, but these are common ones that are known to misbehave often when sizehints aren't handled (xterm will often have its bottom line, i.e. the one you're typing on, only partly visible because of this). And like I said already, not respecting sizehints doesn't cause them to actually *use* more space. The space that's wasted now is also wasted when not respecting sizehints, only the appearance is different (and sometimes the behavior as well, in a negative way). Anyway, if you insist on disrespecting sizehints, suit yourself. I believe the attached patch should do what you want, but I wrote it without testing so your mileage may vary. Greetings, Sander. nosizehints.patch Description: Binary data
Re: [dwm] dwm-4.6 / dmenu-3.4
On 10/27/07, Antoni Grzymala [EMAIL PROTECTED] wrote: Thanks arg (and all contributors), unfortunately the new dwm segfaults on my computer. Since I don't know much about debugging C programs I cannot provide a backtrace or what not (unless instructed). I noticed the segfault also on the hg version on which you introduced the viewprevtag function, but had too much work to sit down and report it back then, sorry about that. Just to verify the obvious: does this happen with config.def.h or only with a custum config.h? Gr. Sander.
Re: [dwm] [PATCH] replacing #define ISTILE by Bool istile
On 10/27/07, Enno Gottox Boland [EMAIL PROTECTED] wrote: Hi! I created a different behavior of the istile-check. I think a layout should decide itself if it is a tiling or a non-tiling layout. I removed the ISTILE declaration and replaced it by a variable which is set by the layout functions. What do you think about this? How about putting it in struct Layout instead? Gr. Sander.
Re: [dwm] [PATCH] replacing #define ISTILE by Bool istile
On 10/27/07, Enno Gottox Boland [EMAIL PROTECTED] wrote: This is also possible. But my intention was that the user does not decide wheather a function is tile or non-tile. It is the choice of the programmer. Right, didn't look at it that way. Now that we're talking about ISTILE, I think there's some room for improvement in the way it functions/is used as well: right now, if ISTILE evaluates to true, this means that: 1. mwfact applies to that layout. 2. zoom applies to that layout. 3. you can push forced-floating clients back into that layout with Button2. I can imagine there are layouts where you want some, but not all of this, which is not possible with ISTILE alone. Not sure what the right way to change that would be (nor if there is one), but I think it's worth a thought. Gr. Sander.
Re: [dwm] dwm-4.6 / dmenu-3.4
On 10/27/07, Jeremy O'Brien [EMAIL PROTECTED] wrote: I had this same problem when I tried to modify my custom config to suit dwm 4.6. After about 30 minutes of tinkering with my config.h, I _finally_ found the difference there. What was changed that made it so that the array doesn't require NULL termination? Just curious. In case the 30 minutes aren't an exaggeration, doing a diff -u config.def.h config.h | less might save you some time in the future. Gr. Sander.
Re: [dwm] Taglayouts poll
On 10/26/07, Jeremy O'Brien [EMAIL PROTECTED] wrote: I was just wondering how many people here use Jan's taglayouts patch. Personally, I won't upgrade to a new version of dwm unless that patch has been updated as well (or if I can update it myself). I find it indispensable. I guess what I'm getting at is if you guys think it should be included in the main dwm tree? (More of a question to Arg I think ;) ) No, it shouldn't, for the simple reason that it doesn't fit within the tagging paradigm. Dwm's paradigm is quite simple: - There's one workspace, in which only one layout can be active at a given moment. - Tags are used to select which windows are visible and which are not in the workspace. Each window can have any combination of tags applied to it, and any combination of tags can be selected for viewing at a given moment. Hence, to do this taglayouts stuff right, you'd need to remember the layout for every possible combination of all the tags that are available, and possibly also the position of each window in eacht tag it has, which you really don't want to. If the taglayouts patch is useful for you, use it, but no matter how useful it is, it is a hack, and a such doesn't belong in mainstream dwm. Greetings, Sander.
Re: [dwm] RESIZEHINTS broken?
On 10/23/07, pancake [EMAIL PROTECTED] wrote: When did you find this feature useful? Don't know about Arg, but I think it has been useful ever since there were apps (xterm for instance) that misbehave without it, i.e. always. Having it optional (in tiled mode) would be ok, dropping it would be a step in the wrong direction. Gr. Sander
Re: [dwm] idxoftag
On 10/22/07, Stefano Soffia [EMAIL PROTECTED] wrote:
The `spawn' case can be handled defining a
const char *spawned_command[] = {
...,
exec uxterm,
...
};
It used to be like that, and it was changed for a reason; it's ugly at
best. If we really need different types of arguments (i.e. we can't
represent them as strings), than I'd rather see the Arg union return
than this...
Greetings, Sander.
Re: [dwm] RESIZEHINTS broken?
On 10/20/07, Robert Figura [EMAIL PROTECTED] wrote: Hi People I may be wrong but to my eye it seems that the RESIZEHINTS doesn't work properly. Here's what i've done: Open a window that hints to require 300px height. Open some more windows to make height for stacked windows 300. Now put that hinted window on the bottom of the stack. It looks like the lower border is missing. Opening enough hinted windows i even made some of them vanish completely off border. No, the lower border isn't missing, it's just not on screen. You have RESIZEHINTS set to true, the window requires 300 px height, and that's not available there (at least not on screen). Gr. Sander.
Re: [dwm] final test call
On 10/19/07, Tony Lainson [EMAIL PROTECTED] wrote: sed -i '24,25s/./@/' dwm/Makefile Not exactly a major issue, but it's nice to look professional :-D. Indeed.
Re: [dwm] feature request: moving/resizing without mouse
On 8/30/07, anhnmncb [EMAIL PROTECTED] wrote: Thanks for all replies. I think dwm should be keyboard-driven, so the functions mouse moving/resizing should be changed to keyboard moving/resizing :) Pardon my English, but that is absolute nonsense. The floating layer is mainly intended for applications that don't fit the tiling paradigm, and 9 out of 10 of such applications are mouse driven anyway. With that in mind _replacing_ mouse based moving/resizing with keyboard shortcuts doesn't make any sense. _Adding_ some functions to allow changing the size and position of windows with keyboard shortcuts would be ok I guess, but I think it's probably better to do that in a separate patch (I believe it would be possible to simply put all the needed stuff in say kbmovres.[ch] and then include kbmovres.h in config.h. Neat and clean). Greetings, Sander. PS. This is not intended as a flame, and not intended as a personal attack either. It's just that I get a little tired of this anti-mouse attitude that shows up every once in a while. This is 2007, the mouse (pointing devices in general) is part of your computer. PPS. The main reason you dislike the mouse is probably because you've never seen a system that puts it to good use. If you're interested, try the Acme editor (of the Plan 9 operating system, also part of plan9port) for a while. Chances are you'll have to revise your oppinion about the mouse.
Re: [dwm] new floating windows
On 8/25/07, y i y u s [EMAIL PROTECTED] wrote: There are other two posible solutions: you can allow togglefloat when in floating mode (just removing one check) That's what I suggested. , or the new windows can be floating by default. Dwm is a tiling window manager. If you want floating by default, than make dwm startup in floating mode by default. If you think that having to toggle each individual window to tiling mode after starting it, using a more conventional wm is probably a better idea. I don't see the inconsistence you tell, it does work like tags: If you have rules, they are applied, else the current tag are applied (in the same way that floating is applied if you set it in rules or else the current mode is applied). Yes and no. The global modes don't work like tags, the individual override does (sort of). Global modes are supposed to affect all clients that don't have this override set, which is basically all non-sucky apps (ok ok, there are also non-sucky apps that are better used floating...). With what you suggested, you could start an app in floating mode, and then when switching to tiled mode, it would still be floating. Comparing this with tags, this would mean that if my app has tag 1, and I apply tag 2, it would still have tag 1 and not tag 2. Looks not like what I want. Anyway, for me it is ok if togglefloating is allowed in floating mode, and it could be more consistent as you tell. I just want a solution. Well, then I guess we can end this discussion, because we basically agree :-) Greetings, Sander.
Re: [dwm] persistent tags and static Layout definition
On 8/22/07, Diego Biurrun [EMAIL PROTECTED] wrote: On Tue, Aug 14, 2007 at 07:36:44PM +0200, Anselm R. Garbe wrote: Yes I will rename that property to _DWM_CONFIG That's no better. I checked back for the details, two underscores or underscore + capital are reserved for any use, underscore is reserved in file scope (so it can be used for local variables). Again, _DWM_CONFIG is not an identifier, it's a window property. The rules you talk about don't apply here. Grep the dwm source for _DWM_CONFIG to see what I mean. Gr. Sander.
Re: [dwm] persistent tags and static Layout definition
On 8/22/07, Diego Biurrun [EMAIL PROTECTED] wrote: cerebus:~/src/dwm/dwm$ grep -ri DWM_CONFIG * cerebus:~/src/dwm/dwm$ .. seems to be gone .. It's called _DWM_PROPERTIES now. Gr. Sander.
Re: [dwm] Thinking about tags
I don't think that using tagnames as argument to view(), toggleview(), tag() and toggletag() would bring much benefit over using tagindices, but using regex's could possibly bring some useful extra abilities: tag(^(www|net)$); view(^(net|dev)$); I'm not sure yet if this would be really useful in the real world, but I think it deserves consideration. Opinions please! Greetings, Sander.
Re: [dwm] Thinking about tags
On 8/16/07, Anselm R. Garbe [EMAIL PROTECTED] wrote: On Thu, Aug 16, 2007 at 09:32:25AM +0200, Sander van Dijk wrote: I don't think that using tagnames as argument to view(), toggleview(), tag() and toggletag() would bring much benefit over using tagindices, but using regex's could possibly bring some useful extra abilities: tag(^(www|net)$); view(^(net|dev)$); I'm not sure yet if this would be really useful in the real world, but I think it deserves consideration. Opinions please! There is no runtime-interface to those args, so I consider this idea not being worth implemented. Esp. because you can achieve the same through making shortcut chains... Ah, true, forgot about those. Gr. Sander.
Re: [dwm] Thinking about tags
On 8/15/07, Brandon Barker [EMAIL PROTECTED] wrote: Regular expressions seem useful to me, for instance, if I want to match an Opera window where Gmail is open but not something else. I agree. Sander.
Re: [dwm] layout state per workspace?
On 8/9/07, Maarten Maathuis [EMAIL PROTECTED] wrote: The only issue (imo) lies with tags that have floating layout, perhaps it's possible to mark windows that are in a floating layout floating. So that they retain their floatiness when coming into a non-floating environment. This would have to be different from windows which are floating by default. Maarten. Just to be sure: you do know that you can toggle the floating state for individual windows, right? (with Mod1-Shift-space in the default setup). Gr. Sander.
Re: [dwm] layout state per workspace?
On 8/9/07, Sylvain Bertrand [EMAIL PROTECTED] wrote: What do you think about this? Tags != workspaces. You can use them as such, but they aren't the same. In dwm, there's only _one_ workspace. (de-)selecting certain tags influences what windows are (not) displayed in that workspace. Since you can select multiple tags for viewing at the same time, having a layout per workspace would imply you'd have to keep a layout for every possible combination of tags a user can select. Have fun doing that when there are 9 tags (like in the default setup)... Of course, you're free to use whatever hack people come up with if it suits you, but I doubt it'll never go into mainstream dwm, simply because it collides with the tagging approach. Greetings, Sander.
Re: [dwm] layout state per workspace?
On 8/9/07, Diego Biurrun [EMAIL PROTECTED] wrote: So how about having a floating tag then? Or more generally spoken, tags with different layouts. Can you elaborate a bit? I'm not sure I understand what you mean. Sander.
Re: [dwm] layout state per workspace?
On 8/9/07, Diego Biurrun [EMAIL PROTECTED] wrote: If I mark a client as tag X it gets float layout, if I mark it as a different tag, it gets tiled again with the rest of the clients of that tag. Yes, but what if you tag it as _both_? Gr. Sander.
Re: [dwm] layout state per workspace?
On 8/9/07, Anydot [EMAIL PROTECTED] wrote: Imho it doesn't collide with tagging approach, it only change their (tags) behaviour. Even with that patch you can choose to view multiple tags at once etc. It only transfer where the state of selected layout is saved from workspace to tag. But what happens when I select one tag with tiling layout, one tag wit floating layout, and one tag with a custom layout (i.e. maximized)? Gr. Sander.
Re: [dwm] first inofficial (#) dwm FAQ - to be reviewed/over-coworked
On 6/28/07, Anselm R. Garbe [EMAIL PROTECTED] wrote: Well, I ignore this thread. hehe, nice contradiction :-P
Re: [dwm] [PATCH] Separate border colors for floating windows
On 6/26/07, Stanislav Maslovski [EMAIL PROTECTED] wrote: On Tue, Jun 26, 2007 at 11:37:46AM +0200, Sander van Dijk wrote: On 6/26/07, Stanislav Maslovski [EMAIL PROTECTED] wrote: Hello, I propose this small change. It allows to use separate border colors for floating windows. If needed I will send a screenshot that shows the use of it: May I ask what you want this for? Floating windows are already distinguished by the little square in their title, and their non-restricted size and position usually gives them away too. I set NORMBORDERCOLOR to the background color of my GTK2 theme so that the tiled windows visually appear glued together (there is no visible border). At the same time I want the floating windows that have a border. It seems to me that what you really want is borderless tiled apps. The way you achieve (well, fake, actually) this now (background-colored borders) looks like a hack to me; it's also incomplete: what about non-gtk apps for example?. Stuff like this is fine for personal use, but I don't think it belongs in mainstream dwm. Greetings, Sander.
Re: [dwm] about dwm's quit and Xorg's quit
On 6/17/07, Philipp Köhler [EMAIL PROTECTED] wrote: If i use dwms MOD+shift+Q i dont really exit dwm... just a blank screen. but i dont return to gdm. Yes, you do really exit dwm. That doesn't necessarily mean that your X session is over though (if it was, you would go back to gdm). Apparently something (not dwm) is keeping your session from finishing, you just need to figure out what. Greetings, Sander.
Re: [dwm] fixed windows must be always floating - error+patch
Hi,
I was testing the new behavior (resize fixed size windows on
togglefloat) a bit, and I noticed that not all windows behave correct
yet. Fixed size ones do, but inc-handling and aspect ratio needing
windows don't. See the attached patch for a fix (it simply calls
resize() on any newly floating window, which will handle any sizehints
(including fixed size) that the client has set (and dwm supports)).
Greetings, Sander.
On 5/25/07, Sander van Dijk [EMAIL PROTECTED] wrote:
On 5/25/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
On (23/05/07 07:48), Anselm R. Garbe wrote:
Ah yes, I remember this decision now, I revert the change.
Regards,
Ok,
then please include this patch:
=
diff -r 42bf8e618d52 client.c
--- a/client.c Tue May 22 11:29:59 2007 +0200
+++ b/client.c Wed May 23 13:22:20 2007 +0200
@@ -305,6 +305,8 @@ togglefloating(const char *arg) {
if(!sel || lt-arrange == floating)
return;
sel-isfloating = !sel-isfloating;
+ if (sel-isfloating sel-isfixed)
+ resize(sel, sel-x, sel-y, sel-minw, sel-minh, True);
lt-arrange();
}
=
So, if fixed client is forced to be non-floating, then if it is switched
back to floating, its fixed dimensions are forced.
He, if someone would have asked me, I would have said dwm already did
this :-). Apparently it doesn't, but you're right that it should.
Greetings, Sander.
togglefloat_sizehints.udiff
Description: Binary data
Re: [dwm] problem with dmenu3.1
On 5/23/07, Diego Biurrun [EMAIL PROTECTED] wrote: The emacs comparison is nonsensical. test is a builtin in most shells (offhand bash, ash, dash, ksh, pdksh, zsh, sash on this Debian system where I have a login shell), so of course [ should be a builtin, too. They're the same thing after all. Yes, if one is builtin, the other should be as well. I'm just saying that it's unclear to me why they should be builtin at all? Efficiency, seems to be the standard answer, but then one could argue to builtin cat, sed, cut, tr, etc. etc., maybe /bin entirely, as well. Efficiency alone does not explain why these, but not others, are builtin. By the way, not very surprisingly, the original UNIX manual pages (see http://plan9.bell-labs.com/7thEdMan/v7vol1.pdf) do not mention test as being part of sh(1) at all, in fact, the only explicit reference to test in the sh(1) manpage is in the see also section. Even if most (if not all) Bourne Shell compatibles of today builtin this stuff, I still consider it bad practice. And the emacs comparison isn't nonsensical, it's just an exaggeration; one could argue to builtin emacs with the exact same arguments as mainly used for test and [. Greetings, Sander.
Re: [dwm] problem with dmenu3.1
On 5/23/07, Jukka Salmi [EMAIL PROTECTED] wrote: Sander van Dijk -- dwm (2007-05-23 16:18:34 +0200): I don't know, I do know it's a symlink to test in many linux distros. I personally hate it though, since it obscures the fact that you are calling a program (test is much clearer in this sense thatn [). That's a matter of taste, of course. I prefer the latter because then the expression is delimited by `[' and `]', making it easier to parse IMHO. It's a matter of taste indeed; some people have taste, some don't :-P (kidding, kidding...) Btw, in bash they are _both_ builtins (don't ask me why, Probably to give all shell scripts the same performace gain, whether they use `test' or `['. True, but see my other post for why I don't think that's reason enough by itself. Greetings, Sander.
Re: [dwm] fixed windows must be always floating - error+patch
On 5/23/07, Premysl anydot Hruby [EMAIL PROTECTED] wrote: as $subj says, there is error as on fixed window the isfloating can be turned off. with this patch, isfloating for fixed window can't be turned off That's not an error, it's a feature (no, really). The idea is that managing fixed size windows is usually not very useful, so dwm makes them floating by default. If the user decides that he really wants to make it non floating afterwards, that is his choice, and it should be possible. Greetings, Sander.
Re: [dwm] Makefile (config.mk) modification
On 5/16/07, mikshaw [EMAIL PROTECTED] wrote: I'm not writing to argue with your position, but merely for (off-topic) clarification of a single point. You're message implies that you have little control over what is happening to your environment, as if applications were constantly changing the environment of your shell in such a way that you never know its status and can't easily avoid the changes. As I see it, this would be a problem only if you tend to do all of your work in a single shell. That would be quite a limiting experience, in my opinion You are right, of course; The point I was trying to make is that the suggested change introduces _possible_ obscurities, while it doesn't seem (to me) to introduce a real advantage. The problem I described is not one I'm actually having though. Greetings, Sander.
Re: [dwm] Makefile (config.mk) modification
On 5/15/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi, created patch for easily modification of CFLAGS/LDFLAGS via env. variables. So, it is good ie. for debuging etc. URL: http://na.srck.net/dwm/dwm-r887-makefile.patch (aplicate to r887 of original repo). Stat: config.mk | 16 ++-- 1 file changed, 10 insertions(+), 6 deletions(-) But, commented out CFLAGS/LDFLAGS can be deleted imho, because of this patch. I don't think this is a very good idea, since it obscures the building process (who knows what the Makefile inherits from the environment? I certainly don't want to have to check my environment every time I build dwm). Why not simply use make CFLAGS=blahblah when you want to do something other then what's written in config.mk? Greetings, Sander.
Re: [dwm] More suckless software
On 4/7/07, Tuncer Ayaz [EMAIL PROTECTED] wrote: I'm not sure whether one can make a selection and add some parameter to it by typing in dmenu after selecting the entry and having the selection with the parameter written to stdout. Yes, that is possible. I frequently do things like firtab suckless.org (which becomes firefox suckless.org on my box) to start firefox with exactly that parameter. It's all about the shell script in which you use dmenu... Greetings, Sander.
Re: [dwm] Reloading running dwm - reload patch
Hi, On 3/21/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I created patch for reloading dwm with signal USR1. Not to put your patch down, but with vanilla dwm you can achieve something pretty similar by doing this in your .xinitrc: while true do dwm done Greetings, Sander.
Re: [dwm] Tabs in dwm
On 2/26/07, y i y u s [EMAIL PROTECTED] wrote: I have modified the restack() function to raise the sel client (it won't happen when the focus changes moving the mouse, it would be annoying). This adds some advantages and removes 3 or 4 loc. This could be useful for people who wants a tabs functionality in dwm. I will explain it with an example: 1. you have three terms open. 2. make the zoomed term float. 3. open a new term. Now you can change focus between the two apps sharing the zoomed space. I did this change to main dwm because it was annoying for me not being able to use my tiled windows when I had a maximized float one in front of them, but I'm finding this new feature really useful. I thought somebody could find it interesting, and it could even go in main dwm if arg agrees (though I don't think it so, and I will respect his opinion). For what it's worth: I believe that floating clients should _never_ be obscured by tiled clients. Greetings, Sander.
Re: [dwm] speaking of terminology...
On 2/22/07, Anselm R. Garbe [EMAIL PROTECTED] wrote: I like untiled. The reason why I changed floating is that it clashes with the datatype, however tile() and untile() seem straight-forward. I go for it. So what's the going to be replaced with now :-) ? Gr. Sander.
Re: [dwm] speaking of terminology...
On 2/22/07, Anselm R. Garbe [EMAIL PROTECTED] wrote: So what's the going to be replaced with now :-) ? It will stay, I like it and somehow it belongs to the soul of dwm ;) And I suggest to stick with floating as well. I really don't think people are going to confuse that with the C float type. Besides, they essentialy mean the same: floating point means that the decimal separator can be anywhere in the number, floating client means that the client can be anywhere on screen... Greetings, Sander.
Re: [dwm] uriel sez the default config is retarded
On 2/9/07, Marek Bernat [EMAIL PROTECTED] wrote: On 2/9/07, Antoni Grzymala [EMAIL PROTECTED] wrote: I most definitely think that LAlt as default modkey is useless (except for old thinkpad users) and I suggest using the winkey as default. It is not totally useless, but certain aps require it a lot for normal work (blender, emacs). Therefore I prefer winkey as well. I'm not so sure about that, as the winkey is still not available on all keyboards (for instance the happy hacking keyboards), and that would be bad for a _default_ config. Greetings, Sander.
Re: [dwm] Re: [PATCH] dofloat removed - saves ~400loc
On 2/5/07, Anselm R. Garbe [EMAIL PROTECTED] wrote: So all in all, it is cleaner to me, to implement different algorithms of window arrangement in different functions, than modifying the behavior of the arrangement algorithm through window-based flags... I agree on that. Having different functions for different types of layout keep things simple, and also keeps it quite trivial to add a new layout. c-isfloat was introduced as an option/hack to enforce floating for apps that just won't behave in any other layout. Using it to get rid of dofloat() is conceptually wrong, and 35 sloc just isn't worth that I think. Greetings, Sander.
Re: [dwm] new windows on slave area
On 1/19/07, pancake [EMAIL PROTECTED] wrote:
I've defined two symbols for the tile and append modes:
#define TILESYMBOL [=
#define APPENDSYMBOL[=
So it looks cleaner for me, instead of const char *..[]={[=,...}
The rest of the code is similar. ARG, what do you think about this?
Could this feature be included into the main stream?
I don't think this is needed, especially the extra symbol.
Greetings, Sander.
Re: [dwm] dwm-3.1 / dmenu-2.0
On 1/16/07, Giorgio Lando [EMAIL PROTECTED] wrote: with a border the focussed window. May be that the border could be activated only when there is more than one client in the view, since when there is only one it seems redundant, but I do not know how heavy would be the impact of this on the code. The impact on the code would be very minimal, but I don't think that should be done, for simplicity's sake. Gr. Sander.
Re: [dwm] Again client titles and nmaster indicator
On 1/14/07, Anselm R. Garbe [EMAIL PROTECTED] wrote:
On Sun, Jan 14, 2007 at 08:39:33AM +0100, Sander van Dijk wrote:
MODE{BG,FG}COLOR (for the modelabel)
TITLE{BG,FG}COLOR (for the selected client's title label)
I'm not sure about this. I agree that STATUS{BG,FG}COLOR is
misleading. We'd have then:
BORDER{BG,FG}COLOR
SELTAG{BG,FG}COLOR
NORMTAG{BG,FG}COLOR
MODE{BG,FG}COLOR
TITLE{BG,FG}COLOR
STATUS{BG,FG}COLOR
DMENU{BG,FG}COLOR
That are 14 colors! Too much in my eyes for a small status bar.
Instead of your proposal I propose the following, which is a
simplification of current colorscheme:
[UN]FOCUSCOLOR - used for focused/unfocused borders
NORM{BG,FG}COLOR - used for bar bg, unselected tags, mode,
status [and dmenu normal stuff]
SEL{BG,FG}COLOR - used for selected tags, title [and dmenu normal stuff]
That are 6 colors!
How about this to keep things even simpler:
Define these (6) colors:
NORM{FG,BG,BORDER}COLOR
SEL{FG,BG,BORDER}COLOR
And then use NORM{BG,FG}COLOR for the entire bar (unselected tags,
mode, title and status), separating different stuff (the tags, the
mode, the title and the status) with a one-pixel-wide vertical line
(with color NORMFGCOLOR).
SEL{BG,FG}COLOR would then only be used for selected tags.
{NORM,SEL}BORDERCOLOR speak for themselves I guess...
Greetings, Sander.
Re: [dwm] Java Saga Continues...
On 12/21/06, Anselm R. Garbe [EMAIL PROTECTED] wrote: I fear there is no simple solution unless Sun don't fixes the JDK properly. Introducing frames for each client would mean much more resource consumption of X, and the dwm codebase would get more complex - one would need to change nearly all resize-related stuff, manage() and unmanage(), besides extending Client struct with Client-fwin. Just a (probably silly) idea: would reparenting to the parent help? I haven't read Sun's sources myself, but from what I understand these java progs discard all configurenotify's and resizes if they are not reparented (or rather, _until_ they are reparented). If one would reparenting such a window to what already is its parent, this java stuff might still react to the ReparentNotify this generates. For the rest nothing would change, so dwm's codebase wouldn't need to change any further. If this works, a nice /* stupid hack to work around java issue */ above the code would suffice I think. Note that I don't really have a clue about this stuff, so this might all be nonsense; decided to share it anyway in case it isn't garbage though :-) Greetings, Sander.
Re: [dwm] dwm/dmenu how to use?
On 12/21/06, Antoni Grzymala [EMAIL PROTECTED] wrote: Tako rzecze Sander van Dijk (w e-mailu datowanym 2006-12-21, 12:16): On 12/21/06, pancake [EMAIL PROTECTED] wrote: `ls /usr/bin | dmenu` `ls --color=never /usr/bin/ | dmenu` ...on GNU systems to avoid ansi weirdness. It's _realy_ sad that that option is necessary... It's not. [a] In that case, let me rephrase: It would be _realy_ sad if that option was necessary... Next time I'll validate such statements before replying to them; sorry for the noise. Grts, Sander.
Re: [dwm] multiple functions per key revised
On 12/15/06, Enno Gottox Boland [EMAIL PROTECTED] wrote: Hi! WTF? Adding return for saving a few milliseconds and adding an extra layout to make dwm more bloat... I dont think this is a good idea. Imho we should stay where we are. This solution is very clean, doesn't waste loc and has a very small overhead. Indeed. It is true that this doubles the average time needed to handle a keypress (before the return was removed the average time to handle a keypress was the time needed the handle the key in the middle of the list, while now all keys take the time of the last one in the list; then again, this does make all keyhandling times equal, which probably increases predictability for people who can sense the difference between 2 and 5 milliseconds :-P), but that's much less of a problem to me than messing up config.h. This is simply not something that belongs in config.h. Greetings, Sander.
Re: [dwm] d{wm,menu} and utf8
On 12/15/06, Christian Garbs [EMAIL PROTECTED] wrote: Sander, does the attached patch fix your problems with the character display under dmenu? It changes the same thing that helped me to display Japanese characters in the dwm status bar. No, I already tried that, but it didn't change anything. Using my default locale settings[1] I need the attached patch to make dmenu print these three selections properly: [EMAIL PROTECTED]:/tmp$ cat foo こんばんわäöü FOO こんいちわäöü FOO おはようäöü FOO But if I am using slightly a different locale[2] (I need it for Japanese character input, but I use it only temporarily) then I don't need the patch and dmenu displays these selections correctly when using the Xmb*() functions. Hm, these all display just fine for me with LC_CTYPE=en_US.UTF-8 and font '*-terminus-*-*-*-*-*-*-*-*-*-*-*', both with and without your patch. Funny enough though, when I tried this with the wrong font (the one urxvt said it took the Œ character from), the ü was replaced by exactly that character :-S. Turns out terminus has that character as well, and I can easily make dmenu display it with a simple echo -e '\214' | dmenu -font '*-terminus-*-*-*-*-*-*-*-*-*-*-*' So I guess all this is due to urxvt using different fonts for different characters and me not really having a clue how that affects things. So it seems that there's no problem in dmenu here, although I'm not completely sure yet exactly what's going on. When (if?) I find out I'll let you know... Greetings, Sander.
[dwm] d{wm,menu} and utf8
Hi,
I'm still experiencing some oddities with multibyte characters in
d{wm,menu}. If, in urxvt, I press and hold Ctrl+Shift, type 1,5,2, and
release Ctrl+Shift, it displays a single character (something like DE,
but with the D mirrorred vertically and attached to the E, I've got no
idea what that character is called).
However, when I echo that character into dmenu, it displays one item
consisting of _two_ characters (with my default font: (+). Even when
I start dmenu explicitly with the font urxvt says it takes the
character from, it still displays one item of two characters (this
time an A with a on top, followed by a square).
The funny thing is, in both of these cases, when I select that item,
it gets printed to stdout correctly as the DE character.
Since urxvt uses different fonts for different characters when
required, it'll always be possible that it displays some stuff that
dmenu doesn't. However, I do believe that a sequence of bytes that
represents _one_ character in urxvt should represent _one_ character
in d{wm,menu} too, right? (even if the used font doesn't contain that
specific character, it should display just one square).
Are other people experiencing the same thing?
Greetings, Sander.
Re: [dwm] dwm and Sun's XToolkit
Well then I guess the fix at the dwm side is simple: add a note to the CAVEATS section of dwm.1 explaining the situation and advising to use the 1.4 series until Sun fixes this (instead of adding workarounds for workarounds for ...). Greetings, Sander. PS. I know your emotions and share them, but please word things in an acceptable way in the manpage ;-)
Re: [dwm] dmenu navigation with a lot of items.
On 12/12/06, Christian Garbs [EMAIL PROTECTED] wrote: Hmm. I don't really understand how the 'pita' is changed with paged scrolling: Either I know where in the list of 1000 items I want to look (if I know that, I can type at least the first character) or I don't - in which case I have to scroll through all 1000 items. Although the scrolling might be faster with the patch, I still think it is as much pita as before because I have to look at the same amount of items as before. Depends on what you use dmenu for. If you use it solely for selecting items from an alphabetically sorted list, home/end and pageup/down may not add much (although they will still speed up browsing quite a bit), but dmenu's use is not limited to that. Let's say I want to feed dmenu a list of recently changed files, and edit the selected one. In this case, time of last change may very well be a better sorting criteria than the alphabet. In this case, the filter isn't going to be of much use, and if I want to scroll to halfway the list I'd rather do that with pagedown than with right. The main point I'm trying to make is that the filter is (very) useful, but only under certain conditions, and I'd like to see a more generic solution for quick browsing through a list. Greetings, Sander.
Re: [dwm] dwm and Sun's XToolkit
On 12/12/06, Anselm R. Garbe [EMAIL PROTECTED] wrote: Hi there, I investigated further into the grey window oddity and found this thread: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6429775 (Actually the compiz WM has/had the same problem as dwm). Well, I guess that's good news ( :-S ) then, might throw in some more weight than just dwm not working. Then again, considering that it's open for more than half a year... Hehe, I really like these parts btw: Possible solution would be detect if we are under Compiz and do not filter events well, to detect Compiz correctly we also need to check an owner of WM_S0 selection (Aaccordnig to ICCCM), since our regular check fails some time. I guess we can only pray that that's not going to be the official hack^H^H^H^Hsolution. Greetings, Sander.
Re: [dwm] Fwd: Re: dwm + java
On 12/11/06, Anselm R. Garbe [EMAIL PROTECTED] wrote: I don't see anything else, which could have an impact. If manage() is not used, dwm don't manages any window and if in such a situation such Java apps still behave weird, then this doesn't really looks like a dwm issue after all... Well, considering that they work both with every other wm I've tried them with _and_ without any wm at all, I think this is quite a daring conclusion :-). It may very well be that it's still java's fault, but given the previous statement there's got to be something that dwm could do to make them work anyway... (and I hope we can figure out what that is). Greetings, Sander.
[dwm] dmenu navigation with a lot of items.
Hi, I love dmenu, but one thing has been bothering me for a while: lists with a lot of items are hard to navigate. With a short list, you can just browse through it with left/right; with a long list you can use the filter to speed up navigation. This is only true however when you already know what you're looking for: typing 'fire' to quickly jump to firefox is only useful if you already know that that's what you want _and_ that it's in the list. If you are faced with a long list, in which you don't know exactly what's in it, typing in a filter isn't really going to help, and scrolling all the way through the list with -- is a big pita. So from this pov, It manages huge amounts (up to 10.000 and more) of user defined menu items efficiently (from the manpage) is only partly true. In order to solve this, I believe some shortcuts to make bigger jumps in the menu are needed. Attached to this mail is a patch that uses PageUp/PageDown for jumping back/forward a full 'page', and Home/End to jump to the first/last item in the list. The patch also updates the manpage accordingly. Have fun, Greetings, Sander. @arg: I'd like to see this go mainstream; if you agree on that, I suggest to resort the keys in kpress(), they are a bit messy now (I didn't resort them in this patch to keep the patch more readable). And by the way: the reason I implemented the XK_End behavior this way is because it leaves the 'pages' intact. A simple while(sel-right) curr = sel = sel-right; calcoffsets(); Would probably do a similar job with slightly less overhead, but it would change the beginnings and ends of pages. The way it is now, pressing End will lead to the exact same result as keeping PageDown (or --) down for a while, which the above code would not do (in most cases). Since that keeps things more predictable, I think it should be the way it is in my patch; besides, I checked the speed on my Pentium 2 (400 mHz), with a list of 10.000 items, and jumping from the start to the end isn't noticably slower than jumping from the end to the start (a _much_ cheaper operation) anyway. dmenu_navigation.patch Description: Binary data
Re: [dwm] Fwd: Re: dwm + java
On 12/9/06, Anselm R. Garbe [EMAIL PROTECTED] wrote: What I'm most interested in is, how do those Java apps behave if you don't use a WM at all. If they behave same weird, then it's definately not a dwm fault. Any X application which is ICCCM-compliant should work even without a WM at all. They work fine for me without any WM at all. So apparently there's some bad interaction between java and dwm (the problem may still be at either side though). Greetings, Sander.
Re: [dwm] unicode characters in status
On 12/5/06, Anselm R. Garbe [EMAIL PROTECTED] wrote: On Tue, Dec 05, 2006 at 12:27:42PM +0300, dmtry wrote: Thank you! :) Problem solved. Now i'm glad and happy. how i should apply patch in right way? I use patch ./dwm-2.5-enforce_fontset.patch, cause with -pl as written on site it don't work. I'm not power nix user or programmer, i'm only newb, but dwm is the best and usable wm wich i try. Thank you all who made it. Well, then I think I will remove that check and we will enforce using the font in such cases anyway. (this is also relevant for dmenu). which probably justifies 2.5.2 and 1.5.1 ;-). Gr. Sander.
Re: [dwm] unicode characters in status
On 12/5/06, dmtry [EMAIL PROTECTED] wrote: I'll be more glad and happy if you advise me what i should read (links, links!) for understanding how work standart input and how i may prepare status text (or if you explain me). I put in .xinitrc while sleep 1; do date +%H:%M, %a, %D; done | dwm and i'm not sure that i understand how it works. I suggest you start with reading the stdin manpage and the redirection part of the sh manpage (type 'man stdin' in a terminal for the stdin manpage; type 'man sh' for the sh manpage; you can search in manpages by typing a slash followed by an expression, for instance '/^REDIRECTION' followed by an 'enter' will take you directly to the redirection part of the sh manpage). Greetings, Sander.
Re: [dwm] unicode characters in status
On 12/5/06, Anselm R. Garbe [EMAIL PROTECTED] wrote: Nah, I'm not sure at all what we do is a good idea. This change will be in dwm-2.6 and dmenu-1.6, but first the change has to be evaluated, before we don't see any impact of it. I think I'm going to consult other WM implementations first, to check how they have decided to handle missing font sets. Considering Diego's mail, I agree. Fixing a problem for one person by breaking it for another is pointless. Gr. Sander.
