bspwm — A tiling window manager based on binary space partitioning

V0rt3k · 2013-05-08 12:00:17

I'm using BSPWM since one month and I can only say: WOW!

I tried Xmonad for just one year (but that large Haskell library ), after that I started using AwesomeWM for just two months (every update a new configuration syntax). Herbstluftwm give me a new world, but it's mainly keyboard driven and manual tiling.

I will upload a screenshot this week.

@bloom, can you maybe add some more information in the PKGBUILD's (bspwm and bspwm-git) about the optional dependencies?

bloom · 2013-05-08 18:16:05

V0rt3k wrote:

I'm using BSPWM since one month and I can only say: WOW!

Thanks.

V0rt3k wrote:

@bloom, can you maybe add some more information in the PKGBUILD's (bspwm and bspwm-git) about the optional dependencies?

Yes I will.

bloom · 2013-05-08 18:27:32

Some recent changes:

The focus history is now infinite (previously it had a depth of 1): this allows to enforce a consistent z-ordering of the tiled windows. The message previously known as reload is now called reload_layout. There's a new message called reload_history (cf. examples/loop).
A new setting: focus_by_distance changes the behavior of the focus message so that the nearest neighbor is determined by the distances between window sides. That setting shall increase the intuitiveness of the focus message.

bloom · 2013-05-13 08:28:12

Since I've written xdo the close and kill messages will probably be removed shortly.

I would therefore advise that you install the xdo-git package and that you replace all the occurrences of bspc {close,kill} that might appear in your sxhkdrc by xdo {close,kill}.

F34R · 2013-05-17 14:23:10

Hi how to bind mygtk menu file with use sxhkd ? I try exec ~/.bin/.menu btw not working.

Shinryuu · 2013-05-17 17:24:32

F34R wrote:

Hi how to bind mygtk menu file with use sxhkd ? I try exec ~/.bin/.menu btw not working.

Can't you do it like this?

mod1 + button2
mygtkmenu /your/path/to/.menu

bloom · 2013-05-17 17:45:21

Shinryuu wrote:

F34R wrote:
Hi how to bind mygtk menu file with use sxhkd ? I try exec ~/.bin/.menu btw not working.
Can't you do it like this?
mod1 + button2
mygtkmenu /your/path/to/.menu

The line holding the command must start with a space character:

mod1 + button2
    mygtkmenu /your/path/to/.menu

Last edited by bloom (2013-05-17 17:46:02)

F34R · 2013-05-17 19:48:25

Ohhh thanks guys its working ^^.

bloom · 2013-05-20 08:22:51

bloom wrote:

the close and kill messages will probably be removed shortly

In fact, the close message will not be removed because it has to deal with the locked state of clients.

Supplantr · 2013-05-26 19:22:26

When in monocle mode with multiple windows open, clicking the visible window causes it to flicker, and it seems like the window behind it "bleeds through" momentarily. I've tested this with and without compton, which doesn't appear to affect it. Is anyone else experiencing this?

Also, not to be a pest, but I was wondering if any progress is being made with regard to supporting xrandr.

bloom · 2013-05-27 08:52:03

Supplantr wrote:

When in monocle mode with multiple windows open, clicking the visible window causes it to flicker, and it seems like the window behind it "bleeds through" momentarily.

It should be fixed.

Supplantr wrote:

I was wondering if any progress is being made with regard to supporting xrandr.

RandR support is at the top of my to do list.

bloom · 2013-05-28 15:36:08

Supplantr wrote:

I was wondering if any progress is being made with regard to supporting xrandr

Please try the newborn randr branch.

Supplantr · 2013-05-28 19:23:24

bloom wrote:

It should be fixed.

I can confirm that this is now fixed. Thanks.

bloom wrote:

Please try the newborn randr branch.

bspwm crashes when I attempt to add a second monitor with xrandr.
I'm using a laptop with Nvidia Optimus and bumblebee/screenclone, so I may have a peculiar use case. Below is the script I use to add the monitor. It works as expected with dwm and i3.

x=1280
y=1024

modeline="$(cvt $x $y | sed '1d' | sed 's/Modeline //')"
mode="$(echo $modeline | sed 's/ .*//')"

xrandr --newmode $modeline &> /dev/null 2>&1
xrandr --addmode VIRTUAL1 $mode
xrandr --output HDMI1 --auto --output VIRTUAL1 --mode $mode --above LVDS1
optirun screenclone -s $DISPLAY -d :8 -x 1
xrandr --output VIRTUAL1 --off

bloom · 2013-05-28 19:52:59

Supplantr wrote:

bspwm crashes when I attempt to add a second monitor with xrandr

I was able to reproduce with xrandr --addmode ..., thanks.

It should be fixed.

Supplantr · 2013-05-28 23:33:39

bloom wrote:

It should be fixed.

It works now.

However, I'm able to produce another crash:

Add external screen
Select external screen with bspc use_monitor VIRTUAL1 (which doesn't take focus away from the terminal on the first screen until...)
Open new terminal instance on VIRTUAL1 (now focus is taken from the terminal on the first screen)
Close terminal on VIRTUAL1
Use bspc focus left|right|up|down
Crash!

Also, an auto_alternate for use_monitor might be handy.

bloom · 2013-05-29 08:15:52

Please note that I forgot not to rebase published branches and therefore you'll problably be better off recreating your local clone. Sorry about that.

Supplantr wrote:

I'm able to produce another crash:
Add external screen
Select external screen with bspc use_monitor VIRTUAL1 (which doesn't take focus away from the terminal on the first screen until...)

I will fix that ASAP.

Supplantr wrote:

Open new terminal instance on VIRTUAL1 (now focus is taken from the terminal on the first screen)
Close terminal on VIRTUAL1
Use bspc focus left|right|up|down

Were you trying to focus the terminal on the initial monitor?

Supplantr wrote:

Crash!

In fact, the crash has nothing to do with RandR and it should be fixed.

Supplantr wrote:

Also, an auto_alternate for use_monitor might be handy.

Should be working now.

aparthia · 2013-05-29 12:21:46

Sorry to bother, but I am trying to get the example bar configuration to work with bspwm.

My xinitrc looks like this: http://pastebin.com/EQHM98K3
My autostart: http://pastebin.com/qJ3sZmtg
I have edited the panel example so that "$PANEL_FIFO" is replaced by /tmp/panel_info and i then run

~/code/bspwm/examples/panel/panel

and I get the following output: http://i.imgur.com/McyzOSM.png

Notably the first letter of each workspace is not in the window. What has happened?

Last edited by aparthia (2013-05-29 12:22:58)

bloom · 2013-05-29 13:06:42

aparthia wrote:

Notably the first letter of each workspace is not in the window.

Fixed by 886d5e8.

aparthia · 2013-05-29 16:16:32

bloom wrote:

aparthia wrote:
Notably the first letter of each workspace is not in the window.
Fixed by 886d5e8.

And now it works perfectly! Thanks for the good work, this is the first wm I have tried in some time I really like and now it's more or less flawless.

bloom · 2013-05-29 20:06:25

Supplantr wrote:

Select external screen with bspc use_monitor VIRTUAL1 (which doesn't take focus away from the terminal on the first screen until...)

It should be fixed.

Supplantr · 2013-05-29 21:18:52

All testing was done with the latest git build.

I can confirm that auto_alternate now applies to use_monitor, thanks!

When sending windows between monitors (with either send_to_monitor or send_to a desktop on that monitor), the border is drawn under the border of already present windows. This may be a non-issue, but since I'm using overlapping borders, it is noticeable.

bloom wrote:

Were you trying to focus the terminal on the initial monitor?

I think the first time I caused the crash I had returned focus to the initial monitor and then attempted to focus another window open on that monitor. But I've had a crash-free experience so far.

However, would it be possible to allow bspc focus left|right|up|down to focus windows between monitors, similar (if I recall correctly) to i3? Maybe add a setting to optionally enable this?

bloom wrote:

It should be fixed.

The window border now reflects focus being switched to a different monitor (or desktop on a different monitor), but urxvt's (and termite's) block cursor still remains "filled," which can be a bit confusing. This only happens if there are no windows open on the monitor receiving focus.
EDIT: I should also mention that this applies to all windows. Input is still received, so the windows effectively remain focused.

Last edited by Supplantr (2013-05-29 21:38:44)

bloom · 2013-05-30 09:37:56

Supplantr wrote:

When sending windows between monitors (with either send_to_monitor or send_to a desktop on that monitor), the border is drawn under the border of already present windows. This may be a non-issue, but since I'm using overlapping borders, it is noticeable.

I can't reproduce this (does it occur with a single head setup too?).

Could you post your autostart and give a more detailed report and a screenshot?

Supplantr wrote:

would it be possible to allow bspc focus left|right|up|down to focus windows between monitors, similar (if I recall correctly) to i3? Maybe add a setting to optionally enable this?

I'll keep that in mind.

Supplantr wrote:

The window border now reflects focus being switched to a different monitor (or desktop on a different monitor), but urxvt's (and termite's) block cursor still remains "filled," which can be a bit confusing. This only happens if there are no windows open on the monitor receiving focus.
EDIT: I should also mention that this applies to all windows. Input is still received, so the windows effectively remain focused.

Should be fixed.

---

Could you try disconnecting a monitor?

In principle, it should transfer all the desktops of the disconnected monitor to the first known connected monitor.

Last edited by bloom (2013-05-30 14:57:34)

milkmiruku · 2013-05-30 19:18:02

Please can you enable the GH project wiki? I'd like to start a page on all the extra infos in the thread pages to help myself and others.

bloom · 2013-05-30 20:57:06

milkmiruku wrote:

Please can you enable the GH project wiki?

Done.

Supplantr · 2013-05-30 21:42:49

bloom wrote:

I can't reproduce this (does it occur with a single head setup too?).
Could you post your autostart and give a more detailed report and a screenshot?

Here's a screenshot:

And here's the relevant part of my autostart:

#!/bin/bash

bspc rename Desktop01 He
bspc add Ne Ar Kr Xe Rn

bspc set focused_border_color '#5F819D'
bspc set active_border_color  '#707880'
bspc set normal_border_color  '#373b41'
bspc set presel_border_color  '#de935f'
bspc set urgent_border_color  '#A54242'

bspc set gapless_monocle    false
bspc set borderless_monocle true
bspc set adaptative_raise   true
bspc set auto_alternate     true
bspc set focus_by_distance  true

bw=2
tp=14
bspc set border_width $bw
bspc set window_gap   -$bw
bspc set top_padding  $tp
for m in $(bspc list_monitors --quiet | cut -d ' ' -f 1); do
    bspc pad "$m" $((tp + bw)) $bw $bw $bw
done

As you can see, the "active_border_color" is drawn below the other borders. This happens when moving a window to or from a different monitor. Selecting the window obviously changes the border color and draws it above the other borders as expected.

bloom wrote:

I'll keep that in mind.

Your responsiveness to bug reports and openness to feature requests should really be commended. bspwm is a great window manager with a great developer.

bloom wrote:

Should be fixed.

I hate to have to say it, but the problems persists. "Active" windows on an unfocused monitor still receive input if there are no windows on the focused monitor.
EDIT: Wait, I think I forgot to make install the latest git build. Doh. Let me test it!
EDIT2: Embarrassing mistake on my part, but this is now fixed. Everything else I reported remains accurate.

bloom wrote:

Could you try disconnecting a monitor?

The only way I'm able to "disconnect" the monitor is by killing the optirun + screenclone process from the script I use. I guess the end effect should be the same.

Anyway, the window on the disconnected monitor becomes visible on screen, but as though it's floating. It's drawn above everything on every desktop! By clicking it, focus is switched to the desktop that it was on from the disconnected monitor, and it's tiled into place. Switching to the desktop from the disconnected monitor also focuses it and tiles it. In both cases, once the desktop it was on from the disconnected monitor is focused, the window behaves normally.

Here's a screenshot (this is immediately after disconnecting the monitor):

Also, as you can see, each time the monitor is "re-added" a new Desktop0X is created, but I suppose that's the intended behavior.

---

EDIT3: Upon further testing I've noticed that dmenu won't appear on an empty desktop when there is a second monitor. Switching to a desktop with an open window or opening a window on the selected desktop nullify this problem and dmenu shows up. Also, floating dialog windows (from gimp, for example) sometimes appear on the second monitor despite the window responsible for spawning them existing on the first. I'm not sure if this is a true bug or if it's the responsibility of the program to place its windows on the correct monitor.

Last edited by Supplantr (2013-05-30 22:38:22)

Arch Linux

#251 2013-05-08 12:00:17

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

#252 2013-05-08 18:16:05

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

#253 2013-05-08 18:27:32

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

#254 2013-05-13 08:28:12

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

#255 2013-05-17 14:23:10

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

#256 2013-05-17 17:24:32

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

#257 2013-05-17 17:45:21

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

#258 2013-05-17 19:48:25

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

#259 2013-05-20 08:22:51

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

#260 2013-05-26 19:22:26

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

#261 2013-05-27 08:52:03

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

#262 2013-05-28 15:36:08

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

#263 2013-05-28 19:23:24

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

#264 2013-05-28 19:52:59

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

#265 2013-05-28 23:33:39

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

#266 2013-05-29 08:15:52

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

#267 2013-05-29 12:21:46

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

#268 2013-05-29 13:06:42

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

#269 2013-05-29 16:16:32

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

#270 2013-05-29 20:06:25

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

#271 2013-05-29 21:18:52

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

#272 2013-05-30 09:37:56

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

#273 2013-05-30 19:18:02

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

#274 2013-05-30 20:57:06

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

#275 2013-05-30 21:42:49

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

Board footer