Re: [dev] wmii falling out of favor
On 1/8/12, Anselm R Garbe garb...@gmail.com wrote: Someone could implement a stacked mode patch for dwm based on two extra windows (similar to the dwm bar) per column -- wouldn't be too hard. I would like a window manager that has wmii's acme-like window management, but without the 9P filesystem, wmiir, support for configuration via python, ruby, etc. Trim the fat off of it (or perhaps it would be better to use dwm as a base to build upon, rather than trying to deconstruct wmii?) Now if only I had the Xlib know-how - not to mention the time - to do it.. John
Re: [dev] [dwm] about _NET_ACTIVE_WINDOW support
On 7 January 2012 21:20, Ivan Kanakarakis ivan.ka...@gmail.com wrote: I was going looking through dwm's code cause I've been having problems with my own implementation of _NET_ACTIVE_WINDOW support for mosnterwm, and noticed some things. 1) The ewmh standard on _NET_ACTIVE_WINDOW [0] says that: [...] This is a read-only property set by the Window Manager. If a Client wants to activate another window, it MUST send a _NET_ACTIVE_WINDOW client message to the root window [...] Depending on the information provided with the message, the Window Manager may decide to refuse the request [...] dwm, when it receives a _NET_ACTIVE_WINDOW message, it transfers focus to the client that asked for it, but never sets the root window id to that window's id. That is ofcourse a choice - the standard doesn't force one to do that, but that makes tools like xdotool and xprop fail on some options that people may find usefull. Specifically the following commands: $ xprop -root _NET_ACTIVE_WINDOW $ xdotool getactivewindow To get those working properly, one would need to, XChangeProperty(dpy, root, netatom[NetActiveWindow], XA_WINDOW, 32, PropModeReplace, (unsigned char *)c-win, 1); everytime a new window is focused. I guess that would go into setfocus(Client *c) function or something similar. Good point, I will consider this modification in dwm. 2) Apart from that, I get another weird focus(?) problem, that I get with dwm and monsterwm too, when I enable the _NET_ACTIVE_WINDOW support. If I go back some revisions before _NET_ACTIVE_WINDOW was added to dwm, everything seems right. It seems some apps (Chromium for me) don't get focused correctly. See this[1] to have a picture of what I'm talking about. Chromium, on the left and highlighted with the orange border, is supposed to be focused. Although it *has* input focus, and all keybinds, actions etc work, it *looks* like it's unfocused - the background on top is grey (the color above the green area with the tool/mail/bookmarks buttons) - when it should be black (thus indicating focus). That makes things like clicking the star to save a bookmark, not work correctly, as the popup that would ask where to place the bookmark, doesn't appear. Again, this happens on mosnterwm and dwm when _NET_ACTIVE_WINDOW is supported. I've tried many different things (eg sending a WM_TAKE_FOCUS event explicitly) but nothing seems to work. Well WM_ shouldn't have any direct effect on the EWMH handling. I have no idea at this point about your focus issue. My initial thought when starting dwm development years ago was not supporting EWMH at all, as it usually leads to all kinds of headaches like the one you are describing and makes the code base messy. But I will look into this issue to see if we find a proper solution. Cheers, Anselm
Re: [dev] [dwm] about _NET_ACTIVE_WINDOW support
On 8 January 2012 02:03, Andreas Amann am...@physik.tu-berlin.de wrote: On Sat, Jan 07, 2012 at 10:20:27PM +0200, Ivan Kanakarakis wrote: dwm, when it receives a _NET_ACTIVE_WINDOW message, it transfers focus to the client that asked for it, but never sets the root window id to that window's id. That is ofcourse a choice - the standard doesn't force one to do that, but that makes tools like xdotool and xprop fail on some options that people may find usefull. Specifically the following commands: $ xprop -root _NET_ACTIVE_WINDOW $ xdotool getactivewindow To get those working properly, one would need to, XChangeProperty(dpy, root, netatom[NetActiveWindow], XA_WINDOW, 32, PropModeReplace, (unsigned char *)c-win, 1); everytime a new window is focused. I guess that would go into setfocus(Client *c) function or something similar. I use the attached patch for this. In addition it also maintains a NetClientList, which exposes the list of managed windows in the ewmh recommended way. Which kind of program is using this client list? Cheers, Anselm
Re: [dev] wmii falling out of favor
On 8 January 2012 10:30, John Matthewman jmatthew...@gmail.com wrote: On 1/8/12, Anselm R Garbe garb...@gmail.com wrote: Someone could implement a stacked mode patch for dwm based on two extra windows (similar to the dwm bar) per column -- wouldn't be too hard. I would like a window manager that has wmii's acme-like window management, but without the 9P filesystem, wmiir, support for configuration via python, ruby, etc. Trim the fat off of it (or perhaps it would be better to use dwm as a base to build upon, rather than trying to deconstruct wmii?) Now if only I had the Xlib know-how - not to mention the time - to do it.. Use dwm as a starting point. It shouldn't be too hard. Cheers, Anselm
Re: [dev] [dwm] about _NET_ACTIVE_WINDOW support
On 8 January 2012 13:28, Anselm R Garbe garb...@gmail.com wrote: On 7 January 2012 21:20, Ivan Kanakarakis ivan.ka...@gmail.com wrote: I was going looking through dwm's code cause I've been having problems with my own implementation of _NET_ACTIVE_WINDOW support for mosnterwm, and noticed some things. 1) The ewmh standard on _NET_ACTIVE_WINDOW [0] says that: [...] This is a read-only property set by the Window Manager. If a Client wants to activate another window, it MUST send a _NET_ACTIVE_WINDOW client message to the root window [...] Depending on the information provided with the message, the Window Manager may decide to refuse the request [...] dwm, when it receives a _NET_ACTIVE_WINDOW message, it transfers focus to the client that asked for it, but never sets the root window id to that window's id. That is ofcourse a choice - the standard doesn't force one to do that, but that makes tools like xdotool and xprop fail on some options that people may find usefull. Specifically the following commands: $ xprop -root _NET_ACTIVE_WINDOW $ xdotool getactivewindow To get those working properly, one would need to, XChangeProperty(dpy, root, netatom[NetActiveWindow], XA_WINDOW, 32, PropModeReplace, (unsigned char *)c-win, 1); everytime a new window is focused. I guess that would go into setfocus(Client *c) function or something similar. Good point, I will consider this modification in dwm. The patch attached to Andreas responce does that and also adds support for _NET_CLIENT_LIST I too do not know where and what uses _NET_CLIENT_LIST 2) Apart from that, I get another weird focus(?) problem, that I get with dwm and monsterwm too, when I enable the _NET_ACTIVE_WINDOW support. If I go back some revisions before _NET_ACTIVE_WINDOW was added to dwm, everything seems right. It seems some apps (Chromium for me) don't get focused correctly. See this[1] to have a picture of what I'm talking about. Chromium, on the left and highlighted with the orange border, is supposed to be focused. Although it *has* input focus, and all keybinds, actions etc work, it *looks* like it's unfocused - the background on top is grey (the color above the green area with the tool/mail/bookmarks buttons) - when it should be black (thus indicating focus). That makes things like clicking the star to save a bookmark, not work correctly, as the popup that would ask where to place the bookmark, doesn't appear. Again, this happens on mosnterwm and dwm when _NET_ACTIVE_WINDOW is supported. I've tried many different things (eg sending a WM_TAKE_FOCUS event explicitly) but nothing seems to work. Well WM_ shouldn't have any direct effect on the EWMH handling. I have no idea at this point about your focus issue. My initial thought when starting dwm development years ago was not supporting EWMH at all, as it usually leads to all kinds of headaches like the one you are describing and makes the code base messy. But I will look into this issue to see if we find a proper solution. Thanks, just keep in mind that I've seen this only on chromium (so far) so it could possibly be something wrong with the app, not the wm. -- *Ivan c00kiemon5ter V Kanakarakis *
[dev] dmenu-4.5
Hey all, I've released dmenu-4.5 [1][2]. A summary of changes: * Detects monitor based on input focus, not just pointer location. * Token matching instead of just substrings. * XIM composition support. * Paste from clipboard with C-S-y. * stest(1) replaces lsx(1). * M-[Gghjkl] restored for vi-like navigation. * And a couple of bug fixes. Finally, I probably won't be doing any more active development for dmenu, though I'll help fix any bugs if they come up. [1]: http://tools.suckless.org/dmenu [2]: http://hg.suckless.org/dmenu Thanks, cls
[dev] Re: dmenu-4.5
Oh, and most important of all, a new colour scheme, matching dwm-6.0! cls
Re: [dev] wmii falling out of favor
On Sun 08 Jan 2012 04:30:47 PM PST, John Matthewman wrote: I would like a window manager that has wmii's acme-like window management, but without the 9P filesystem, wmiir, support for configuration via python, ruby, etc. Try i3, which was inspired by wmii: http://i3wm.org/ -- If something has not yet gone wrong then it would ultimately have been beneficial for it to go wrong.
Re: [dev] dmenu-4.5
Connor Lane Smith: * M-[Gghjkl] restored for vi-like navigation. When lines 1, I would expect M-j to select the next item (because it's below the current one), but I have to press M-l instead. -- b.d (| |) ^ ^
Re: [dev] [dwm] about _NET_ACTIVE_WINDOW support
On Sun, Jan 08, 2012 at 12:29:38PM +0100, Anselm R Garbe wrote: On 8 January 2012 02:03, Andreas Amann am...@physik.tu-berlin.de wrote: I use the attached patch for this. In addition it also maintains a NetClientList, which exposes the list of managed windows in the ewmh recommended way. Which kind of program is using this client list? The attached shell script for example. I bind it to Alt-W as a quick and dirty dmenu based windows selector. For me the quickest way of finding and focusing a particular window. Google shows quite a couple of other programs which seem to use NetClientlist, but still I think it is not worth the trouble to support it in mainline dwm. Andreas listwin.sh Description: Bourne shell script
Re: [dev] [dwm] about _NET_ACTIVE_WINDOW support
On Sun, Jan 08, 2012 at 01:50:35PM +0200, Ivan Kanakarakis wrote: The patch attached to Andreas responce does that and also adds support for _NET_CLIENT_LIST Just to ask, does your other focus problem with Chromium still exist with that patch applied? Andreas
Re: [dev] wmii falling out of favor
2012/1/8 John Matthewman jmatthew...@gmail.com: I would like a window manager that has wmii's acme-like window management, but without the 9P filesystem, wmiir, support for configuration via python, ruby, etc. Trim the fat off of it (or perhaps it would be better to use dwm as a base to build upon, rather than trying to deconstruct wmii?) Quintin Guillaume posted a patch providing a wmii-like layout for dwm a while ago [1]. I doubt that it applies to current dwm as it probably is from the pre-Xinerama era of dwm, but it may be easily brought up to date. There were some updated versions of that patch, make sure to search the old d...@suckless.org mailing list archives for the latest one. [1] http://lists.suckless.org/dwm/0808/6435.html -- Thomas Dahms
Re: [dev] wmii falling out of favor
On 1/9/12, Thomas Dahms thmsd...@googlemail.com wrote: 2012/1/8 John Matthewman jmatthew...@gmail.com: I would like a window manager that has wmii's acme-like window management, but without the 9P filesystem, wmiir, support for configuration via python, ruby, etc. Trim the fat off of it (or perhaps it would be better to use dwm as a base to build upon, rather than trying to deconstruct wmii?) Quintin Guillaume posted a patch providing a wmii-like layout for dwm a while ago [1]. I doubt that it applies to current dwm as it probably is from the pre-Xinerama era of dwm, but it may be easily brought up to date. There were some updated versions of that patch, make sure to search the old d...@suckless.org mailing list archives for the latest one. [1] http://lists.suckless.org/dwm/0808/6435.html Thanks for the tip! I vaguely remember reading about that patch a long time ago. Maybe I'll see if I can get it to work -- then try to make it a bit more mouse-friendly (like acme). Cheers, John
