bspwm — A tiling window manager based on binary space partitioning

Supplantr · 2013-08-28 14:39:49

bloom wrote:

Could you specify the expected results?

It's my understanding that dragging windows with the mouse should only swap them, not transplant them. For instance, when the rightmost window (3000001 in the above example) is preselected and the window to the left on the same desktop is dragged into it, the windows are merely swapped. Also, even if transplanting were the intended behavior, it's not done correctly in the above scenario. If window 3000001 is preselected right or left the window dragged into it from the second monitor is transplanted to the right; if preselected up or down it's transplanted up.

Also, since we're on the topic of monitors, would it be possible to allow an empty desktop on a secondary monitor to be focused by clicking the root window of that monitor?

bloom · 2013-08-29 09:56:16

Supplantr wrote:

It might be useful to include the presel condition of windows in query -T output

Done.

bloom · 2013-08-29 09:57:37

Supplantr wrote:

Also, since we're on the topic of monitors, would it be possible to allow an empty desktop on a secondary monitor to be focused by clicking the root window of that monitor?

It is now possible (via pointer -g focus).

Supplantr · 2013-08-29 23:00:37

bloom wrote:

It is now possible (via pointer -g focus).

Thanks, it works well.

I tried to use xwinmosaic with bspwm but it fails, reporting that the window manager doesn't support EWMH specifications. It seems to expect the _NET_SUPPORTING_WM_CHECK atom to be defined.

I've also noticed that, when switching to monocle layout, there appears to be a delay dependent on the number of open windows on the desktop. Is this to be expected?

bloom · 2013-08-30 09:59:03

Supplantr wrote:

I tried to use xwinmosaic with bspwm but it fails, reporting that the window manager doesn't support EWMH specifications. It seems to expect the _NET_SUPPORTING_WM_CHECK atom to be defined.

It should work as of f98770b.

Supplantr wrote:

I've also noticed that, when switching to monocle layout, there appears to be a delay dependent on the number of open windows on the desktop. Is this to be expected?

The delay seems to come from compton.

aoba · 2013-08-30 19:57:47

Hello!

I am having an issue with bspwm + compton and (only) terminal windows. Here is a (zoomed) picture:

(linked due to size)
An unfocused terminal (left) and a focused terminal.

As you can see, the unfocused terminal does not appear to have a border at all (it should be #000000). What you probably cannot see is that the focused window's border is partially transparent (it should be #ffc47a). Setting opacity in the terminal preferences does not help, and I have seen this problem with urxvt, terminator and sakura, all from the Arch repositories. And just to reiterate, I have only see this happen with terminals.

Regarding compton

I have tried:

$ compton --vsync opengl
$ compton --config /dev/null

I do not know whose fault it is: compton's, bspwm's, or mine. I did not see any outstanding issues on github. The problem does vanish immediately if I kill compton, but if I do that, vsync/tearing issues will come back to haunt my computer.

I do not think it has anything to do with this issue, because the problem is a little different, and the compton versions I have tried (compton-git in the aur: compton-git-2013.06.25.gb26bbc0-1, compton-git-2013.08.13.g6037eb2-1) were from long after that issue was marked as resolved.

bspwmrc

#!/bin/bash

#
# bspwmrc
#


# background stuff

compton --vsync opengl &
/usr/lib/openbox/openbox-xdg-autostart &
sxhkd -c $HOME/.config/bspwm/sxhkdrc &
(sleep 4 && stalonetray --background black --decorations none --geometry '1x1-48+0' --grow-gravity E --icon-gravity NE --icon-size 16 --sticky true --window-layer top) &

# desktops

bspc desktop Desktop01 -n web
bspc monitor -a code media games wine


# colors

bspc config active_border_color		'#ffc47a'
bspc config focused_border_color 	'#ffc47a'
bspc config normal_border_color		'#000000'
bspc config presel_border_color		'#31aeff'
bspc config urgent_border_color		'#ff9e24'

bspc config active_locked_border_color		'#ff9e24'
bspc config focused_locked_border_color		'#ff9e24'
bspc config normal_locked_border_color		'#31aeff'


# geometry

bspc config border_width	2
bspc config window_gap		4
bspc config split_ratio		0.5
bspc monitor -p 			18 0 0 0


# misc

bspc config auto_cancel 			true
bspc config apply_shadow_property 	true
bspc config borderless_monocle 		false
bspc config focus_follows_pointer 	false
bspc config gapless_monocle 		false
bspc config pointer_follows_monitor	false


# desktop rules

bspc rule -a Gimp-2.8 -d media --follow --floating --focus
bspc rule -a mplayer2 -d media --follow --floating --focus
bspc rule -a Sonata -d media --follow --floating --focus
bspc rule -a Wine -d wine --follow --floating --focus


# floating rules

bspc rule -a 'File Operation Progress' --floating --focus
bspc rule -a Mirage --floating --focus
bspc rule -a Nitrogen --floating --focus

Final Remarks

If you need any additional info from me (config/log files, testing, screenshots...), please ask. And thank you for sharing bspwm/sxhkd. It took some effort for me to set them up, but they are a pleasure to use.

bloom · 2013-08-30 21:43:26

ciarlill wrote:

Has anyone got bspwm working with LXDM?
I get logged into to some sort of session but no hotkeys work.

The issue might be fixed by 8448fe0.

Could you try again?

bloom · 2013-08-31 12:40:21

aoba wrote:

bspc rule -a Gimp-2.8 -d media --follow --floating --focus
bspc rule -a mplayer2 -d media --follow --floating --focus
bspc rule -a Sonata -d media --follow --floating --focus
bspc rule -a Wine -d wine --follow --floating --focus
bspc rule -a 'File Operation Progress' --floating --focus
bspc rule -a Mirage --floating --focus
bspc rule -a Nitrogen --floating --focus

Unrelated remark: you don't need --focus here.

aoba wrote:

If you need any additional info from me (config/log files, testing, screenshots...), please ask.

Maybe .Xresources.

(And a guide on how to reproduce the issue.)

aoba · 2013-08-31 17:15:15

Thanks for the tip.

I can reproduce the problem with the following steps. It was not done on a fresh install, so there is a chance that they were not sufficient. Even though it is likely irrelevant, I included sxhkd.

1. Reinstall Packages

$ sudo pacman -Rns bspwm-git compton-git sxhkd-git
$ sudo pacman -U bspwm-git-660-1-x86_64.pkg.tar.xz
$ sudo pacman -U compton-git-2013.08.13.g6037eb2-1-x86_64.pkg.tar.xz
$ sudo pacman -U sxhkd-git-84-1-x86_64.pkg.tar.xz

2. Add a New User
I added a new user with the following config files:

~/.bash_profile

#
# ~/.bash_profile
#

[[ -f ~/.bashrc ]] && . ~/.bashrc

~/.bashrc

#
# ~/.bashrc
#

# If not running interactively, don't do anything
[[ $- != *i* ]] && return

alias ls='ls --color=auto'
PS1='[\u@\h \W]\$ '

~/.xinitrc

#!/bin/sh
#
# ~/.xinitrc
#

bspwm

~/.xsession

#!/bin/sh

#
# ~/.xsession
#
# Executed by xdm/gdm/kdm at login
#

/bin/bash --login -i ~/.xinitrc

~/.config/bspwm/bspwmrc

#!/bin/bash

#
# bspwmrc
#


# background
compton &
sxhkd -c $HOME/.config/bspwm/sxhkdrc &


# desktops

bspc desktop Desktop01 -n web
bspc monitor -a code media games wine


# colors

bspc config active_border_color		'#ffc47a'
bspc config focused_border_color 	'#ffc47a'
bspc config normal_border_color		'#000000'
bspc config presel_border_color		'#31aeff'
bspc config urgent_border_color		'#ff9e24'

bspc config active_locked_border_color		'#ff9e24'
bspc config focused_locked_border_color		'#ff9e24'
bspc config normal_locked_border_color		'#31aeff'


# geometry

bspc config border_width	2
bspc config window_gap		4

~/.config/bspwm/sxhkdrc

#!/bin/bash

#
# bspwm-specific sxhkd config
#



# launcher
super + u
	dmenu_run



# global

# exit
super + control + e
	bspc quit

# reload these hotkeys
super + control + l
	pkill -USR1 -x sxhkd



# window controls

# main focus control

~button1
	bspc pointer -g focus

# move/resize
super + button{1,3}
	bspc pointer -g {move,resize_corner}

super + @button{1,3}
	bspc pointer -g focus

super + !button{1,3}
	bspc pointer -t %i %i

# close/kill
# focus on middle button down; kill on middle button up.  the window
# focused on mousedown will still be killed even if you move the
# away before releasing the button.  instead, release the super key
# before the mouse button to cancel the action.
super + button2
	bspc pointer -g focus

super + {_,control +} @button2
	bspc window {-c,-k}

# move the focused window to the biggest tile
super + Return
	bspc window -w biggest

# move the focused window in the specified direction
super + alt + {Up,Down,Left,Right}
	bspc window -w {up,down,left,right}

# focus the next window in the specified direction
super + {Up,Down,Left,Right,shift + tab,tab}
	bspc window -f {up,down,left,right,prev,next}

# move the focused window to the specified desktop
super + alt + {1,2,3,4,5,comma,period}
	bspc window -d {web,code,media,games,wine,prev,next} -f

# toggle the focused window's fullscreen/floating state
super + {f,space}
	bspc window -t {fullscreen,floating}

# close/kill the focused window
super + {_,control +} k
	bspc window {-c,-k}




# desktop controls

# switch to the specified desktop
super + {1,2,3,4,5,comma,period}
	bspc desktop -f {web,code,media,games,wine,prev,next}

# cycle the windows on the focused desktop
super + {bracketleft,bracketright}
	bspc desktop -C {forward,backward}

# flip the windows on the focused desktop
super + {slash,equal}
	bspc desktop -F {horizontal,vertical}

# cycle the layout on the focused desktop
super + backslash
	bspc desktop -l next

Note: sorry that this one is so huge.

Note 2: the only other config file was ~/.bash_logout (which was blank), so I did not include an ~/.Xresources.

3. Start X
I logged into the new user's account and started X:

$ startx

Note: the problem also happens when I log in with LightDM.

4. Launch Programs

At this point I launched a terminal with dmenu (sakura) and another program (leafpad in this case, but any seems to be fine), and observed the problem.

Mindstormscreator · 2013-08-31 20:56:29

Is there / could there be a way to preselect other window actions such as enabling floating mode? For example, preselecting floating and opening a window would automatically make that window in floating mode which could be useful for keybindings which open temporary terminals, file managers and the like.

EDIT: It would also be nice to be able to set different window gaps per desktop, for example one desktop might be for casual work with huge gaps and one with no gaps.

Last edited by Mindstormscreator (2013-09-01 16:30:52)

F34R · 2013-09-01 16:06:43

I try many suggestion , and i want move to bspwm. Some method for use the bar alike dzen. Anybody tell me step to step how make this bar ? #223 from Starfall post and some usefull settings in statusbar : cmus, volume, clock/date, cpu , ram

Iao · 2013-09-02 05:57:00

I have a feature suggestion: Give monitors/desktops/windows (I'll call them items) ID #s and let them be selected by assigned ID #s when using commands. Each item type would have a separate list of ID #s. This would allow for more ways to interact with items, including features found in other window managers such as i3.

For example, I would edit my sxhkd keybinds to point to ID #s for desktop switching. This way I would be able to create/remove desktops and switch between any available without having to edit keybinds in my sxhkdrc and reload sxhkd.

super + {1-9}
   bspc desktop -f # {1-9}

You may ask why I don't just change the desktop names to numbers. Well, I simply want to be able to give desktops actual names for what they're being used for.

You could also include settings for how the ID #s are generated and organized. This would also allow more functionality than what's possible with desktops just named with numbers:

1) Assign the ID # following the previously created ID # when creating a new item
2) Assign the lowest available ID # when creating a new item
3) Actively assign the lowest #s available to existent items (for when there are higher ID #s when a monitor/desktop is removed)
4) Start generating ID #s from a certain # (for if you want to start from 1, not 0 and vice versa)

I suppose some of things I'm looking for could be done with some scripting but it would be nice if they could be done by default. Let me know what you think.

bloom · 2013-09-02 09:48:54

aoba wrote:

I can reproduce the problem with the following steps.

You should probably create an issue on compton's github page.

bloom · 2013-09-02 09:56:46

Iao wrote:

I have a feature suggestion: Give monitors/desktops/windows (I'll call them items) ID #s and let them be selected by assigned ID #s when using commands. Each item type would have a separate list of ID #s. This would allow for more ways to interact with items, including features found in other window managers such as i3.

What I could provide is a notation such that: ^n would designate the nth object of the given type.

E.g.:

bspc desktop ^3 -f

would focus the third desktop.

Last edited by bloom (2013-09-02 19:57:18)

Iao · 2013-09-02 14:00:03

bloom wrote:

What I could provide is a notation such that: #n would designate the nth object of the given type.
E.g.:
bspc desktop #3 -f
would focus the third desktop.

Something along those lines would be great. Thank you.

aoba · 2013-09-02 17:13:07

bloom wrote:

You should probably create an issue on compton's github page.

I reported this issue if anyone is interested.

bloom · 2013-09-02 19:11:35

Iao wrote:

Something along those lines would be great.

Brought by e2f0858 (I chose a different character for obvious reasons).

Last edited by bloom (2013-09-02 19:56:26)

Supplantr · 2013-09-03 02:04:05

Mindstormscreator wrote:

Is there / could there be a way to preselect other window actions such as enabling floating mode? For example, preselecting floating and opening a window would automatically make that window in floating mode which could be useful for keybindings which open temporary terminals, file managers and the like.

The utility of something like this has occurred to me as well. If any window action could be applied, I'd imagine it would be possible to presel windows as they're spawned and create a sort of "dynamic" layout.

Mindstormscreator wrote:

It would also be nice to be able to set different window gaps per desktop, for example one desktop might be for casual work with huge gaps and one with no gaps.

This would be handy, but I think for it to be the most useful, border width (and maybe even padding) would also need to be definable per-desktop. Actually, looking at the list of settings, quite a few of them could be defined per-desktop.

Even more wishful thinking: allow padding to be specified for each edge independently (i.e. bspc monitor -p top 16) and keep the current syntax available as well.

---

The recently added ^<n> notation doesn't seem to be working (unless I'm simply using it incorrectly). bspc desktop ^1 -f fails with an exit code of 1.

Also, is there any other possible fix for the currently open issue on github? It seems to also affect Steam. Its drop down menus appear but clicking on them does nothing. Removing the indicated keybinding from sxhkdrc resolves this, but obviously isn't the most ideal solution.
[edit] I should note that the above issue with Steam only surfaced recently, and I've always been using the problematic keybinding. And it happens regardless of whether or not the main Steam window is floating or tiled.

Last edited by Supplantr (2013-09-03 02:25:27)

dLclassic · 2013-09-03 06:55:23

I'm still receiving the "failed to connect to socket" after having "export BSPWM_SOCKET=/tmp/bspwm-socket" in my .profile as well as the first line in my .bashrc. My non-wm specific sxkcd bindings all work but if i try to run a bspwm command I receive that error. What am i missing? Is there a file that should actually be in /tmp/bspwm-socket?

bloom · 2013-09-03 09:46:27

Supplantr wrote:

Mindstormscreator wrote:
Is there / could there be a way to preselect other window actions such as enabling floating mode? For example, preselecting floating and opening a window would automatically make that window in floating mode which could be useful for keybindings which open temporary terminals, file managers and the like.
The utility of something like this has occurred to me as well. If any window action could be applied, I'd imagine it would be possible to presel windows as they're spawned and create a sort of "dynamic" layout.

I'd like to have a concrete example.

Supplantr wrote:

Mindstormscreator wrote:
It would also be nice to be able to set different window gaps per desktop, for example one desktop might be for casual work with huge gaps and one with no gaps.
This would be handy, but I think for it to be the most useful, border width (and maybe even padding) would also need to be definable per-desktop. Actually, looking at the list of settings, quite a few of them could be defined per-desktop.

I'll keep that in mind.

Supplantr wrote:

Even more wishful thinking: allow padding to be specified for each edge independently

Agreed.

Supplantr wrote:

The recently added ^<n> notation doesn't seem to be working (unless I'm simply using it incorrectly). bspc desktop ^1 -f fails with an exit code of 1.

The above command works fine here.

Supplantr wrote:

Also, is there any other possible fix for the currently open issue on github? It seems to also affect Steam. Its drop down menus appear but clicking on them does nothing. Removing the indicated keybinding from sxhkdrc resolves this, but obviously isn't the most ideal solution.
[edit] I should note that the above issue with Steam only surfaced recently, and I've always been using the problematic keybinding. And it happens regardless of whether or not the main Steam window is floating or tiled.

The suggested fix is not to remove the indicated binding but to modify it.

Since the menu's window is not managed, there is no other fix.

Last edited by bloom (2013-09-03 21:00:47)

cippaciong · 2013-09-03 11:56:50

dLclassic wrote:

I'm still receiving the "failed to connect to socket" after having "export BSPWM_SOCKET=/tmp/bspwm-socket" in my .profile as well as the first line in my .bashrc.

echo $BSPWM_SOCKET

to check if the variable is correctly set.

dLclassic wrote:

My non-wm specific sxkcd bindings all work but if i try to run a bspwm command I receive that error. What am i missing? Is there a file that should actually be in /tmp/bspwm-socket?

Actually, that is the file.

instantepiphany · 2013-09-04 03:49:29

This may be slightly off-topic, but I am having issues configuring bspwm. I am trying to use windelicato's config, and then once I get that working change it to my liking from there. Anyway, the thread I just made is here. I am posting this in this thread on the off chance that it is a bug with bspwm(probably isn't but just in case) and I would appreciate it if someone could give a quick glance over my post in that thread and point out the probably obvious problem. Thanks!

flexo3001 · 2013-09-04 12:53:57

bloom wrote:

flexo3001 wrote:
is bspwm using code from dwm?
No, why?

was just a stupid thought. 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".

nevermind, besides herbstluftwm is bspwm the best

aoba · 2013-09-04 15:36:49

bloom wrote:

aoba wrote:
If you need any additional info from me (config/log files, testing, screenshots...), please ask.
Maybe .Xresources.

I messed up before when testing. Setting the following line in ~/.Xresources triggers the issue for urxvt (and removing the line fixes it).

URxvt.depth: 32

sakura and terminator appear to be 32-bit windows regardless of configuration.

The following is the latest comment from richardgv on the issue I reported to compton's github.

richardgv wrote:

Tested with urxvt and could reproduce the issue. But it happens on xcompmgr-1.1.6 and gandalfn/Cairo-Composite-Manager@719a997 as well. (Cairo-compmgr does not handle border position correctly, additionally.)
Read some code in bspwm, and it's using the default colormap to configure color on all windows -- regardless of whether they are using default colormap, which I believe isn't too great. I wrote a patch to test the effect of doing this in the correct way:
diff --git a/window.c b/window.c
index 184ba86..fc24052 100644
--- a/window.c
+++ b/window.c
@@ -206,7 +206,18 @@ void window_draw_border(node_t *n, bool focused_window, bool focused_monitor)
         return;

     xcb_window_t win = n->client->window;
-    uint32_t border_color_pxl = get_border_color(n->client, focused_window, focused_monitor);
+
+    /**
+     * WARNING: This is intended to demonstrate the effect of selecting
+     * color from correct colormap and should not be used practically!
+     */
+    uint32_t border_color_pxl = 0;
+    {
+        xcb_get_window_attributes_reply_t *r = xcb_get_window_attributes_reply(dpy, xcb_get_window_attributes(dpy, win), NULL);
+        xcb_colormap_t cmap = r->colormap;
+        border_color_pxl = xcb_alloc_color_reply(dpy, xcb_alloc_color(dpy, cmap, 0xffff, 0x0000, 0x0000), NULL)->pixel;
+        free(r);
+    }

     if (n->split_mode == MODE_AUTOMATIC) {
         xcb_change_window_attributes(dpy, win, XCB_CW_BORDER_PIXEL, &border_color_pxl);
After applying this patch the border color appears correct (all red) on windows with 24/32-bit visuals. This patch is intended for demonstration only. Fixing the whole routine requires a number of modifications to the code of bspwm, and I know little about XCB. Thus it should be done by the author of it to avoid any potential issues. Feel free to forward my comments to him.
Update: Weirdly enough, on my home computer, with bspwm-e2f085815a, all window borders appear yellow, regardless of what color I configure... Don't have time to look into this tonight.
Update 2: I could reproduce the bug on normal X on my home computer, and my patch seemingly is working. Weirdly enough Xephyr doesn't work.

bloom · 2013-09-04 15:48:16

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

Arch Linux

#451 2013-08-28 14:39:49

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

#452 2013-08-29 09:56:16

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

#453 2013-08-29 09:57:37

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

#454 2013-08-29 23:00:37

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

#455 2013-08-30 09:59:03

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

#456 2013-08-30 19:57:47

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

#457 2013-08-30 21:43:26

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

#458 2013-08-31 12:40:21

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

#459 2013-08-31 17:15:15

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

#460 2013-08-31 20:56:29

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

#461 2013-09-01 16:06:43

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

#462 2013-09-02 05:57:00

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

#463 2013-09-02 09:48:54

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

#464 2013-09-02 09:56:46

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

#465 2013-09-02 14:00:03

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

#466 2013-09-02 17:13:07

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

#467 2013-09-02 19:11:35

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

#468 2013-09-03 02:04:05

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

#469 2013-09-03 06:55:23

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

#470 2013-09-03 09:46:27

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

#471 2013-09-03 11:56:50

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

#472 2013-09-04 03:49:29

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

#473 2013-09-04 12:53:57

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

#474 2013-09-04 15:36:49

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

#475 2013-09-04 15:48:16

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

Board footer