bspwm — A tiling window manager based on binary space partitioning

bloom · 2013-06-07 10:58:47

The randr branch was merged into the master branch.

Supplantr · 2013-06-07 21:38:16

bloom wrote:

Implemented.

This works, thanks.

Could settings be made to propagate across all desktops immediately? Currently, only the focused desktop is updated immediately (I only tested border_width and window_gap, but I'm assuming it's the same for other settings), while others update when an action is performed on them, i.e. opening a new window, rotating, etc.

Also, while I wasn't able to reproduce this, for some reason the mouse pointer would only show up on the second monitor once it intersected an open window. This happened regardless of pointer_follows_monitor's setting. After restarting X, it's working normally, so maybe it was a harmless fluke.

bloom · 2013-06-08 10:46:13

Supplantr wrote:

Could settings be made to propagate across all desktops immediately? Currently, only the focused desktop is updated immediately (I only tested border_width and window_gap, but I'm assuming it's the same for other settings), while others update when an action is performed on them, i.e. opening a new window, rotating, etc.

Part of this was due to a regression but still: very good catch!
Fixed.

Supplantr wrote:

Also, while I wasn't able to reproduce this, for some reason the mouse pointer would only show up on the second monitor once it intersected an open window.

Doesn't ring any bells with me.

Supplantr · 2013-06-09 14:19:53

bloom wrote:

Part of this was due to a regression but still: very good catch!
Fixed.

Thanks.

bspwm crashes after removing the second monitor, but only when the mouse is moved!

bloom · 2013-06-09 15:20:59

Supplantr wrote:

bspwm crashes after removing the second monitor, but only when the mouse is moved!

Fixed (the pointer motions had nothing to do with it though).

Supplantr · 2013-06-09 16:46:30

bloom wrote:

Fixed (the pointer motions had nothing to do with it though).

Thanks, it's fixed. In my situation, bspwm was still usable until the pointer was moved, at which time it crashed. Now that it doesn't produce a crash, when the pointer is moved for the first time after disconnecting the second monitor, the screen flashes once and the pointer sometimes jumps a short distance. Maybe this is particular to me because it's a side effect of the script I use.

bloom · 2013-06-09 20:29:59

Supplantr wrote:

Maybe this is particular to me because it's a side effect of the script I use.

Probably.

aparthia · 2013-06-10 06:23:20

Is there a way to get notification support in bspwm somewhat akin to what naughty does for awesome?

bloom · 2013-06-10 10:39:55

aparthia wrote:

Is there a way to get notification support in bspwm somewhat akin to what naughty does for awesome?

Not exactly. But I don't see what a window manager would have to do with this…

You might be able to integrate notifications with your panel via cow-notify though.

Last edited by bloom (2013-06-10 10:40:28)

aparthia · 2013-06-10 12:45:18

Yeah, I wasn't assuming it should be integrated into bspwm, I was simply looking for a notification server. I have since my post found dunst which works wonders.

Supplantr · 2013-06-13 08:08:09

Would it be possible to make the focusing mechanism remember which window in a "split container" (for lack of a better term) had focus last? For example:

+-------------------------+
|            |            |
|            |     3      |
|            |            |
|     4      |------------|
|            |      |     |
|            |   1  |  2  |
|            |      |     |
+-------------------------+

Say the currently focused window is 1. If focus is changed to 4, then focus right is used, 3 will receive focus. Can focus be returned to 1 when using focus right?
I'm not entirely confident I know exactly how binary trees work, so maybe this isn't possible.

bloom · 2013-06-18 12:58:46

Supplantr wrote:

Would it be possible to make the focusing mechanism remember which window in a "split container" (for lack of a better term) had focus last?

(Sorry: I was busy with sxhkd.)

I'll consider it.

milomouse · 2013-06-24 01:17:01

bloom wrote:

Supplantr wrote:
Would it be possible to make the focusing mechanism remember which window in a "split container" (for lack of a better term) had focus last?
(Sorry: I was busy with sxhkd.)
I'll consider it.

I second the focusing mechanism change. It's the one major qualm I have against using bspwm full-time. Other than that, it's a great window manager and I thank you.

bloom · 2013-06-24 14:33:08

milomouse wrote:

Supplantr wrote:
Would it be possible to make the focusing mechanism remember which window in a "split container" (for lack of a better term) had focus last?
I second the focusing mechanism change.

The requested behavior is brought by d5d8805 via the history_aware_focus setting.

milomouse · 2013-06-24 15:02:13

bloom wrote:

milomouse wrote:
Supplantr wrote:
Would it be possible to make the focusing mechanism remember which window in a "split container" (for lack of a better term) had focus last?
I second the focusing mechanism change.
The requested behavior is brought by d5d8805 via the history_aware_focus setting.

Wow, that was fast -- works great too. I will definitely start using `bspwm' more often and perhaps completely convert after I get everything configured (what I'm doing now). Thank you, bloom. I will let you know if I see any odd behavior or am confused about anything. Appreciate your hard work, really.

cippaciong · 2013-06-24 15:07:38

I noticed that if I use the

bspc list_monitors > "$BSPWM_LAYOUT"; bspc list_history > "$BSPWM_HISTORY"; bspc quit

sequence then dzen behaves strangely. I'm using your scripts for dzen but after running that command workspaces are not colored correctly when swapping: the new focused workspace is not colored as focused but remain with the unfocused color.

bloom · 2013-06-24 18:36:38

cippaciong wrote:

I noticed that if I use the
bspc list_monitors > "$BSPWM_LAYOUT"; bspc list_history > "$BSPWM_HISTORY"; bspc quit
sequence then dzen behaves strangely.

It works fine here.

cippaciong wrote:

I'm using your scripts for dzen but after running that command workspaces are not colored correctly when swapping: the new focused workspace is not colored as focused but remain with the unfocused color.

I assume that by swapping you mean: focus a different desktop?

And does your panel react if you send the focused window to an empty desktop?

After running the series of commands that make your copy of dzen2 behaves oddly, could you issue this:

pgrep -cx cat

And paste the output here?

Last edited by bloom (2013-06-24 18:45:08)

cippaciong · 2013-06-24 19:11:09

bloom wrote:

I assume that by swapping you mean: focus a different desktop?

Yes, I mean using bspc use

bloom wrote:

And does your panel react if you send the focused window to an empty desktop?

Sometime yes, other no.

bloom wrote:

After running the series of commands that make your copy of dzen2 behaves oddly, could you issue this:
pgrep -cx cat
And paste the output here?

pgrep -cx cat
2

I suppose the problem is that I have to instances of dzen2 right? I launch the panel from bspwm's autostart file.

bloom · 2013-06-24 20:03:38

cippaciong wrote:

▶ pgrep -cx cat
2

It means that your previous panel was not properly killed and a remaining cat process is stealing part of the informations from the panel FIFO.

I remember I had this problem with an old version of my killpanel script.

So: make sure you're using fresh versions of the killpanel, launchpanel, etc. scripts.

Last edited by bloom (2013-06-24 20:43:52)

Supplantr · 2013-06-25 08:55:52

bloom wrote:

The requested behavior is brought by d5d8805 via the history_aware_focus setting.

It works well, but could the setting also affect the shift command in a similar manner?

+-------------------------+
|            |            |
|            |     2      |
|            |            |
|     3      |------------|
|            |            |
|            |     1      |
|            |            |
+-------------------------+

Currently, even if window 1 was focused before window 3, if 3 is shifted right it will be swapped with window 2.

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:

+-------------------------+
|      |     |            |
|      |     |            |
|      |     |            |
|   1  |  3  |      2     |
|      |     |            |
|      |     |            |
|      |     |            |
+-------------------------+

bloom · 2013-06-25 12:51:27

Supplantr wrote:

It works well, but could the setting also affect the shift command in a similar manner?

It should be the case now.

Supplantr wrote:

This may be a bit ambitious, but would it be possible to implement a sort of "sticky" presel [...]

It seems quite intuitive, I'll see if I can make this happen.

cippaciong · 2013-06-25 19:15:12

Supplantr wrote:

bloom wrote:
The requested behavior is brought by d5d8805 via the history_aware_focus setting.
It works well, but could the setting also affect the shift command in a similar manner?
+-------------------------+
|            |            |
|            |     2      |
|            |            |
|     3      |------------|
|            |            |
|            |     1      |
|            |            |
+-------------------------+
Currently, even if window 1 was focused before window 3, if 3 is shifted right it will be swapped with window 2.
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:
+-------------------------+
|      |     |            |
|      |     |            |
|      |     |            |
|   1  |  3  |      2     |
|      |     |            |
|      |     |            |
|      |     |            |
+-------------------------+

I like your ideas man

Supplantr · 2013-06-25 20:21:01

bloom wrote:

It should be the case now.

It works as expected, thanks.

bloom wrote:

It seems quite intuitive, I'll see if I can make this happen.

If this could be implemented, bspwm would be more or less feature complete for me.

cippaciong wrote:

I like your ideas man

Another vote for the above feature.

---

The only other feature I can think of is i3-style "focusing windows across monitors," which I mentioned once before.
I'd imagine this could require some substantial changes, and since it doesn't appear that there are too many users of multiple monitors, maybe it's not worth the effort.

bloom · 2013-06-26 10:03:28

@Supplantr:

Regarding the sticky presel feature:

I don't think it would be a good idea to have two presel flavors.

Therefore, I'm thinking of making the global manual/automatic mode local (and sticky): that way I won't have to worry about resetting the mode each time the focus changes, etc.

Regarding the focusing windows across monitors feature:

I could add the following message:

focus_monitor left|right|up|down
Focus the nearest monitor in the given direction.

And add a fallback mechanism so that the function associated with the above message is called when the nearest_neighbor function fails (in the handling of the focus message).

bloom · 2013-06-26 12:18:48

The textwidth project was renamed to txtw to avoid conflicts with dzen2's textwidth gadget.

If you call textwidth from your panel you must:

Kill your panel.
Remove the textwidth-git package.
Install txtw-git.
Replace every instance of textwidth by txtw in your panel script.
Launch your panel.

Arch Linux

#301 2013-06-07 10:58:47

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

#302 2013-06-07 21:38:16

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

#303 2013-06-08 10:46:13

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

#304 2013-06-09 14:19:53

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

#305 2013-06-09 15:20:59

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

#306 2013-06-09 16:46:30

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

#307 2013-06-09 20:29:59

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

#308 2013-06-10 06:23:20

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

#309 2013-06-10 10:39:55

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

#310 2013-06-10 12:45:18

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

#311 2013-06-13 08:08:09

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

#312 2013-06-18 12:58:46

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

#313 2013-06-24 01:17:01

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

#314 2013-06-24 14:33:08

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

#315 2013-06-24 15:02:13

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

#316 2013-06-24 15:07:38

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

#317 2013-06-24 18:36:38

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

#318 2013-06-24 19:11:09

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

#319 2013-06-24 20:03:38

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

#320 2013-06-25 08:55:52

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

#321 2013-06-25 12:51:27

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

#322 2013-06-25 19:15:12

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

#323 2013-06-25 20:21:01

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

#324 2013-06-26 10:03:28

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

#325 2013-06-26 12:18:48

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

Board footer