monsterwm! ~ yet another tiny wm

Šaran · 2012-10-16 16:45:07

Here is my clickable dzen2-svn startup script (I'm using LemonBar now) with stlarch icons for workspaces and editable colors. Right click on middle of the bar spawn another dzen pipped with different conky config for additional info I don't want to be seeing all the time (wifi info, temps, cpu and ram usage, weather).

#!/usr/bin/env bash

# Create a fifo to send output
ff="/tmp/monsterwm.fifo"
[[ -p $ff ]] || mkfifo -m 600 "$ff"

font="-*-ohsnap-medium-*-*-*-13-*-*-*-*-*-*-*"

backg="#242424"  #background
color1="#CDEE69" #selected, layout
color2="#B0B0B0" #text
color3="#E09690" #urgent


## Conky ##
# Blank centered dzen spawning another instance piped with conky on right click
dzen2 -e 'button3=exec:$HOME/bin/dzen_info' -h 16 -w 1620 -x 150 -ta c -fn "$font" -bg "$backg" -fg "$color2" -p &

# Right dzen piped with conky clock
while :; do conky -c $HOME/.conky/monsterwm
done | dzen2 -e '' -h 16 -w 150 -x 1770 -ta r -fn "$font" -bg "$backg" -fg "$color2" -p &

while read -r; do
    [[ $REPLY =~ ^(([[:digit:]]+:)+[[:digit:]]+ ?)+$ ]] && read -ra desktops <<< "$REPLY" || continue
        for desktop in "${desktops[@]}"; do
        IFS=':' read -r d w m c u <<< "$desktop"
        case $d in
            0) d="^ca(1,xdotool key alt+1)^i($HOME/bin/xbm/dice1.xbm)^ca()"  s="" ;;
            1) d="^ca(1,xdotool key alt+2)^i($HOME/bin/xbm/dice2.xbm)^ca()"  s="" ;;
            2) d="^ca(1,xdotool key alt+3)^i($HOME/bin/xbm/dice3.xbm)^ca()"  s="" ;;
            3) d="^ca(1,xdotool key alt+4)^i($HOME/bin/xbm/dice4.xbm)^ca()"  s="" ;;
            4) d="^ca(1,xdotool key alt+5)^i($HOME/bin/xbm/dice5.xbm)^ca()"  s="" ;;
        esac
        ((c)) && f="$color1" && case $m in   #selected workspace
            0) i="^fg($color2)^i($HOME/bin/xbm/tile.xbm)"    ;;
            1) i="^fg($color2)^i($HOME/bin/xbm/monocle.xbm)" ;;
            2) i="^fg($color2)^i($HOME/bin/xbm/bstack.xbm)"  ;;
            3) i="^fg($color2)^i($HOME/bin/xbm/grid.xbm)"    ;;
            4) i="^fg($color2)^i($HOME/bin/xbm/float.xbm)"   ;;
        esac || f="$color2"   #other workspaces
        ((u)) && f="$color3"  #urgent
        ((w)) && r+="$s ^fg($f)$d°^fg()" || r+="$s ^fg($f)$d^fg() "     #dwm style
#       ((w)) && r+="$s ^fg($f)$d $w^fg()" || r+="$s ^fg($f)$d^fg() "   #number of windows
    done
    printf "%s%s\n" "$r" " $i" && unset r

# Left dzen showing workspaces
done < "$ff" | dzen2 -e '' -h 16 -w 150 -ta l -fn "$font" -bg "$backg" -fg "$color1" -p &

# Pass output to fifo
monsterwm > "$ff"

#!/usr/bin/env bash
# ~/bin/dzen_info
font="-*-ohsnap-medium-*-*-*-13-*-*-*-*-*-*-*"

backg="#242424"  #background
text="#B0B0B0"

conky -c $HOME/.conky/dzen | dzen2 -e 'button1=exit;button3=exit' -h 15 -w 1620 -x 150 -ta c -fn "$font" -bg "$backg" -fg "$text" -p &

And can somebody please help me with this.

Šaran wrote:

When I was using dzen2 for statusbar, I had had configured bind that spawned another instance piped with conky (wifi, temperatures, weather) over the empty part of bar. It was set to close on click.
Is there any way to add conky (preferably) or some script output to lemonbar on bind. Currently it only shows date and time which is fine most of the time, but sometimes I need extra info.
Can anybody help me adapt my startup script (taken from Simon.Swe) for conky?
#!/usr/bin/env bash

wm=monsterwm
ff="/tmp/$RANDOM.monsterwm.fifo"
tags=('' '' '' '' '')
layouts=('' '' '' '' '') 

[[ -p $ff ]] || mkfifo -m 600 "$ff"

function statusbar {
    echo "\r\f9 $(date +"%a %d") \f2- \f3$(date +"%H:%M") "
}

while read -t 1 -r wmout || true; do
    if [[ $wmout =~ ^(([[:digit:]]+:)+[[:digit:]]+ ?)+$ ]]; then
        read -ra desktops <<< "$wmout"

        tmp=
        for desktop in "${desktops[@]}"; do
            IFS=':' read -r d w m c u <<< "$desktop"
            # Tags labels
            label=${tags[$d]}
            # Current desktop
            ((c)) && fg="4" bg="0" lc="\u0 " rc=" \ur" && layout="\f2"${layouts[$m]} || fg="2" bg="0" lc=" " rc=" "
            # Has windows
            ((w)) && ((! c)) && fg="9" lc="\u0 " rc=" \ur"
            # Urgent windows
            ((u)) && fg="3" bg="0" lc="\u0 " rc=" \ur"

            tmp+="\f$fg\b$bg$lc$label$rc\fr\br"
        done

        tmp+=" $layout"
    fi
    echo "$tmp $(statusbar)"
done < "$ff" | bar &

$wm > "$ff"

rm $ff
I have tried this script, but workspace indicator lags for about a minute after starting wm (icon changes color few seconds after switching workspaces).

Last edited by Šaran (2012-10-16 16:47:40)

Unia · 2012-10-16 16:59:52

^ I see you use xdotool for this little hack. I take it then there's no 'native' way of doing this with MonsterWM?

Also, I have another question: Can I use a single dzen2 instance, that both contains the WM info as well as statusbar?

c00kiemon5ter · 2012-10-16 17:00:42

Unia wrote:

I also decided to play around with MonsterWM. For now I'm just using the default branch, but once I think I could use it for longer periods of time I will try to combine the uselessgap branch with the initlayout one. (any tips to accomplish this easy? )

$ git clone https://github.com/c00kiemon5ter/monsterwm.git   # get the repo
$ git cherry-pick origin/uselessgaps
$ git cherry-pick origin/initlayouts
$ make
$ vim config.h     # configure .. 
$ sudo make install

Unia wrote:

1. Can I somehow configure this so when I left-click the desktop name in dzen2, MonsterWM will switch to that desktop? I know dzen2 supports mouseclicks, I just need to know if there's some way I can use those to call Monster to switch desktop.

yep, just like Šaran showed in the above script, use dzen2's '^ca' escape code to invoke 'xdotool key ...' with the combination to switch to the desired desktop

Unia wrote:

2. The separators and tiling layout indicator are a gray color. I don't have this specified in my script and would like these to be the normal foreground color. Where can I change this?

separators on the gist are denoted as '$s' , so changing line 41

((w)) && r+="$s ^fg($f)$d $w^fg() " || r+="$s ^fg($f)$d^fg() "

to

((w)) && r+="^fg(#COLOR)$s ^fg($f)$d $w^fg() " || r+="^fg(#COLOR)$s ^fg($f)$d^fg() "

will change the separator color. Leave it empty to get the default foreground color

Unia wrote:

Oh - also, I have found that restarting Monster makes it crash. Is this known, or am I doing something wrong?

not sure about this.
monsterwm does not keep the windows on restart, it just respawns itself.
making hold on to the windows was a bit of a mess when I first tried it.
to have it restart just place it in a loop in your .xinitrc/launcher:

 while true; do monsterwm || break; done

Unia wrote:

^ I see you use xdotool for this little hack. I take it then there's no 'native' way of doing this with MonsterWM?

monsterwm listens to keypresses, so someone or something must emulate a keypress.

Unia wrote:

Also, I have another question: Can I use a single dzen2 instance, that both contains the WM info as well as statusbar?

yep, just put anything you want after line 42 on the gist and add that to the printf statement on line 45
anything printed from there is fed to dzen2 which will display it - date, time, battery status, now playing song etc

Last edited by c00kiemon5ter (2012-10-16 17:03:37)

Šaran · 2012-10-16 17:02:44

I think xdotool is the only way, xmonad users are using it too for clickable workspaces.
Dzen doesn't support text allignment so two instances are necessary.

c00kiemon5ter · 2012-10-16 17:16:21

Šaran wrote:

When I was using dzen2 for statusbar, I had had configured bind that spawned another instance piped with conky (wifi, temperatures, weather) over the empty part of bar. It was set to close on click.
Is there any way to add conky (preferably) or some script output to lemonbar on bind. Currently it only shows date and time which is fine most of the time, but sometimes I need extra info.
Can anybody help me adapt my startup script (taken from Simon.Swe) for conky?
#!/usr/bin/env bash

wm=monsterwm
ff="/tmp/$RANDOM.monsterwm.fifo"
tags=('' '' '' '' '')
layouts=('' '' '' '' '') 

[[ -p $ff ]] || mkfifo -m 600 "$ff"

function statusbar {
    echo "\r\f9 $(date +"%a %d") \f2- \f3$(date +"%H:%M") "
}

while read -t 1 -r wmout || true; do
    if [[ $wmout =~ ^(([[:digit:]]+:)+[[:digit:]]+ ?)+$ ]]; then
        read -ra desktops <<< "$wmout"

        tmp=
        for desktop in "${desktops[@]}"; do
            IFS=':' read -r d w m c u <<< "$desktop"
            # Tags labels
            label=${tags[$d]}
            # Current desktop
            ((c)) && fg="4" bg="0" lc="\u0 " rc=" \ur" && layout="\f2"${layouts[$m]} || fg="2" bg="0" lc=" " rc=" "
            # Has windows
            ((w)) && ((! c)) && fg="9" lc="\u0 " rc=" \ur"
            # Urgent windows
            ((u)) && fg="3" bg="0" lc="\u0 " rc=" \ur"

            tmp+="\f$fg\b$bg$lc$label$rc\fr\br"
        done

        tmp+=" $layout"
    fi
    echo "$tmp $(statusbar)"
done < "$ff" | bar &

$wm > "$ff"

rm $ff

what you need is to find a way to execute a command when an event happens
and when another event happens close stop executing it.

a quick hack I can think of right now is setting a keybind for monsterwm which
will execute a script, which I'll name 'toggle_info.sh'

static const char *toggle_info[] = { "/bin/sh", "-c", "toggle_info.sh", NULL };  /* should be in your path abd executable */
[...]
{ MOD1,    XK_i,    spawn,    {.com = toggle_info}},

and here is 'toggle_info.sh'

#!/bin/sh
file='/tmp/.info'
[ -f "$file" ] && rm -f "$file" || touch "$file"

and here is the modified launcher

[...]
function statusbar {
    [ -f "/tmp/.info" ] && extra="$(extra commands)"
    echo "\r\f9 $extra $(date +"%a %d") \f2- \f3$(date +"%H:%M") "
    unset extra
}
[...]

so now, running the 'toggle_info.sh' script will create a file under '/tmp'
if you run it again the file is removed.

when looking for info to output to bar, if that file exists extra commands will be run
if it doesn't exist then those commands are skipped.

so pressing the keybind will create that file and extra info will be printed,
when pressed again, the file will be removed and the extra info will be hidden.

Last edited by c00kiemon5ter (2012-10-16 17:18:40)

Unia · 2012-10-16 17:28:38

c00kiemon5ter wrote:

Unia wrote:
I also decided to play around with MonsterWM. For now I'm just using the default branch, but once I think I could use it for longer periods of time I will try to combine the uselessgap branch with the initlayout one. (any tips to accomplish this easy? )
$ git clone https://github.com/c00kiemon5ter/monsterwm.git   # get the repo
$ git cherry-pick origin/uselessgaps
$ git cherry-pick origin/initlayouts
$ make
$ vim config.h     # configure .. 
$ sudo make install

Thanks. I will look into this.

c00kiemon5ter wrote:

Unia wrote:
Oh - also, I have found that restarting Monster makes it crash. Is this known, or am I doing something wrong?
not sure about this.
monsterwm does not keep the windows on restart, it just respawns itself.
making hold on to the windows was a bit of a mess when I first tried it.
to have it restart just place it in a loop in your .xinitrc/launcher:
 while true; do monsterwm || break; done 

I didn't expect it to remember windows, but it doesn't respawn itself. It just crashes and I get send back to TTY. I don't think this is the intended behaviour for a restart? (also I noticed that sometimes when I 'restart' Monster, the input to my TTY is 'blocked' - nothing I type shows up. Switching to another one and typing in there works, though)

Šaran · 2012-10-16 18:00:01

c00kiemon5ter wrote:

what you need is to find a way to execute a command when an event happens
and when another event happens close stop executing it.
...

Works perfectly, thank you very much!

Ypnose · 2012-10-16 23:31:54

c00kiemon5ter wrote:

$ git clone https://github.com/c00kiemon5ter/monsterwm.git   # get the repo
$ git cherry-pick origin/uselessgaps
$ git cherry-pick origin/initlayouts
...

Can I ask why you use git cherry-pick and not git merge (I do git merge)?

Last edited by Ypnose (2012-10-16 23:32:20)

c00kiemon5ter · 2012-10-16 23:44:29

merge compares and merges the _whole tree_ (by "tree" I mean all the commits from a common ancestor up to the specified commit; the head of the branch)
cherry pick, only care about the latest commit of the pointed branch, it grabs that and applies it on top of the current branch.
using cherry-pick is less liked to break.

for this occasion there would be no problems with merge, but if you wanted to get uselessgaps to say, xinerama-* then you would be in trouble, because you would have tried to merge every previous commit of the uselessgaps branch to the xinerama-* branch.

so cherry-pick will work good for us here cherry-pick though, cannot be used anywhere.
monsterwm's branches act much like patches, and cherry-pick does that for us. every new branch introduces only one new commit - the one that is cherry-pick'ed. if there were more then cherry-pick would ignore those, as, as I said before, it only cares about and picks the latest commit of the pointed branch.

nperry · 2012-10-17 08:09:02

c00kiemon5ter wrote:

merge compares and merges the _whole tree_ (by "tree" I mean all the commits from a common ancestor up to the specified commit; the head of the branch)
cherry pick, only care about the latest commit of the pointed branch, it grabs that and applies it on top of the current branch.
using cherry-pick is less liked to break.
for this occasion there would be no problems with merge, but if you wanted to get uselessgaps to say, xinerama-* then you would be in trouble, because you would have tried to merge every previous commit of the uselessgaps branch to the xinerama-* branch.
so cherry-pick will work good for us here cherry-pick though, cannot be used anywhere.
monsterwm's branches act much like patches, and cherry-pick does that for us. every new branch introduces only one new commit - the one that is cherry-pick'ed. if there were more then cherry-pick would ignore those, as, as I said before, it only cares about and picks the latest commit of the pointed branch.

Just wondering is any easy way to update xinerama-* to master, without to much manual intervention?

c00kiemon5ter · 2012-10-17 08:18:09

to go from xinerama-* to master you're better off storing the config
switching to master or the non-xinerama branch you want and getting
the config back there.
then you'd need to remove some vars from it.
namely, you need to remove the 'monitor' column from the rules,
and the calls to 'MONITORCHANGE' in the 'keys[]' array.

here is an example with the default config from xinerama-init to master

68,69c68,69
<     { "MPlayer",     0,       3,    True,   False },
<     { "Gimp",        1,       0,    False,  True  },
---
>     { "MPlayer",   /*0,*/     3,    True,   False },
>     { "Gimp",      /*1,*/     0,    False,  True  },
131,132c131,132
<        MONITORCHANGE(    XK_F1,                             0)
<        MONITORCHANGE(    XK_F2,                             1)
---
>        // MONITORCHANGE(    XK_F1,                             0)
>        // MONITORCHANGE(    XK_F2,                             1)

commenting out the 'monitor' column and the MONITORCHANGE calls and that's it

nperry · 2012-10-17 09:16:02

c00kiemon5ter wrote:

to go from xinerama-* to master you're better off storing the config
switching to master or the non-xinerama branch you want and getting
the config back there.
then you'd need to remove some vars from it.
namely, you need to remove the 'monitor' column from the rules,
and the calls to 'MONITORCHANGE' in the 'keys[]' array.
here is an example with the default config from xinerama-init to master
68,69c68,69
<     { "MPlayer",     0,       3,    True,   False },
<     { "Gimp",        1,       0,    False,  True  },
---
>     { "MPlayer",   /*0,*/     3,    True,   False },
>     { "Gimp",      /*1,*/     0,    False,  True  },
131,132c131,132
<        MONITORCHANGE(    XK_F1,                             0)
<        MONITORCHANGE(    XK_F2,                             1)
---
>        // MONITORCHANGE(    XK_F1,                             0)
>        // MONITORCHANGE(    XK_F2,                             1)
commenting out the 'monitor' column and the MONITORCHANGE calls and that's it

Looks like what I'm wanting to do isn't needed. I'm using xinerama-master. From looking at github I thought xinerama-master was behind master by a couple of weeks, but after a quick look it seems to be master + xinerama patches, when you push a change to master do you push the change to xinerama as well?

c00kiemon5ter · 2012-10-17 09:35:32

yep, once a bug is found it is fixed and updated everywhere.
it is always

core --> master ----------------.
      |     |`--> uselessgaps    |
      |     |`--> initlayout     |
      |      `--> etc            V
       `--> xinerama-core --> xinerama-master
                                        |`--> xinerama-init
                                         `--> xinerama-etc

Ypnose · 2012-10-17 11:02:53

Thanks for the explanations. It was pretty interesting.
Is there a way to manage windows by instance name? For example, I would like to apply a custom AppRule (float) on a window with the following specs:

WM_CLASS(STRING) = "Download", "Firefox"

Actually, it's not very important. This is just because I'm monstrously curious.

c00kiemon5ter · 2012-10-17 11:11:38

yep, in rules the 'class' field is checked for both the class name and instance name.
so using 'Download' there will work
however if you have another rule for 'Firefox', the 'Download' rule has to be before the 'Firefox' rule,
as, once a match is found, it will not look further.

 { "Firefox",      3,    True,   False },   // will not work - will match 'Firefox' and stop
 { "Download",     3,    True,   False },

 { "Download",     3,    True,   False },   // will work
 { "Firefox",      3,    True,   False },

Last edited by c00kiemon5ter (2012-10-17 11:14:32)

Ypnose · 2012-10-17 11:38:58

Nice. Man you rock so hard!

Unia · 2012-10-17 18:01:06

C00kie, I just tried what you suggested with the cherry pick but I get this:

┌─[jente @ lappy monsterwm-git] 19:59:58 
└─■ git clone https://github.com/c00kiemon5ter/monsterwm.git   # get the repo
Cloning into 'monsterwm'...
remote: Counting objects: 1706, done.
remote: Compressing objects: 100% (648/648), done.
remote: Total 1706 (delta 1090), reused 1663 (delta 1051)
Receiving objects: 100% (1706/1706), 318.07 KiB | 335 KiB/s, done.
Resolving deltas: 100% (1090/1090), done.
┌─[jente @ lappy monsterwm-git] 20:00:10 
└─■ git cherry-pick origin/uselessgaps
fatal: bad revision 'origin/uselessgaps'
┌─[jente @ lappy monsterwm-git] 20:00:13 
└─■ git cherry-pick origin/initlayouts
fatal: bad revision 'origin/initlayouts'

What am I doing wrong?

EDIT: Nevermind, seems like I needed to cd into monsterwm first though it complains now when applying uselessgaps, but I'll look into it first.

EDIT2: Seems like it complains at the second cherry pick. Applying either one first works, but with the second it says:

┌─[jente @ lappy monsterwm] 20:03:46 
└─■ git cherry-pick origin/uselessgaps
[master 1e7ab12] useless gaps around windows for all layout modes
 Author: Ivan Kanakarakis <ivan.kanak@gmail.com>
 2 files changed, 16 insertions(+), 10 deletions(-)
┌─[jente @ lappy monsterwm] 20:03:52 
└─■ git cherry-pick origin/initlayouts
error: could not apply 71cb2b1... initial layouts per desktop
hint: after resolving the conflicts, mark the corrected paths
hint: with 'git add <paths>' or 'git rm <paths>'
hint: and commit the result with 'git commit'

Again, other way around gives the same. Sorry I'm such a Git newb. I only know how to add, commit, push and clone

Last edited by Unia (2012-10-17 18:12:26)

c00kiemon5ter · 2012-10-17 18:42:30

it's an easy fix, open config.def.h and you should see

[...]
#define DEFAULT_DESKTOP 0         /* the desktop to focus initially */                                                                                      
<<<<<<< HEAD
#define DESKTOPS        4         /* number of desktops - edit DESKTOPCHANGE keys to suit */
#define USELESSGAP      8         /* the size of the useless gap in pixels */
=======
#define DESKTOPS        5         /* number of desktops - edit DESKTOPCHANGE keys to suit */

/**
 * layouts for each desktops
 */
static const int initlayouts[] = { TILE, BSTACK, GRID, MONOCLE, FLOAT, };
>>>>>>> 71cb2b1... initial layouts per desktop

/**
 * open applications to specified desktop with specified mode.
[...]

well, you need USELESSGAP var there, so turn it into:

[...]
#define DEFAULT_DESKTOP 0         /* the desktop to focus initially */ 
#define USELESSGAP      8         /* the size of the useless gap in pixels */
#define DESKTOPS        5         /* number of desktops - edit DESKTOPCHANGE keys to suit */

/**
 * layouts for each desktops
 */
static const int initlayouts[] = { TILE, BSTACK, GRID, MONOCLE, FLOAT, };

/**
 * open applications to specified desktop with specified mode.
[...]

(that is remove the double vars and allow 'initlayouts[]' array to be there)

Unia · 2012-10-17 18:45:53

How did you know it was that file? It's not listed somewhere? Thanks ofc!

Last edited by Unia (2012-10-17 18:46:02)

c00kiemon5ter · 2012-10-17 18:55:32

do the merge/cherry-pick again and see the output of

$ git status  # or git status -s
$ git diff

Unia · 2012-10-17 19:13:03

Okay, I see. Bit of magic I guess

It's working now, thanks!

Supplantr · 2012-10-19 16:32:23

I recently began using monsterwm after having tried many other tiling window managers. Here's some input:

One of the first things I noticed is the overlap of window borders, which is really nice. However, when using the nmaster patch, if there are multiple windows in master the borders of those windows don't overlap. It would be neat if they did.
Also, a simple swap focus function might be useful. And, I'm guessing it's not possible at the moment to use two "bars" with monsterwm. Has anyone shown interest in this?

Another thing, the focus-follows-mouse function can be inconvenient at times when it shouldn't be. For example, if there are two clients on desktop 2 and the one in master has focus, switching to another desktop and moving the mouse to the right side of the screen (where the client in the stack is located on desktop 2), then switching back to desktop 2 will focus the window under the mouse. Similarly, resizing master or the stack will focus a window that is moved under the mouse. I think it would make more sense if monsterwm behaved like dwm in these regards, but that's just my two cents.

In config.def.h, under #define DESKTOPCHANGE, I think it should be SHIFT rather than ShiftMask.

Finally, launching chromium twice causes monsterwm to exit. I don't say crash because chromium doesn't report that it "didn't shut down correctly." This happens if launched through monsterwm itself or from dmenu, but not if launched from a terminal. Also, about halfway through GtkPerf's test (and when simply closing the GtkPerf window), monsterwm exits. I'm using monsterwm with the centerwindow, initlayouts, nmaster, and windowtitles patches. Neither of these problems occur in dwm.

Keep up the good work!

c00kiemon5ter · 2012-10-20 05:33:25

Supplantr wrote:

One of the first things I noticed is the overlap of window borders, which is really nice.
However, when using the nmaster patch, if there are multiple windows in master the borders of those windows don't overlap.
It would be neat if they did.

yep, I want to, but I haven't gone into much thought on that yet. I'll see what I can do, as I may need it elsewhere too

Supplantr wrote:

Also, a simple swap focus function might be useful.

what would swap focus do ? jump between the current and the previously focused window ?
that'd be easy I think, I can make a patch for that if that's the behaviour you want

Supplantr wrote:

I'm guessing it's not possible at the moment to use two "bars" with monsterwm. Has anyone shown interest in this?

well, the panels are independent of monsterwm. you can actually have as many as you want,
but you have to take care as to how you process monsterwm's output, how many processes read that output etc
Some pages before we were playing with a script about this ..
well it was related, not the same thing per se; that was how to have bar or dzen2 output each monitor's info on just that monitor
the better you are on scripting, the more things you can do. actually you do not need to know shell scripting,
you can process monsterwm's output with an language you think it's easier and you're more comfortable to use.

Supplantr wrote:

Another thing, the focus-follows-mouse function can be inconvenient at times when it shouldn't be. For example, if there are two clients on desktop 2 and the one in master has focus, switching to another desktop and moving the mouse to the right side of the screen (where the client in the stack is located on desktop 2), then switching back to desktop 2 will focus the window under the mouse. Similarly, resizing master or the stack will focus a window that is moved under the mouse.

well, I personally find follow mouse a bit silly concept and very inconvenient. It is also buggy and troublesome.
I would very happily remove that functionality altogether, but some people use it, so it's there.
Soo, having said that, I'm not really motivated to work much on it, and I currently do not have the time

Supplantr wrote:

Finally, launching chromium twice causes monsterwm to exit. I don't say crash because chromium doesn't report that it "didn't shut down correctly." This happens if launched through monsterwm itself or from dmenu, but not if launched from a terminal. Also, about halfway through GtkPerf's test (and when simply closing the GtkPerf window), monsterwm exits. I'm using monsterwm with the centerwindow, initlayouts, nmaster, and windowtitles patches. Neither of these problems occur in dwm.

not sure about this one here. I will have to check and run some tests. Will definitely look into it

Supplantr wrote:

Keep up the good work!

thanks for your feedback and taking the time to configure and try this

c00kiemon5ter · 2012-10-20 16:58:35

here's a swap focus patch:

diff --git a/config.def.h b/config.def.h
index a710598..7db6fe9 100644
--- a/config.def.h
+++ b/config.def.h
@@ -79,6 +79,7 @@ static Key keys[] = {
     {  MOD1|SHIFT,       XK_h,          rotate_filled,     {.i = -1}},
     {  MOD1|SHIFT,       XK_l,          rotate_filled,     {.i = +1}},
     {  MOD1,             XK_Tab,        last_desktop,      {NULL}},
+    {  MOD4,             XK_Tab,        swap_focus,        {NULL}},
     {  MOD1,             XK_Return,     swap_master,       {NULL}},
     {  MOD1|SHIFT,       XK_j,          move_down,         {NULL}},
     {  MOD1|SHIFT,       XK_k,          move_up,           {NULL}},
diff --git a/monsterwm.c b/monsterwm.c
index 9d21d3f..b9554ad 100644
--- a/monsterwm.c
+++ b/monsterwm.c
@@ -97,6 +97,7 @@ static void resize_stack(const Arg *arg);
 static void rotate(const Arg *arg);
 static void rotate_filled(const Arg *arg);
 static void spawn(const Arg *arg);
+static void swap_focus();
 static void swap_master();
 static void switch_mode(const Arg *arg);
 static void togglepanel();
@@ -1185,6 +1186,15 @@ void stack(int x, int y, int w, int h, const Desktop *d) {
 }
 
 /**
+ * swap focus between current and previously focused window
+ */
+void swap_focus(void) {
+    Client *c = desktops[currdeskidx].curr;
+    focus(desktops[currdeskidx].prev, &desktops[currdeskidx]);
+    desktops[currdeskidx].prev = c;
+}
+
+/**
  * swap master window with current.
  * if current is head swap with next
  * if current is not head, then head

I cannot reproduce the GtkPerf nor the "crashing" with chromium.
I tested every branch and the merge of the ones you mentioned.
I use chromium myself and never had any such problem.
Listing the steps you take to reproduce this may help.

I'll see what I can do for single borders on nmaster now

moetunes · 2012-10-20 20:25:12

Hi cookie, I thought the warpcursor branch might solve some of what Supplantr had issues with. Unless that doesn't do what I think it does...

Arch Linux

#1051 2012-10-16 16:45:07

Re: monsterwm! ~ yet another tiny wm

#1052 2012-10-16 16:59:52

Re: monsterwm! ~ yet another tiny wm

#1053 2012-10-16 17:00:42

Re: monsterwm! ~ yet another tiny wm

#1054 2012-10-16 17:02:44

Re: monsterwm! ~ yet another tiny wm

#1055 2012-10-16 17:16:21

Re: monsterwm! ~ yet another tiny wm

#1056 2012-10-16 17:28:38

Re: monsterwm! ~ yet another tiny wm

#1057 2012-10-16 18:00:01

Re: monsterwm! ~ yet another tiny wm

#1058 2012-10-16 23:31:54

Re: monsterwm! ~ yet another tiny wm

#1059 2012-10-16 23:44:29

Re: monsterwm! ~ yet another tiny wm

#1060 2012-10-17 08:09:02

Re: monsterwm! ~ yet another tiny wm

#1061 2012-10-17 08:18:09

Re: monsterwm! ~ yet another tiny wm

#1062 2012-10-17 09:16:02

Re: monsterwm! ~ yet another tiny wm

#1063 2012-10-17 09:35:32

Re: monsterwm! ~ yet another tiny wm

#1064 2012-10-17 11:02:53

Re: monsterwm! ~ yet another tiny wm

#1065 2012-10-17 11:11:38

Re: monsterwm! ~ yet another tiny wm

#1066 2012-10-17 11:38:58

Re: monsterwm! ~ yet another tiny wm

#1067 2012-10-17 18:01:06

Re: monsterwm! ~ yet another tiny wm

#1068 2012-10-17 18:42:30

Re: monsterwm! ~ yet another tiny wm

#1069 2012-10-17 18:45:53

Re: monsterwm! ~ yet another tiny wm

#1070 2012-10-17 18:55:32

Re: monsterwm! ~ yet another tiny wm

#1071 2012-10-17 19:13:03

Re: monsterwm! ~ yet another tiny wm

#1072 2012-10-19 16:32:23

Re: monsterwm! ~ yet another tiny wm

#1073 2012-10-20 05:33:25

Re: monsterwm! ~ yet another tiny wm

#1074 2012-10-20 16:58:35

Re: monsterwm! ~ yet another tiny wm

#1075 2012-10-20 20:25:12

Re: monsterwm! ~ yet another tiny wm

Board footer