bspwm — A tiling window manager based on binary space partitioning

andornaut · 2013-09-19 15:56:04

Supplantr wrote:

This may be a bit ambitious, but would it be possible to implement a sort of "sticky" presel that would remain after a window loses focus, so that another window could be shifted into the preselected area? Using the above example, if window 3 has focus and a "sticky" presel left 0.5 command is issued, then window 1 is shifted left, instead of swapping 1 and 3, window 1 would be moved into the presel area like so: ...

Just wondering if this is supported now? If so, how would I move an existing window into a presel position of an existing window?

I was thinking that if one uses the mouse to `move` a window toward another window with a presel state, that instead of swapping the windows, it might be intuitive if the moved window is slotted into the presel position. This would make it easier to reconfigure layouts (if you forgot to use presel when creating a new window, for instance).

Last edited by andornaut (2013-09-19 15:56:52)

Stalafin · 2013-09-19 16:14:10

WonderWoofy wrote:

@Stalafin, you have been around here since 2007 and should know by now that those pictures are far, far too large for these threads. You need to post those on some kind of picture hosting site and then link to them from here. You can also create thumbnails and do some fancy tag nesting to make a thumbnail link to your image.

Sorry there; my browser scaled the pictures down for me for some reason and it looked fine. Thumbnailed those images.

Ploppz · 2013-09-19 16:18:15

I thought I had replied but upon further investigation it seems I haven't...

Supplantr wrote:

Did you follow @aoba's advice to add:
sxhkd &
exec bspwm
to .xinitrc? It really shouldn't be that difficult to get everything working. Look at the examples provided with bspwm and read sxhkd's documentation.

Yes, added that. Is the panel and loop examples there important to make it work?
My bspwmrc file in ~/.config/bspwm looks like this: http://sprunge.us/WePR.

So when I run startx, I just get a black screen and have to force shut down.
But if I run sudo startx, I get the regular startx, you know the basic xorg interface you get without any DE/WM. And the prompt looks like this:

I guess I've just missed something obvious -- then sorry, I'm rather nooby.

Ploppz · 2013-09-19 18:01:58

Okay I figured it out. (doh >_>)
Assigned a shortcut inside sxhkdrc, to open a terminal.

jdarnold wrote:

I'm having the same problem as Ploppz - I've added sxhkd & bspwm to my .xinitrc and all I get is a black screen. The only slightly unusual setup for me is a dual monitor using nVidia's proprietary drivers.
I'm using the bspwm package, not -git, if it matters.

Last edited by Ploppz (2013-09-19 18:02:56)

jdarnold · 2013-09-19 18:24:36

oops, you're right!

Now *that's* minimal!

Supplantr · 2013-09-19 18:28:58

andornaut wrote:

Just wondering if this is supported now? If so, how would I move an existing window into a presel position of an existing window?

Yes, it's possible. window --to-window is used to transplant a window into a preselection. These are the relevant sxhkd keybindings I use:

super + shift + {h,j,k,l}
    d={left,down,up,right}; \
    bspc window $d -w focused.manual || bspc window -w $d.manual || bspc window -s $d || bspc window -m $d -f

EquivEx · 2013-09-19 18:54:22

Pretty sure this works also after the presel

super + y
    bspc window -w last.manual

bloom · 2013-09-19 20:35:23

Stalafin wrote:

I want to report another thing I noticed, which has to do with running two screens:
My Laptop is attached to an external monitor via a docking station. At start-up, the laptop's TFT shows a small portion (the top left part) of the external screen. Also, windows are not expanded to encompass the entire external screen, but only the part that fits the TFT is used.

What's the output of:

xrandr; bspc query -T

for this situation?

Stalafin wrote:

After turning the laptop's screen off with xrandr, the enumeration of the virtual desktops gets changed: look at the bar in the top left. “Desktop02” (I don't know, why it's called that) is now accessible via Super+1, while “I” is accessible via Super+2, etc. Before xrandr, Super+1 corresponded to “1”, as it should. This is what I see right after issuing the command.

This is expected: the desktops of the disconnected monitor are merged into the remaining monitor.

Ploppz · 2013-09-19 20:47:59

loadkeys doesn't work in bspwm. I have a norwegian keyboard. Is there any other way to change the keymap?

Also this is probably a stupid question but how do I add settings in bspwm?
I tried adding this line in .config/bspwm/bspwmrc:
focused_border_color=#FF0000
But no effect.

Supplantr · 2013-09-19 22:08:11

@everyone,
If you're new to bspwm, please consult the documentation and examples. (There's also a wiki entry.) You should find answers to most of your questions contained within!
Disclaimer: I have no authority here; just my two cents.

Ploppz wrote:

loadkeys doesn't work in bspwm. I have a norwegian keyboard. Is there any other way to change the keymap?

Try setxkbmap. Also, remember that keybindings are handled by sxhkd.

Ploppz wrote:

Also this is probably a stupid question but how do I add settings in bspwm?
I tried adding this line in .config/bspwm/bspwmrc:
focused_border_color=#FF0000
But no effect.

bspwmrc is a script executed when bspwm is run. It's not parsed by bspwm whatsoever.
This is what you want:

bspc config focused_border_color '#FF0000'

Last edited by Supplantr (2013-09-19 23:22:53)

andornaut · 2013-09-20 14:08:38

Supplantr wrote:

andornaut wrote:
Just wondering if this is supported now? If so, how would I move an existing window into a presel position of an existing window?
Yes, it's possible. window --to-window is used to transplant a window into a preselection. These are the relevant sxhkd keybindings I use:
super + shift + {h,j,k,l}
    d={left,down,up,right}; \
    bspc window $d -w focused.manual || bspc window -w $d.manual || bspc window -s $d || bspc window -m $d -f

Great, thanks for your help.

Stalafin · 2013-09-20 22:33:40

bloom wrote:

What's the output of:
xrandr; bspc query -T
for this situation?

The output for the situation before turning off the laptop's screen:

% xrandr; bspc query -T
Screen 0: minimum 320 x 200, current 2560 x 1600, maximum 32767 x 32767
LVDS1 connected 1280x800+0+0 (normal left inverted right x axis y axis) 261mm x 163mm
   1280x800       60.2*+   50.0  
   1024x768       60.0  
   800x600        60.3     56.2  
   640x480        59.9  
VGA1 disconnected (normal left inverted right x axis y axis)
HDMI1 disconnected (normal left inverted right x axis y axis)
DP1 connected 2560x1600+0+0 (normal left inverted right x axis y axis) 641mm x 401mm
   2560x1600      60.0*+
   1920x1200      60.0  
   1920x1080      60.0  
   1600x1200      60.0  
   1680x1050      60.0  
   1280x1024      60.0  
   1440x900       59.9  
   1280x720       60.0  
   1024x768       60.0  
   800x600        60.3     56.2  
   640x480        60.0     59.9  
   720x400        70.1  
LVDS1 1280x800+0+0 24,0,0,0 #
  I 12 T @
    m Termite 1200003 2 640x362+320+219 L ------ *
  II 12 T
  III 12 T
  IV 12 T
  V 12 T
  VI 12 T
  VII 12 T
  VIII 12 T
  IX 12 T
  X 12 T
DP1 2560x1600+0+0 24,0,0,0
  Desktop02 12 T @

And after:

% xrandr; bspc query -T      
Screen 0: minimum 320 x 200, current 2560 x 1600, maximum 32767 x 32767
LVDS1 connected (normal left inverted right x axis y axis)
   1280x800       60.2 +   50.0  
   1024x768       60.0  
   800x600        60.3     56.2  
   640x480        59.9  
VGA1 disconnected (normal left inverted right x axis y axis)
HDMI1 disconnected (normal left inverted right x axis y axis)
DP1 connected 2560x1600+0+0 (normal left inverted right x axis y axis) 641mm x 401mm
   2560x1600      60.0*+
   1920x1200      60.0  
   1920x1080      60.0  
   1600x1200      60.0  
   1680x1050      60.0  
   1280x1024      60.0  
   1440x900       59.9  
   1280x720       60.0  
   1024x768       60.0  
   800x600        60.3     56.2  
   640x480        60.0     59.9  
   720x400        70.1  
DP1 2560x1600+0+0 24,0,0,0 #
  Desktop02 12 T ~
  I 12 T @
    m Termite 1200003 2 640x362+320+219 L ------ *
  II 12 T
  III 12 T
  IV 12 T
  V 12 T
  VI 12 T
  VII 12 T
  VIII 12 T
  IX 12 T
  X 12 T

What I find confusing is that I technically don't have two screens - they are showing the same space. I guess in xrandr the appropriate option would be “--same-as” (but I am really just using the default settings the Intel driver uses automagically).

bloom wrote:

Stalafin wrote:
After turning the laptop's screen off with xrandr, the enumeration of the virtual desktops gets changed: look at the bar in the top left. “Desktop02” (I don't know, why it's called that) is now accessible via Super+1, while “I” is accessible via Super+2, etc. Before xrandr, Super+1 corresponded to “1”, as it should. This is what I see right after issuing the command.
This is expected: the desktops of the disconnected monitor are merged into the remaining monitor.

Can I somehow fix that, i.e. reset the desktops?

bloom · 2013-09-21 17:06:36

Nindwen wrote:

With sxhkd, is there a way to easily use one key to cycle through multiple actions?

Yes.

bloom · 2013-09-21 19:18:07

Stalafin wrote:

What I find confusing is that I technically don't have two screens [...]

This should be fixed by ca2d030.

Supplantr · 2013-09-21 22:34:05

I've noticed something peculiar, but I'm not sure wherein lies the problem.
If compton is running alongside dunst and notifications are currently being displayed, switching to an empty desktop and creating a new window will cause this window (and any other windows immediately spawned on the desktop) to overlap dunst's notifications. The notifications remain below these windows until the current notifications are cleared and a new notification window is created. This only happens when compton is running and regardless of dunst's transparency setting.

Another anomaly: if a floating window is intersecting the top edge of the monitor and is unmapped (xdo hide), remapping (xdo show) it will cause the window to appear intersecting the bottom edge of the monitor directly below its previous position.

Possibly a non-issue: rule -a something -d will interpret the next argument as the desktop, even when it's obviously a flag.

Last but not least: perhaps it would be a good idea to maintain some consistency regarding rule UIDs and initial desktop names, seeing as the first rule is 1 but the first desktop is Desktop01.

bloom · 2013-09-22 20:15:05

Supplantr wrote:

If compton is running alongside dunst and notifications are currently being displayed, switching to an empty desktop and creating a new window will cause this window (and any other windows immediately spawned on the desktop) to overlap dunst's notifications. The notifications remain below these windows until the current notifications are cleared and a new notification window is created. This only happens when compton is running and regardless of dunst's transparency setting.

While I was debugging a multi-head problem with my fake multi-head local branch, I found a bug in the current stacking algorithm: the history will have to become global.

However, I don't know if there might be a relation between this bug and your issue.

Supplantr wrote:

Another anomaly: if a floating window is intersecting the top edge of the monitor and is unmapped (xdo hide), remapping (xdo show) it will cause the window to appear intersecting the bottom edge of the monitor directly below its previous position.

It tries to fit the window into its monitor.

I guess it could be avoided by not removing nodes on unmap notify events.

Supplantr wrote:

Possibly a non-issue: rule -a something -d will interpret the next argument as the desktop, even when it's obviously a flag.

--floating is not a forbidden desktop name, but it might not be a very good choice.

Supplantr wrote:

Last but not least: perhaps it would be a good idea to maintain some consistency regarding rule UIDs and initial desktop names, seeing as the first rule is 1 but the first desktop is Desktop01.

Could you elaborate?

(Desktops don't have IDs.)

Supplantr · 2013-09-22 23:03:26

bloom wrote:

However, I don't know if there might be a relation between this bug and your issue.

Let me know if any additional information could be helpful.

bloom wrote:

Could you elaborate?
(Desktops don't have IDs.)

I was suggesting (to promote consistency) that the first desktop be automatically named Desktop1 instead of Desktop01 since rule UIDs forgo the preceding 0. But maybe there is a reason for this, and it's obviously not a real issue. Just an idea.

bloom · 2013-09-23 09:59:06

andornaut wrote:

I have a bspwmrc rule that moves Pidgin to the 3rd desktop and changes it to floating, and I also autostart pidgin with bspwm:
bspc rule -a Pidgin -d ^3 --floating
pidgin &
This works, except that it changes focus to the 3rd desktop as well, but I'd like to keep focus on the 1st desktop. Is there any way to accomplish this?

This should not happen as of 16eae53.

The default behavior is now to ignore EWMH focus requests (the related setting is honor_ewmh_focus).

andornaut · 2013-09-23 13:45:45

bloom wrote:

andornaut wrote:
This works, except that it changes focus to the 3rd desktop as well, but I'd like to keep focus on the 1st desktop. Is there any way to accomplish this?
This should not happen as of 16eae53.

Works great, thanks!

andornaut · 2013-09-23 13:50:17

Sometimes all of my windows will disappear. The window titles will still show up in the panel, but all of the windows on all of the desktops will not be visible (but the applications are still running). Any new applications that I launch will also be invisible. This occurs on both my single-head laptop, and dual-head workstation. When this happens I've resorted to quitting and restarting bspwm.

I've not been able to discover how to reproduce it as it seems to happen somewhat randomly and infrequently.

Let me know if there's any other information that I could provide to help troubleshoot this issue.

WonderWoofy · 2013-09-23 14:45:44

andornaut wrote:

Sometimes all of my windows will disappear. The window titles will still show up in the panel, but all of the windows on all of the desktops will not be visible (but the applications are still running). Any new applications that I launch will also be invisible. This occurs on both my single-head laptop, and dual-head workstation. When this happens I've resorted to quitting and restarting bspwm.
I've not been able to discover how to reproduce it as it seems to happen somewhat randomly and infrequently.
Let me know if there's any other information that I could provide to help troubleshoot this issue.

bspc control --toggle-visibility ???

andornaut · 2013-09-23 17:45:12

WonderWoofy wrote:

andornaut wrote:
Sometimes all of my windows will disappear. The window titles will still show up in the panel, but all of the windows on all of the desktops will not be visible (but the applications are still running). Any new applications that I launch will also be invisible. This occurs on both my single-head laptop, and dual-head workstation. When this happens I've resorted to quitting and restarting bspwm.
I've not been able to discover how to reproduce it as it seems to happen somewhat randomly and infrequently.
Let me know if there's any other information that I could provide to help troubleshoot this issue.
bspc control --toggle-visibility ???

Yeah, that fixes it, thanks. I'm not sure why the windows are hidden to begin with, though. I don't have bspc control --toggle-visibility bound to a key-combination that I'm aware of.

Stalafin · 2013-09-23 19:29:29

bloom wrote:

Stalafin wrote:
What I find confusing is that I technically don't have two screens [...]
This should be fixed by ca2d030.

Got the latest git version - bspwm starts if I have my laptop running only, but exits immediately when I run it with an external screen attached. Not sure how to debug that at the moment.

andornaut · 2013-09-23 21:10:07

andornaut wrote:

WonderWoofy wrote:
andornaut wrote:
Sometimes all of my windows will disappear. The window titles will still show up in the panel, but all of the windows on all of the desktops will not be visible (but the applications are still running). Any new applications that I launch will also be invisible. This occurs on both my single-head laptop, and dual-head workstation. When this happens I've resorted to quitting and restarting bspwm.
I've not been able to discover how to reproduce it as it seems to happen somewhat randomly and infrequently.
Let me know if there's any other information that I could provide to help troubleshoot this issue.
bspc control --toggle-visibility ???
Yeah, that fixes it, thanks. I'm not sure why the windows are hidden to begin with, though. I don't have bspc control --toggle-visibility bound to a key-combination that I'm aware of.

Just noticed that clicking in the clock part of the dzen2 will toggle visibility of all windows. I've unbound button #1,3 events with "dzen ... -e button1=;button=3" - does anyone know how to unbind the "toggle visibility" from the clock?

Supplantr · 2013-09-23 21:34:05

andornaut wrote:

does anyone know how to unbind the "toggle visibility" from the clock?

Assuming you're using the example dzen2 script, it should be as simple as removing ^ca(1, bspc control --toggle-visibility) and the consecutive ^ca() from sys_infos.

[edit] Which was just done in the latest git commit.

Last edited by Supplantr (2013-09-23 21:35:46)

Arch Linux

#626 2013-09-19 15:56:04

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

#627 2013-09-19 16:14:10

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

#628 2013-09-19 16:18:15

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

#629 2013-09-19 18:01:58

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

#630 2013-09-19 18:24:36

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

#631 2013-09-19 18:28:58

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

#632 2013-09-19 18:54:22

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

#633 2013-09-19 20:35:23

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

#634 2013-09-19 20:47:59

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

#635 2013-09-19 22:08:11

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

#636 2013-09-20 14:08:38

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

#637 2013-09-20 22:33:40

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

#638 2013-09-21 17:06:36

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

#639 2013-09-21 19:18:07

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

#640 2013-09-21 22:34:05

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

#641 2013-09-22 20:15:05

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

#642 2013-09-22 23:03:26

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

#643 2013-09-23 09:59:06

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

#644 2013-09-23 13:45:45

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

#645 2013-09-23 13:50:17

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

#646 2013-09-23 14:45:44

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

#647 2013-09-23 17:45:12

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

#648 2013-09-23 19:29:29

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

#649 2013-09-23 21:10:07

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

#650 2013-09-23 21:34:05

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

Board footer