bspwm — A tiling window manager based on binary space partitioning

flexo3001 · 2013-09-04 20:21:28

bloom wrote:

flexo3001 wrote:
i have the same "bug" with dwm/bspwm and chromium. and just bspwm and dwm if i focus a chromium-window i have the focus in bspwm but chromium shows up its "inactive window theme".
http://lists.suckless.org/dev/1201/10614.html

thats it! thanks. but will my hated java-applications work in bspwm without setting with wmname?

bloom · 2013-09-04 20:39:30

flexo3001 wrote:

bloom wrote:
flexo3001 wrote:
i have the same "bug" with dwm/bspwm and chromium. and just bspwm and dwm if i focus a chromium-window i have the focus in bspwm but chromium shows up its "inactive window theme".
http://lists.suckless.org/dev/1201/10614.html
thats it! thanks. but will my hated java-applications work in bspwm without setting with wmname?

You could try adding:

bspc config wm_name LG3D

to your bspwmrc.

(There's a bug in wmname and the Chromium issue probably comes from this bug.)

Another solution is mentioned in dwm's wiki.

Last edited by bloom (2013-09-04 20:51:17)

bloom · 2013-09-05 09:19:07

@flexo3001:
In fact the wm_name setting was just removed because it has no purpose, if you use OpenJDK, your can add the following:

export _JAVA_AWT_WM_NONREPARENTING=1

to /etc/profile.d/jre.sh.
Otherwise, you'll have to endure the side effects of wmname.

Last edited by bloom (2013-09-05 09:19:35)

bloom · 2013-09-05 13:45:09

The setting previously known as apply_shadow_property is now called apply_floating_atom.

instantepiphany · 2013-09-05 15:07:08

I am using lemonboy's bar and sending my panel-fifo to it, and everything is working great except if I change desktop, or a window on a hidden desktop becomes urgent(whether it is because I have received a message on a chat program or I have used wmctrl to mark it as urgent) the bar doesn't update until I select my other monitor, and then select the original one again, and select different windows. This happens about 80% of the time, sometimes windows marked as urgent update the respective desktop on the bar constantly and without me having to move the focus around windows/monitors.

cippaciong · 2013-09-05 18:42:47

bloom wrote:

The setting previously known as apply_shadow_property is now called apply_floating_atom.

I don't get very well how this setting works. Could you enlighten me?

earsplit · 2013-09-06 04:02:42

I recently did a git pull + make / make install and some applications don't register with clicks (mostly the skype I'm forced to use for work.

To replicate, open up skype, send someone an IM, switch workspaces, and click on the text entry area. At this point, I hvae to close and reopen the window to enter text.

If bitlbee supported skype group chats, I wouldn't have this problem =[

bloom · 2013-09-06 09:04:16

earsplit wrote:

I recently did a git pull + make / make install and some applications don't register with clicks (mostly the skype I'm forced to use for work.

It seems you haven't updated your sxhkdrc: you must replace :button1 with ~button1.

bloom · 2013-09-06 13:36:47

instantepiphany wrote:

I am using lemonboy's bar and sending my panel-fifo to it, and everything is working great except if I change desktop, or a window on a hidden desktop becomes urgent(whether it is because I have received a message on a chat program or I have used wmctrl to mark it as urgent) the bar doesn't update until I select my other monitor, and then select the original one again, and select different windows. This happens about 80% of the time, sometimes windows marked as urgent update the respective desktop on the bar constantly and without me having to move the focus around windows/monitors.

What's your panel script?

How do you kill your panel?

Most probably, remaining processes of badly killed panels are reading informations from the panel FIFO and the process that actually feeds your bar misses those informations.

earsplit · 2013-09-06 15:23:42

bloom wrote:

earsplit wrote:
I recently did a git pull + make / make install and some applications don't register with clicks (mostly the skype I'm forced to use for work.
It seems you haven't updated your sxhkdrc: you must replace :button1 with ~button1.

Edit: This fixed a problem on a new debian netinstall I had, but my skype issue still remains. This is most likely an issue with skype itself, but there me be some edge case to catch here.

I hate skype with a passion.

Last edited by earsplit (2013-09-06 15:29:46)

instantepiphany · 2013-09-06 17:42:38

bloom wrote:

What's your panel script?
How do you kill your panel?
Most probably, remaining processes of badly killed panels are reading informations from the panel FIFO and the process that actually feeds your bar misses those informations.

Right on the mark, killed the ~8 or so panel/panel_bar scripts I had running and then it worked flawlessly. I believe I was just running my panel script from urxvt, not forking it, and just ^C'ing it when I needed to restart to test a change in config. Would that have left processes running? If I had forked it to background I just ran "killall bar".

aoba · 2013-09-06 19:05:42

@instantepiphany

When putting together a dzen panel (based on the github example), I had to do the following to ensure that killing and restarting the panel did not leave a bunch of processes running (and to ensure that when my X session ended, they were gone).

A section of ~/bin/panel:

#!/bin/bash

# ...

trap 'kill $(jobs -p) > /dev/null 2>&1' EXIT SIGHUP SIGINT SIGTERM

bspc control --put-status
xtitle -sf 'T%s' > "${PANEL_FIFO}" &
clock '+C%H:%M' > "${PANEL_FIFO}" &
cat "${PANEL_FIFO}" | panel-bspwm & pid=$!

wait $pid

A section of ~/bin/panel-bspwm:

#!/bin/bash

# ...

function on_signal {
	running=false
}
trap on_signal EXIT SIGHUP SIGINT SIGTERM

while read -r line; do
	if [ "${running}" != "true" ]; then
		echo EOF
		break
	fi

	# ...

	echo "${formatted_text}"

done | dzen2 -fg "${c_fg}" -bg "${c_bg}" -fn "${font}" -ta l -h "${height}" -e 'onstart=lower'

The key lines are the traps. The first one (in ~/bin/panel), in theory, kills all child processes whenever it dies or exits. The second one sends an EOF to dzen2 then stops piping information.

I sort of understand how it works (I think) - if dzen2 exits for any reason, so too will panel-bspwm; if panel-bspwm receives a signal, an EOF will be sent to dzen2, also causing both to exit; the panel script waits on the panel-bspwm process and will exit when it does; and, finally, if panel dies for any reason, all of its child jobs will be killed with a SIGTERM - but I am sort of surprised that the bookkeeping with the traps appears to be necessary.

In fact, half the reason I am posting this is to ask if there is a better way to go about this (is there?). The other half is because I have not noticed any unwanted processes enduring after frequently killing the panel or logging in and out of my user, so hopefully this will help.

Edit: upon further research, it appears that the `echo EOF` line is likely meaningless.

Last edited by aoba (2013-09-06 19:41:24)

Mindstormscreator · 2013-09-06 20:15:37

I have an extremely similar setup to aoba that I coded recently with traps:

bspc control --put-status
conky > "$PANEL_FIFO" &

function cleanup() {
	for proc in $(jobs -pr); do
		# Sub-processes may be chained, so if one is killed, they may not all still exist
		[ "$(jobs -pr | grep $proc)" ] && kill $proc
	done
}

trap cleanup SIGTERM SIGINT EXIT
wait

I was a little paranoid with killing the background jobs because killing certain ones (like cat) kills others chained to it, which results in non-existant pids trying to be killed. I don't know how possible it is for this to accidentally kill something not involved in the panel script, but I wanted to make sure.

I'm using a wmrun.sh script called with "exec" from .xinitrc now:

#! /bin/sh
sxhkd &

[ -e "$PANEL_FIFO" ] && rm "$PANEL_FIFO"
mkfifo -m 600 "$PANEL_FIFO"

panel &

bspwm -c /home/alex/.config/bspwm/autostart -s "$PANEL_FIFO" -p WM
pkill panel

exit 0

I've actually found that if panel is left alone, it is killed when X exits, but if I kill it and restart it with this sxhkd entry:

alt + z
	pkill panel; panel

The panel must be killed before X exits, or else I end up with residual panel processes like cat (and even bar)

As aoba said, is there really any better way to do this?

earsplit · 2013-09-06 20:38:42

alt + shift + q
        bspc quit && pkill bar && pkill dzen2

alt + q
        pkill dzen2 && pkill bar && /path/to/status/bar/script

I use an xmonad-like method. mod-q reloads the panels, mod+shift+q quits (logs out) and kills the panels. This is the way i do this...

Last edited by earsplit (2013-09-06 20:38:49)

Supplantr · 2013-09-06 20:39:34

earsplit wrote:

Edit: This fixed a problem on a new debian netinstall I had, but my skype issue still remains. This is most likely an issue with skype itself, but there me be some edge case to catch here.

I noticed this as well. It seems to be a result of commit 387ece3. I reverted to the preceding commit and Skype retains focus as expected.

aoba · 2013-09-06 20:48:26

Mindstormscreator wrote:

function cleanup() {
	for proc in $(jobs -pr); do
		# Sub-processes may be chained, so if one is killed, they may not all still exist
		[ "$(jobs -pr | grep $proc)" ] && kill $proc
	done
}

I really like this. I spent a good deal of time trying to figure out how to do what you have here, but I eventually gave up and - very frustrated - just redirected the output to /dev/null.

bloom · 2013-09-06 20:58:12

Supplantr wrote:

earsplit wrote:
Edit: This fixed a problem on a new debian netinstall I had, but my skype issue still remains. This is most likely an issue with skype itself, but there me be some edge case to catch here.
I noticed this as well. It seems to be a result of commit 387ece3. I reverted to the preceding commit and Skype retains focus as expected.

Does 2bfaefa help?

earsplit · 2013-09-06 21:24:55

Sure did! Why was this reverted? did it cause other problems?

bloom · 2013-09-07 08:46:04

earsplit wrote:

Sure did! Why was this reverted?

I thought your issue only came from your sxhkd misconfiguration.

The commit is now re-applied as e757323.

bloom · 2013-09-07 09:30:00

cippaciong wrote:

bloom wrote:
The setting previously known as apply_shadow_property is now called apply_floating_atom.
I don't get very well how this setting works. Could you enlighten me?

If apply_floating_atom is enabled, then the output of the following command:

xprop _BSPWM_FLOATING_WINDOW

is 1 if you click on a floating window and 0 otherwise.

bloom · 2013-09-07 09:46:26

Mindstormscreator wrote:

As aoba said, is there really any better way to do this?

One interesting fact is that, (for most shells) all background processes of the panel script will have the same process group ID.

Another experimental discovery: the aforementioned pgid is equal to $$ (in the context of the script).

Hence after running the following script:

a &
b &
c &
d &
echo $$ > /tmp/foo-pgid

The following command:

pkill -g $(cat /tmp/foo-pgid)

will precisely kill a-d.

Last edited by bloom (2013-09-08 12:57:37)

chickenPie4tea · 2013-09-08 13:54:51

bloom wrote:

The following:
make clean install
will necessary fails since the clean target removes the binaries .
The install instructions are:
make
make install
Or simply:
owl install bspwm-git

make then make install don't work for me either - I get the same message as the other poster called andmars

mkdir -p "/usr/local/bin"
cp -p bspwm "/usr/local/bin"
cp: cannot stat `bspwm': No such file or directory
make: *** [install] Error 1

After trying to find out what dependencies I need and installing xcb
when I run make again I now get

cc -std=c99 -pedantic -Wall -Wextra -I/usr/local/include -D_POSIX_C_SOURCE=200112L -DVERSION=\"0.8\" -Os -c -o bspwm.o bspwm.c
bspwm.c:11:27: fatal error: xcb/xcb_event.h: No such file or directory
compilation terminated.
make: *** [bspwm.o] Error 1

It would be great if I could find out what the dependencies are but I cant see any such info on the git hub page.

Last edited by chickenPie4tea (2013-09-09 10:23:15)

andornaut · 2013-09-09 05:06:17

I'm really loving bspwm! It's pretty much exactly what I was looking for. It works great on my laptop, but I have a minor issue on my dual-head workstation:

My secondary monitor is on the left and primary monitor is on the right, but these are inverted in my dzen2 panel with my primary monitor on the left and secondary monitor on the right.

Is there any way of inverting the order of these monitors in the dzen2 panel?

(I don't want to physically switch my primary monitor and secondary monitors b/c I prefer my secondary to be in portrait mode, and on the left).

Thanks.

Last edited by andornaut (2013-09-09 05:09:42)

earsplit · 2013-09-09 06:27:02

andornaut wrote:

I'm really loving bspwm! It's pretty much exactly what I was looking for. It works great on my laptop, but I have a minor issue on my dual-head workstation:
My secondary monitor is on the left and primary monitor is on the right, but these are inverted in my dzen2 panel with my primary monitor on the left and secondary monitor on the right.
Is there any way of inverting the order of these monitors in the dzen2 panel?
(I don't want to physically switch my primary monitor and secondary monitors b/c I prefer my secondary to be in portrait mode, and on the left).
Thanks.

What xrandr command are you using? Play around with the --primary setting, as well as --left-of and --right-of. Dzen also has a -xs option to specify the xinerama screen number. See http://dzen.googlecode.com/svn/trunk/README

bloom · 2013-09-09 13:28:49

ttz wrote:

Is there a way to control which monitor is detected "first" by bspwm on startup, assuming an external monitor is connected to the laptop on startx?
Currently, I use a VGA and my laptop screen. In xrandr, VGA is detected "first" (i.e. higher on the list, even though I've set LVDS to be my primary).
What happens is that Desktop01 is always put on my VGA screen, even though I set LVDS as my primary. I am obviously able to just hack this in bspwmrc so that Desktop02, which is the "main" screen on my LVDS, is set to be my "main" desktop... however, this messes with my bar script, in that the desktops for VGA (since VGA comes first in the xrandr listing) always appear to the left of the desktops for LVDS.
This is purely cosmetic, and if it can't be fixed, it's fine, I was just wondering.

It should be fixed by f38f863.

Arch Linux

#476 2013-09-04 20:21:28

Re: bspwm — A tiling window manager based on binary space partitioning

#477 2013-09-04 20:39:30

Re: bspwm — A tiling window manager based on binary space partitioning

#478 2013-09-05 09:19:07

Re: bspwm — A tiling window manager based on binary space partitioning

#479 2013-09-05 13:45:09

Re: bspwm — A tiling window manager based on binary space partitioning

#480 2013-09-05 15:07:08

Re: bspwm — A tiling window manager based on binary space partitioning

#481 2013-09-05 18:42:47

Re: bspwm — A tiling window manager based on binary space partitioning

#482 2013-09-06 04:02:42

Re: bspwm — A tiling window manager based on binary space partitioning

#483 2013-09-06 09:04:16

Re: bspwm — A tiling window manager based on binary space partitioning

#484 2013-09-06 13:36:47

Re: bspwm — A tiling window manager based on binary space partitioning

#485 2013-09-06 15:23:42

Re: bspwm — A tiling window manager based on binary space partitioning

#486 2013-09-06 17:42:38

Re: bspwm — A tiling window manager based on binary space partitioning

#487 2013-09-06 19:05:42

Re: bspwm — A tiling window manager based on binary space partitioning

#488 2013-09-06 20:15:37

Re: bspwm — A tiling window manager based on binary space partitioning

#489 2013-09-06 20:38:42

Re: bspwm — A tiling window manager based on binary space partitioning

#490 2013-09-06 20:39:34

Re: bspwm — A tiling window manager based on binary space partitioning

#491 2013-09-06 20:48:26

Re: bspwm — A tiling window manager based on binary space partitioning

#492 2013-09-06 20:58:12

Re: bspwm — A tiling window manager based on binary space partitioning

#493 2013-09-06 21:24:55

Re: bspwm — A tiling window manager based on binary space partitioning

#494 2013-09-07 08:46:04

Re: bspwm — A tiling window manager based on binary space partitioning

#495 2013-09-07 09:30:00

Re: bspwm — A tiling window manager based on binary space partitioning

#496 2013-09-07 09:46:26

Re: bspwm — A tiling window manager based on binary space partitioning

#497 2013-09-08 13:54:51

Re: bspwm — A tiling window manager based on binary space partitioning

#498 2013-09-09 05:06:17

Re: bspwm — A tiling window manager based on binary space partitioning

#499 2013-09-09 06:27:02

Re: bspwm — A tiling window manager based on binary space partitioning

#500 2013-09-09 13:28:49

Re: bspwm — A tiling window manager based on binary space partitioning

Board footer