Re: [dwm] dwm and dualhead
mnagy: Hiho, On Wed, Dec 10, 2008 at 06:05:23PM +0100, Johannes Wegener wrote: 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 people on this list seemed to have convinced themselves that this is a good thing to do in any way or form. (It's not.) no more supported by xorg 7.4 and the intel driver. I just ran into this about a week ago. Dammit. So my question are do you plan to put xrandr support into dwm? or has anybody a hack/workaround for that problem? It's called 'awesome', a fork of dwm that has proper xrandr support... and drops every other advantage of dwm, has completely ridiculous dependencies (including nonstandard make), theme support and ugly graphics all over the place. 'awesome' is not the only option (and yes, I agree, their deps are now ridculous). -- Don
Re: [dwm] XCB?
tobiasu: On Sun, Sep 14, 2008 at 12:32:25PM +0100, Anselm R Garbe wrote: 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. Keep in mind that this locks out a number of users not running bleeding edge stuff... I think this is the biggest concern. Just look at the dependencies: http://aur.archlinux.org/packages.php?ID=18981 cairo-xcb dbus gtk2 imlib2 libev libgpg-error libxcb lua luafilesystem So that's starting to get a bit serious. On Debian it is just ridiculous, http://packages.debian.org/experimental/awesome dep libc0.1 dep: libc6 dep: libc6.1 dep: libcairo2 dep: libdbus-1-3 dep: libev3 dep: libglib2.0-0 dep: libgtk2.0-0 dep: libimlib2 dep: liblua5.1-0 dep: libncurses5 dep: libpango1.0-0 dep: libreadline5 dep: libx11-6 dep: libxcb-atom0 dep: libxcb-aux0 dep: libxcb-event0 dep: libxcb-icccm0 dep: libxcb-keysyms0 dep: libxcb-property0 dep: libxcb-randr0 dep: libxcb-render-util0 dep: libxcb-render0 dep: libxcb-xinerama0 dep: libxcb1 Of course, this might pay off for them in the long run, once all this stuff is supported. The performance question is just advertising, without numbers. Despite all this, they seem to be picking up users. Users like features, I guess. -- Don
Re: [dwm] EWMH code would enable some code cuts
tuncer.ayaz: On Tue, May 6, 2008 at 5:01 PM, Anselm R. Garbe [EMAIL PROTECTED] wrote: On Tue, May 06, 2008 at 12:14:10AM +0200, Henrik Holst wrote: I think an implementation of EWMH would make it possible to remove the dwm panel (the one that reads stdin and displays it) from dwm code base. In that way dwm would be smaller (or maybe just break even) and more symmetric with how dmenu is fitted to the equation today. It would also allowe the user to choose whatever kind of panel he or she wants. That is an escape and dpanel (or some other name maybe) would not have to be counted in the ridicules 2 kloc limit. :P But seriously, EWMH support with struts and all, should be on the top of the list for dwm. EWMH is too important to be left to forks. Something for 5.0? EWMH is evil. I see reasons for people arguing to get rid of the status text processing code in dwm, but the tagging approach is a too integral part of dwm which heavily depends on the bar. Thus there is no way to get rid of the bar. The overhead introduced by EWMH and a EWMH-driven bar for the tagging concept would make the code base much more complex. Currently I'm at a stage to reconsider features for removal again. Esp. DEFGEOM seems to have a lot of potential for simplification(s). +1 on status text processing removal (it just eats cycles and makes life harder while trying to concentrate on real work) +1 on keeping a possibility to have the tags part of the bar for people who need it +1 on keeping a way to add a status bar somehow without having it in dwm but I'm not sure how that would be combined with the tags support. As there are presumably Xmonad devs/users lurking here I'm curious how the tags part in http://haskell.org/sitewiki/images/b/b2/Byorgey-config.png is accomplished. is it dzen or xmobar which has a way to talk to Xmonad? That's just dzen by the looks of it (with a xinerama hook to print which workspaces are currently on screen, into dzen). -- Don
Re: [dwm] EWMH code would enable some code cuts
tuncer.ayaz: On Wed, May 7, 2008 at 8:25 AM, Don Stewart [EMAIL PROTECTED] wrote: tuncer.ayaz: On Tue, May 6, 2008 at 5:01 PM, Anselm R. Garbe [EMAIL PROTECTED] wrote: On Tue, May 06, 2008 at 12:14:10AM +0200, Henrik Holst wrote: I think an implementation of EWMH would make it possible to remove the dwm panel (the one that reads stdin and displays it) from dwm code base. In that way dwm would be smaller (or maybe just break even) and more symmetric with how dmenu is fitted to the equation today. It would also allowe the user to choose whatever kind of panel he or she wants. That is an escape and dpanel (or some other name maybe) would not have to be counted in the ridicules 2 kloc limit. :P But seriously, EWMH support with struts and all, should be on the top of the list for dwm. EWMH is too important to be left to forks. Something for 5.0? EWMH is evil. I see reasons for people arguing to get rid of the status text processing code in dwm, but the tagging approach is a too integral part of dwm which heavily depends on the bar. Thus there is no way to get rid of the bar. The overhead introduced by EWMH and a EWMH-driven bar for the tagging concept would make the code base much more complex. Currently I'm at a stage to reconsider features for removal again. Esp. DEFGEOM seems to have a lot of potential for simplification(s). +1 on status text processing removal (it just eats cycles and makes life harder while trying to concentrate on real work) +1 on keeping a possibility to have the tags part of the bar for people who need it +1 on keeping a way to add a status bar somehow without having it in dwm but I'm not sure how that would be combined with the tags support. As there are presumably Xmonad devs/users lurking here I'm curious how the tags part in http://haskell.org/sitewiki/images/b/b2/Byorgey-config.png is accomplished. is it dzen or xmobar which has a way to talk to Xmonad? That's just dzen by the looks of it (with a xinerama hook to print which workspaces are currently on screen, into dzen). so it's Xmonad dzen where dzen expects a string/bytestream to parse in a defined format/structure? if so it would make sense to try to standardize a subset of the format for both dwm and Xmonad just in case dwm goes down that path. Yep, its just dzen's input format. text and pixmaps. You can run this stuff from the command line, so no need for further standardisation (well, maybe more docs from Rob about dzen). -- Don
Re: [dwm] Java patch
arg: On Sun, Apr 27, 2008 at 01:43:14PM -0700, Don Stewart wrote: luizribeiro: On Sun, Apr 27, 2008 at 4:59 PM, Jukka Salmi [EMAIL PROTECTED] wrote: It doesn't work for me. Just tested with jdk 1.5.0 and netbeans... I think the LG3D Java compatibility came with jdk 1.6. Remember that the hack sets the NET_WM_NAME to LG3D. Maybe setting it to a different name could work with jdk 1.5. But I'm not sure about that, or what window manager name you should use. This patch has been in xmonad for a while, there's some more documentation here, http://xmonad.org/xmonad-docs/xmonad-contrib/XMonad-Hooks-SetWMName.html Several users have reported this as useful. So why not converting this patch into a standalone setwmname application written in C, then we can delete the patches in dwm and XMonad and people just run setwmname FooBarBaz to work around the XToolkit bug(s)? Good idea. -- Don
Re: [dwm] Java patch
luizribeiro: On Sun, Apr 27, 2008 at 4:59 PM, Jukka Salmi [EMAIL PROTECTED] wrote: It doesn't work for me. Just tested with jdk 1.5.0 and netbeans... I think the LG3D Java compatibility came with jdk 1.6. Remember that the hack sets the NET_WM_NAME to LG3D. Maybe setting it to a different name could work with jdk 1.5. But I'm not sure about that, or what window manager name you should use. This patch has been in xmonad for a while, there's some more documentation here, http://xmonad.org/xmonad-docs/xmonad-contrib/XMonad-Hooks-SetWMName.html Several users have reported this as useful. -- Don
Re: [dwm] a lone client could be borderless
vamosaverlas: Date: Fri, 21 Mar 2008 19:49:18 +0100 From: [EMAIL PROTECTED] To: dwm@suckless.org Subject: Re: [dwm] a lone client could be borderless On 3/21/08, markus schnalke wrote: But anyway, special corner case handling leads to bad code. It conflicts with generality, which is one of the design principles. I understand. My principle would be the border only appears when needed. for what its worth, we had to tackle this too in xmonad, which now has an extension, 'smart borders', that tries to apply this rule. given any layout, it uses some heuristics to hide the border of windows in that layout (its a layout modifier, basically) http://xmonad.org/xmonad-docs/xmonad-contrib/XMonad-Layout-NoBorders.html so any layout, with a single client, or a fullscreen client, or a floating window at fullscreen, etc. for the xinerama case, its a bit tricky: you sometimes need the border to decide which screen has focus. -- Don
Re: [dwm] We need a different Xinerama implementation
arg: I agree that the current approach has flaws and I'd like to address them before dwm-4.8. Actually I'd like to hear your opinions first to what you think might be the best solution of supporting multihead setups? I more and more come to the conclusion that classical multihead support is not worth the effort anymore. The DISPLAY= variable should do the trick for those setups (meaning running separate instances of dwm for each screen) -- but Xinerama provides much more possibilities so that I see a different use case here. I consider different tagsets for each screen, which can't be selected in a join way, to prevent the basic problem of being unable to display the same window on different screens. Maybe somewhat into the direction of having a 2D tagset, with y addressing different screens (yiyus or pancake came up with this idea if I remember correctly) for the Xinerama case, and y addressing different virtual screens for the non Xinerama case. Hence, say tags 1-4 address screen 1, tags 5-9 address screen 2 or so, but tagging a client 1+5 is not possible. This should give you a rough idea. Please let me know what you think. This is essentially the approach we chose for xmonad. No union of window sets, and display one set per physical screen. You can then index phsyical screens, and window sets separately We use mod-w,e,r to select a physical screen as current. Then mod-1..9 to load a window set onto that physical screen. If the set is visible on another physical screen already, you either switch the current screen, or swap window sets. -- Don
Re: [dwm] Urgency hook?
obrien654j: Just out of curiosity, has anyone made a patch that puts a special color or some indicator on tags that have windows that set the Urgency window hook, such as pidgin or urxvt if setup correctly? And if not, how feasible would this be? Thanks in advance. This is moderately straight forward. We added it to xmonad in the last couple of weeks. http://xmonad.org/xmonad-docs/xmonad-contrib/XMonad-Hooks-UrgencyHook.html It seems to be a commonly requested feature. -- Don
Re: [dwm] dwm wish, a tidy-up function
antoni: Hi, just came across another idea. How about implementing a function in dwm that would reapply all the predefined rules (float/non-float, tagging) to all clients in a dwm session. This could either be a function bindable to a keystroke, or dwm reacting to a signal (say, HUP), or what not. This way, when I do a total mess with tagging and floating my clients (sometimes it happens and I get lost) I could get my everyday dwm state with one keystroke or command. What do you think? I presume this could also be achieved by restarting dwm, but this doesn't seem too clean to me, and also would not integrate well with a login manager (from what it seems). If something like that is already there, excuse my infinite dumbness for not noticing. We added mod-shift-space (rest workspace to default settings) recently to xmonad -- it becomes particular useful once you start serialising state, across restarts. -- Don
