[dev] colmode stack+max cannot be written to /ctl
Hi, in the latest tip of wmii, upon echo -n "colmode stack+max" | wmiir write /ctl or echo -n "colmode default+max" | wmiir write /ctl I get wmiir: fatal: cannot write file /ctl While echo -n "colmode stack" | wmiir write /ctl and echo -n "colmode default" | wmiir write /ctl work fine. Is this supposed behaviour? I would like to set stack+max as default mode... Thanks -- Thomas
[dev] [wmii] wmii9menu and xinerama
Hi, I recently adapted my wmiirc_local such that when I right-click on a tagname in the statusbar, I get a wmii9menu with the names of the clients in that tag. When I attach my secondary screen left of the primary, half of the wmii9menu window is displayed on the secondary screen. Can this be avoided in some way, i.e. can I have the whole wmii9menu window on one of the screens? It is particularly annoying since my secondary screen has a lower resolution than the primary, thus part of the wmii9menu is hidden below the lower border of the screen. Thanks for the great work, James
Re: [dev] [wmii] wmii9menu and xinerama
On Wed, Oct 21, 2009 at 04:34:20AM -0400, Kris Maglione wrote: > Sure, please file an issue. Hmm, I need a Google account for that? ... No! :-) James
Re: [dev] [wmii] wmii9menu and xinerama
On Wed, Oct 21, 2009 at 10:44:25AM +0200, Thomas Dean wrote: > On Wed, Oct 21, 2009 at 04:34:20AM -0400, Kris Maglione wrote: > > Sure, please file an issue. > > Hmm, I need a Google account for that? ... No! :-) Okay, I did it anyway... but why google? :-( James
Re: [dev] [wmii] problem with wmiir xwrite /client/$client/ctl kill
I ran into the same problem today. The wmiirc script as well as all my
status bar scripts die frequently. All of them are run with dash.
Switching /bin/sh from dash to bash (and replacing dash with bash in
wmiirc) fixes the problem. It seems to be related to the latest update
of dash (0.5.5.1-5) in Debian.
One example is the attached script, which shows my mail count, and
shows ~/.fetchmaillog on a right click. Strangely, the script survives
multiple right clicks (the file is shown in multiple windows), but
dies as soon as one of those windows is closed, either via C-c, or via
Mod-Shift-c.
-
#!/bin/sh
# show email information in the status bar
# Configuration
delay=10
barname="8-mail"
maildir="$HOME/.Maildir"
# Functions
mailcount() {
echo -n `ls -l $@ | grep ^- | wc -l`
}
output() {
echo -n Mail `mailcount $maildir/new` `mailcount $maildir/.Lists*/new`
}
# Trigger event such that previous instances can quit
echo Start $barname | wmiir write /event
# Create bar with content
echo "$WMII_BARCOLORS" | wmiir create /rbar/$barname
wmiir xwrite /rbar/"$barname" `output`
# Event loop
{ wmiir read /event & childpid=$!
while true; do
echo "$barname" `output` || { kill $childpid; exit; }
sleep $delay
done &
} | while read event
do
set -f
set -- $event
set +f
type="$1"; shift
case "$type" in
# Exit if another instance starts up
Start)
if test "$1" = "$barname"; then
break
fi;;
# Write output to bar. If that fails, exit.
"$barname")
wmiir xwrite /rbar/$barname "$@" || exit;;
# React to clicks on our bar
RightBarClick)
if test "$2" = "$barname"; then
case "$1" in
1)
fetchmail &;;
3)
x-terminal-emulator -e tail -n 200 -f
~/.fetchmaillog &;;
esac
fi;;
esac
done
Re: [dev] [wmii] problem with wmiir xwrite /client/$client/ctl kill
On Thu, May 27, 2010 at 11:22:25 +0200, Thomas Dean wrote: > I ran into the same problem today. The wmiirc script as well as all my > status bar scripts die frequently. All of them are run with dash. > Switching /bin/sh from dash to bash (and replacing dash with bash in > wmiirc) fixes the problem. It seems to be related to the latest update > of dash (0.5.5.1-5) in Debian. The problem could also be in the previous version. I run Debian testing and updated 0.5.5.1-3 to 0.5.5.1-5 recently. Thomas
Re: [dev] [wmii] problem with wmiir xwrite /client/$client/ctl kill
On Thu, May 27, 2010 at 11:32:06 -0400, Kris Maglione wrote: > Ok, so that suggests that dash has a problem when its backgrounded > children die. Can you try running them with ‘wmiir setsid’ and see if > it helps? Hmm, I'm not sure what I should do. Should I place "wmiir setsid" as a command somewhere in the beginning of the script? Sorry, I am not so familiar with this kind of things. If that's what you meant, it does not help, the scripts still die. I would be happy to investigate the issue further, but I might need more detailed instructions... Thanks and best, Thomas
Re: [dev] [wmii] problem with wmiir xwrite /client/$client/ctl kill
On Thu, May 27, 2010 at 11:55:38 -0400, Kris Maglione wrote: > Oh, sorry, I thought it was in the man page. Just add ‘wmiir setsid’ to > the front of the lines that start fetchmail and x-terminal-emulator. Ok, I just did that, but it did not change anything. Nor is there any further output when the script dies. Should there? I don't know what "wmiir setsid" does... Anything else I can do?
Re: [dev] [wmii] problem with wmiir xwrite /client/$client/ctl kill
On Thu, May 27, 2010 at 12:31:42 -0400, Kris Maglione wrote: > It's not supposed to have any output. It just basically disassociates a > process from its parent. You should generally use it when launching > programs from wmiirc so they don't catch any signals if you kill wmiirc. > This would be easier if I could duplicate this. I think your best bet is > some hack like this: > > --- fetchmail.sh 2010-05-27 12:30:39.0 -0400 > +++ - 2010-05-27 12:30:48.882841963 -0400 > @@ -49,7 +49,7 @@ > 3) > - x-terminal-emulator -e tail -n 200 -f > ~/.fetchmaillog &;; > + ( wmiir setsid x-terminal-emulator -e tail -n > 200 -f ~/.fetchmaillog & )&;; > esac With that the script already dies as soon as the fetchmaillog window opens :-) Given that this seems to be a problem of dash, maybe I should file a Debian bug report...
Re: [dev] [wmii] problem with wmiir xwrite /client/$client/ctl kill
On Thu, May 27, 2010 at 14:22:27 -0400, Kris Maglione wrote: > > With that the script already dies as soon as the fetchmaillog window > > opens :-) Given that this seems to be a problem of dash, maybe I > > should file a Debian bug report... > > That would probably be a good idea, if you can come up with a good > test case. The simplest idea, dash -c 'while true; do xterm & sleep 10; done' unfortunately does not die when I kill the xterm. But I will look into it, reducing the script I have as much as possible.
Re: [dev] [wmii] problem with wmiir xwrite /client/$client/ctl kill
On Thu, May 27, 2010 at 20:44:17 -0400, Kris Maglione wrote: > For what it's worth, I've sent a report to the dash mailing list. The > offending revision is 3800d4934391b144:[JOBS] Fix dowait signal race > > This means that the bug was introduced just after 0.5.5.1 and first > showed up in 0.5.6, so if you can revert to some prior version, you > should be golden. Thanks for looking into this and even filing a report, Kris. For what it's worth, I just switched /bin/sh to /bin/bash for the moment, and I'll just wait until dash gets fixed. Thomas
[dev] wmii-hg2663: Compile error on Debian
Trying to compile hg2663 on Debian testing with "make" or "make deb", I get cmd/tray/selection.c:50:26: error: X11/Xlib-xcb.h: No such file or directory In file included from /usr/include/xcb/xproto.h:15, from cmd/tray/selection.c:51: /usr/include/xcb/xcb.h:328: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘*’ token /usr/include/xcb/xcb.h:364: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘*’ token It appears that Xlib-xcb.h does not exist in any Debian package. Thomas
Re: [dev] wmii-hg2663: Compile error on Debian
On Fri, May 28, 2010 at 15:49:39 +0200, Davide Anchisi wrote: > That's right, you need to install the package: libx11-xcb-dev. Stupid me, I searched on packages.debian.org, but only in the etch suite. Thanks, it works now! Thomas
Re: [dev] [wmii] problem with wmiir xwrite /client/$client/ctl kill
On Fri, May 28, 2010 at 20:52:06 -0400, Kris Maglione wrote: > They've worked out the problem on the dash list. The following patch > *should* fix your script. Alternatively, you could try the version > attached with wmii tip. Thanks for the scripts, Kris! Thomas
[dev] [wmii] grow command does not work on floating mplayer
Hi, mplayer windows keeps a fixed aspect ratio when floating. Growing such windows via wmiir does not seem to work, because one can only grow either horizontally or vertically, but not both at the same time. (Shrinking works, the other direction gets shrunk accordingly.) Is there any way to still grow floating mplayer windows without the mouse? Thanks and best, Thomas
Re: [dev] [wmii] grow command does not work on floating mplayer
On Thu, Oct 28, 2010 at 09:56:13 -0400, Kris Maglione wrote: > Fixed in tip. Thanks, that was fast, works great! I noticed another problem introduced in hg2782: In rc/wmiirc.sh, local_events | wi_events needs to be replaced by wi_events local_events in order for the local events to work.
Re: [dev] [dwm] visible only if needed [patch]
On Mon, Jul 04, 2011 at 11:37:15 +0200, julien steinhauser wrote: > Code from Hiltjo Posthuma and Jeremiah Dow ( with minor add ) is merged in > this patch. > The behaviour is : > > - border is shown when one sees more than one client. > - tags are shown when they are viewed or when clients are labelled with them. I like the idea of having only used tags visible. One problem with this patch though is that dwm loses all tags when restarting. Before, the tagging survived restarting, which is very nice when playing with config.h. I don't understand the mechanisms behind it, thus I am unfortunately not able to fix this myself.
Re: [dev] [dwm] visible only if needed [patch]
On Thu, Jul 07, 2011 at 13:48:27 +0200, Hiltjo Posthuma wrote: > I don't think vanilla dwm remembers tags when restarting so it's not > that the patch removes that behaviour. You can specify rules in your > config.h which tags to apply to each application. You are right, I was remembering it incorrectly. I run a loop at the end of my .xsession that keeps restarting dwm. Somehow I thought I remembered that the tag would be preserved in the loop. Sorry for the confusion.
Re: [dev] dwm: xclip problem
On Sun, Jul 10, 2011 at 09:49:43 -0700, brad clawsie wrote:
> i recently created a shell script called "pastexclip" which contains the text
>
> xclip -o
>
> and bound this in dwm to Alt+v
>
> but when i use my dwm shortcut Alt+v, the text is printed not to the
> current context in X, but the system console (i.e. i see it after
> exiting X)
I pipe the output of xclip through xmacroplay, like this:
#!/bin/sh
sleep 0.2
{
echo -n 'String '
xclip -o
} | xmacroplay -d 3 :0
which I also bound to Modkey-v. The sleep statement ensures that I can let
go of the Modkey in time. Otherwise the outcome can be ugly :-)
Re: [dev] dwm 6.0
On Mon, Dec 19, 2011 at 17:08:54 +0100, Thomas Dean wrote: > > (M == Mod1, right?) What I'm seeing is that, if I press Mod1-i (-d), say 3 > > times too many, then I need to press Mod1-d (-i) *4* times for it to have > > any effect. > > Also, when nmaster=1 and pressing Mod1-d, nmaster seems to become infinity. > I see this as a feature, but is it intended? Of course, now I see it: 0=infinity in this case, i.e. slave effectively becomes master :-)
Re: [dev] dwm 6.0
On Mon, Dec 19, 2011 at 16:50:01 +0100, Manolo Martínez wrote: > (M == Mod1, right?) What I'm seeing is that, if I press Mod1-i (-d), say 3 > times too many, then I need to press Mod1-d (-i) *4* times for it to have any > effect. Also, when nmaster=1 and pressing Mod1-d, nmaster seems to become infinity. I see this as a feature, but is it intended?
Re: [dev] dwm 6.0
On Mon, Dec 19, 2011 at 11:21:28 -0500, Andrew Hills wrote: > > Of course, now I see it: 0=infinity in this case, i.e. slave effectively > > becomes master :-) > > Be careful when creating a power vacuum. Eliminating the remaining > authority will lead to anarchy as the slaves all scramble to create a > new class of masters. :-) More of this on this list please!
[dev] [dwm] Tags vs Monitors
I've used dwm for about half a year now (3 years of wmii before), and like it a lot. However, I find that the handling of tags for multiple monitors keeps disturbing my workflow. Isn't it against the general philosophy of dwm to assign a definite monitor to each window, and to have separate tagsets for each monitor? I usually use tags as a sort of "grouping" of windows pertaining to certain tasks. With only one monitor, dwm works wonderfully for me, and I never have to think about arranging windows. But with two monitors, I constantly find myself moving windows between the two, and searching for windows that I "lost" because I put them on the other monitor, which makes them lose their previously assigned tags. I would imagine that the (or my at least) workflow could be much smoother if there was only one tagset, independently of the number of monitors, and if there were (a) layout(s) suitable for multi-screen views. The first useful layout for two monitors that would come to my mind would consist of two master windows plus one stack on one of the two monitors. What do you guys think? How do you make efficient use of two monitors? Do you find the current tag/monitor paradigm useful? I would be very interested in your opinions. Best, TD
Re: [dev] [dwm] Tags vs Monitors
On Thu, Jan 12, 2012 at 18:09:15 +, Rob wrote: > > I would imagine that the (or my at least) workflow could be much smoother > > if there was only one tagset, independently of the number of monitors, and > > if there were (a) layout(s) suitable for multi-screen views. The first > > useful layout for two monitors that would come to my mind would consist of > > two master windows plus one stack on one of the two monitors. > > > > What do you guys think? How do you make efficient use of two monitors? Do > > you find the current tag/monitor paradigm useful? I would be very > > interested in your opinions. > > I had this thought, but how would you implement it? What if you selected > the same tagset on each monitor? You can only display a window in a single > place, so it couldn't be on both monitors at the same time, think about > it. It can't be done unless you can somehow clone the window or something > (I'm not very clued up on X11). This problem would come up if there was only one tagset and each monitor would be an independent view whose visible tags could be set independently. I rather meant that there should be only one tagset, and all monitors together would form a combined view, i.e. both monitors would always have the same set of tags visible. Each window should still be assigned a definite monitor. I'm sorry if my previous description was unclear, and hope that this one clarifies it.
Re: [dev] [dwm] Tags vs Monitors
On Thu, Jan 12, 2012 at 17:44:56 -0500, TJ Robotham wrote: > > But with two monitors, I constantly find myself moving windows between the > > two, and searching for windows that I "lost" because I put them on the other > > monitor, which makes them lose their previously assigned tags. > > You might find it helpful to go into sendmon and delete that one line that > resets the window's tags to whatever's currently visible on the other monitor. > That was pretty much the first thing I did when multihead support was added, > since I rarely want to both move a window between monitors and retag it. Thank's a lot for this hint! This would result in almost exactly what I want. In fact, if combined with a patch that would keep the set of visible tags on both screens in sync, I think it would be exactly what I want. Does anyone know how to achieve the latter?
Re: [dev] [dwm] Tags vs Monitors
On Fri, Jan 13, 2012 at 21:48:47 +, Bjartur Thorlacius wrote: > >This problem would come up if there was only one tagset and each monitor > >would be an independent view whose visible tags could be set independently. > >I rather meant that there should be only one tagset, and all monitors > >together would form a combined view, i.e. both monitors would always have > >the same set of tags visible. Each window should still be assigned a > >definite monitor. I'm sorry if my previous description was unclear, and > >hope that this one clarifies it. > > That sounds great. At that point I would in fact expect dynamic > monitor assignment. I think that's what I meant in my first email by "layout(s) suitable for multiple screens".
Re: [dev] [dwm] Tags vs Monitors
On Fri, Jan 13, 2012 at 21:57:31 +, Rob wrote:
> Check /(toggle)?(view|tag)/ functions in dwm.c
> Or you could change arrange() so it sets the tagset for all other monitors too
I looked into this, and the attached patch seems to result in exactly what
I asked for -- synchronized tags across monitors. Thanks for your help!
# HG changeset patch
# Parent 64831f9265e00631a32effa1ce03efb69b2521d5
diff -r 64831f9265e0 dwm.c
--- a/dwm.c Mon Nov 14 14:35:42 2011 -0500
+++ b/dwm.c Mon Jan 16 11:17:47 2012 +0100
@@ -1467,7 +1467,6 @@
detach(c);
detachstack(c);
c->mon = m;
- c->tags = m->tagset[m->seltags]; /* assign tags of target monitor */
attach(c);
attachstack(c);
focus(NULL);
@@ -1751,12 +1750,16 @@
void
toggleview(const Arg *arg) {
+ Monitor *m;
+
unsigned int newtagset = selmon->tagset[selmon->seltags] ^ (arg->ui &
TAGMASK);
if(newtagset) {
- selmon->tagset[selmon->seltags] = newtagset;
+ for(m = mons; m; m = m->next)
+ m->tagset[m->seltags] = newtagset;
focus(NULL);
- arrange(selmon);
+ for(m = mons; m; m = m->next)
+ arrange(m);
}
}
@@ -2032,13 +2035,17 @@
void
view(const Arg *arg) {
+ Monitor *m;
+
if((arg->ui & TAGMASK) == selmon->tagset[selmon->seltags])
return;
selmon->seltags ^= 1; /* toggle sel tagset */
if(arg->ui & TAGMASK)
- selmon->tagset[selmon->seltags] = arg->ui & TAGMASK;
+ for(m = mons; m; m = m->next)
+ m->tagset[m->seltags] = arg->ui & TAGMASK;
focus(NULL);
- arrange(selmon);
+ for(m = mons; m; m = m->next)
+ arrange(m);
}
Client *
Re: [dev] [dwm] strange behavior with mupdf
On Thu, Feb 02, 2012 at 14:45:42 +0100, Uli Armbruster wrote: > Means, only after refocusing mupdf, it looks fine. It doesn't depend on > this certain pdf file, it happens with all pdf files. It also doesn't > depend on the layout I use. Using no layout (floating) it's fine. I have the exact same problem. This is the only annoyance of dwm for me.
Re: [dev] dwm window outline during mouse resize/move patch
On Fri, Jun 01, 2012 at 23:04:29 -0400, John A. Grahor wrote: > I have included a patch for dwm-5.8.2 in which I basically stole the > wire frame move/resize code from evilwm and adapted it for dwm. > > If anyone is interested I'll do a patch for a more modern release. I like this patch a lot. When dealing with floating windows, I often find myself wanting to resize a window by moving other corners than the lower-right one. Would anyone else like this? Has anyone tried implementing this?
Re: [dev] [surf] keyboard shortcut not working
On Sat, Oct 13, 2012 at 13:56:48 +0200, Thuban wrote: > I was just meaning the shortcus defined in config.h, nothing else. > > I just tried your changes, but I still can't, as example, scroll with > control-j. > > Am I the only one with this issue? I have the same problem since changeset 246. None of the keyboard shortcuts work anymore, and there are no error messages.
Re: [dev] snotes v0.9 - a simple notes system
Great tool, thank you! One thing to mention: sh links to dash in my case, which has no built-in "source" command. Is there a standalone substitute? TD
[dev] Find window with dmenu
I often have many windows open (mostly with pdf files I need to read), and try to come up with a tool that lets me find and focus a window easily. I now simply list all windows with xwininfo and feed that to dmenu. But the list is full of invisible/dummy windows I don't care about. I clean the list somewhat with sed, but I can't figure out how to cleverly filter out all the unwanted windows in the list. See the attached scripts. Does anyone know a solution for this? Is there an existing tool that lists all "visible" windows along with their id? #!/bin/sh wmctrl -i -a $(windowlist | dmenu -i -l 50) #!/bin/sh xwininfo -tree -root \ | sed 's/\s\+//' \ | grep '^0x[^ ]* "[^<]' \ | sed 's/") [1-90].*/")/' \ | grep -v ': ()' \ | grep -v 'Qt-subapplication' \ | grep -v '" ":' \ | grep -v '"GnuCash":' \ | grep -v '"keepassx":' \ | grep -v '"knotify4":' \ | grep -v '"kded4":' \ | grep -v '"opera":' \ | grep -v '"Opera":' \ | grep -v '"operapluginwrapper":' \ | grep -v '"surf":' \ | grep -v '"Vim":' \ | grep -v '"VIM":' \ | grep -v '"Worker":' \ | grep -v '"xautolock":' \ | grep -v '"XOSD":'
Re: [dev] Find window with dmenu
Yes, my solution is very ad hoc, I'm sure it can be improved in many ways. But I'm looking for something that avoids the problem to begin with. On Tue, Feb 12, 2013 at 17:39:30 +0800, Chris Down wrote: > Just a comment on your method rather than your problem, calling ''grep'' > that many times through that many pipes is fairly expensive and should be > avoided, since it has to create each new process and pass the same data > through every single one. You'd be better using awk and a single pipe. > > Chris > > On 12 February 2013 17:36, Thomas Dean <78...@web.de> wrote: > > > I often have many windows open (mostly with pdf files I need to read), and > > try to come up with a tool that lets me find and focus a window easily. I > > now simply list all windows with xwininfo and feed that to dmenu. But the > > list is full of invisible/dummy windows I don't care about. I clean the > > list somewhat with sed, but I can't figure out how to cleverly filter out > > all the unwanted windows in the list. See the attached scripts. Does anyone > > know a solution for this? Is there an existing tool that lists all > > "visible" windows along with their id? > > > >
Re: [dev] Find window with dmenu
On Tue, Feb 12, 2013 at 11:07:52 +0100, Michał Kazior wrote: > You might consider using lsw (http://tools.suckless.org/lsw). Excellent! I think I tried it earlier, but it did not list the window id's back then. Now it does the job perfectly, thanks!
Re: [dev] Find window with dmenu
On Tue, Feb 12, 2013 at 16:40:55 +0100, Andreas Amann wrote: > the ids of visible windows is stored in the _NET_CLIENT_LIST property of the > root window and can be accessed with "xprop -root _NET_CLIENT_LIST" > > The followning script lets you select one with dmenu and then focus it: Thank you for the script!
Re: SV: [dev] Why HTTP is so bad?
On Wed, May 22, 2013 at 20:37:47 +0200, seb.cato wrote: > I'm not a hater most of the time though. HTTP and by extension the > web is quite organic. It's like a rain forest. There's a lot of > things in there, and a lot of it is redundant and some things serves > no real purpose, but at the same time the bio-diversity is > wonderful. It's very refreshing to see such a positive stance on this list!
