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] Dualhead + tiling
2011/11/14 Jonas H. jo...@lophus.org: Is it possible to use tiling w/ dualhead? i.e. have a separate tiling area on each monitor - so that if you move a window from monitor 0 to monitor 1 in floating mode and then move it to the tiling layer, it stays on monitor 1. (The way it works for my setup right now is that it's moved back to monitor 0.) wmii spans the tiling area over all monitors, but managed columns end at screen boundaries. -- Thomas Dahms
Re: [dev] [wmii] Dualhead + tiling
2011/11/15 Jonas H. jo...@lophus.org: What's that Xinerama support that came with 3.9 then? It is Xinerama. One view just includes both monitors. That is different from dwm and other window managers, but not necessarily worse. -- Thomas Dahms
Re: [dev] Some 2wm questions
2011/11/1 Bert Münnich be.muenn...@googlemail.com: On 01.11.11, Connor Lane Smith wrote: I notice this patch doesn't have an attach (M-a) to accompany detach (M-d). Is this a bug or a feature? It's a feature. I've used attach only very rarely. Instead, I switch to the other tag temporarily, use detach (toggletag) on the clients I want to detach and switch back. Your patch is quite a bit different than 2wm. 2wm has only one view. Your patch looks more like dwm limited to two tags. -- Thomas Dahms
Re: [dev] Some 2wm questions
2011/11/1 Thomas Dahms thmsd...@googlemail.com: 2011/11/1 Bert Münnich be.muenn...@googlemail.com: On 01.11.11, Connor Lane Smith wrote: I notice this patch doesn't have an attach (M-a) to accompany detach (M-d). Is this a bug or a feature? It's a feature. I've used attach only very rarely. Instead, I switch to the other tag temporarily, use detach (toggletag) on the clients I want to detach and switch back. Your patch is quite a bit different than 2wm. 2wm has only one view. Sorry, I missed toggleview(). Nevertheless, I found attach to be essential when trying 2wm. Your patch looks more like dwm limited to two tags. -- Thomas Dahms -- Thomas Dahms
Re: [dev] [dwm] ncol layout
2011/10/31 Anselm R Garbe garb...@gmail.com: So after having clarified the question about if you'd change nmaster dynamically, I'd like to clarify this question: -- What is your typical range of nmaster in reality? Is it just 1-2 or even 1-3 or more? I use ncol with nmaster=2 most of the time. On small screens I use nmaster=1 (which is equivalent to standard tile). That said, I have no problem with patching ncol in, no need to have it in mainline. I think others may not want it and layouts should be in mainline only when a majority of users actually uses them. -- Thomas Dahms
Re: [dev] [dwm] ncol layout
2011/10/31 Anselm R Garbe garb...@gmail.com: Ok, if the majority rarly increases nmaster to 3, I would suggest the approach to have setnmaster() rather than incnmaster(). Then one could define: Mod1-t: setnmaster(1); setlayout(tile); Mod1-Shift-t: setnmaster(2); setlayout(tile); What about some people using ntile (rows in master area) and some using ncol (columns in master area)? Half of the users would have to patch, I guess. -- Thomas Dahms
Re: [dev] Re: [dwm] A general approach to master-slave layouts
2011/10/31 lolilolicon loliloli...@gmail.com: On Mon, Oct 31, 2011 at 9:49 PM, lolilolicon loliloli...@gmail.com wrote: The code is in the attachment. *huge facepalm* Forgot to attach the fixed code. Attached here. That looks interesting. I have one suggestion for a simplification: I guess you can get rid of the functions combining the master and slave layouts by modifying setlayout() to take three arguments (the two layouts and the direction of master/slave splitting). This way you could combine any two layouts in the key binding section of config.h. -- Thomas Dahms
Re: [dev] [dwm] ncol layout
2011/10/29 Anselm R Garbe garb...@gmail.com: I'm not really convinced nmaster should be mainstream, rather I believe that bstack and tile are a better compromise, but I need to work with this setup a bit more during this weekend to make up my mind. I never used the regular nmaster layout (ntile), but ncol is what I use on screens with relatively high resolution. If your editor clients don't need more than 80 characters width, having only two columns as in standard tile mode is just wasting screen space. Concerning bstack, I don't find any use for this with wide screens (16:10 or even 16:9) becoming mainstream. -- Thomas Dahms
[dev] [dwm] ncol layout
Hi list,
with nmaster becoming mainstream (again), what was known as the
nmaster-ncol patch can also be simplified a lot. Attached file
provides a layout that arranges clients in columns in the master area.
Maybe someone finds it useful.
--
Thomas Dahms
void
ncol(Monitor *m) {
unsigned int i, n, mw, tw, th;
Client *c;
for(n = 0, c = nexttiled(m-clients); c; c = nexttiled(c-next), n++);
if(n == 0)
return;
mw = (n m-nmaster) ? m-ww * m-mfact / m-nmaster : m-ww / n;
th = (n m-nmaster) ? m-wh / (n - m-nmaster) : 0;
tw = (n m-nmaster) ? m-ww - mw * m-nmaster : 0;
for(i = 0, c = nexttiled(m-clients); c; c = nexttiled(c-next), i++)
if(i m-nmaster)
resize(c, m-wx + (i*mw), m-wy, mw - (2*c-bw), m-wh - (2*c-bw), False);
else
resize(c, m-wx + mw * m-nmaster, m-wy + ((i - m-nmaster)*th), tw - (2*c-bw), th - (2*c-bw), False);
}
Re: [dev] dwm 5.9 small patch for non xinerama users
Hi, 2011/7/22 mauro tonon tono...@gmail.com: I noted that if i disable Xinerama, i don't use also the following functions: dirtomon, focusmon, tagmon. So, i think it is possible to hold all these functions between #ifdef XINERAMA ... #endif. The difference in the final binary file size is very little but... A possible patch is attached... What about prefixing these functions with something like xinerama_? They would then be all after another and a single ifdef would suffice instead of three. -- Thomas Dahms
Re: [dev] exiting dwm correctly
2011/6/28 Thuban thu...@singularity.fr: Hello I can't find mails about exiting dwm properly, in order to kill every process launched before dwm when using a .xinitrc file as example. Can you help me finding it please? thank you There was a thread about properly terminating the loop that updates your status bar [1]. If you want to kill everything started in .xinitrc you could remember every PID to kill them all at the end: xbindkeys PID1=$! wicd-client PID2=$! dwm kill $PID1 $PID2 You would have to be sure that the programs keep their PID and are not replaced by child processes. Otherwise you would kill random processes in the end. [1] http://thread.gmane.org/gmane.comp.misc.suckless/5391 -- Thomas Dahms
Re: [dev] Please test dwm master
2011/6/25 garbeam garb...@gmail.com: I'm planning the dwm-5.9 release very shortly, prior to a major overhaul of the multiscreen handling and the draw.c introduction in dwm 6.0. I'd like you to test it and let me know any issues. I have one minor issue that never really bothered me, but while you are fixing bugs, I thought I could mention it: When Firefox opens a dialog, this usually opens a floating window. If, however, Firefox opens such a window while I am not viewing the tag that Firefox is on, the dialog will be opened as a managed window. I guess this is generic to any application opening dialog windows. -- Thomas Dahms
Re: [dev] wmii
2011/6/25 hiro 23h...@googlemail.com: Wrong permissions perhaps? Other than that I have no idea. Removing the whole ~/.wmii directory should work at least, using the system-wide configuration. That will trigger an xmessage asking you what Modkey you want to use. Answer Mod1 and you should be happy. -- Thomas Dahms
Re: [dev] wmii
2011/6/25 Thomas Kucharczyk kuc...@googlemail.com: This is weird, deleting the wmii dir doesnt seem to cause changes, nor pops up a menu creating wmiirc_local doesnt solve it changing Modkey in /etc/wmii/wmiirc doesnt solve it Try to start wmii with wmii -r /etc/wmii/wmiirc and change the Modkey in /etc/wmii/wmiirc. The -r flag specifies which wmiirc to load; maybe something mixed up the configuration-path auto magic. Are any other changes to your config files affecting wmii's behavior? Try to change some color, for example. And are you sure you are using wmii 3.9.2 and not hg tip? The hg version uses /etc/wmii-hg and ~/.wmii-hg as configuration paths. -- Thomas Dahms
Re: [dev] wmii
2011/6/24 Thomas Kucharczyk kuc...@googlemail.com: Hi, i want to change my Modkey to Alt L/Mod1, because i dont hany a windows key on my t40. But i cant get it to work. Here the Details: http://pastebin.com/Lm5sKzfH Sabayo 6 x86 wmii-3.9.2-r2 -rwxr-xr-x 1 thomas thomas 7310 24. Jun 22:02 /home/thomas/.wmii/wmiirc regards Make sure that there is no wmiirc_local with another MODKEY= line in your ~/.wmii directory. -- Thomas Dahms
Re: [dev] wmii - key events are not read unless they are repeated
On Sun, 08 May 2011 07:54:33 +0200, Ben Smith bensmit...@gmail.com wrote: I'm on arch linux with the wmii installed from community which is version 3.9.2-1 and I'm following the customizing section of the users guide. You should be aware that this user guide describes the setup of a wmiirc from scratch. If you just want to customize the existing one, you can do so by using a ~/.wmii/wmiirc_local (the recommended, but not overly well documented way) or by copying /etc/wmii/wmiirc (or wherever yours is) to ~/.wmii/wmiirc and modifying it. The latter is not recommended, because you will have to keep track of upstream changes to the vanilla wmiirc. -- Thomas Dahms
[dev] [dwm] terminating the status loop
Hi list, using something like while true; do xsetroot -name ... sleep 1 done exec dwm in .xsession (I have to use KDM at work) as advertised in dwm's README leaves the background loop running even after logout, which has some ugly side effects: While not logged in, xsetroot floods the logs because it is unable to find the display. And logging back in, I have two loops running. The following fixes the problem: while true; do xsetroot -name ... sleep 1 done statuspid=$! dwm wait $! kill $statuspid This looks quite ugly and I am curious if there is a more elegant way to terminate the status loop on logout. -- Thomas Dahms
Re: [dev] [dwm] terminating the status loop
On Wed, 27 Apr 2011 13:55:08 +0200, Kurt Van Dijck kurt.van.di...@eia.be wrote: why not just: dwm kill $statuspid I see no use in backgrounding dwm, and then waiting for it. What did I miss? Nothing; backgrounding dwm was left from trying a few other ways to do it. Thank you. Then it can be simplified further: while true; do xsetroot -name ... sleep 1 done dwm kill $! I wonder whether the README should be updated accordingly. But it is there for years and nobody seemed to notice before. I attach the trivial patch, just in case. -- Thomas Dahms example.patch Description: Binary data
Re: [dev] [dwm] terminating the status loop
Hi Andreas, while xsetroot -name $(date +%a, %b %d %Y | %H:%M) do sleep 20 done exec dwm This is even nicer as the original instance of .xsession is not kept running. -- Thomas Dahms
Re: [dev] [wmii] Ignoring key presses
Am 15.04.2011, 19:41 Uhr, schrieb Jay Mundrawala jdmundraw...@gmail.com: I've set it to alt, but I have tried both. Where have you set that? Keep in mind that wmii from hg reads files in ~/.wmii-hg/, while it is ~/.wmii/ for released versions. Also, the syntax of wmiirc has changed slightly since 3.9.2; using an older wmiirc in ~/.wmii-hg/ might cause the failure. Try with an empty ~/.wmii-hg/ first. If that still does not help, check whether your keys appear in the output of wmiir read /keys. -- Thomas Dahms
Re: [dev] How do you cope with OSX? (if at all)
The only approach I can envision is running arch in VirtualBox and having a saner Linux environment to work with. But I have no idea what performance penalty that will be in regular use. I use Arch Linux in a Virtualbox on my Windows laptop and there is no noticeable performance penalty, only in very I/O intense operations. You should be aware of an issue in Virtualbox' X driver that affects dwm [1]. [1] http://article.gmane.org/gmane.comp.misc.suckless/4021 -- Thomas Dahms
Re: [dev] [wmii] Chromium always starts as a floating window
Moreover, if you open up such an application via MOD4+p and then try to open a terminal(for ex.) in the same workspace that floating application is, terminal will load in a floating mode too, You can switch between the floating and the managed layer with Mod-Space. When you opened a floating window, you are in floating mode and any window will spawn floated. Just Mod-Space before and it opens managed. so you can drag and resize its window as if you're in good old openbox. You can just send the window to managed mode by Mod-Shift-Space. I think this should be fixed maybe, There is really nothing to fix here. -- Thomas Dahms
Re: [dev] wmii noob key binding help
Traditionally, this was solved by making wmiirc (1) emit Start wmiirc to /event at startup and later (2) exit if they see Start wmiirc inside their /event processing loop. In this manner, new instances of wmiirc terminate previously existing ones. I don't know why that mechanism was removed from the default SH wmiirc. It did exist in the past, however. It still exists. See ll. 2-4 and 211-212 in cmd/wmii.sh.sh in the source tree. However, spawning wmiirc from the Action menu does not work for me as well, although with different symptoms: No keybindings work thereafter. -- Thomas Dahms
Re: [dev] wmii noob key binding help
It was the wrong wmiirc turns out. I was editing /etc/wmii-hg/wmiirc and I was thinking about how the keybindings aren't the only thing that wasn't working, so I ran a locate on wmiirc and found out I have a /usr/local/etc/wmii-hg/wmiirc. Putting the key bindings in there made them work. But I'm still confused about why they don't work when I put them in wmiirc_local in the local_events() function. I have a similar problem [1], but only when using dash as the shell. Try another shell if you are using dash. Or use the workaround described in [1]. [1] http://code.google.com/p/wmii/issues/detail?id=229 -- Thomas Dahms
Re: [dev] [wmii] wedged indication does not go away
As for the flag not going away, when does it happen? It did not occur since then. You can consider it a very minor issue. Please fix the more annoying ones first if you find the time. I am thinking of issue 201 and of course the infamous issue 22. ;) There's a known bug where the wedged indication appears for all clients, due to the timer that pings the clients dieing, but it happens so rarely that I always forget to fix it. I had some emacs, evince, and xterm clients. Only the xterms were not indicated as wedged. If it only happens for a select few clients which aren't actually unresponsive then it's hard to say and the most likely explanation is that they advertise that they'll respond to pings but for some reason don't. However, I don't think I've seen this happen. Looks like you can't do anything in this case anyway. -- Thomas Dahms
Re: [dev] [wmii] wedged indication does not go away
Well, colrules are in for a revamp, possibly sometime this month. As for #22, to be honest, it's never bothered me. I wasn't aware that it was infamous. That wasn't meant to sound that serious. With screens getting larger and larger, not being able to use the fullscreen view has no longer been a problem in the last time for me. On smaller screens, however, I found it rather annoying and remember that other people felt the same in the last discussion on this. -- Thomas Dahms
Re: [dev] wmii how to replace status bar with dzen2
With the sh wmiirc, you can also change color of the status bar, with something like wmiir xwrite /rbar/status color #55 #ededeb #dcdcdb That one puts the color #55 #ededeb #dcdcdb text into my bar instead of changing it's color. What did I missed? It is colors, not color, sorry: wmiir xwrite /rbar/status colors #55 #ededeb #dcdcdb Anyway, that has changed at some point after the release of 3.9.2, I believe. In hg tip, you write text with label and color with colors. Before, you just wrote everything directly. If you are using 3.9.2, you can try omitting the prefix and just write wmiir xwrite /rbar/status #55 #ededeb #dcdcdb -- Thomas Dahms
Re: [dev] wmii how to replace status bar with dzen2
My reason is that I can use small icons with dzen2 and they can change
colors. So for example when my battery life goes low then the battery
icon is turning red.
Probably I could get away with text info instead of icons, but then I
still need some way of changing the color of given text depending on
it's value. And I failed to find a way of doing it in wmiirc.
You can do it most easily with the python wmiirc (started with wmii -r
python/wmiirc). I defined a function like this in wmiirc.py which changes
color on low battery:
@defmonitor
def battery(self):
for line in open('/proc/acpi/battery/BAT0/state','r'):
if len(line.split()) = 3 and line.split()[0] == 'remaining':
uebrig = int(line.split()[2])/1000
struebrig = 'battery {0} Wh'.format(uebrig)
if uebrig 10:
return wmii.cache['focuscolors'], struebrig
else:
return wmii.cache['normcolors'], struebrig
return wmii.cache['normcolors'], 'no battery info'
With the sh wmiirc, you can also change color of the status bar, with
something like
wmiir xwrite /rbar/status color #55 #ededeb #dcdcdb
You can only write label (i.e. text) or color at a time, so you have to
modify the Action status piece in wmiirc to write both after another.
Note that /rbar/status includes the whole right status bar by default.
Defining another /rbar/battery is probably what you want in order to
change color of only this.
--
Thomas Dahms
[dev] [wmii] wedged indication does not go away
Hi, some of my windows (namely Emacs and Evince) are suddenly marked (wedged). There was no obvious reason, the clients were responsive all the time. I would not bother, but the indications do not go away. New Emacs client windows from the same server instance do not have the indication. I don't really understand what is done here (changeset 2697:fe8a99d89597). If these clients were really unresponsive, shouldn't this trigger the Unresponsive event in wmiirc and thus bring up an xmessage? Thanks, -- Thomas Dahms
Re: [dev] wmii how to replace status bar with dzen2
For now I'm not bothered with colors etc. I just need a working example
of how to automatically put some data (refreshed every second) into my
/rbar/cpu. Any ideas please?
Just create a similar function and Action:
cpu() {
echo -n 'CPU:' $(sysctl -n dev.cpu.0.freq) 'MHz'
}
Action cpu
set +xv
if wmiir remove /rbar/cpu 2/dev/null; then
sleep 2
fi
echo $WMII_NORMCOLORS | wmiir create /rbar/cpu
while cpu | wmiir write /rbar/cpu; do
sleep 1
done
And then at the bottom of your wmiirc locate action status and insert
behind that:
action cpu
One more thing: Remember that wmiirc sources wmiirc_local. You should be
able to put all your customizations into an wmiirc_local without having
the need to modifiy wmiirc. Which is handy since the upstream wmiirc may
change at times. Unfortunately, I don't really know at the moment how to
use wi_events or local_events correctly inside wmiirc_local.
--
Thomas Dahms
Re: [dev] tagging rules question
Hi, Is it possible to force new windows to open floating and on a specific head (in a two head setup)? I have some windows already open, floating however they are always on the first head and in the upper left corner (not sure if there is a way to force them to open in center either?) I assume that wmii is aware of heads as the bar is only on the first head. Any help with tagging rule syntax would be appreciated. As discussed in the other thread, the new rule syntax is not well documented and not fully implemented. In particular, there is no rule yet to select the screen (head) for a client. See [1]. You will want to wait for Kris to show up on the list if you want details. [1] http://code.google.com/p/wmii/issues/detail?id=178 -- Thomas Dahms
Re: [dev] wmii opening new windows in same tag
Hi, I don't see anything about group=0 in wmii documentations. Where documentation for current wmii. if it exists, can be found? Or read wmii sources is the only way to learn this?) I think the /rules file is described in the man page of wmii, but IIRC the move of all rules into /rules instead of /colrules and /tagrules is not finished yet. This may explain the missing documentation. As I said earlier, I am not sure if this feature is in 3.9.2 already. You may want to browse the changesets to see when it was added. -- Thomas Dahms
Re: [dev] wmii opening new windows in same tag
Am 30.01.2011, 17:30 Uhr, schrieb Eitan Goldshtrom thesource...@gmail.com: Adding /.*/ group=0 to the bottom of my rules file seemed to fix the problem. However, I don't get the impression that that is the correct way to do it. Is there no global setting somewhere to make the default behavior that it shouldn't group? Matching /.*/ looks as global as it gets for me. There was a discussion on wmii's bug tracker regarding this issue. I can't find the bug number now, but essentially Kris wanted to have the grouping behavior as default (In fact there are reasons for that.) and created this group rule to obtain different behavior. There is no other global option. -- Thomas Dahms
Re: [dev] wmii opening new windows in same tag
Hi, On Fri, 28 Jan 2011 00:08:49 +0100, Eitan Goldshtrom thesource...@gmail.com wrote: Hi. Since I've upgraded to 3.9.2, or maybe since I've setup my wmiirc_local http://tinypaste.com/bbf341, I've been having a tagging problem -- that link is to a pastebin of it in case it helps. When I open a new window for anything at all, if another instance of that program is already open in another tag then the new instance opens in that tag instead of the currently active one. It is a particularly annoying problem when I want to do small things in a terminal because I need to remember in which tag has the currently open terminal and go there to retrieve the new one. You probably use something like gnome-terminal. You can set a rule like this wmiir write /rules ! /gnome-terminal/ group=0 ! In general, use xprop on your terminal and look for the WM_CLASS to fill in the snippet above. I am not sure if this kind of rule is already possible in 3.9.2. If not, you have to use the hg tip. Also, I've noticed something else since upgrading. When I Mod-p or Mod-a there is no highlighting on the currently selected item in the bar, as there was for me with 3.5. Several times I've accidentally tried to scroll through the options with the arrow keys only to realize I have to cancel and try again because I don't know what is selected. Shortly after upgrading I was messing around with the colors a bit and for a short time I did see highlighting of the selected item, but not since then. Try reverting the colors to default values. Highlighting should work. Note, however, that wimenu includes a cursor for some time now and thus moving the selection has changed to Tab and Shift-Tab. -- Thomas Dahms
Re: [dev] [dwm] window borders in Virtualbox
Am 01.11.2010 16:05, schrieb Thomas Dahms: Hi list, I am using dwm inside an Oracle Virtualbox (version 3.2.10 on Windows host, Arch Linux x86_64 guest with xorg-server 1.9.901). When switching focus between two side-by-side terminals, only the upper parts of the window borders are redrawn (down to the point where the lowest of the two cursors is). Other applications also show border drawing issues, but it's not as predictable as with terminals. When redrawing everything (by switching layouts), the borders are redrawn correctly. The funny thing is that when I try to take a screenshot of what's happening, the borders look right in the screenshot. Regardless of where I take the screenshot, host or guest. This does not occur with other window managers, but it may still not be dwm's fault. I'd be glad if someone can help. Nobody replied, which is fine because this is really not a bug in dwm. The X drivers of Virtualbox and VMWare seem to mishandle XSetWindowBorder() [1]. Attached patch (against dwm tip) works around the problem in a very ugly way, but maybe other people running Virtualbox are interested. [1] https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-vmware/+bug/312080 -- Thomas Dahms
Re: [dev] [dwm] window borders in Virtualbox
Am 01.11.2010 16:05, schrieb Thomas Dahms:
Hi list,
I am using dwm inside an Oracle Virtualbox (version 3.2.10 on Windows
host, Arch Linux x86_64 guest with xorg-server 1.9.901).
When switching focus between two side-by-side terminals, only the upper
parts of the window borders are redrawn (down to the point where the
lowest of the two cursors is). Other applications also show border
drawing issues, but it's not as predictable as with terminals. When
redrawing everything (by switching layouts), the borders are redrawn
correctly.
The funny thing is that when I try to take a screenshot of what's
happening, the borders look right in the screenshot. Regardless of where
I take the screenshot, host or guest.
This does not occur with other window managers, but it may still not be
dwm's fault. I'd be glad if someone can help.
Nobody replied, which is fine because this is really not a bug in dwm.
The X drivers of Virtualbox and VMWare seem to mishandle
XSetWindowBorder() [1].
Attached patch (against dwm tip) works around the problem in a very ugly
way, but maybe other people running Virtualbox are interested.
[1]
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-vmware/+bug/312080
--
Thomas Dahms
# HG changeset patch
# User Thomas Dahms t...@skwillt.de
# Date 1288773625 -3600
# Node ID b86e37eb3d5f0f348239b8abf72d8caf9f4b617b
# Parent 406003e3a01f8584f7bb54d0e5b1ff6585f7de6d
Virtualbox workaround.
diff -r 406003e3a01f -r b86e37eb3d5f dwm.c
--- a/dwm.c Mon Sep 27 07:53:44 2010 +
+++ b/dwm.c Wed Nov 03 09:40:25 2010 +0100
@@ -202,6 +202,7 @@
static Monitor *ptrtomon(int x, int y);
static void propertynotify(XEvent *e);
static void quit(const Arg *arg);
+static void redrawborder(Client *c);
static void resize(Client *c, int x, int y, int w, int h, Bool interact);
static void resizeclient(Client *c, int x, int y, int w, int h);
static void resizemouse(const Arg *arg);
@@ -825,6 +826,7 @@
attachstack(c);
grabbuttons(c, True);
XSetWindowBorder(dpy, c-win, dc.sel[ColBorder]);
+ redrawborder(c);
XSetInputFocus(dpy, c-win, RevertToPointerRoot, CurrentTime);
}
else
@@ -1334,6 +1336,16 @@
}
void
+redrawborder(Client *c) {
+ /* works around a bug in X drivers of Virtualbox and VMWare */
+ XWindowChanges wc;
+ wc.border_width = 0;
+ XConfigureWindow(dpy, c-win, CWBorderWidth, wc);
+ wc.border_width = c-bw;
+ XConfigureWindow(dpy, c-win, CWBorderWidth, wc);
+}
+
+void
resizeclient(Client *c, int x, int y, int w, int h) {
XWindowChanges wc;
@@ -1704,6 +1716,7 @@
return;
grabbuttons(c, False);
XSetWindowBorder(dpy, c-win, dc.norm[ColBorder]);
+ redrawborder(c);
if(setfocus)
XSetInputFocus(dpy, root, RevertToPointerRoot, CurrentTime);
}
[dev] [dwm] window borders in Virtualbox
Hi list, I am using dwm inside an Oracle Virtualbox (version 3.2.10 on Windows host, Arch Linux x86_64 guest with xorg-server 1.9.901). When switching focus between two side-by-side terminals, only the upper parts of the window borders are redrawn (down to the point where the lowest of the two cursors is). Other applications also show border drawing issues, but it's not as predictable as with terminals. When redrawing everything (by switching layouts), the borders are redrawn correctly. The funny thing is that when I try to take a screenshot of what's happening, the borders look right in the screenshot. Regardless of where I take the screenshot, host or guest. This does not occur with other window managers, but it may still not be dwm's fault. I'd be glad if someone can help. Thanks. -- Thomas Dahms
Re: [dev] [wmii] Ruby wmiirc leaving space on screen without bar
On Mon, 04 Oct 2010 15:03:18 +0200, Adam Lloyd a...@alloy-d.net wrote: Excerpts from Davide Anchisi's message of 2010-10-04 07:04:45 -0400: I have noticed that too, and it is related to the use of witray (kill it and the space disappears, but it is not a valid solution). I am using plan9port wmiirc, so it does not depend on ruby. Davide That's what I thought might be the case. Unfortunately, witray isn't running (and Arch's wmii package doesn't even seem to include it, oddly enough). witray is not in the 3.9.x branch but only in the default branch (that will become 3.10 one day). Try wmii-hg from AUR if you want the bleeding edge. In any case, you may want wmii-hg to check if your bug is already fixed in tip. Using the tip and the sh wmiirc, I don't see any spurious space in Twinview, but I never used the p9p or Ruby flavours. -- Thomas Dahms
Re: [dev] [wmii] Ruby wmiirc leaving space on screen without bar
Am 04.10.2010, 16:17 Uhr, schrieb Davide Anchisi danch...@gmail.com: Sure, I forgot to mention it: I do use wmii-hg, and the problem is with witray. Witray appears only when there is an application in the tray (you can tray nm-applet, or pidgin, for example). And along with witray appears the space on the second monitor. I had not the problem before witrayed versions (e.g. 3.9), and killing witray makes the unwanted space disappeare. I reported the bug some time ago, but got no answer nor fixes. From what I understand, Adam sees a bug with wmii 3.9.2, which has no witray. This is why I thought it may be a different bug and suggested to update his wmii installation. -- Thomas Dahms
[dev] [wmii] tagging Thunderbird windows
Hi, I have a rule for Thunderbird /Thunderbird/ tags=netz. I composed a message, which opens a new window. Then I tagged this new window +something to have it also on another tag. Later I sent the mail, which closed that window. Now, when composing another new message, these new windows still get tagged netz+something, although Thunderbirds main window is still netz only. Is this expected behavior? (Please no Thunderbird bashing in this thread.) -- Thomas Dahms
Re: [dev] [wmii] Between tiling and floating
Hi, On 07/26/2010 12:17 PM, LuX wrote: Thus I am wondering if it would be possible: 1) to increase dynamically the width of the focused column of a given percentage, say; 2) or otherwise to make the focused column overlap the others of a given percentage while the others columns keep the same width. Probably the second solution is more difficult, if not impossible, since it is not pure tiling. But in my opinion, on the screen I'm working right now, it would be much more comfortable since it keeps unchanged all the clients in unfocused columns. Pro: - Keeps the advantages of tiling modes: no action is needed to resize the focused client, neither to reduce it when it looses the focus. - Adds some advantages of floating mode: -- The focused client has more space. -- All the other clients remain partly visible, hence can be seen in a glance, contrary to stack or max mode . You might try subtle [1]. Nice window manager which uses gravities to arrange clients. You can nicely overlay and overlap several clients using this feature. As a side effect this also avoids automatic resizes, which are a pain in dwm and wmii when you view large pdf files (e.g., poster drafts) in a viewer. It has some drawbacks compared to wmii of course. Its strict tagging behavior makes it hard to use project-based tags and views instead of application-based ones out of the box, for example. And you have to like Ruby. [1] http://subforge.org/wiki/subtle -- Thomas Dahms
[dev] [wmii] Python monitor function failure
Hi,
I have this status bar function in my wmiirc.py:
@defmonitor
def anowplaying(self):
try:
np=open('/tmp/shell-fm').read()
except:
np=' '
return wmii.cache['normcolors'], np
Where /tmp/shell-fm is a now-playing file generated by shell-fm. Until
recently, this just worked, but now I get errors as attached. The
wmiirc.py then just seems to stop at this point.
--
Thomas Dahms
which: no keychain in
(/users/dahms/local/bin:/home/dahms/bin:/home/dahms/local/bin:/home/dahms/local/usr/bin:/usr/mlocal/bin:/usr/glocal/bin:/usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/x86_64-pc-linux-gnu/gcc-bin/4.4.3:/opt/ICAClient:/usr/qt/3/bin:/usr/games/bin)
Traceback (most recent call last):
File /home/dahms/local/etc/wmii-hg/python/wmiirc, line 9, in module
import wmiirc
File /home/dahms/.wmii-hg/wmiirc.py, line 59, in module
@defmonitor
File /home/dahms/local/etc/wmii-hg/python/pygmi/monitor.py, line 31, in
defmonitor
return monitor(fn)
File /home/dahms/local/etc/wmii-hg/python/pygmi/monitor.py, line 25, in
monitor
monitor = Monitor(*args, **kwargs)
File /home/dahms/local/etc/wmii-hg/python/pygmi/monitor.py, line 75, in
__init__
self.tick()
File /home/dahms/local/etc/wmii-hg/python/pygmi/monitor.py, line 93, in tick
self.button.create(*label)
File /home/dahms/local/etc/wmii-hg/python/pygmi/fs.py, line 477, in create
self.file.awrite(self.getval(colors, label), offset=0, fail=fail)
File /home/dahms/local/etc/wmii-hg/python/pygmi/fs.py, line 489, in getval
return ' '.join([Color(c).hex for c in self._colors or self.colors] +
[unicode(self._label or '')])
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 42:
ordinal not in range(128)
[dev] libixp 131 build error
Hi, make PREFIX=/home/dahms/local install throws an error, see below. Fortunately only the manpages are affected. ... MAKE install man/ Install directories: Man: /home/dahms/local/share/man INSTALL man/ixpc.1 INSTALL man/IXP_API.3 INSTALL man/IxpFcall.3 INSTALL man/IxpFid.3 INSTALL man/IxpThread.3 INSTALL man/ixp_unmount.3 INSTALL man/ixp_mount.3 INSTALL man/ixp_remove.3 INSTALL man/ixp_open.3 INSTALL man/ixp_close.3 INSTALL man/ixp_stat.3 INSTALL man/ixp_read.3 INSTALL man/ixp_write.3 INSTALL man/ixp_print.3 /bin/sh: /home/dahms/local/share/man/man3/ixp_print.3: Too many levels of symbolic links make[1]: *** [ixp_print.install] Error 1 make: *** [dinstall] Error 2 -- Thomas Dahms
Re: [dev] libixp 131 build error
Am 21.06.2010 17:13, schrieb Kris Maglione: Run 'make uninstall' first. That did help. Sorry for the alarm. -- Thomas Dahms
Re: [dev] wmii FAQ
I have these: - How to start wmii with one of the alternative wmiircs. - How to customize using the wmiirc_local variants of the wmiircs. - How to restart wmii in-place. Probably too much for the FAQ, but at least the latter two are not well documented for a beginner. On 06/11/2010 10:29 AM, Kris Maglione wrote: Hi, I'm updating the utterly aged wmii FAQ, and I'm hoping some of you can think of some frequently asked questions, or things that have caught you off guard, that I may miss. Thanks, -- Thomas Dahms
Re: [dev] wmii: floating=True not working?
On 06/10/2010 02:51 PM, Davide Anchisi wrote: I have set the following in my wmiirc_local.rc: # Tagging Rules wmiir write /rules ! /VLC|xine/ floating=True ! floating=on works, floating=True does not. Seems to be a mistake for the default sh and plan9port wmiircs in changeset 2710:41325c2ff8ec -- Thomas Dahms
[dev] [wmii] new /rules in tip
Hi, I thought it is worth mentioning how tagrules in the new /rules file work. I found the following to work (in Python): wmii.rules = ( (ur'MPlayer|VLC', dict(floating=True)), (ur'Firefox|Conkeror|Opera|Thunderbird|Shredder', \ dict(tags='netz')), (ur'Emacs|Evince|Adobe Reader', dict(tags='sel')), ) which just writes something like /Emacs|Evince|Adobe Reader/ tags=sel to /rules, for example. That said, the sh version of wmiirc still uses the old style, though there is no /tagrules file any more. Btw, you removed the standard colrules from the stock wmiirc.py. -- Thomas Dahms
[dev] libixp hg 118 install problems
Hi, the recent Makefile changes will install the libs always to /lib instead of $(PREFIX)/lib. Looking in /lib, I also found libwmii_hack.so there, so wmii probably has the same issue. Also DESTDIR seems to be completely ignored. -- Thomas Dahms
Re: [dev] libixp hg 118 install problems
Hi,
Am 24.05.2010 14:38, schrieb Kris Maglione:
Not quite. It installs it to $(LIBDIR)/../../lib. It looks like it's
always been a bug, which just happened to be copacetic when the libs
were held in ../lib instead of ../../lib.
The fix for wmii brings up a new problem (see below). This happens when
trying to build an Arch package for wmii (not libixp) with both the AUR
PKGBUILD and the one provided by you (which is a bit broken, btw). Seems
that DESTDIR is ignored here, though it is set to ${pkgdir}.
...
MKDIR /usr/share/doc/wmii
INSTALL README
/bin/sh line 1: /usr/share/doc/wmii/README: Permission denied
make: *** [simpleinstall] Error 1
--
Thomas Dahms
Re: [dev] libixp hg 118 install problems
Sorry, minor typo. It should be fixed. How is the PKGBUILD broken? It works fine for me. It will probably work if you have a local clone of the repo and just do a makepkg therein. If you look at it like the average user that tries to build a package, it works only when you already cloned the repo, so you have to comment out the _hgrepo and _hgroot lines on the first run, but then this ln -snf does not work, because the path exists, and then cd $startdir further below should read cd $startdir/src/wmii (or better cd $srcdir/wmii according to the Arch guidelines). -- Thomas Dahms
Re: [dev] wmii: Modifier+mouse click?
I was hoping to bind a shortcut of MOD-mousescrolldown to flip to the next window, ala Mod-J, and Mod-mousescrollup to flip to the previous window in the stack, ala Mod-K. But I can't figure out how to do it. The ClientMouseDown event seems to only tell us which button is pressed. A while ago, I used to use xbindkeys to bind Mod4+Mousewheel for scrolling the clients in a column. I can't tell the exact syntax, but the manpage of xbindkeys is helpful to find out how to bind mouse buttons and then you just have to bind a call to the desired wmiir command. -- Thomas Dahms da...@gmx.com
Re: [dev] [dwm] patch - nametag
On Thu, 29 Oct 2009 12:11:55 -0700 Evan Gates evan.ga...@gmail.com wrote: This patch allows you to change the names of dwm's tags while it's running. I find it's useful to change one of my 'misc' tags to a more descriptive name if I find myself working on something specific for a few hours. I like this. It made me switch from wmii to dwm. At least for today. -- Thomas Dahms da...@gmx.com
[dev] [wmii] hg2574 fails to build
Hi, this is what I get (using the Arch PKGBUILD from AUR): ... LD cmd/wmii/wmii.out cc: ../lib/libregexp9.a: No such file or directory cc: ../lib/libbio.a: No such file or directory cc: ../lib/libfmt.a: No such file or directory cc: ../lib/libutf.a: No such file or directory make[2]: *** [wmii.out] Error 1 make[1]: *** [dall] Error 2 make: *** [dall] Error 2 -- Thomas Dahms
[dev] [wmii] wmiir broken in 2546
Hi, wmiir xwrite /ctl exec wmii wmiir: fatal: Can't open file 'xwrite': file not found Just an example. This happens with any ls, read, write, or xwrite. -- Thomas Dahms
Re: [dev] [wmii] wmiir broken in 2546
On Wed, 14 Oct 2009 03:20:02 -0400 Kris Maglione maglion...@gmail.com wrote: Thanks, I don't know how I missed that. Thanks for the fast fix. Now this: ... MAKE all doc/ MAKE all man/ TXT2TAGS man/wmiir.man1 /bin/sh: txt2tags: command not found make[1]: *** [wmiir.1] Error 127 make: *** [dall] Error 2 I got the txt2tags error before, since I have no txt2tags here, but the make error is new. -- Thomas Dahms da...@gmx.com
Re: [dev] [wmii] wmiir broken in 2546
... MAKE all doc/ MAKE all man/ TXT2TAGS man/wmiir.man1 /bin/sh: txt2tags: command not found make[1]: *** [wmiir.1] Error 127 make: *** [dall] Error 2 I got the txt2tags error before, since I have no txt2tags here, but the make error is new. Mmh, builds now on a second try, although I used a fresh clone before. Don't know what's the deal about this. -- Thomas Dahms da...@gmx.com
Re: [dev] wmii: Question on wmiirc_local.py
On Tue, 6 Oct 2009, Kris Maglione wrote:
On Wed, Sep 30, 2009 at 03:09:43PM -0400, Kris Maglione wrote:
Well, to start with, you don't need to import all of those modules. Aside
from that, you bring up a good point: key bindings are interpolated from
events.keydefs when they're defined. You're changing them after that point.
I'll see what I can do before the next snapshot. It will be fixed before
3.9 is released. For now, just copy wmiirc.py to ~/.wmii and edit that.
This is fixed in tip. events.keydefs can be changed in wmiirc_local.py and
the changes will be applied when the event loop starts.
Thanks for this. But other issues occur:
- pygmi has to be imported into wmiirc_local.py. This should be documented
somewhere.
- Color definitions in wmiir_local.py are only partially applied.
- Cannot undefine monitor functions defined in wmiirc.py. Or am I missing
something? I don't want to see the load.
Find attached my wmiirc_local.py and a screenshot showing the odd colors.
The clock is now properly updating, but I don't know whether pulling it
into wmiirc_loca.py or pulling the import line out of the function fixed
it.
I'd be glad if you could also have a look at issue 132, which is kind of
annoying.
--
Thomas Dahmsattachment: screen.pngimport pygmi
from pygmi import *
from pygmi import events
# Keys
events.keydefs = dict(
mod='Mod4',
left='Left',
down='Down',
up='Up',
right='Right')
# Theme
background = '#33'
floatbackground='#22'
wmii['font'] = '-*-clean-medium-r-*-*-12-*-*-*-*-*-iso10646-*'
wmii['normcolors'] = '#88', '#22', '#33'
wmii['focuscolors'] = '#ff', '#285577', '#4c7899'
terminal = 'wmiir', 'setsid', 'uxterm'
@defmonitor
def battery(self):
for line in open('/proc/acpi/battery/BAT1/state','r'):
if len(line.split()) = 3 and line.split()[0] == 'remaining':
return line.split()[2] + 'mAh'
return 'no battery info'
@defmonitor
def netz(self):
return call('iwgetid', '-r')
from datetime import datetime
@defmonitor
def time(self):
return datetime.now().strftime('%a %d %b %T')
wmii.tagrules = (
('MPlayer|VLC', '~'),
('Conkeror|Firefox|Opera|Shiretoko|Claws Mail|Sylpheed', 'netz'),
)
[dev] wmii: Question on wmiirc_local.py
Hi, I tried the Python wmiirc today. As I understand the documentation, all I have to do is put wmiirc_local.py to ~/.wmii-hg and leave everything else in /etc. Then wmii -r python/wmiirc starts with the Python wmiirc, but anything in wmiirc_local.py is ignored. So far I tried only key bindings adjustments. My wmiirc_local.py looks like this: import operator import os import re import sys import traceback import pygmi from pygmi import * from pygmi import events events.keydefs = dict( mod='Mod4', left='Left', down='Down', up='Up', right='Right') Am I doing anything wrong? -- Thomas Dahms
Re: [dev] wmii: Question on wmiirc_local.py
On Wed, 30 Sep 2009 15:09:43 -0400 Kris Maglione maglion...@gmail.com wrote: Well, to start with, you don't need to import all of those modules. Aside from that, you bring up a good point: key bindings are interpolated from events.keydefs when they're defined. You're changing them after that point. I'll see what I can do before the next snapshot. It will be fixed before 3.9 is released. For now, just copy wmiirc.py to ~/.wmii and edit that. Cool, thanks. Btw, the history files are named history.prog and history.action for the Python wmiirc and history.progs and history.actions for the sh version. Only history.tags is common. May be good to have the same names in order to reuse the history when changing the config. -- Thomas Dahms
Re: [dev] wmii: Question on wmiirc_local.py
On Wed, 30 Sep 2009 15:09:43 -0400 Kris Maglione maglion...@gmail.com wrote: For now, just copy wmiirc.py to ~/.wmii and edit that. I should have tried before replying. This did not work. I had to copy the whole python/ from /etc/wmii-hg to ~/.wmii-hg and edit wmiirc.py in there. I guess the import wmiirc in python/wmiirc gives always priority to the working directory regardless of sys.path. -- Thomas Dahms
Re: [dev] hg tip fails on make target `rc.wmii.out'
On Tue, 29 Sep 2009 15:00:09 -0400 Kris Maglione maglion...@gmail.com wrote: On Tue, Sep 29, 2009 at 11:03:01AM -0700, Suraj Kurapati wrote: Please observe: ... make[1]: *** No rule to make target `rc.wmii.out', needed by `all'. Stop. make: *** [dall] Error 2 Thanks, fixed. That was fast. But now this: ... MAKE all doc/ make[1]: *** No rule to make target `all'. Stop. make: *** [dall] Error 2 -- Thomas
