Re: [dwm] nanox
Hi pancake, 2009/5/19 pancake panc...@youterm.com: 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=9833t=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] nanox
2009/5/20 Jacob Todd jaketodd...@gmail.com: 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] 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 mei...@marmaro.de: [2009-05-20 08:35] Uriel urie...@gmail.com 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
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 garb...@gmail.com: 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 mei...@marmaro.de: [2009-05-20 08:35] Uriel urie...@gmail.com 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
Hi, 2009/5/20 Szabolcs Nagy nszabo...@gmail.com: On 5/20/09, Anselm R Garbe garb...@gmail.com 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
2009/5/20 Premysl Hruby dfe...@gmail.com: On (20/05/09 10:04), Anselm R Garbe wrote: To: dwm mail list dwm@suckless.org, wmii mail list w...@suckless.org From: Anselm R Garbe garb...@gmail.com Subject: Re: [dwm] Re: New mailing list Reply-To: dwm mail list dwm@suckless.org List-Id: dwm mail list dwm.suckless.org 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
2009/5/20 yy yiyu@gmail.com: 2009/5/20 Szabolcs Nagy nszabo...@gmail.com: On 5/20/09, Anselm R Garbe garb...@gmail.com 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 Uriel urie...@gmail.com: 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] Irc channel moved
2009/5/20 Dusan ef_...@yahoo.com: #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] musca wm
2009/5/15 pancake panc...@youterm.com: 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] musca wm
2009/5/15 pancake panc...@youterm.com: 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] dwm status bar..
2009/4/30 Wu, Yue vano...@gmail.com: On Wed, Apr 29, 2009 at 10:08:09PM -0700, Scytrin dai Kinthra wrote: use `xsetroot -name status` 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
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/28 pmarin pacog...@gmail.com: 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
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/27 Preben Randhol rand...@pvv.org: On Sun, 26 Apr 2009 11:11:03 +0100 Anselm R Garbe garb...@gmail.com 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
Hi, 2009/4/26 Szabolcs Nagy nszabo...@gmail.com: On 4/26/09, Christian Garbs mi...@cgarbs.de wrote: On Sat, Apr 25, 2009 at 11:06:08PM +0100, Szabolcs Nagy wrote: On 4/25/09, Christian Garbs mi...@cgarbs.de 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/26 Szabolcs Nagy nszabo...@gmail.com: On 4/25/09, Anselm R Garbe garb...@gmail.com 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
[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] dwm's future
2009/4/25 yy yiyu@gmail.com: 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
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 m...@brain-dump.org: 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
Re: [dwm] Replacing slock screen overlay with screenshot / bitmap
2009/4/18 Jan Blazek appoli...@gmail.com 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 wen1...@gmail.com: 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 appoli...@gmail.com:
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 niklas.ih...@gmail.com: 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 tinou...@gmail.com: 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
[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] autoconf
2009/3/19 bill lam cbill@gmail.com: - 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] 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 cbill@gmail.com: 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] Gaps
2009/3/13 anonymous anonym...@id.ru: 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] 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 urie...@gmail.com: 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, sta...@cs.tu-berlin.de wrote: * markus schnalke mei...@marmaro.de [2009-03-11 16:42]: [2009-03-11 16:10] yy yiyu@gmail.com 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] suckless.org stylesheet glitch
2009/3/13 Uriel urie...@gmail.com: 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] suckless.org stylesheet glitch
2009/3/11 pmarin pacog...@gmail.com: 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/11 twfb twf...@googlemail.com: 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] wiki location changed
2009/3/9 Uriel urie...@gmail.com: 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
Re: [dwm] C unit testing
2009/3/10 Richard Pöttler richard.poett...@gmail.com: 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 assert.h ;) 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
[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 c...@gmx.ch: 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 cont...@ikhider.com: 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 o...@mirix.org: 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
[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/19 Matthias-Christian Ott o...@mirix.org: 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
Re: [dwm] [OT] Personal Website and CSS
2009/2/18 Matthias-Christian Ott o...@mirix.org: 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 dele...@gmx.net: 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] Virtual keyboards
Hi Peter, 2009/2/9 Peter Hartlich sg...@hartlich.com: 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
Re: [dwm] Virtual keyboards
Hi Peter, 2009/1/31 Peter Hartlich sg...@hartlich.com: 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
[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] dwm-5.4
Ok, I hope that's fixed in 5.4.1. Kind regards, Anselm 2009/2/8 Nibble nibble...@gmail.com: 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.1
Hi there, a bugfix release: http://code.suckless.org/dl/dwm/dwm-5.4.1.tar.gz 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 sg...@hartlich.com: 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] Layers
2009/1/22 Matthias-Christian Ott o...@mirix.org: 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 16 will do the trick without switching the layout. Kind regards, --Anselm
Re: [dwm] No Border Behaviour
Hi, 2008/12/22 Matthias-Christian Ott o...@mirix.org: 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 yoshi.rok...@yokuts.org: 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] [dmenu] help me test possibly faster dmenu_path
Neale, 2008/12/17 Neale Pickett ne...@woozle.org: 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] Border hater, border lover
2008/12/15 Anselm R Garbe garb...@gmail.com: 2008/12/14 voltaic volt...@gmail.com: 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] xsetroot/status scripting using rc shell?
Try
text=`{date}^ ^`{uptime}
xsetroot -name $text
Kind regards,
Anselm
2008/12/16 Michael Brown ebeb...@gmail.com:
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 garb...@gmail.com wrote:
2008/12/14 Michael Brown ebeb...@gmail.com:
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 ebeb...@gmail.com:
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
[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] Border hater, border lover
2008/12/14 voltaic volt...@gmail.com: 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
Re: [dwm] dwm-5.3
2008/12/13 Frederic Chardon chardon.frede...@gmail.com: 2008/12/13 James Turner ja...@bsdgroup.org: After taking some time and looking at the different signal headers on OpenBSD only #include sys/signal.h is required, no need to #include signal.h 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
Re: [dwm] dwm on tablet pc
2008/12/12 jo...@freenet.de: 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.4 stdin; cycle tags
2008/12/13 henry atting nspm...@literaturlatenight.de: - 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] Re: dwm-5.4 stdin; cycle tags
2008/12/13 henry atting nspm...@literaturlatenight.de: 2008/12/13 henry atting nspm...@literaturlatenight.de: 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
[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 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] 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] 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] 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] 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] 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/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] 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] 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] 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] 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.
[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] 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
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] 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
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 signal.h, infact without it I couldn't compile on NetBSD. #include signal.h 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] slock dialog behavior
Thanks for reporting this, I currently try to reproduce and fix this. Kind regards, Anselm 2008/11/29 list subscriber [EMAIL PROTECTED]: Hello, It seems as though some variation of a previous dialog bug (http://lists.suckless.org/dwm/0711/4361.html) still exists. I was able to reproduce the behavior with dwm and twm. In the first case I am able to regain control to the window manager, but in the second case X must be restarted. cat t.sh #!/bin/bash firefox PID=$! sleep 3 kill -9 $PID # 1. slock drops back to wm and all windows are visible until an input event # (key press/mouse event) in which case it blanks again and it behaves as # normal slock firefox # 2. just flashes to wm on an input event but doesn't allow entering password # Warning! I was unable to unlock the display and had to restart X :EOF while :; do [[ `xlsclients | grep firefox` ]] slock done EOF Thanks
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);
}
}
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
[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] make setlayout toggle
2008/11/20 Claudio M. Alessi [EMAIL PROTECTED]: On Wed, Nov 05, 2008 at 09:39:58AM +, Anselm R Garbe wrote: Ok, are there any concerns making this upstream again? (Yes I know, we had this already in earlier versions, by that time it was called togglelayout())... There were reasons for not toggling, basically it was confusing to toggle the layout after a long period of time, because one forgets about what the previous layout was. You shouldn't care about the previous layout, it's not a memory game. Users change layouts once they need it, then use another layout in order to fit their new needs and so forth. Changing the layout is not an hard task, i think. I already have some feature i never use but i wouldn't make a dwm-lite release. Please add only real useful code :-) Am I right that you are against re-adding the toggle? Kind regards, Anselm
Re: [dwm] OT : suckless foreign function interface
Hi Fernan, 2008/11/15 Fernan Bolando [EMAIL PROTECTED]: 1. Generate small C programs and call them via system() inside the scheme interpreter. 2. Add custom code into the scheme interpreter and link in the lib 3. Develop some sort of foreign function interface What about a 9P interface? Here is a scheme implementation: http://www.ohloh.net/projects/chicken-9p If you guys have an example of implementing some sort of suckless approach to foreign function that would be cool. The advantage is, 9P can be used in an universal way, network transparently and without any platform/language boundaries. The only tricky part is defining a sane synthetic fs for abstracting the RPCs you are looking for. However, there are non-Plan9ish examples in the procfs (might not be the best reference though). Kind regards, --Anselm
Re: [dwm] patch to not reparent children to init
Hi Neale, 2008/11/6 Neale Pickett [EMAIL PROTECTED]: Donald Chai [EMAIL PROTECTED] writes: On Tue, Nov 4, 2008 at 9:09 AM, Neale Pickett [EMAIL PROTECTED] wrote: 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... If you quit dwm, what happens to any programs that you've launched? Nothing, the setsid() call makes children process group leaders so they don't receive any of the signals the parent gets. Well, I remember there was a problem with the SIGCHLD signal handler, I need to recheck with Stevens tomorrow. It might be that this was on some ancient UNIX though. But the double-fork is definately the most portable solution. Kind regards, --Anselm
Re: [dwm] patch to not reparent children to init
Well, catching all zombies is a tricky task. AFAIK the SIGCHILD
handler on its own is no reliable solution on all systems. There were
several iterations regarding spawn() during the time, most of them
happened at wmii times and the old double-fork() was the most reliable
and simple solution, which was the reason I chose it and keep it.
Kind regards,
Anselm
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);
}
}
Re: [dwm] make setlayout toggle
2008/11/4 Neale Pickett [EMAIL PROTECTED]:
yy [EMAIL PROTECTED] writes:
After a quick look, I think the last check in the first if should be
arg-v != lt[sellt^1]
Yes, that's what it should have said. I wonder how it was working for
me before, when I sent the code to the list. [cue twilight zone music]
Here's what it should have said:
void
setlayout(const Arg *arg)
{
sellt ^= 1;
if(arg arg-v (arg-v != lt[sellt^1]))
lt[sellt] = (Layout *)arg-v;
if(sel)
arrange();
else
drawbar();
}
Ok, are there any concerns making this upstream again? (Yes I know, we
had this already in earlier versions, by that time it was called
togglelayout())... There were reasons for not toggling, basically it
was confusing to toggle the layout after a long period of time,
because one forgets about what the previous layout was.
Kind regards,
--Anselm
Re: [dwm] sswarp page may need an update
2008/11/2 Thayer Williams [EMAIL PROTECTED]: To the powers that be, I just noticed tonight that the swarp page shows some contradictory information. Namely, it lists the bin as sswarp and the package itself as SSWARP, yet the actual files swarp with a single 's'. Fixed. However all web pages can be fixed by anyone since we are using a world-writable hg repository for the wiki contents, see http://www.suckless.org/wiki.html for details. Kind regards, --Anselm
Re: [dwm] Can dwm ignore tray utilities out of the box?
You should define some junk tag and tag such clients accordingly in
some rule, then you could avoid binding any keybinding to this junk
tag that you would never see them, except from clicking the tag.
HTH,
Anselm
2008/10/25 Thayer Williams [EMAIL PROTECTED]:
Alright, so here goes my silly newb post #1...
Is it possible to run a tray utility, such as trayer or stalonetray,
and have dwm ignore it completely? I've tried various tray settings
and I also found what I thought was a relevant snippet from a recent
(v5.2) config.h. It mentioned an extended set of Rules, which I
adopted for trayer:
/* classinstancetitle tags mask
isfloating isignored isontop*/
{ trayer, NULL, NULL, 0,True,
True, True },
But this doesn't have the expected effect so I maybe wrong about its
intention.
My main goal is to make it so that trays are not selectable as a
client--I'd also like the keep the tray on top of the statusbar at all
times.
Re: [dwm] Getting a List of Installed Applications in System
Mod1-p will show all executables in the path. 2008/10/24 Amit Uttamchandani [EMAIL PROTECTED]: Hey guys, I recently introduced my friend to DWM. He was using KDE before that. He was very happy and surprised about the speed of DWM. Now, the question he had was is there some sort of application menu that lists all the installed apps? Like the kicker for KDE or its similar GNOME/Fluxbox counterpart? I did not have an answer for him...I did a search on aptitude but the only thing I found was the debian 'menu' package but I am not sure how to use that. Any ideas? --Anselm
Re: [dwm] Terminals retain size of stack
2008/10/15 Tinou [EMAIL PROTECTED]: Could this have something to do with gvim not getting proper size at launch ? (wrong number of lines: about 2 or 3 less than expected, until resize) I'm out of guesses on this issue: tried with and without resizehints (made a small function to toggle that btw), different versions of gvim, with and without any config, newer versions of gtk, xorg, nvidia driver... but I'm currently using a 2.6.22 kernel (the 2.6.25 made hiccups in mpd playback, don't know why) AFAIR there are some known issues with configure request handling in gvim. Kind regards, Anselm
Re: [dwm] Re: Patch: pertag for dwm-5.2
2008/10/15 v4hn [EMAIL PROTECTED]: Ev'ning, On Sun, Sep 14, 2008 at 05:34:08PM +0200, Fredrik Ternerot wrote: Updated to also support toggle layout per tag. /Fredrik On 9/13/08, Fredrik Ternerot [EMAIL PROTECTED] wrote: Updated pertag patch for dwm-5.2. Could someone please upload/link this patch on the website? Actually the provided link is dead. /* http://www.suckless.org/dwm/patches/dwm-5.2-pertag.diff */ Just add this patch to the wiki repository. It's world-writable. See http://www.suckless.org/wiki.html for details. Make sure the file has the .diff extension. Kind regards, Anselm
Re: [dwm] Floating children
2008/9/28 Carlos Pita [EMAIL PROTECTED]: as I'm no expert I would like to ask you about the possibility of opening clients that are children of a floating one as floating themselves, disregarding the current layout. If these clients set the TRANSIENT_FOR hint to reflect they are relatives to some kind of main window, this will work out of the box. Otherwise not. You can ask the developers of these apps to set the TRANSIENT_FOR flag on these windows. For example fluid, the gui designer for fltk, which follows the gimp and gaim ugly paradigm of presenting a number of floating windows. I can add a rule for floating its main window, based on its class. But the child windows has no class or instance properties that can be ruled as floating, and the titles are unmatcheable without regexp support, so I need to manually move them to the floating state (and there is no fixed set of windows, new ones are always popping up during the work session). Even worst, if the current layout is, say, monocle, they are automatically maximized, so I need to resize them every time too. Of course, I could change the layout to floating each time I enter fluid's tag, but then I also need to remember to revert to monocle -my default mode- upon tag exit. As you can see, there is a lot of manual, fallible, work involved. Sounds like the app you are using is broken in many regards, bug the developers of this app. The changes they need to do are really simple, just setting some proper hints on the windows will do the trick. I'm a bit reluctant to patch dwm pertag just for this. I think it's more sensible to make floating client's children recursively floating. The problem is, that the children windows you are referring to are no child windows in the sense of X, they are only child windows from a semantical point of view of the application itself. What do you think? Can you help me implement this, if it's possible at all? (I'm not even sure whether X has a notion of parent-child relationship between clients or not) Usually this relationship is reflected by using the TRANSIENT_FOR hint instead. Kind regards, --Anselm
Re: [dwm] Re: font problem
Try using xfontsel to see if there is a problem with the terminus package. Also let us know what your actual LC_* vars look like, e.g. ; env | grep LC Kind regards, Anselm 2008/9/21 Max Fischer [EMAIL PROTECTED]: On Sun, Sep 21, 2008 at 02:06:06AM +0200, Marcin Cieslak wrote: Max Fischer wrote: hi, i've lately some problems with using the terminus font. dwm responses missing font: ISO8859-1. terminus font is working in terminals etc. and many other fonts are working with dwm, too. I don't get what's wrong, my locale seems ok to me http://pastie.org/276377 That does not explain anything. What is your font specification in the config.h? Mine is (for example): static const char font[] = -*-terminus-medium-r-normal-*-12-*-*-*-*-*-iso10646-*; (this is wrapped, it's one line). Make sure that there are no unwanted spaces in the specification. --m I've tried several specifications, at least -*-terminus-medium-r-normal-*-12-*-*-*-*-*-*-*. Your spec. did it neither. -- --Anselm
Re: [dwm] XCB?
2008/9/14 Johannes Wegener [EMAIL PROTECTED]: I recently read that awesome is going to use XCB over Xlib and says that it is faster becouse it is asynchronous. Does XCB realy its job faster than Xlib? And if this is the case is dwm going to use XCB in any further release? I'd be interested in benchmarks proving this thesis. Xlib isn't synchronous either, though it can be enforced by clients to process all pending requests using XSync(). I'd bet that a thread-safe Xlib reimplementation from scratch using C might be a lot faster than XCB, since XCB is generated code in plenty parts. Just some stupid questions - don't take them to serious - I like dwm and how it is,its just some kind of intrest in that thing of XCB :) I have in mind to give dwm on xcb a try. Kind regards, --Anselm
