Re: [dwm] Irc channel moved
2009/5/20 Dusan : > #suckless is probably the best. #hackers will attract wrong kids and > does not describe anything. The agreed channel name is #suckless. Period. Kind regards, Anselm
Re: [dwm] Re: New mailing list
2009/5/20 Uriel : > The problem is not dwm@ and wmii@, the problem is all the other stuff > that is unrelated to either, the only two logical and consistent > options are to either we further split the community into st@ dws@ and > so on, or we merge everything, and I think that option is a > no-brainer. I agree with that, though I think we should introduce a new list. Here is what we will do: We'll keep hackers@ as is -- just commit logs. We will introduce d...@suckless.org which merges dwm@ and wmii@ into one list, and dwm@ and wmii@ will be aliases for that. On IRC we already formed #suckless @ oftc.net Kind regards, Anselm
Re: [dwm] Re: New mailing list
2009/5/20 yy : > 2009/5/20 Szabolcs Nagy : >> On 5/20/09, Anselm R Garbe wrote: >>> Let's have hackers@ be some meta list which sends to dwm@ and wmii@, >>> and those subscribed to hackers will receive dwm@ and w...@. Those who >>> are only interested in dwm@ or wmii@ specifically could just stay on >>> dwm@ resp. w...@. That should be technically possible. >> >> dwm, wmii -> hackers >> hackers -> dwm, wmii >> >> so one sends a mail to dwm@ then it goes to hackers@ then someone >> replies there and the reply goes to w...@? >> > > Maybe I'm being naive, mailing lists are not my strong point. But IMO > you can send the messages to the people subscribed to hackers with the > corresponding FROM: field (dwm or wmii). So, if one sends a mail to > dwm, you recive it as coming from dwm. Since hackers subscribed recive > mail from both lists, the reply will arrive to dwm and hackers > subscribers. Only if you specifically send an email to hackers it will > be received by both lists (and you could, for example, change the TO: > field when the discussion goes off-topic). Maybe somebody knows if I'm > right or absolutely wrong. That's possible, though in reality people will reply to dwm@ or wmii@ and the others won't see it, which is why having one list to keep track of the discussions is better, where dwm@ and wmii@ are aliases for the same. In the beginning I'd even go that far to have the commit logs on that list as well. Kind regards, Anselm
Re: [dwm] Re: New mailing list
2009/5/20 Premysl Hruby : > On (20/05/09 10:04), Anselm R Garbe wrote: >> To: dwm mail list , wmii mail list >> From: Anselm R Garbe >> Subject: Re: [dwm] Re: New mailing list >> Reply-To: dwm mail list >> List-Id: dwm mail list >> >> Ok, I meant the following: >> >> Let's have hackers@ be some meta list which sends to dwm@ and wmii@, >> and those subscribed to hackers will receive dwm@ and w...@. Those who >> are only interested in dwm@ or wmii@ specifically could just stay on >> dwm@ resp. w...@. That should be technically possible. >> >> Kind regards, >> Anselm >> > > Don't forget that hackers@ receive commit emails, imho leave it as is or > join all into one ml. Idea for having one ml as sort of syndication ml > imho sux :), if someone wants to receive/send both ml, he/she can > subscribe/cc them. If commit messages become a problem, we can move them to hglog@ Kind regards, Anselm
Re: [dwm] Re: New mailing list
Hi, 2009/5/20 Szabolcs Nagy : > On 5/20/09, Anselm R Garbe wrote: >> Let's have hackers@ be some meta list which sends to dwm@ and wmii@, >> and those subscribed to hackers will receive dwm@ and w...@. Those who >> are only interested in dwm@ or wmii@ specifically could just stay on >> dwm@ resp. w...@. That should be technically possible. > > dwm, wmii -> hackers > hackers -> dwm, wmii > > so one sends a mail to dwm@ then it goes to hackers@ then someone > replies there and the reply goes to w...@? > > imho if we merge then don't keep separate dwm and wmii lists > > if there are too many commits then commit messages may be separated > from discussions Well, let's have one list then as you propose and see how we get on. I like to see the commits side by side. Because so far there were nearly 0 discussions regarding commits, but we had plenty on dwm@ about patches. Still, the traffic won't go up like hell. Kind regards, Anselm
Re: [dwm] Re: New mailing list
Ok, I meant the following: Let's have hackers@ be some meta list which sends to dwm@ and wmii@, and those subscribed to hackers will receive dwm@ and w...@. Those who are only interested in dwm@ or wmii@ specifically could just stay on dwm@ resp. w...@. That should be technically possible. Kind regards, Anselm 2009/5/20 Anselm R Garbe : > I think that's a sensible proposal, let's do it. > > For those who are subscribed already, there won't be a difference. The > new ones will subscribe to hackers. We will keep dwm@ and wmii@ > working, but direct it to hack...@. > > Kind regards, > Anselm > > 2009/5/20 markus schnalke : >> [2009-05-20 08:35] Uriel >>> >>> I suggested a while ago to merge wmii@ and dwm@ into hackers@, both >>> lists are rather low level, and there is much overlap, and such a >>> single list would be more fitting for new minor side projects and for >>> 'offtopic' discussion. >> >> +1 >> >> >>> Right now when one has something to say that doesn't quite fit in >>> wmii@ or dwm@, or that could fit in both, you have to pick one list at >>> random, or to cross post, and both options suck. >> >>> > > What do you think about creating an offtopic mailing list in suckless >>> > > for >>> > > discussing such >>> > > kind of topics, instead of using the dwm@ one like nowadays happen. >>> > >>> > I think it's been the charme of dwm@ to discuss lot's of other things, >> >> Yes. Merge, don't split. >> >> >> meillo >> >> -BEGIN PGP SIGNATURE- >> Version: GnuPG v1.4.6 (GNU/Linux) >> >> iD8DBQFKE6ly6aFpZ+X9qBIRArW7AJ4sXPrq+pagoWmS2AKT032PSmqOTQCfXsgx >> b3yhcxM+v9dwI/Mo9IklZHU= >> =OWPz >> -END PGP SIGNATURE- >> >> >
Re: [dwm] Re: New mailing list
I think that's a sensible proposal, let's do it. For those who are subscribed already, there won't be a difference. The new ones will subscribe to hackers. We will keep dwm@ and wmii@ working, but direct it to hack...@. Kind regards, Anselm 2009/5/20 markus schnalke : > [2009-05-20 08:35] Uriel >> >> I suggested a while ago to merge wmii@ and dwm@ into hackers@, both >> lists are rather low level, and there is much overlap, and such a >> single list would be more fitting for new minor side projects and for >> 'offtopic' discussion. > > +1 > > >> Right now when one has something to say that doesn't quite fit in >> wmii@ or dwm@, or that could fit in both, you have to pick one list at >> random, or to cross post, and both options suck. > >> > > What do you think about creating an offtopic mailing list in suckless for >> > > discussing such >> > > kind of topics, instead of using the dwm@ one like nowadays happen. >> > >> > I think it's been the charme of dwm@ to discuss lot's of other things, > > Yes. Merge, don't split. > > > meillo > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.6 (GNU/Linux) > > iD8DBQFKE6ly6aFpZ+X9qBIRArW7AJ4sXPrq+pagoWmS2AKT032PSmqOTQCfXsgx > b3yhcxM+v9dwI/Mo9IklZHU= > =OWPz > -END PGP SIGNATURE- > >
Re: [dwm] nanox
2009/5/20 Jacob Todd : > On Tue, May 19, 2009 at 04:08:07PM +0200, pancake wrote: >> > > Seems interesting, but instead of reinventing the wheel, why don't we just > clean > up X.org and submit patches back upstream? Rewriting/implementing X.org seems > li > ke more work than it's worth, but cleaning up Xorg would be better for > everyone. Unfortunately that's not my intention. I have a completely new WS in mind, design-wise with no X dependency, just an X legacy support layer instead. The crucial part of X imho is the hardware support, that's why I want to stick to xorg-drivers*, just because that's the bit which can't be done properly without driver experts. X.org can't be fixed because it consists of all the X10 and X11 legacy we don't want to carry on in a new WS, we want a different WS, not a state-machine WS like X. And X.org won't be willing to accept patches which change its internal behavior radically. Kind regards, Anselm
Re: [dwm] nanox
Hi pancake, 2009/5/19 pancake : > I have been looking a bit for an alternative for X11, and I found nano-X > quite interesting, > but it is currently an abandoned project. 8000 LOCs, there's an abstraction > library to wrap > libX11 and there's support for some many IO devices (tty, gpm, ..) It runs > directly writing > on fb0, but it shouldnt be hard to make it run as Xnest (for testing > purposes) or draw a > xorg-driver layer to directly run with native graphics drivers. > > The source looks quite clean and I think we can use it as base for the > minimal X replacement. > > ARG, what do you think about this? :) I'm looking at it and must confess it could be some starting point. > There's little movement in the mailing list nowadays, but the last release > is from 1999. So I > can think that the project is dead. > > Here's the last release of nanox (0.4) > http://www.tucows.com/download.html?software_id=9833&t=2 > > Actually the project has grown and it was renamed to "microwindows" which > has become a much bigger project: ( iwas unable to compile it because of the > outdated dependency against freetype (v1) ) > > ftp://microwindows.censoft.com/pub/microwindows/microwindows-full-0.91.tar.gz > (10MB) > > this tarball contains nanox (but depends on freetype and such) and now is > 16KLOC > > Official website: > http://www.microwindows.org/ Thanks and kind regards, Anselm
Re: [dwm] musca wm
2009/5/15 pancake : > What I find interesting is the support for multi-screen. Actually I'm using > wmii at work, > because dwm cannot properly handle multiscreen layouts and this made me use > the > mouse too much. > > Wmii has some bugs, but at least is IMHO better for multiscreen layouts. I > think this is > the eternal discussion, because it is hard to find the 'best' approach to > this problem > for dwm. > > But for single-screen environments dwm still rocks :) > > I really miss the conceptual experimentation that dwm was in the past. But I > agree that > we should probably focus on other topics like 'st' or a full OS based on > minimalist software > (based on Linux without GNU craps) ... I'll provide a new multiscreen support this weekend in dwm. It's based on assigning specific tags to specific screens. > What do you think about creating an offtopic mailing list in suckless for > discussing such > kind of topics, instead of using the dwm@ one like nowadays happen. I think it's been the charme of dwm@ to discuss lot's of other things, so I'd rather keep it as it is for now ;) Kind regards, Anselm
Re: [dwm] musca wm
2009/5/15 pancake : > another tiling manager with interesting features: > > http://aerosuidae.net/musca.html Looks to me it's aiming the original WMI without tabbing a little bit. I definately prefer the dwm way after all ;) Kind regards, Anselm
Re: [dwm] st - bug with select in run()
Hi Christoph, 2009/5/13 Christoph Schied : > After the select call in run(), the timeout argument gets changed to the > remaining time to wait, which will result in a timeout of 0 after a few > iterations. (I think thats implemenetation dependand behaviour) > Attached is a patch to fix this issue. > > Anyway, the algorithm to find out about the next event (input or x event) is > not ideal because it will cause the cpu to wake up pretty often, even if > there is nothing happening in the terminal. I dont know much about XLib, is > there possibility to find out about a new X Event by querying a fd, which > could be added to select? thanks for your patch. The current state of st is very early and it's undergoing a rewrite in nearly all drawing portions in order to adopt the still work-in-progress libtg. The select() issue you mention will be improved through checking the X connections fd similiarly to what we did in dwm until the switch to X properties for the status text feed. That will be a better solution than the timeout behavior currently in use. Kind regards, Anselm
Re: [dwm] dwm status bar..
2009/4/30 Wu, Yue : > On Thu, Apr 30, 2009 at 08:22:59AM +0100, Anselm R Garbe wrote: >> 2009/4/30 Wu, Yue : >> > On Wed, Apr 29, 2009 at 10:08:09PM -0700, Scytrin dai Kinthra wrote: >> >> use `xsetroot -name ` as dwm's status bar contents are now >> >> derived from the name attribute of the root window. >> >> It's a good thing, as you no longer need to play the pipe game. >> > >> > It's a pain that I have to install an extra software to achieve this simple >> > thing. :( >> >> There is wmname as well which can be used. > > I'll have a try, thank you :) Anyway, I think add it into dwm is a perfect way > for me, it just a simple function, and won't add much more lines of code I > think, right? Reading from stdin is significantly more complex than using an X property. I refer to the hg history: http://code.suckless.org/hg/dwm/rev/6d6ed7a9183c Kind regards, --Anselm
Re: [dwm] dwm status bar..
2009/4/30 Wu, Yue : > On Wed, Apr 29, 2009 at 10:08:09PM -0700, Scytrin dai Kinthra wrote: >> use `xsetroot -name ` as dwm's status bar contents are now >> derived from the name attribute of the root window. >> It's a good thing, as you no longer need to play the pipe game. > > It's a pain that I have to install an extra software to achieve this simple > thing. :( There is wmname as well which can be used. Kind regards, --Anselm
Re: [dwm] dwm's future
2009/4/28 pmarin : > Try to make the new dependencies optionals. > > About the broken non-free apps, is not dwm's problem and one solution > can be to use a qemu instance with another WM and connect to the host > Xwindows server. That won't be a really good solution, the better solution is Xnest. And don't worry about the dependencies, there won't be any more than what we currently got. Kind regards, Anselm
Re: [dwm] dwm's future
Ok, thanks again for continuing the discussion. My conclusion is as follows: 1) dwm will be slightly redesigned, code-wise. I consider having a less suckish font and drawing abstraction in order to be implemented in different ways (which will also be used by st and dmenu). Officially there will only be X font support as is. But due to this abstraction it'll be possible to implement cairo/pango backends if that seems more suitable for non western glyphs without the need to change any vanilla dwm code. 2) Similiarly I will separate the bar bits into a separate file to make it easy to get rid of the bar if someone prefers going with dzen+xdotool. 3) Regarding the broken apps I need to investigate further. If it's really related to reparenting, it's definately a bug in these apps or in the toolkit (JDK?) they rely on. If that's the case I WON'T introduce kludges to handle them, instead we should file bug reports that these apps get fixed. Particularly if these apps are of commercial nature, it should be the vendor's interest to fix their apps that you as a customer can use them in your preferred environment. You or your organization pays someone license fees I guess so that's just a totally valid request that the vendor fixes these apps. 4) Regarding multihead I will start a separate thread soon what a viable solution might be. Kind regards, Anselm
Re: [dwm] dwm's future
2009/4/27 Preben Randhol : > On Sun, 26 Apr 2009 11:11:03 +0100 > Anselm R Garbe wrote: > >> So there are only three ways: >> >> - stick with what we got (don't care if some langs look ugly) >> - use pango and/or cairo or something like that >> - invest some effort into a new font rendering lib (seems to be a hard >> job, esp. if one asks for proper font support which can't be done by >> us) > > What about xft? Wasn't there a patch for 4.7 (can't find it anymore). > I don't know much about the font systems. One option, though quite half hearted in my opinion. Kind regards, --Anselm
Re: [dwm] dwm's future
Thanks for all the valueable input so far in this thread. I think here are the action points: 1) I plan to separate the bar stuff code-wise into two portions -- the tag bar with tags and layout info, and the title/status bar, but things will stay as they are from a user perspective, it's just some code cleanup which allows replacing the tagbar and/or title/status bar with something else (or avoiding to compile it in) There might be possible pango/cairo implementations of this stuff, I plan to have a font API interface, something like libsfont which is used by dwm and dmenu to start with, and which depends on either Xlib or some more fancy sucking stuff optionally. 2) I need to investigate into the reparent stuff first, I really dislike going the reparent route, because each parent window consumes much more X resource memory (basically twice the buffer sizes as we have already if you use a reparenting WM -- this makes everything slower). I really think bug the authors of the broken apps to fix their apps that they do not assume a reparenting WM. So the action here is: let's make a list of all apps which are known to be broken and behaving strange with dwm first, that I can investigate. - Mathematica (Version?) - ... please provide input 3) I agree multihead has got some preference, I like the approach to assign certain tags to specific screens. Kind regards, Anselm
Re: [dwm] dwm's future
2009/4/26 Szabolcs Nagy : > On 4/25/09, Anselm R Garbe wrote: >> 1. One idea is getting rid of the dwm bar altogether and to print the >> dwm state to stdout when it changes, however after thinking carefully >> about it I conclude that having the bar build-in is definately a >> stayer. It's so much simpler than the hassle with an external bar, not >> worth it. So very unlikely. > > if external bar is a hassle then inter-process communication is broken > in our systems > > if built-in bar is a hassle then x is broken (unable to display text) Well, an external bar is a hassle because it would increase the overall complexity if it's assumed to be implemented properly (or in a fashion like what we got). One has to specify handling where the bar appears, which size, and all kinds of interface handling between the bar and dwm. >> 2. Another idea is to switch to another dependency for the rendering >> bit which could possibly be cairo. After all I'm nearly giving up the >> hope that X font handling will ever be fixed and work properly, > > $ du -h /usr/lib/libcairo.a > 608K /usr/lib/libcairo.a > > pango seems to be slightly smaller, but i don't know what these libs > do exactly.. They do fairly more than what we need for a single bar. So let's stick to what we got. > imo it's not suckless, but it can be a temporary solution until x is fixed Knowing who drives the X development I gave up any hope that X will ever be fixed, more the contrary. I think the only solution is dws, which needs more assistance and which can be based on legacy crap. Important is that dws provides decent interfaces and possibly a legacy X interface on top of it. I think that's the long term plan we should achieve. But it'll take a long time with the resources we got atm (I hoped GSoC would sponsor us somehow to get started into that direction). >> 3. A third idea for legacy support is, that I tend to add a >> compile-time option or a specific Rule extension that let's you set to >> reparent all clients or certain clients which are broken > > rule extension won't work as these applications tend not to set > class,instance,name properly Yea that's a pity and that makes the rules more questionable, perhaps I should make them simpler or changing the mechanism eg having a "catch next map" function instead which applies a certain rule to the next window which is mapped. Kind regards, --Anselm
Re: [dwm] dwm's future
Hi, 2009/4/26 Szabolcs Nagy : > On 4/26/09, Christian Garbs wrote: >> On Sat, Apr 25, 2009 at 11:06:08PM +0100, Szabolcs Nagy wrote: >>> On 4/25/09, Christian Garbs wrote: >>> > work, even without pango or cairo. I have German umlauts as well as >>> > Japanese characters (eg. web page titles from Firefox). >>> >>> try greek or cyrillic >>> i had trouble with those when fonts were loaded with XCreateFontSet >> >> Looks ok to me: >> https://www.cgarbs.de/tmp/dwm-ru.png > > no, that is ugly bold font, same problem with greek > >> Wrong font here? >> https://www.cgarbs.de/tmp/dwm-ar.png > > most likely your font does not cover arabic fonts (iso8859-6) in the given > size > >> Korean does look broken, though: >> https://www.cgarbs.de/tmp/dwm-ko.png > > yes, i get the same result using fixed-14 With the font spec: "-*-*-medium-*-*-*-14-*-*-*-*-*-*-*" I'm able to get proper results including Japanese, Chinese, Korean, Greek, Russian, Hebrew, and Thai with that. Though not all of them are monospaced (Gree and Russian for instance). Arabic doesn't work for me if I'm not increasing the size to 17 or above which is huge... and that's hard to be monospaced anyways. I had a look into pango, well and I agree having such a dependency is not very nice, pango is quite complex for what we need, cairo is bad either for what we require. These achieve pseudo-monospace'ing through scaling, which ends up in more or less equally bad results as using plain X fonts, though perhaps looking a little bit smoother because one doesn't need to declare large fonts. So there are only three ways: - stick with what we got (don't care if some langs look ugly) - use pango and/or cairo or something like that - invest some effort into a new font rendering lib (seems to be a hard job, esp. if one asks for proper font support which can't be done by us) So I think, we stick to what we got after all. The bar stays at it is. I agree there are more interesting problems. Kind regards, --Anselm
Re: [dwm] dwm's future
2009/4/25 yy : > There is a middle way solution. I just thought about it, and will > probably have its drawbacks, but here it goes: keep a bar with only > the tags and tile symbol and print the sel client title to stdout. > This way you can use an external program (dzen) to render the title > (and status text, of course). I don't think nobody needs unicode > glyphs in their tag names or tile symbols, you wouldn't need cairo in > dwm (but could add it to dzen) and would remove a lot of loc getting > ride of status text and window title. > About the reparent call, I don't think is a good idea. There are lots > of dwm similar wms around, and it is very easy changing between them. > I would keep dwm as pure as possible and would let the others to > handle the dirty stuff, but of course I'm not the one who needs to use > those broken apps... Well I like and hate that idea. Those who do not like relying on some other apps won't see the title anymore (just ignoring the status text). On the other hand, purists might not be interested in the title and status text anyways. So definately worth considering! Kind regards, --Anselm
[dwm] dwm's future
Hi there, I discussed several stuff on IRC recently but wanted to share my thoughts here. 1. One idea is getting rid of the dwm bar altogether and to print the dwm state to stdout when it changes, however after thinking carefully about it I conclude that having the bar build-in is definately a stayer. It's so much simpler than the hassle with an external bar, not worth it. So very unlikely. 2. Another idea is to switch to another dependency for the rendering bit which could possibly be cairo. After all I'm nearly giving up the hope that X font handling will ever be fixed and work properly, so that relying on a pile of other crap seems to become a solution. cairo is a dependency for firefox and I guess that every dwm user uses firefox occasionally. And we might benefit from a little bit smoother looking dwm (same for dmenu of course and my ongoing st efforts). I think this idea is quite likely. 3. A third idea for legacy support is, that I tend to add a compile-time option or a specific Rule extension that let's you set to reparent all clients or certain clients which are broken such as Mathematica or various Swing apps, though I'm not absolutely sure how likely that is. Somehow my inner feelings are against it, because it's not a dwm problem and those broken apps should be fixed. Please feel free to comment or add other ideas to this list. Kind regards, --Anselm
Re: [dwm] [patch] flag for default option
2009/4/25 Dieter Plaetinck : > I'm not a proficient C coder but I managed to hack this patch together. > With this, you can set the starting search string to something else then an > empty string. You should have asked before patching, there is a much simpler solution for what you attempt to achieve: echo blah | dmenu Nevermind and kind regards, --Anselm
Re: [dwm] [patch] flag for default option
2009/4/25 Anselm R Garbe : > 2009/4/25 Dieter Plaetinck : >> I'm not a proficient C coder but I managed to hack this patch together. >> With this, you can set the starting search string to something else then an >> empty string. > > You should have asked before patching, there is a much simpler > solution for what you attempt to achieve: > > echo blah | dmenu Ah damn, I'm a moron ;) Ignore what I said before... Kind regards, --Anselm
Re: [dwm] [RFC] dwm-win32
Hi Marc, just digged through my spam filter and spotted that thread here (including your older mail a month ago): 2009/4/20 Marc Andre Tanner : > So a month passed since my last posting and there was absolutely > no feedback so I assume the reasons are: > > (a) you guys are in the comfortable situation of not having to > touch windows boxes > > (b) alpha1 was unusable and you didn't even bother to write a comment > > Anyway I have since fixed a few bugs and probably also introduced some > new ones. But since I most likely wont have time to look into this in > the near future I post my current codebase just in case someone is > interested in it. > > http://www.brain-dump.org/projects/dwm-win32/dwm-win32-alpha2.zip > http://www.brain-dump.org/projects/dwm-win32/dwm-win32-alpha2.tar.gz > http://www.brain-dump.org/projects/dwm-win32/dwm-win32-alpha2.exe Thanks, that's very interesting I will look into it. Lemme get back to you soon. Kind regards, --Anselm
[dwm] dwm-5.5 / dmenu-4.0
Hi there, I'm glad to announce some new releases: http://code.suckless.org/dl/dwm/dwm-5.5.tar.gz http://code.suckless.org/dl/tools/dmenu-4.0.tar.gz The new dwm release contains various bugfixes and code cleanups appeared during the last months and it has also been simplified: - the noborder feature of single tiled clients in the view has been removed for simplicity reasons - the usegrab option in config.h has been removed The new dmenu release also contains various bugfixes appeared during the last months. Let me know any issues. Kind regards, --Anselm
Re: [dwm] Replacing slock screen overlay with screenshot / bitmap
2009/4/18 Jan Blazek > Scytrin dai Kinthra wrote: >> I use a combination of xss and xkeygrab to lock my screen but allow >> the UI to update in the background so I can see incoming emails and >> chats. > > This is something I always wanted but didn't have enough time/will to dig > into it. Would you mind sharing your solution? What about not creating the black window at all? Kind regards, --Anselm
Re: [dwm] Raise window when requested?
Hi, 2009/4/14 Haomin Wen : > I often write some latex files in vim, and use xdvi to see the result. My > screen is small, so I work in monocle layout. > > The man page of xdvi said that the existing xdvi will raise its window when > another xdvi is evoked with -sourceposition option, but it seems that dwm > can not handle this. > > Can somebody fix this? I will have a look into it. It'll be required that these windows are set to floating, otherwise dwm will always override to "behind floating windows" if these windows are managed/tiled by default. Afaik configurenotify does not handle raise requests right now. Note, this fix won't be in officially before dwm-5.6, because hg tip is what I'm going to release as dwm-5.5. Kind regards, --Anselm
Re: [dwm] [dmenu] OPTFLAGS in config.mk + patch
Hi,
Honestly, I think introducing OPTFLAGS is kind of arbitrary, even if
it's done in existing software (well existing software uses autohell
quite a lot). In my opinion CFLAGS is the right variable to include
compiler flags, and -Ox is one of them.
Kind regards,
Anselm
2009/4/8 Jan Blazek :
> I would like to make package of dmenu for Fedora and in the review process
> someone (Till Maas) suggested it would be better to have ability to pass gcc
> optimization flags to make on the command line. [1]
>
> Best regards,
> Jan Blazek
>
> PS: Patch attached.
>
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=485638#c3
>
> --- dmenu-3.9/config.mk.optflags 2008-09-09 15:45:00.0 -0400
> +++ dmenu-3.9/config.mk 2009-04-02 15:26:41.0 -0400
> @@ -20,7 +20,8 @@ LIBS = -L/usr/lib -lc -L${X11LIB} -lX11
>
> # flags
> CPPFLAGS = -DVERSION=\"${VERSION}\" ${XINERAMAFLAGS}
> -CFLAGS = -std=c99 -pedantic -Wall -Os ${INCS} ${CPPFLAGS}
> +OPTFLAGS = -Os
> +CFLAGS = -std=c99 -pedantic -Wall ${OPTFLAGS} ${INCS} ${CPPFLAGS}
> LDFLAGS = -s ${LIBS}
>
> # Solaris
Re: [dwm] Push patch
http://dwm.suckless.org/patches/push-5.3.c Sorry, the page is not formatted correctly. 2009/4/1 Nikke : > I can't seem to find the download link for the push patch? > There is no link at the push patch site, can someone give me a working > url please? :) > > /Nikke
Re: [dwm] Fake key in xterm
2009/3/31 Tinou : > In vim, to jump to a tag (tjump) ctrl-] is used. I'm french and using a > french azerty keyboard. On windows or osx, ctrl-] can be acheived by > pressing ctrl-$ but not in xorg, since ^$ doesn't seem to exist. > > ctrl-$ is simpler because to produce a ']' I need to use one more > modifier: "altgr". > > So, to reproduce the windows/osx behaviour, I though I could grab the > key ctrl-$ in dwm and then send to the selected window the key > combination ctrl-altgr-]. > > The attach code does this and it works perfectly in gvim or > rxvt-unicode. > > But not in xterm (nor uxterm). > > My question is: how can I make this work in xterm ? The reason is that you are using XSendEvent and that xterm has got a protection against synthetic key events by default (otherwise a malicious app could send rm -rf /\n to a xterm window). To allow synthetic key events, set something like: XTerm*allowSendEvents: True Kind regards, Anselm
Re: [dwm] dmenu filename tab-completion patch
Hi Steven,
sorry for getting back so late, I think it might be worth considering
it after the 4.0 release which I plan to do very soon.
Kind regards,
Anselm
2009/3/27 Steven Blatchford :
> @Anselm
> I am curious, will you be committing this patch?
>
> -steve
>
>
> On 18:25 Wed 28 Jan, Jeremy Jay wrote:
>>
>>On Wed 28 Jan 2009 - 12:38PM, bill lam wrote:
>>> It is very useful!
>>> Can it be extended to handle ?
>>
>>request granted =) first tab will do longest
>>completion, subsequent tabs will cycle through
>>all choices.
>>
>>I dont know if others tried or not, but my
>>example didnt work... OpenOffice (and a few
>>other apps I noticed) doesn't like the escaped
>>spaces, so I tweaked the dmenu_run script so
>>it'll work now (assuming the filename is the
>>only argument... YMMV)
>>
>>This patch makes the functionality optional
>>through a "-c" command line argument, in the
>>interests of keeping dmenu generic and hoping
>>this will get committed to the main line. So
>>you'll want to add it to your dwm config.h or
>>whatever you call it through. I've also
>>added some info to the man page too.
>>
>>Jeremy
>
>>diff -r 13402291bc76 dmenu.1
>>--- a/dmenu.1 Fri Dec 12 19:58:52 2008 +
>>+++ b/dmenu.1 Wed Jan 28 18:15:59 2009 -0500
>>@@ -12,6 +12,7 @@
>> .RB [ \-sb " "]
>> .RB [ \-sf " "]
>> .RB [ \-v ]
>>+.RB [ \-c ]
>> .SH DESCRIPTION
>> .SS Overview
>> dmenu is a generic menu for X, originally designed for
>>@@ -46,6 +47,9 @@
>> .TP
>> .B \-v
>> prints version information to standard output, then exits.
>>+.TP
>>+.B \-c
>>+enables filename completion for text after a space (useful with the
>>dmenu_run script).
>> .SH USAGE
>> dmenu reads a list of newline-separated items from standard input and
>> creates a
>> menu. When the user selects an item or enters any text and presses Return,
>> his/her
>>@@ -67,7 +71,9 @@
>> Select the first/last item.
>> .TP
>> .B Tab (Control\-i)
>>-Copy the selected item to the input field.
>>+Copy the selected item to the input field. Also, if the -c option is given
>>and there
>>+is a space in the input, will try to expand and complete text after the
>>space into a
>>+valid filename. (First Tab - Longest Completion, Multiple Tabs - cycle
>>through files)
>> .TP
>> .B Return (Control\-j)
>> Confirm selection and quit (print the selected item to standard output).
>> Returns
>>diff -r 13402291bc76 dmenu.c
>>--- a/dmenu.c Fri Dec 12 19:58:52 2008 +
>>+++ b/dmenu.c Wed Jan 28 18:15:59 2009 -0500
>>@@ -8,6 +8,7 @@
>> #include
>> #include
>> #include
>>+#include
>> #include
>> #include
>> #include
>>@@ -59,6 +60,7 @@
>> static void initfont(const char *fontstr);
>> static void kpress(XKeyEvent * e);
>> static void match(char *pattern);
>>+static void matchfile(char *filestart, Bool cycling);
>> static void readstdin(void);
>> static void run(void);
>> static void setup(Bool topbar);
>>@@ -77,7 +79,7 @@
>> static int screen;
>> static unsigned int mw, mh;
>> static unsigned int numlockmask = 0;
>>-static Bool running = True;
>>+static Bool running = True, filecomplete = False;
>> static Display *dpy;
>> static DC dc;
>> static Item *allitems = NULL; /* first of all items */
>>@@ -311,6 +313,7 @@
>>
>> void
>> kpress(XKeyEvent * e) {
>>+ static KeySym lastkey=0;
>> char buf[32];
>> int i, num;
>> unsigned int len;
>>@@ -396,7 +399,10 @@
>> default:
>> if(num && !iscntrl((int) buf[0])) {
>> buf[num] = 0;
>>- strncpy(text + len, buf, sizeof text - len);
>>+ if(len > 0)
>>+ strncat(text, buf, sizeof text);
>>+ else
>>+ strncpy(text, buf, sizeof text);
>> match(text);
>> }
>> break;
>>@@ -467,12 +473,17 @@
>> }
>> break;
>> case XK_Tab:
>>+ if( filecomplete && strchr(text, ' ')!=NULL ) {
>>+ matchfile( strchr(text, ' ')+1, lastkey==XK_Tab );
>>+ break;
>>+ }
>> if(!sel)
>> return;
>> strncpy(text, sel->text, sizeof text);
>> match(text);
>> break;
>> }
>>+ lastkey=ksym;
>> drawmenu();
>> }
>>
>>@@ -518,6 +529,44 @@
>> }
>>
>> void
>>+matchfile(char *filestart, Bool cycling ) {
>>+ static int try=0, p=0;
>>+ wordexp_t exp;
>>+ int i, j, k;
>>+
>>+ if( !cycling ) {
>>+ p = strlen(filestart);
>>+ try=0;
>>+ }
>>+ filestart[ p+1 ] = 0;
>>+ filestart[ p ] = '*';
>>+
>>+ wordexp(filestart, &exp, 0);
>>+ if( exp.we_wordc > 0 ) {
>>+ for(j=0,i=0; exp.we_wordv[try][i]!=0; i++,j++) {
>>+ if( exp.we_wordv[try][i]==' ' ) filestart[j++]='\\';
>>+ filestart[j]=exp.we_wordv[try][i];
>>+ }
>>+ filest
Re: [dwm] autoconf
2009/3/19 bill lam :
>> - die("dwm-"VERSION", © 2006-2009 dwm engineers, see LICENSE for
>> details\n");
>
> Not related to autoconfm but I notice the copyright sign is in utf-8.
> If dwm is compiled in other locale, will it display properly when
> run on that locale?
No, but we expect all users are using UTF-8 nowadays -- and if not,
they won't care either about that detail I suppose (like those OpenBSD
users ;)).
Kind regards,
--Anselm
Re: [dwm] autoconf
2009/3/19 Kurt Van Dijck : > I'm in the process of cross-compiling dwm. I understand the idea of > having a config.mk for this, but it is not the easiest. > Since I had to fix some other packets too, I learned myself to setup a > minimal autoconf. This allows one to do: > ./configure && make && make install What does wc -l configure output after you run autoconf? Anyway, I can't see any reason why setting CC and possibly INCS and LIBS is more difficult than dealing with obscure arguments to configure, which also may require CFLAGS, LDFLAGS and CC in the environment if you intend to cross compiler -- OR some --target-XYZ and --host-XYZ arguments... For which target platform do you attempt to compile dwm? (I only did it for maemo so far, and there I didn't need to change anything at all, because my scratchbox setup was done properly). Kind regards, --Anselm
[dwm] GSoC 2009, suckless.org has been rejected
Hi there, I'm sorry to announce that we didn't make it this time. I want to thank all people involved in the preparations for their efforts. Hopefully, I will have a private chat tomorrow with Leslie to hear about the reasons and what we can do better the next time. The GSoC page is moved to http://suckless.org/common/project_ideas I will add an auto-redirection later today (currently it's an href)... Kind regards, --Anselm
Re: [dwm] splash screen
On Tue, Mar 17, 2009 at 12:05:15AM +0800, bill lam wrote:
> On Mon, 16 Mar 2009, mi...@milesgroman.com wrote:
> > Can you reply with your rule for gnumeric? I occasionally use
> > gnumeric, though I do not recall a splash, it does tile as expected.
>
> static Rule rules[] = {
> /* class instancetitle tags mask isfloating */
> { "UXTerm",NULL, NULL, 0,False },
> { "XTerm",NULL, NULL, 0,False },
> { "Iceweasel", NULL, NULL, 1 << 8, True },
> { "Firefox", NULL, NULL, 1 << 8, True },
> };
>
> No special treatment for gnumeric. It tiles correctly if starts with
> no worksheet or with a small worksheet because gnumeric will only
> shows a splash screen when it needs a longer time to load, about 5 to
> 10 seconds. I do not know the exact timing but that should be the
> intended behavior of gnumeric
I suppose it sets a TRANSIENT_FOR hint on the main window to the
splash because of some brokeness in gnumeric.
Kind regards,
Anselm
Re: [dwm] what is mwm hint?
2009/3/16 bill lam : > When I try turn on full screen in feh (an image viewer). It said > > feh WARNING: Window Manager does not support MWM hints. > To get a borderless window I have to bypass your wm. > > What is mwm hint? Is that important? > > dwm-5.5 Hmm, if so that's a bug, because dwm used to support MWM since the beginning. Will check. MWM stands for Motif WM hints. Kind regards, --Anselm
Re: [dwm] suckless.org stylesheet glitch
2009/3/13 Uriel : > I run http://cat-v.org on xen, and even really long pages like > http://ninetimes.cat-v.org take a couple of seconds to load. > > Something was wrong with suckless.org, sometimes a small page could > take ten seconds, it is better now but still on the slow side of > things. I guess you use ipv6? Kind regards, --Anselm
Re: [dwm] Wiki date format
I think the whole issue is resolved now, because the news index is using /MM/DD now. Kind regards, Anselm 2009/3/13 Uriel : > The '-' is a tr(1) call away, but I don't see the point, and using '/' > emphasizes the fs structure and that the urls are 'hackable' (as the > latest buzzword goes). > > uriel > > On Wed, Mar 11, 2009 at 6:34 PM, wrote: >> * markus schnalke [2009-03-11 16:42]: >>> [2009-03-11 16:10] yy >>> > OTOH, a >>> > /mm/dd structure is convenient to organize months and years in a >>> > tree structure, i.e. directories >>> >>> If /mm/dd depicts a path, I agree. Anyway, in this case it's the >>> only way, as slash separates files in a path. >> >> One can use the standard for representation, i.e. show 2042-03-11 _and_ >> store files in 2042/03/11 ( ... as was the intention when time was invented >> :o) ). >> What's the problem? >> >> Well, this will effectively result in URLs like >> http://foo.bar.bg/posts/2042/03/11/date-format-is-confusing.html which may >> be a bit confusing for some people, but the context (hierarchical >> structure) should prompt what date it is supposed to be. (if one is aware >> of what the intention was when time was invented) >> :o) >> >> -- >> cheers >> stanio_
Re: [dwm] Gaps
2009/3/13 anonymous : > Is it possible to add, for example, left side gap? Yes, have a look at tile() and change it in order to use w- instead of 0 as offset. Kind regards, --Anselm
Re: [dwm] suckless.org stylesheet glitch
2009/3/11 twfb : > On 00:59 Wed 11 Mar , Uriel wrote: >> Also, www.suckless.org is *SLOW* to the point of being unusable > > Slight exaggeration perhaps... but it is a little bit slow and was > indeed slow even before the switch to werc. Nothing dramatic but > noticable slow for such a low graphic website. Don't expect too much from a xen instance. But it's more friendly to the environment than having a full blown dedicated server idling most of the time ;) Kind regards, --Anselm
Re: [dwm] suckless.org stylesheet glitch
2009/3/11 pmarin : > Why have you change to werc? The main reason is I'm not very keen on maintaining a web framework and Uriel spend his last year on this and I think his werc is very good. Kind regards, --Anselm
Re: [dwm] suckless.org stylesheet glitch
2009/3/10 Uriel : > Good point, probably the werc stylesheet should be split and > reorganized to avoid this kind of issues, I will think about it. > > Also, www.suckless.org is *SLOW* to the point of being unusable, and > i'm sure that is not werc's fault because http://cat-v.org and many > other werc sites are quite fast. If it's slow it's definately werc or p9p, because even the old UML static web server (now sandbox.suckless.org) was fast enough for static pages that nobody complained ;) But I don't think that www.suckless.org is too slow. Kind regards, --Anselm
[dwm] GSoC2009
For those of you who haven't noticed, we are applying as a mentoring organization during GSoC2009 this year. http://www.suckless.org/GSoC2009 We set up a new mailing list for GSoC specific questions which is world-writable here: g...@suckless.org We do not know yet if we will be accepted. Kind regards, --Anselm
Re: [dwm] C unit testing
2009/3/10 Richard Pöttler : > I just wanted to ask you guys if you could recommend me a tool to > unit test my C code. So far I only found CUnit, Check and CuTest but > haven't dug into any of them. Do you have any suggestions? #include ;) Kind regards, --Anselm
Re: [dwm] wiki location changed
2009/3/9 Uriel : > Good work Anselm! > > And anyone interested in werc, see: http://werc.cat-v.org > > uriel > > P.S.: Can you make http://suckless.org work properly and > http://www.suckless.org redirect to it? (Or the other way around if > you really prefer it that way, although I prefer no www.) You are right. I'll do so when I got some time today. Kind regards, --Anselm
[dwm] wiki location changed
Hi there, those of you who contributed to the wiki in the past, please note that the new URL of the wiki repository (which has to be cloned freshly again) is as follows: hg clone http://sandbox.suckless.org/hg/sites The online preview wiki is broken atm and will be back up and running again on http://sandbox.suckless.org shortly. As you will notice the web site http://www.suckless.org has been migrated to werc. Please bare in mind that the migration work is still ongoing, though any contributions to the wiki are welcome (mails to w...@suckless.org are issued for changes from this location now). Cheers, --Anselm
[dwm] GSoC 2009 mentors please shout
Hi there, please send me a private mail if you'd be willing to mentor a GSoC project this year for suckless.org. We need at least 10 mentors I'd say. Kind regards, --Anselm
Re: [dwm] .xinitrc error?
2009/3/5 Christoph Siegenthaler : > I haven't changed my dwm config.h since 4.9 and was using it happily for > months. I finally decided to try out 5.4.1 and I'm almost done. > The only problem is that I can't get the status bar to display what's piped > into dwm. It was working before and displayed a lot of fancy stuff. > I stripped it down to the bare minimum now but it still displays dwm-5.4.1 > instead of what I want it to: > > $ cat .xinitrc > #!/bin/sh > ### > # DWM # > ### > timeout=0.2 > while true > do > echo "Test" > sleep $timeout > done | dwm | eval `cat ~/.fehbg` > > What do I miss here? I'm sure it's something obvious (far somebody else but > me)... See the README file ;) Kind regards, --Anselm
Re: [dwm] This question is probably beneath you all--but I will ask anyway
Doesn't Alt+Left mouse button drags for move, and Alt+Right mouse button drags for resize work? I haven't seen any X window which won't resize using this. Kind regards, Anselm 2009/2/28 I. Khider : > Greeting fellow DWM users > > I noticed with certain applications like Gimp, k3b, etc. it is very > difficult to maximize a work screen--I have yet to figure it out. Also for > Gimp, I have tried to move my tools applications around the workspace and > apart from toggling between them, I canot move them around. > > I tried the man page and to google the problem and IRC on some channels but > nobody knows, hence my appeal to you. Perhaps someone knows of a document I > could consult to get on my way? > > Thank you in advance for your patience. > > -I- -- --Anselm
Re: [dwm] Google Summer of Code 2009
2009/2/20 Matthias-Christian Ott : > this year there will be Google' Summer of Code and Anselm has agreed > that the suckless project will pariticipate. Usually it will be > announced in the next weeks. > > Since they require every participating project to provide a website > that lists the ideas for the student projects, I suggest to setup a wiki > page. Maybe we can discuss them here prior posting them. The requirements: http://code.google.com/opensource/gsoc/2009/faqs.html#0_1_org_apply_4694175091022641 Kind regards, --Anselm
Re: [dwm] [OT] Personal Website and CSS
2009/2/19 Matthias-Christian Ott : > On Thu, Feb 19, 2009 at 12:07:16AM +0100, hiro wrote: >> > I think the only way is dropping HTML and CSS altogether and going >> > with something new. I'd be very interested in contributing. I think >> > the replacement should not only focus on presentation but equally on >> > forming a base for less suckish applications which are highly network >> > transparent. >> > >> > Kind regards, >> > --Anselm >> >> Not sure if OP really wanted to do this, but such alternatives have >> always existed. Look at gopher for example. >> >> I would export 9p filetrees and mount them in acme. You can use text >> files and plumbing if you want hyperlinks. >> I very much enjoy reading 9fans that way. >> >> But I admit this not being beauty typesetting. >> >> > browsers like Mozilla Firefox have terrible default typographic style >> > and using text-mode browsers like links often seems to be only solution >> > when reading longer texts. >> >> I don't really get this: Where can we find real typographic style in links? > > There's actually none, but it's better to display the text in a fixed-font > uniform size than in misproportioned text with unsuitable spacing. > >> Perhaps we need a combination of Troff's beauty and web browser's dynamics. > > What do you mean by dynamic? AJAX? I suppose you mean hyperlinks. Well, here is what I realized during the st development and which emerged into some text (g)ui library which can be seen as graphical curses at some point and which I'm going to consider forming the base of replacing HTML+CSS and vt100 and curses and all that stuff (and which I'm afraid to publish in its current flaky and unfinished state still but I need to do so anyways sooner or later). Apart from presenting information (which can be done in a terminal-like sense, and a browser is a terminal to some extend) which used to be HTML in the past, it is very obvious that there is the demand for so called "web applications" which run as hybrids remotely and locally and which are simply loaded (instead of physically installed) on every access time again and again... They can access local and remote resources in a kind of transparent way and provide services -- even if it's just about reading a bolg article. There are 3 layers in such an approach: - resource access - resource - scripting The resource access should be done using a stateful protocol rather than HTTP. The resource itself isthe content (could be something that replaces HTML+CSS+JS and provide extensions such as map() for mapping contents rendered by server- or client-side code and extensions for scripting). The scripting layer is also an extension with access to the server and client environment (not necessarily bound to the resource only). One can compare it to JS -- though I doubt the DOM-based approach of how web pages are scriptable nowadays is right. In the case of a terminal, the resource is a tty session, the resource access is the connection to it and the scripting are the commands send back and forth (which are not restricted to the resource itself, which could be a shell process, but which could be control sequences as well (server- and client environment access). So if you consider the modern Web as consisting of terminal servers providing content then we get closer to the idea. I think designing the HTML+CSS replacement must go hand in hand with the underlying protocol. Kind regards, --Anselm
[dwm] Issues with border
Hi,
I dislike the recent addition of the 0 border if only 1 tiled client
is in the view, reasons:
- gained screen real eastate is very minimal
- configure events are increased by n at any view() and toggleview(),
if n is the number of clients in the view
- corner cases for togglefloating()
- I dislike adjustborder() altogether
So my proposal is: reverting to old behavior (nonoborder), and for
those who like it, use a config.h function like:
void toggleborder(const Arg *arg) {
borderpx = 1 - borderpx;
arrange();
}
And then define a key binding for it.
Opinions?
Kind regards,
--Anselm
Re: [dwm] [OT] Personal Website and CSS
2009/2/18 Matthias-Christian Ott : > since several years I have been planed to launch a personal website. I > used to do quite aesthetical web design before I have subscribed to > minimalism. What annoyed me then and now was CSS and its implementations > in modern browsers. > > When I tried to design a minimalist website (just some typographic > enhancements to make texts more read- and printable), I realised that > there seems to be no agreed standard for a default CSS stylesheet merely a > recommendation from the CSS standard [1] (which is incomplete) and a lot > of people seem to be concerned about resetting the browser CSS defaults - > even the W3C does so in their stylesheets [2]. Most people seems to have > installed nearly all popular browsers, test with those and incorporate > workarounds if necessary. > > All in all this seems very absurd to me and I would like to know how > you approached this problem. > > At the moment I'm just aware of The Anti-web Manifesto [3] that someone > linked to on this mailing list. Although I mainly subscribe to it, > browsers like Mozilla Firefox have terrible default typographic style > and using text-mode browsers like links often seems to be only solution > when reading longer texts. > > Any ideas? I think the only way is dropping HTML and CSS altogether and going with something new. I'd be very interested in contributing. I think the replacement should not only focus on presentation but equally on forming a base for less suckish applications which are highly network transparent. Kind regards, --Anselm
Re: [dwm] solaris regression tests
Hi, 2009/2/13 Stefan Kuttler : > After some digging within Solaris PATH Settings, I managed to compile > dwm-5.4.1 without problems: (So did others hopefully, but I want to > collect nearly all plattforms) > > ,echo $PATH > /usr/bin:/usr/openwin/bin:/usr/ucb:/usr/dist/exe:/usr/sfw:/usr/sfw/bin > > ,CC=/usr/sfw/bin/gcc > > ,gmake > dwm build options: > CFLAGS = -std=c99 -pedantic -Wall -Os -I. -I/usr/include > -I/usr/X11R6/include -DVERSION="5.4.1" > LDFLAGS = -s -L/usr/lib -lc -L/usr/X11R6/lib -lX11 > CC = /usr/sfw/bin/gcc > CC dwm.c > CC -o dwm > ,uname -a > SunOS srm-hello-08 5.10 Generic_127111-07 sun4v sparc SUNW,Sun-Fire-T200 > ,file dwm > dwm:ELF 32-bit MSB executable SPARC Version 1, dynamically > linked, stripped > > > I got the idea of nightly regression tests for dwm (think Tinderbox). > This could then be extended to match several patches against several > Versions. Last time I checked to compile it on SunOS it worked well with the sun cc, not sure why you want to use gcc instead. Also, note that there are some FLAGS in config.mk for SunOS. Kind regards, --Anselm
Re: [dwm] 5.4.1 - two issues with floating clients and borders
2009/2/14 Adam F : > hello all. I have run into two issues with the latest release. > > 1 - mplayer started keeping its borders (well, 2 of 4 - the top and > left border, if it matters) in full screen mode. If I move the window > around a few pixels I can get the normal fullscreen look. This happens > regardless of the tag of the terminal I am using, but I don't think it > should matter anyway since I set class "MPlayer" as always float in > config.h. I remember this was an issue a few years ago, but before > the latest release I havent had this problem with mplayer. > > 2 - regarding the new behavior of single windows - i.e. no borders > when only one client is in view, I observe the following: If I am > viewing an empty tag, which is float, and open a single terminal, it > opens to the default size (80x24 or whatever), and the borders are > displayed. However, If I am in tile mode viewing a single window, > then alt-f to floating mode, and resize the terminal, the boarders > stay invisible. The only way to get them to show up is to open > another client. I think the intuitive behavior would be for the > borders to show up upon the client being resized. > > Can anyone else confirm these issues? I am running 5.4.1 as on the > dwm page, and the only patch I use is bottomstack. I can confirm both issues and I'm working on several fixes. Kind regards, --Anselm
Re: [dwm] [PATCH] small fix in propertynotify
Thanks for these patches!
Kind regards,
Anselm
2009/2/12 Szabolcs Nagy :
> On 2/12/09, Peter Hartlich wrote:
>>> - if((ev->window == root) && (ev->atom = XA_WM_NAME))
>>> + if((ev->window == root) && (ev->atom == XA_WM_NAME))
>>
>> Why not remove the inner parens as well? Without them, gcc would have
>> noticed.
>
> yes, that's how i'd do (but in certain cases parents makes the code
> easier to read)
>
> now this is what i found in toggletag():
>
>if(!sel)
>return;
>
>mask = sel->tags ^ (arg->ui & TAGMASK);
> - if(sel && mask) {
> + if(mask) {
Re: [dwm] Virtual keyboards
Hi Peter, 2009/2/9 Peter Hartlich : >> It appears to me that both the onscreen keyboard and the client with >> the input focus should have a selfg border -- at least that makes most >> sense in my opinion. > > But you need to be able to distinguish between dwm's _selected_ (for > tagging, closing etc.) client and X's _focused_ client. Killing your > terminal window on accident could be awful. What's wrong with focussing the next in the stack? >> Introducing another couple just for that sounds quite over-engineered >> to me. > > Agreed. > > What I would propose is the attached series of patches for hg import: > The first renames focus() to selclient() and focusstack() to selstack(). > The second adds a new focus() function calling XSetInputFocus() and > saving the client in a global foc (analogue to sel) variable; it then > implements isfocusable based on the Gottox port + selfgcolor border > for focused, but unselected windows. Agreed, I'll apply your patches. > By the way, your last commits have "a...@null" as the author? I will address this. I'm using a fresh host. Kind regards, --Anselm
[dwm] dwm-5.4.1
Hi there, a bugfix release: http://code.suckless.org/dl/dwm/dwm-5.4.1.tar.gz Kind regards, --Anselm
Re: [dwm] dwm-5.4
Ok, I hope that's fixed in 5.4.1. Kind regards, Anselm 2009/2/8 Nibble : >> This release doesn't draw any borders around tiled clients if there is >> only 1 tiled client in the view. This saves some extra space of screen >> real estate for the application in use -- and provides a hint in >> monocle layout if there are more clients managed by dwm or not. > > Hi, > > I think this isn't working as expected, try the next scenario: > 1. We have a view with 2 tiled clients > 2. We toggle to floating layout one of them. So, we have a tiled > client with no border and a floating client with border. > 3. We toggle to floating layout the other one. And now, we have two > floating clients, one with border and one with no border. > > Maybe, number of visible clients should be used instead of number > of tiled clients when calling showhide(). > > Kind Regards, > Nibble
[dwm] dwm-5.4
Hi there, I'm glad to announce the new dwm-5.4 release which can be downloaded from: http://code.suckless.org/dl/dwm/dwm-5.4.tar.gz This release doesn't draw any borders around tiled clients if there is only 1 tiled client in the view. This saves some extra space of screen real estate for the application in use -- and provides a hint in monocle layout if there are more clients managed by dwm or not. Kind regards, --Anselm
Re: [dwm] Virtual keyboards
Hi Peter, 2009/1/31 Peter Hartlich : >> I like this patch and will apply it to 5.4 which is going to be >> released until the weekend. > > One problem with it is that you don't really know where keyboard input > will be going (dwm being focus-follows-mouse by default). I use another > patch on top of that (attached) to draw a selfgcolor border around the > last focusable window when an unfocusable window is selected, but I'm > not sure recycling selfgcolor is kosher... > > Plus you may want to rename focus() to selectwin() or something. I see. I think the whole unfocussable stuff needs further thinking before going mainstream. I'm going to release 5.4 now. It appears to me that both the onscreen keyboard and the client with the input focus should have a selfg border -- at least that makes most sense in my opinion. Introducing another couple just for that sounds quite over-engineered to me. >> I should get broadband today that I'll be ack online and can support >> questions regarding my upcoming st and libtg release. > > So, when's the st release and does libtg (if that's the name of the > not-completely-secret project) use XCB? :) Well, I changed my mind several times during the last weeks. When I get time I end up thinking that several decisions I made are wrong by nature... but I will come up with one way or another soon. I'm not too convinced libtg as it is (X abstraction primitives + text format processing + parts of text window abstractions and input handling) is the right way to go. I feel remembered at the wmii times, when wmii was screwed up due to depending on its 9P scripting interface. I believe I did the same journey with st making it dependent on libtg, and I tend to revert this mistake at the moment. Kind regards, --Anselm
Re: [dwm] Layers
2009/1/22 Matthias-Christian Ott : > Dwm has by default a floating and a tiled layer that can have a different > layout. Tiling or maximisation works fine for most clients (by the way, > is there are reason why windows are called clients in dwm jargon?), some > dialogs, popups or short-living windows require to be floating. Therefore > dwm keeps these windows on an upper layer. It's called client because it's a client of the window manager -- the terminology has been in use for ages in different WMs and been adopted by dwm for this legacy reason in order to increase the understanding by the reader (who might compare the code base with different WMs). > While this makes sense for most applications, there are some (Gimp is > as famous example for this) that are build around this WIMP concept and > thus have to be floating in order to usable. But sometimes it makes sense > to quickly hide them to access information hidden by them (for example > I use the dictionary programme Ding when writing E-Mails in English). > > A common approach would be to dedicate a tag to them and switch > via ALT+TAB back and forth. In my opinion this a bit cumbersome and > non-intuitive. I rather expect to rotate the two layers like I can do > with windows in monocle layout. Well, apart from the floating mode, I bind gimp to the dedicated tag "7" where I only assign broken apps with. Since all gimp windows are floating by the same rule, toggleview()'ing 1<<6 will do the trick without switching the layout. Kind regards, --Anselm
Re: [dwm] Virtual keyboards
Hi, I like this patch and will apply it to 5.4 which is going to be released until the weekend. I should get broadband today that I'll be back online and can support questions regarding my upcoming st and libtg release. Kind regards, Anselm 2009/1/22 Peter Hartlich : > Hi, > >> http://s01.de/~gottox/hg/dwm/rev/d3c3a8018349 > > A port of that + http://s01.de/~gottox/hg/dwm/rev/0c589f7247e6 > is attached. Thanks Gottox! > > Regards, > Peter
Re: [dwm] No Border Behaviour
2009/1/8 Matthias-Christian Ott : > I think, this doesn't make much sense. My proposed conception of borderless > clients seems more reasonable and intuitive to me. If you take borders not > as decoration (as some window manager do), but instead as separating > entities, that are used to distinguish windows, it makes sense to omit the > borders if only one particular window is visible, because they aren't > serving any purpose. In others words: borders are superfluous in that case. I think that is exactly how the current dwm implementation is supposed to be -- I never said anything different to that (at least not that I intended it). Kind regards, --Anselm
Re: [dwm] No Border Behaviour
Hi, 2008/12/22 Matthias-Christian Ott : > Yesterday I updated my dwm tree to tip and noticed that the borders were > removed (1376). This applies only to clients in tiled layout, is there > a reason why this behaviour is not present in monocle? It is present in monocle as well, if there is only 1 client. This makes the new behavior also an indicator for the monocle layout if there are more clients. > If no border indicates that there's just one client in the tag it makes > some sense, but I rather like borderless if there's only one client > visible. This seems more intuitive to me, because borders indicate a > separation which is only necessary when there is more than one client > visible. Yes, that's how it is supposed to be. Kind regards, --Anselm
Re: [dwm] dio-0.1.3
2009/1/4 Yoshi Rokuko : > On Fri, Jan 02, 2009 at 06:53:10PM +0100, yy wrote: >> I have been experimenting with user interfaces concepts lately. >> My first aim was a simple mp3 player. The code has been adapted later >> to do other tasks, and now it is some sort of generic list manager, >> where items can be played. It was initially based on dmenu-3.9 (that's >> the reason it is announced here), though it has evolved to be much >> more complicated (too much, actually). > > I like the idea. A while ago I was thinking about a xlib gui file-opener, > your `launcher' dio script reminds me on that ... > > It would be cool to have more nice xlib apps to create some sort of dwm > desktop, I have to try your stuff ;-) My still secret project is about the foundation for that -- a collection of libraries which should enable writing such apps, mainly window/event abstractions and a decent font API -- this is code which emerged from my st code base which is subject to be published soon as well. I was a little bit shocked, that yiyus went into a similiar direction already ;) But I'm in the middle of yet another move currently, so I will postpone any announcements, otherwise I won't be able to be of any support... Kind regards, --Anselm
Re: [dwm] Border hater, border lover
2008/12/15 Anselm R Garbe : > 2008/12/14 voltaic : >> It seems this idea was forgotten again, so I thought I would bring it >> up once more. As DWM 5.4 is being finalized and there is discussion on >> what to include in future versions, I'd love to see the >> no-border-if-single-window behavior become mainstream. > > Agreed, will push a patch accordingly during the day. It's in. Please recheck if there are any issues. Otherwise I'm going to release 5.4 tomorrow. Kind regards, --Anselm
Re: [dwm] [dmenu] help me test possibly faster dmenu_path
Neale, 2008/12/17 Neale Pickett : > I theorize that find outperforms for/test. Below are two shell scripts: > if you run the first one it will let you know the results of two runs. > The second one is a modified dmenu_run that uses find. I'd appreciate > it if people would run the first one and mail the results to me. I'll > let the list know what the results are. Similiar tests have been done a while ago, however we decided for the shell-only version for various reasons. First of all you are referring to GNU find as far as I can tell, however the BSD find is slightly different (same applies to Solaris), then there was an issue with softlink following and something else which resulted in displaying executables which were not intended to show up, the refresh testing and maybe another issue I don't remember right now (it's all in the mail archive somewhere). Of course find is faster, however I don't intend to change the shell only solution since we got cached results... Kind regards, --Anselm
Re: [dwm] C-version of dwm status (no xsetroot needed)
Guillaume, hg tip contains Neale's x property based status feed approach which I agree with after some thought. I think there are no open issues anymore and no need for popen, SIGALRM and spawn2 etc. Try it, I'm going to do a new release tomorrow. Kind regards, Anselm 2008/12/16 Guillaume Quintin : > On Tue, 16 Dec 2008 12:38:17 -0500 > Jeremy Jay wrote: > >> Here's some simple C code I wrote to handle setting the >> xprop without using xsetroot. At the moment it just >> spawns the same shell scripts I used before, but it may >> be useful for those having issues with xsetroot... >> >> If anyone is interested, this is the beginings of a >> libnotify-aware status script :) >> >> Jeremy > > Hi, > > IMHO it is too complicated. Moreover that's exactly the solution > I proposed some days ago but mine was simplier and within dwm.c. This > will not satisfy Donald Chai : > > Donald Chai wrote in a previous post : > My status text includes the weather (updated only every 15min to > avoid hammering their servers), and the time (updated once a minute, > on the minute, to reduce my wakeups-per-second in PowerTOP). For me, > this SIGALRM and spawn2 would require that I store some temporary > data somewhere between invocations. > > Anselm, if you don't like popen, then take Jeremy's runScript function. > > Neale Pickett, where are you in your investigations ? Could be X the > problem ? > > -- > Kind regards, > Guillaume Quintin.
Re: [dwm] xsetroot/status scripting using rc shell?
Try
text=`{date}^" "^`{uptime}
xsetroot -name $"text
Kind regards,
Anselm
2008/12/16 Michael Brown :
> These work:
> xsetroot -name test
> xsetroot -name `{echo test}
>
> These don't:
> xsetroot -name `{date}
> xsetroot -name `{echo test test}
> xsetroot -name `{echo 'test test'}
> xsetroot -name (`{echo test test})
>
> Seems the problem has something to do with xsetroot's whitespace handling...
>
> Mike
>
> On Mon, Dec 15, 2008 at 3:15 AM, Anselm R Garbe wrote:
>> 2008/12/14 Michael Brown :
>>> Maybe a silly question, but is any p9p user out there able to set the
>>> statusbar text with xsetroot using rc(1)?
>>
>> Did you check if
>>
>> xsetroot -name foobar
>>
>> works at all? If not something might be wrong with the DISPLAY variable.
>>
>>> The following don't seem to work:
>>> xsetroot -name `{SCRIPT}
>>> xsetroot -name "`{SCRIPT}"
>>> xsetroot -name "(`{SCRIPT})"
>>
>> The first one is correct. Try something like
>>
>> xsetroot -name `{date}^" "^`{uptime}
>>
>> for example.
>>
>> Kind regards,
>> --Anselm
Re: [dwm] xsetroot/status scripting using rc shell?
2008/12/14 Michael Brown :
> Maybe a silly question, but is any p9p user out there able to set the
> statusbar text with xsetroot using rc(1)?
Did you check if
xsetroot -name foobar
works at all? If not something might be wrong with the DISPLAY variable.
> The following don't seem to work:
> xsetroot -name `{SCRIPT}
> xsetroot -name "`{SCRIPT}"
> xsetroot -name "(`{SCRIPT})"
The first one is correct. Try something like
xsetroot -name `{date}^" "^`{uptime}
for example.
Kind regards,
--Anselm
Re: [dwm] Border hater, border lover
2008/12/14 voltaic : > It seems this idea was forgotten again, so I thought I would bring it > up once more. As DWM 5.4 is being finalized and there is discussion on > what to include in future versions, I'd love to see the > no-border-if-single-window behavior become mainstream. Agreed, will push a patch accordingly during the day. Kind regards, --Anselm
[dwm] 25c3
Hi there, I'll be around from Dec 27 late night to Dec 28 late night at 25c3 in Berlin this year only. Let me know if you are around as well through editing the scklss wiki entry of the 25c3 wiki at: http://events.ccc.de/congress/2008/wiki/Scklss I'd also like to see some guys willing to escape from the BCC in order to get some drinks in some nice bar... I plan a lightning talk on the 28/12 in the morning about st and the secret project... so if you arrive late we could meet there as well. I haven't reserved any space in the hack center unfortunately. But usually there is enough space to hang around anyways. Kind regards, --Anselm
Re: [dwm] Re: dwm-5.4 stdin; cycle tags
2008/12/13 henry atting : >> 2008/12/13 henry atting : >> The tagging approach didn't change between 5.2 and 5.4, so I assume >> it's just a matter of making the 5.2 patch applying to the 5.4 >> codebase. > > Mmh, I am not very familiar with patching, I did it this way: > > , > | do! patch -p1 < dwm-5.2-arrownav.diff > | missing header for unified diff at line 3 of patch > | can't find file to patch at input line 3 > | Perhaps you used the wrong -p or --strip option? > | The text leading up to this was: > | -- > | |--- config.def.h Tue Sep 9 15:46:17 2008 > | |+++ config.def.h Tue Nov 18 19:26:53 2008 > | -- > | File to patch: config.def.h > | patching file config.def.h > | Hunk #1 succeeded at 62 (offset 1 line). > | missing header for unified diff at line 14 of patch > | can't find file to patch at input line 14 > | Perhaps you used the wrong -p or --strip option? > | The text leading up to this was: > | -- > | |--- dwm.c Tue Sep 9 15:46:17 2008 > | |+++ dwm.c Tue Nov 18 19:31:55 2008 > | -- > | File to patch: dwm.c > | patching file dwm.c > | Hunk #1 succeeded at 197 (offset -1 lines). > | Hunk #2 FAILED at 1668. > | 1 out of 2 hunks FAILED -- saving rejects to file dwm.c.rej > ` Well as I said, you will need to patch it manually, since the lines have changed and the heuristic approach supported by patch(1) isn't succeeding either. Kind regards, --Anselm
Re: [dwm] dwm-5.4 stdin; cycle tags
2008/12/13 henry atting : > - A `make clean install' does install dwm but it cannot read from stdin > which prevents me from displaying time and date on the toolbar. > >config.h:15: warning: 'readin' defined but not used See the README file for an example, the status text is set using xsetroot(1) now. > - I found a patch for cycling through tags in this group but it is for > dwm-5.2 and apparently does not work for 5.4. How can I set up cycling > through tags for 5.4? The tagging approach didn't change between 5.2 and 5.4, so I assume it's just a matter of making the 5.2 patch applying to the 5.4 codebase. Kind regards, --Anselm
Re: [dwm] dwm on tablet pc
2008/12/12 : >> Try dwm-gtx. Onscreenkeyboards should work with it. :) > Thanks for the hint. I tried your version of dwm, and cellwriter works. > What is the essential part for this to work? > > Getting cw to work is the first step. I also tried the mouse > actions for the bar, which are already implemented in dwm, but > especially those with MODKEY do not work in conjunction with cw. There > would still be much work to do regarding a clickable bar and of course > a clickable version of dmenu for application launching. > > @yy: Emulating a 5 buttons mouse would only be possible by implementing > onscreen buttons, I think, causing a similar amount of work. > > I am not a c programmer - writing a small patch is possible, but not > more - I am more a "script kiddie" ;-) Atm I am using openbox and > fbpanel, but I am missing dynamic tiling. Of course there are "tile" > and "whaw", but they are not sufficient for me. I will try to get it > working with devilspie executing a perl script and issuing wmctrl. I think for tablet pcs, there must be a less suckish onscreen keyboard with some extensions which allow integration with dwm, wether as patch of dwm.c (which would be the easiest since it doesnt require any additional communication between dwm and a some kind of a input event client) or as external app using some x property to communicate with dwm. In a first attempt this should be a patch however. Kind regards, --Anselm
Re: [dwm] dwm-5.3
2008/12/13 Frederic Chardon : > 2008/12/13 James Turner : >> After taking some time and looking at the different signal headers on >> OpenBSD only #include is required, no need to #include >> which contains additional functions. > > Same for FreeBSD (and probably all other *BSD). Would it be possible > to include this one line mainstream? > Fred Yes, will do that. Kind regards, --Anselm
[dwm] plan for dwm
Hi, here is the plan: slock-1.1 will be released soon containing Ali's patch with some minor modifications. dwm-5.4 will also be released soon containing the transition patch with the proposed x property based status reporting, and Neale's spawn patch again, and possibly some other minor patches ;) After that 5.5 could contain a more advanced approach for multihead support (though I think I need to investigate further and experiment more into this direction, before agreeing on the final approach). It should also contain a cleaned up usage of the HEIGHT/WIDTH macros besides the reduction of the ugly "2 * c->bw" occurrences throughout the code (I plan to move these border deductions to resize). Then there will be something else soon as well... Kind regards, --Anselm
Re: [dwm] dwm and dualhead
Hi, I tried different multihead approaches in between 4.9 and 5.1 with dwm. I remember the following: - have a dwm environment on each Xinerama screen (like multiple dwm's in classic multihead setups) as suggested by Mate -> the problem was, it didn't felt right because it added another navigation layer on top of dwm, to basically navigate through screens and to move clients between screens, the conclusion was, if you really want this, run multiple instances of dwm with a classic multihead setup - make layout algorithms use more screens (keep the bar at a specific "main screen") -> the problem was, that it doesn't scale well, most layout algorithms aren't designed for multihead setups, esp. if the screens have different geometries - split the tags into n distinct tagsets (1 for each screen) and use the existing tagging concept for focussing/moving clients between different screens using tagging, display the status bar on the screen with the focussed client (or some arbitrary fallback if there are no clients) -> I think that was my favorit approach, so the main drawback was that it made dwm significantly more complex and that there needs to be some kind of setup option which tells which tag belongs to which screen, so the intermediate approach was having a tag struct with a screen index -> but hell taht sucked - use the screen with the pointer as default screen where the bar is presented and the layout algorithms happen, use all other screens for floating clients -> this is the current approach Also, the main question remains, how many multihead users are there? The main argument for the last approach was, if there are only 10% of multihead users, why should all single head/laptop users suffer from the unnecessary complexity? dwm's current Xinerama support isn't worse than the Xinerama support in any major desktop environment, but it is not very smart compared to other tiling WMs. Kind regards, --Anselm
Re: [dwm] dwm and dualhead
2008/12/10 Mate Nagy <[EMAIL PROTECTED]>: > The lesson I learnt from this: I will never buy a laptop with integrated > intel graphics again. Which laptop model is to blame? ;) Kind regards, --Anselm
Re: [dwm] dwm and dualhead
2008/12/10 Johannes Wegener <[EMAIL PROTECTED]>: > Hi, > is there anybody who has experience with dwm and dualhead setups? I > tried to use dwm with a xrandr dualhead but it seemed quite useless becouse I > could just drag floating windows into the second screen. Xinerama seems > no more supported by xorg 7.4 and the intel driver. > > So my question are do you plan to put xrandr support into dwm? or has > anybody a hack/workaround for that problem? Seems that XRandR support in dwm is becoming a requirement soon, unfortunately. I wonder which X morons are to blame for dropping Xinerama completely... I think the whole X.org crowd is totally misled by dodgy desktop environment communities... Hopefully I will find some sponsor to fund a from-scratch X server and X lib reimplementation which does multihead without any quirks and hacks like XRandR... and which provides a decent font interface to begin with. Kind regards, Anselm
Re: [dwm] applyrules()
2008/12/6 yy <[EMAIL PROTECTED]>:
> Great 5.3.1 release!
>
> What about this little change in applyrules?
> @@ -259,7 +259,7 @@
>&& (!r->class || (ch.res_class &&
> strstr(ch.res_class, r->class)))
>&& (!r->instance || (ch.res_name &&
> strstr(ch.res_name, r->instance {
>c->isfloating = r->isfloating;
> - c->tags |= r->tags & TAGMASK;
> + c->tags |= r->tags & TAGMASK ? r->tags
> & TAGMASK : tagset[seltags];
>}
>}
>if(ch.res_class)
>
> This way you can define rules like:
>{ "MPlayer",NULL, NULL, 0,True },
>{ "MPlayer",NULL, NULL, 1 << 6, True },
> and have mplayer tagged to the currently selected tags and to the 6th
> tag, for example. This trick is very convenient to group windows by
> categories, I do it with image viewers, music players... and I think
> it makes clearer the rules definition. With the current
> implementation, if r->tags is 0 the result of applying that rule is
> undefined depending on the previous rules. The only problem I can see
> is that somebody could be doing:
>{ NULL, NULL, NULL, 0,True },
> to treat new windows like float by default, by I doubt there's anybody
> here doing such a thing...
> - yiyus || JGL .
I see the use and won't worry to much about this corner case. I
consider making this mainstream as well.
Kind regards,
--Anselm
Re: [dwm] xprop patch
2008/12/9 Neale Pickett <[EMAIL PROTECTED]>: > I very much like this patch. I realized right away that I would never > again need to restart dwm when I work on my status script. When it > dies, I can just start it up again without restarting DWM. Someone > could even have multiple programs running to update the status text. It > removes the need for the "readin" variable: you either set the property > or you don't. I dislike X properties, however I like your patch a lot and consider it making mainstream, since it simplifies dwm a lot and fixes a lot of issues. dwm depends on X anyways, so for the status text mechanism to happen, it's the simpler method. > This would be 40 if the property were hard coded to XA_WM_NAME. I left > in a comment to use a property named "DWM_STATUS" instead of XA_WM_NAME, > so people could play with it easily, but I think XA_WM_NAME is > ultimately the right way to do it. XA_WM_NAME is the way to go. Kind regards, --Anselm
Re: [dwm] xprop patch
2008/12/9 Benoit T <[EMAIL PROTECTED]>: > On Tue, Dec 09, 2008 at 10:41:35AM -0700, Neale Pickett wrote: >> I very much like this patch. I realized right away that I would never >> again need to restart dwm when I work on my status script. When it >> dies, I can just start it up again without restarting DWM. Someone >> could even have multiple programs running to update the status text. It >> removes the need for the "readin" variable: you either set the property >> or you don't. >> >> The patch removes 39 SLOC: > > gotta admit Neale has 2 points :) > > i like the idea of not having to restart dwm when hacking on the status > script > > conversely, when hacking on dwm itself, i like being able to restart dwm > without restarting my x session, yet i want the session to exit when dwm > exits, ie. "dwm & xterm" in .xsession is not what i want. > > here is a "respawn" patch. it is most useful in conjunction with a > "local install" in the makefile, copying the newly built dwm binary over > the currently running one, inside my $HOME rather than in /usr/local > > the patch costs 5 loc in the source + 1 loc in config.h > the patch is not completely portable due to use of ``environ''. i hope > that even the BSDs have that nowadays, but probably not through defining > _GNU_SOURCE, which is glibc specific. If you consider that Neale's patch makes it upstream, what do you think about: while true do dwm done in .xinitrc to restart dwm? Kind regards, --Anselm
Re: [dwm] [slock] slock doesn't like to deactivate after password entry
2008/12/9 Ali Gholami Rudi <[EMAIL PROTECTED]>:
> On Mon, Dec 08, 2008 at 04:00:48PM -0800, Thayer Williams wrote:
>> I've been using slock for about two months now and, as per the
>> subject, slock doesn't release my screen right away after a valid
>> password entry. After inputing the password and pressing Enter, the
>> screen remains blanked and no amount of input brings it up. I can
>> actually see the LCD backlight flicking on and off with each
>> subsequent keypress or mouse wiggle.
>
> I don't know how to handle others, but I use this patch for handling the
> flickering problem. AFAIK turning a lamp on and off excessively
> decreases its lifetime; that might be true for displays, too.
>
> Regards,
> Ali
>
> diff --git a/slock.c b/slock.c
> --- a/slock.c
> +++ b/slock.c
> @@ -79,6 +79,7 @@
>XColor black, dummy;
>XEvent ev;
>XSetWindowAttributes wa;
> + CARD16 standby, suspend, off;
>
> if((argc == 2) && !strcmp("-v", argv[1]))
>die("slock-"VERSION", (c) 2006-2008 Anselm R Garbe\n");
> @@ -123,12 +124,14 @@
>len = 0;
>XSync(dpy, False);
>
> + /* save and customize DPMS settings */
> + if (DPMSCapable(dpy)) {
> + DPMSGetTimeouts(dpy, &standby, &suspend, &off);
> + DPMSSetTimeouts(dpy, 10, 30, 90);
> + }
> +
>/* main event loop */
>while(running && !XNextEvent(dpy, &ev)) {
> - if(len == 0 && DPMSCapable(dpy)) {
> - DPMSEnable(dpy);
> - DPMSForceLevel(dpy, DPMSModeOff);
> - }
>if(ev.type == KeyPress) {
>buf[0] = 0;
>num = XLookupString(&ev.xkey, buf, sizeof buf, &ksym,
> 0);
> @@ -170,6 +173,10 @@
>}
>}
>}
> + /* restore DPMS settings */
> + if (DPMSCapable(dpy)) {
> + DPMSSetTimeouts(dpy, standby, suspend, off);
> + }
>XUngrabPointer(dpy, CurrentTime);
>XFreePixmap(dpy, pmap);
>XDestroyWindow(dpy, w);
I agree, I consider this going upstream Ali!
Kind regards,
--Anselm
Re: [dwm] dwm-5.3
2008/12/7 Neale Pickett <[EMAIL PROTECTED]>: > Guillaume Quintin <[EMAIL PROTECTED]> writes: > >> But now, when I reinstall dwm-5.2 I get the same problem than in >> dwm-5.3 and dwm-5.3.1, "double-fork", "simple-fork" and >> re-"double-fork". I don't understand why. > > This makes me happy, not only because my spawn function wasn't the > problem, but also because I can feel again like I know how Unix works :) > > I now think it is the open file descriptor causing the problem. The > SIGCHLD or double-fork would both cause this behavior; the problem is > that the shell running .xinitrc is waiting for an EOF on the pipe it > created for STD(IN|OUT|ERR), and is never getting it because you still > have some X clients with it open. Afair running exec dwmstatus in .xinitrc should delegate this issue to dwmstatus, because the problem of running some loop | dwm in .xinitrc existed since the very first dwm version and there is no real solution to this problem unless the feed process is replaced by something more appropriate which uses a fifo redirection. > I advise against closing STDOUT or STDERR in the spawn function: that's > how error messages make it in to .xsession-errors. So far it was only about closing stdin. I don't like the alternatives very much, I dislike popen() some status feed process, or creating a fifo, or reading from some status text file, or using X properties (like larsremote). Reading from stdin in dwm is the simpliest and most elegant solution imho. Kind regards, --Anselm
Re: [dwm] DWM 5.3.1 and Xinerama
2008/12/7 Amit Uttamchandani <[EMAIL PROTECTED]>: > Sorry to bother with this question > > I have been using DWM for a year or so now but never needed to connect > my laptop to a projector till today. I realized I had no idea how to do > this with DWM. > > After some research I found that DWM uses Xinerama and not xrandr. I got > as far as compiling DWM with Xinerema support and then getting lost. Isn't Xinerama a legacy API which is glued with XrandR in recent X.Org builds? At least that was my impression. > What's the next step? I plan to put a how to in the DWM page once I get > this up an running. If dwm has been build with Xinerama support it will use the screen which contains the pointer as "default" screen when it starts. The "default" screen will be used to display the bar and to apply all layout algorithms. All other screens can only be used for floating clients. That's how it is supposed to behave in vanilla dwm. HTH, --Anselm
Re: [dwm] dwm-5.3
2008/12/6 Jeremy Jay <[EMAIL PROTECTED]>: > This was my hunch too, glad someone got it before me though. This > patch fixes the problem with 5.3. Probably the same with the double- > fork version too. Glad you investigated further ;) I will test this and wait some days, looks like there will be some 5.3.2 soon ;) Kind regards, --Anselm
Re: [dwm] Re: urgent windows border
2008/12/6 yy <[EMAIL PROTECTED]>: > 2008/12/6 yy <[EMAIL PROTECTED]>: >> There is little error here. It is not working as expected in 5.3.1. >> This patch fixes it. > > Be care if you apply this, I forgot to remove my PREFIX (which is > /usr) in config.mk Thanks, applied. I'll wait for other issues first before making a new micro release. Kind regards, --Anselm
[dwm] dwm-5.3.1
Hi, the bugfix release can be found at http://code.suckless.org/dl/dwm/dwm-5.3.1.tar.gz It includes a reverted spawn function. Sorry for any inconvenience. Kind regards, Anselm 2008/12/4 Anselm R Garbe <[EMAIL PROTECTED]>: > Hi, > > there was some silence during the last weeks, simply because I am/was > rather busy but also because I'm working on a secret surprise project > (yes it's st related). But I won't tell anything about it yet -- I > hope to disclose the details at 25C3 in Berlin in a couple of weeks ;) > > Anyway, it's time for a new dwm release, you can fetch it from > > http://code.suckless.org/dl/dwm/dwm-5.3.tar.gz > > This release contains the spawn() version of Neale and several > bugfixes regarding the NOBORDER handling in 5.2, and a new config.h > option which allows to set use server grabs during mouse based > resizals/movements. > > Let me know any issues. > > Kind regards, > --Anselm
Re: [dwm] dwm-5.3
I reverted the old spawn in the 5.3.1 release I'm currently uploading, until this issue gets sorted. But this proofs again never change a running system, especially I believe we experienced exactly the same 4 years ago when we switched back and forth to double-forks and signal handlers. Unix is a mess... ;) Kind regards, Anselm 2008/12/5 Guillaume Quintin <[EMAIL PROTECTED]>: > On Fri, 5 Dec 2008 15:52:26 +0100 > yy <[EMAIL PROTECTED]> wrote: > >> 2008/12/5 Guillaume Quintin <[EMAIL PROTECTED]>: >> > On Fri, 5 Dec 2008 08:33:44 + >> > >> > Here is my .xinitrc : >> > >> > while true >> > do >> >echo `date` >> >sleep 1 >> > done | dwm >> > >> >> A bit off-topic, but, why the echo? A simple date should do it. >> > > Yes a simple date makes it. > > -- > Kind regards, > Guillaume Quintin.
Re: [dwm] Re: urgent windows border
2008/12/4 yy <[EMAIL PROTECTED]>: > 2008/12/4 Anselm R Garbe <[EMAIL PROTECTED]>: >> I have mixed feelings about this patch. Does someone has strong >> arguments that this would be a good idea for upstream dwm? >> > > I also have mixed feelings... I wrote it because I didn't see urgent > windows when they were visible (I know this sentence looks stupid, I > know, but you get it), and since the implementation resulted simpler I > decided to post it here. > There is another middle-way solution which you could be interested in: > move the clearurgent() call to focus(), like in my patch, but forget > about the urgent border color (which is what makes the patch uglier). > This way, you could save some loc while getting the functionality of > notifying urgent clients in viewed tags. If you have no time or > whatever I can modify my patch and send it to the list tomorrow. > OTOH, I will probably maintain the patch for the border color, at > least for the moment. But I won't post it here or anything if nobody > else is interested. Yes, I did something similiar for the 5.3.1 bugfix release I'm currently uploading. Kind regards, --Anselm
Re: [dwm] patch for colored status text
What about adding this patch to the wiki?
Kind regards,
Anselm
2008/12/4 Jeremy Jay <[EMAIL PROTECTED]>:
> Another simple patch for anyone interested. Changes the way colors are
> defined slighty, allowing you to create more color combinations. Then,
> to color the status text from stdin you can simply use the color combo # as
> follows:
>
> echo -e "\x03 warning low battery" -- will be printed with the third color
> combo
> echo -e "\x04 danger will robinson" -- will be printed with the fourth color
> combo
> echo -e " normal text \x03 warning \x04 error \x01 normal again"
>
> For example, my colors in config.h are:
>#define NUMCOLORS 4
>static const char colors[NUMCOLORS][ColLast][8] = {
> // border foreground background
> { "#33", "#dd", "#33" }, // normal
> { "#88", "#ff", "#88" }, // selected
> { "#ff", "#00", "#00" }, // urgent/warning (black on
> yellow)
> { "#ff", "#ff", "#ff" }, // error (white on red)
> // add more here
>};
>
> Which, coupled with my own status script results in things like the attached
> image.
>
> Hope someone else finds this handy, I let my battery die one too many
> times because I never noticed how low it was...
>
> Jeremy
Re: [dwm] Using dwm as a nested manager?
2008/12/6 Jorge Vargas <[EMAIL PROTECTED]>: > Hi, I have been thinking about this for some time, and I like dwm a > lot but I don't like it to manage all my windows, so I was wondering > if it's possible to nest it inside another manager and tell it to > handle only some windows? Please note I used this a long time ago in > the 2.x releases so I'm not familiar with the codebase anymore. You could use Xnest(1) in order to run dwm in a nested sense. However what do you miss in dwm that you don't like to manage all windows? Kind regards, --Anselm
Re: [dwm] dwm-5.3
2008/12/5 James Turner <[EMAIL PROTECTED]>: >> Great! Thank you for dwm-5.3. I think that it's needed to #include >> , infact without it I couldn't compile on NetBSD. > > #include is also required on OpenBSD. Oh yes, I missed that. I will re-issue dwm-5.3.1 with this fix tonight. Kind regards, --Anselm
Re: [dwm] dwm-5.3
2008/12/5 Neale Pickett <[EMAIL PROTECTED]>: > Neale Pickett <[EMAIL PROTECTED]> writes: > >> Would you mind sharing how you launch dwm? > > It might also be helpful to share your status script. If you launch > your status script like this: > > status | dwm > > and status forks, the parent may not be exiting. > > If the status program never exits, X won't terminate when you kill dwm. > To test if yours operates this way, try the following experiment: > > xterm1$ status | cat > xterm2$ kill (pid of cat) > > My status program at least keeps on running even though it can no longer > write to stdout. I think it's because the parent shell, the one outside > the loop, never gets the SIGPIPE and keeps on running. I'll play with > it and report back. > > This problem isn't related to the recent fork patch, tough; you can > reproduce this behavior without ever calling spawn. > > The reason this doesn't stop X is because your .xsession (or .xinitrc) > is waiting for all subprocesses to exit. As long as status keeps > running, .xsession won't exit, and the X server startup script won't > kill the X server. > > Here's something you can put in .xsession to run status as a background > process and cause your .xsession to exit when dwm exits: > > XSTATUS=$HOME/.status.$(hostname).$DISPLAY > mkfifo -m 600 $XSTATUS > status > $XSTATUS & > STATUS_PID=$! > dwm < $XSTATUS > kill $STATUS_PID > rm $XSTATUS I also think this is rather related to the status feed. Kind regards, --Anselm
[dwm] dwm-5.3
Hi, there was some silence during the last weeks, simply because I am/was rather busy but also because I'm working on a secret surprise project (yes it's st related). But I won't tell anything about it yet -- I hope to disclose the details at 25C3 in Berlin in a couple of weeks ;) Anyway, it's time for a new dwm release, you can fetch it from http://code.suckless.org/dl/dwm/dwm-5.3.tar.gz This release contains the spawn() version of Neale and several bugfixes regarding the NOBORDER handling in 5.2, and a new config.h option which allows to set use server grabs during mouse based resizals/movements. Let me know any issues. Kind regards, --Anselm
Re: [dwm] Re: urgent windows border
2008/11/29 yy <[EMAIL PROTECTED]>: > It had a bug. We don't want to set as urgent the sel client. Sorry for > the noise. I have mixed feelings about this patch. Does someone has strong arguments that this would be a good idea for upstream dwm? Kind regards, --Anselm
Re: [dwm] patch to not reparent children to init
Applied in hg tip, thanks Neale!
2008/11/4 Neale Pickett <[EMAIL PROTECTED]>:
> Reparenting everything to init with the double-fork is a nightmare on a
> many-user machine, especially when I'm logged in more than once. pstree
> becomes useless. This sets up a SIGCHLD handler and only forks once.
> Adds 2 SLOC, but surely there's some reason the double-fork is there that
> I'm just missing...
>
> void
> sigchld(int signal)
> {
> while (0 < waitpid(-1, NULL, WNOHANG));
> }
>
> void
> spawn(const Arg *arg)
> {
> signal(SIGCHLD, sigchld);
> if (fork() == 0) {
>if (dpy) close(ConnectionNumber(dpy));
>setsid();
>execvp(((char **)arg->v)[0], (char **)arg->v);
>fprintf(stderr, "dwm: execvp %s", ((char **)arg->v)[0]);
>perror(" failed");
>exit(0);
> }
> }
