bspwm — A tiling window manager based on binary space partitioning

Supplantr · 2013-06-26 18:03:59

bloom wrote:

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.

Would this mean that if a presel command is issued and it's not cancelled/a new window isn't spawned that it would remain after the preselected window loses focus? This seems intuitive.
I'm not entirely sure what you mean by "local," especially in the context of automatic mode.

bloom wrote:

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).

This sounds like a good idea! Would the fallback mechanism be enabled through a setting?

---

The order in which the window tree is traversed by focus is different if:

focus_by_distance is set (obviously)
history_aware_focus is set (which trumps focus_by_distance)
Neither are set, i.e. "vanilla" focusing order

I'm mentioning this because a) it's slightly odd that history_aware_focus's initial focusing order is different than "vanilla," and b) currently it's not possible to use focus_by_distance and history_aware_focus in conjunction. Could this be remedied?

Last edited by Supplantr (2013-06-26 19:22:59)

bloom · 2013-06-26 21:06:19

Supplantr wrote:

Would this mean that if a presel command is issued and it's not cancelled/a new window isn't spawned that it would remain after the preselected window loses focus? This seems intuitive.

You're probably right, I'll more likely add a --sticky option to presel then.

Supplantr wrote:

bloom wrote:
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).
This sounds like a good idea! Would the fallback mechanism be enabled through a setting?

Yes.

Supplantr wrote:

The order in which the window tree is traversed by focus is different if:
focus_by_distance is set (obviously)
history_aware_focus is set (which trumps focus_by_distance)
Neither are set, i.e. "vanilla" focusing order
I'm mentioning this because a) it's slightly odd that history_aware_focus's initial focusing order is different than "vanilla," and b) currently it's not possible to use focus_by_distance and history_aware_focus in conjunction. Could this be remedied?

a)

In fact the history_aware_focus uses the focus history which is already used to provide consistent stacking order, etc.

A node is added to that list each time it is focused: not necessarily via a focus message.

I know how to implement it without relying on the focus history but it requires to introduce new node attributes and to update those attributes on each rotation, swap, etc.

b)
Could you provide an example on how they might interact?

Last edited by bloom (2013-06-26 21:06:49)

Supplantr · 2013-06-26 23:48:59

bloom wrote:

You're probably right, I'll more likely add a --sticky option to presel then.

Maybe this would be the best option. Although, I'd probably end up using presel --sticky exclusively. My logic being: if you issue a presel command and don't immediately spawn a new window to occupy it, you'd probably want the preselection to persist after changing focus so you could fill it with an already open window. It couldn't hurt to make the "sticky" behavior optional, though.

In either case, if presel gains a "sticky" behavior, a cancel --all command would be useful, don't you think?

bloom wrote:

Supplantr wrote:
This sounds like a good idea! Would the fallback mechanism be enabled through a setting?
Yes.

This would satisfy me.

bloom wrote:

In fact the history_aware_focus uses the focus history which is already used to provide consistent stacking order, etc.
A node is added to that list each time it is focused: not necessarily via a focus message.
I know how to implement it without relying on the focus history but it requires to introduce new node attributes and to update those attributes on each rotation, swap, etc.

This is a *facepalm* moment. I pretty much totally misunderstood what was happening here. Now that I think (correctly) about it, everything makes sense. I'm not smart enough for this window manager!

bloom wrote:

Could you provide an example on how they might interact?

Now that I've become enlightened, I guess there is no way for them to interact. I don't know what I was thinking.

bloom · 2013-06-27 09:05:27

Supplantr wrote:

bloom wrote:
You're probably right, I'll more likely add a --sticky option to presel then.
Maybe this would be the best option. Although, I'd probably end up using presel --sticky exclusively. My logic being: if you issue a presel command and don't immediately spawn a new window to occupy it, you'd probably want the preselection to persist after changing focus so you could fill it with an already open window. It couldn't hurt to make the "sticky" behavior optional, though.

My bad: I misread you original objection. Spawning should always reset the mode of the focused node, this is obvious and will never change.

We have the same views on the subject: there must be only one version of presel: otherwise you'll have to think about which version is best suited for the task you're about to perform.

Supplantr wrote:

In either case, if presel gains a "sticky" behavior, a cancel --all command would be useful, don't you think?

Yes, it was already planned.

Last edited by bloom (2013-06-27 09:06:12)

bloom · 2013-06-27 17:46:37

Supplantr wrote:

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?

Should be working as of dee3902.

Supplantr · 2013-06-27 19:38:41

bloom wrote:

Should be working as of dee3902.

It seems to be working perfectly, and I must say this is a life-affirming window management experience.

I have one question: is swap designed to literally "swap" windows rather than use the same mechanism as shift?
If that's the case, could a message be added that actually "shifts" a focused window into the previously focused window? That way one would be able to switch focus to a window, apply a presel, then bspc alternate && bspc "shift into last focused window".

EDIT: Also, swap's --keep-focus flag is a bit redundant since the same effect can be achieved with bspc swap && bspc alternate.

Last edited by Supplantr (2013-06-27 19:50:40)

bloom · 2013-06-28 10:13:22

Supplantr wrote:

I have one question: is swap designed to literally "swap" windows rather than use the same mechanism as shift?

shift and swap both call swap_nodes but I was reluctant to do node transplantation directly within swap_node because it is also called by circulate.

However, I was able to fix the crash that occurred in circulate_leaves when node transplantation was involved.

And therefore swap should now work as expected.

Supplantr wrote:

Also, swap's --keep-focus flag is a bit redundant since the same effect can be achieved with bspc swap && bspc alternate.

Not exactly because:

It generates two useless and contradictory calls to focus_node.
It makes the window borders blink.
Since bspc always returns successfully, it is equivalent to bspc swap; bspc alternate.

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

bloom · 2013-06-28 13:52:41

New message: focus_monitor.
New setting: monitor_focus_fallback.

Sirsurthur · 2013-07-01 18:40:02

Hi bloom,

Thanks for your great work ! I especially like the hydrid tiling approach that bspwm provides. It gives a great control over window management and fulfills greatly my needs.

Coming from dwm, I would perhaps miss two things :
1- the possibility to display two tags/workspaces in one workspace,
2- the presence of a simple and built-in statusbar, which could be toggled and could read stdin.

Looking forward to see your next developments !

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

Sirsurthur wrote:

Coming from dwm, I would perhaps miss two things :
1- the possibility to display two tags/workspaces in one workspace,

The question was raised in the embryonic days of bspwm and I still don't know how I might transpose this.

Sirsurthur wrote:

2- the presence of a simple and built-in statusbar, which could be toggled and could read stdin.

There will never be a built-in panel because it would violate one of the UNIX design principles.

However:

Panels can be quite simple.
And can be toggled.

Supplantr · 2013-07-02 19:01:03

bloom wrote:

However, I was able to fix the crash that occurred in circulate_leaves when node transplantation was involved.
And therefore swap should now work as expected.

Thanks, swap works.
However, there is a problem with circulate:

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

The above windows were automatically tiled. If presel up is applied to window 4 and circulate forward is used four times, the layout becomes:

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

bloom wrote:

New message: focus_monitor.
New setting: monitor_focus_fallback.

These seem to be working perfectly; thanks!

Sirsurthur wrote:

1- the possibility to display two tags/workspaces in one workspace

My two cents: a tagging system wouldn't make much sense without dynamic layouts. How would windows from multiple tags be arranged together in an intuitive manner?

bloom · 2013-07-02 19:37:26

Supplantr wrote:

There is a problem with circulate

Should be fixed.

Supplantr · 2013-07-04 04:10:52

bloom wrote:

Should be fixed.

It's working correctly now.

I don't know if this is really an issue, but if send_to DESKTOP --follow is used on a desktop with no windows, focus is still switched to DESKTOP.

Would it be viable to make two consecutive and identical presel messages (e.g. presel right 0.6 followed by presel right 0.6) call cancel? That way a preselection could be "toggled" with the same hotkey.

---EDIT---

bloom wrote:

The problem is that when you release super before releasing button1, bspc ungrab_pointer is not called.
Maybe I can work things out so that the ungrab_pointer message isn't needed...

Just wondering, has any progress been made regarding the above (from this post)? Moving floating windows with the mouse is still a bit finicky because of this.

Last edited by Supplantr (2013-07-04 06:52:38)

bloom · 2013-07-04 09:17:51

Supplantr wrote:

bloom wrote:
The problem is that when you release super before releasing button1, bspc ungrab_pointer is not called.
Maybe I can work things out so that the ungrab_pointer message isn't needed...
Just wondering, has any progress been made regarding the above (from this post)? Moving floating windows with the mouse is still a bit finicky because of this.

It should now work as expected.

(The ungrab_pointer message was removed.)

Furthermore, it is advised to update to the latest Git version of sxhkd, otherwise it will crash if you release super before releasing button1.

bloom · 2013-07-04 10:22:31

Supplantr wrote:

I don't know if this is really an issue, but if send_to DESKTOP --follow is used on a desktop with no windows, focus is still switched to DESKTOP.

Fixed.

Supplantr wrote:

Would it be viable to make two consecutive and identical presel messages (e.g. presel right 0.6 followed by presel right 0.6) call cancel? That way a preselection could be "toggled" with the same hotkey.

New setting: auto_cancel.

aparthia · 2013-07-04 22:44:18

Is there a way to 'tag' an entire workspace/desktop as floating in the same way as you can set a desktop to monocle or tiling mode?

Last edited by aparthia (2013-07-04 22:59:53)

bloom · 2013-07-05 07:01:11

aparthia wrote:

Is there a way to 'tag' an entire workspace/desktop as floating in the same way as you can set a desktop to monocle or tiling mode?

Not exactly, because there's no floating layout but only a floating state.

I assume you're not willing to use rules for this?

Supplantr · 2013-07-05 10:16:41

bloom wrote:

It should now work as expected.
(The ungrab_pointer message was removed.)

Thanks, it works. Moving floating windows is now a breeze!

bloom wrote:

New setting: auto_cancel.

This works well; thanks.

---

With monitor_focus_fallback enabled, it's possible to shift windows between monitors, but focus doesn't follow the shifted window.

bloom · 2013-07-05 10:37:57

Supplantr wrote:

With monitor_focus_fallback enabled, it's possible to shift windows between monitors, but focus doesn't follow the shifted window.

It should now behave as expected.

---

An important discussion has started.

Users are invited to participate.

aparthia · 2013-07-05 16:51:07

bloom wrote:

aparthia wrote:
Is there a way to 'tag' an entire workspace/desktop as floating in the same way as you can set a desktop to monocle or tiling mode?
Not exactly, because there's no floating layout but only a floating state.
I assume you're not willing to use rules for this?

It involves a decent amount of windows(12-15) at various stages of the process, none of which operate in a good manner when tiled. I was not inclined to use rules at first if there was a more elegant/simple solution, but it seems I'll use them instead!

milomouse · 2013-07-09 02:50:23

Not sure if this was addressed before but when there's a floating window open on focused desktop, "history_aware_focus" doesn't seem to work anymore when focusing between tiled windows. If you close the floating window then "history_aware_focus" will work again as predicted. Is this by design or something not yet configured? Anyway, just passing this along.

bloom · 2013-07-09 08:52:27

milomouse wrote:

Not sure if this was addressed before but when there's a floating window open on focused desktop, "history_aware_focus" doesn't seem to work anymore when focusing between tiled windows. If you close the floating window then "history_aware_focus" will work again as predicted. Is this by design or something not yet configured? Anyway, just passing this along.

I will fix this (the problem is that the floating windows are vacant and the is_adjacent function can't cope with that yet), thanks for reporting.

bloom · 2013-07-11 20:36:51

milomouse wrote:

Not sure if this was addressed before but when there's a floating window open on focused desktop, "history_aware_focus" doesn't seem to work anymore when focusing between tiled windows. If you close the floating window then "history_aware_focus" will work again as predicted. Is this by design or something not yet configured? Anyway, just passing this along.

It is fixed in the messages-rewrite branch.

(The branch implements the new syntax devised by Stebalien.)

milomouse · 2013-07-11 23:40:44

bloom wrote:

milomouse wrote:
Not sure if this was addressed before but when there's a floating window open on focused desktop, "history_aware_focus" doesn't seem to work anymore when focusing between tiled windows. If you close the floating window then "history_aware_focus" will work again as predicted. Is this by design or something not yet configured? Anyway, just passing this along.
It is fixed in the messages-rewrite branch.
(The branch implements the new syntax devised by Stebalien.)

Works great, and I like the new syntax. Once you realize what it's all about it seems very intuitive. Thanks guys.

Supplantr · 2013-07-12 08:20:06

I'm also a fan of the new syntax. I do have one issue to report so far: when bspc window last --swap focused is used to swap a window into a preselected area, the window that is moved (last) gains focus, but the window that was preselected (focused) keeps input focus, i.e. input still goes to this window. This is resolved after focusing the original window.

Arch Linux

#326 2013-06-26 18:03:59

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

#327 2013-06-26 21:06:19

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

#328 2013-06-26 23:48:59

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

#329 2013-06-27 09:05:27

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

#330 2013-06-27 17:46:37

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

#331 2013-06-27 19:38:41

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

#332 2013-06-28 10:13:22

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

#333 2013-06-28 13:52:41

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

#334 2013-07-01 18:40:02

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

#335 2013-07-02 09:09:00

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

#336 2013-07-02 19:01:03

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

#337 2013-07-02 19:37:26

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

#338 2013-07-04 04:10:52

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

#339 2013-07-04 09:17:51

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

#340 2013-07-04 10:22:31

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

#341 2013-07-04 22:44:18

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

#342 2013-07-05 07:01:11

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

#343 2013-07-05 10:16:41

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

#344 2013-07-05 10:37:57

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

#345 2013-07-05 16:51:07

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

#346 2013-07-09 02:50:23

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

#347 2013-07-09 08:52:27

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

#348 2013-07-11 20:36:51

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

#349 2013-07-11 23:40:44

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

#350 2013-07-12 08:20:06

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

Board footer