You are not logged in.

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

Supplantr
Member
From: a state of sunshine
Registered: 2011-12-12
Posts: 149
Website

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

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:

  1. focus_by_distance is set (obviously)

  2. history_aware_focus is set (which trumps focus_by_distance)

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


I use linux and I dont understand nothing in this post.

Offline

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

bloom
Member
Registered: 2010-08-18
Posts: 749
Website

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

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:

  1. focus_by_distance is set (obviously)

  2. history_aware_focus is set (which trumps focus_by_distance)

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


gh · da · ds · cr · ab · fkr

Online

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

Supplantr
Member
From: a state of sunshine
Registered: 2011-12-12
Posts: 149
Website

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

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

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.


I use linux and I dont understand nothing in this post.

Offline

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

bloom
Member
Registered: 2010-08-18
Posts: 749
Website

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

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)


gh · da · ds · cr · ab · fkr

Online

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

bloom
Member
Registered: 2010-08-18
Posts: 749
Website

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

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.


gh · da · ds · cr · ab · fkr

Online

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

Supplantr
Member
From: a state of sunshine
Registered: 2011-12-12
Posts: 149
Website

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

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

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)


I use linux and I dont understand nothing in this post.

Offline

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

bloom
Member
Registered: 2010-08-18
Posts: 749
Website

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

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)


gh · da · ds · cr · ab · fkr

Online

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

bloom
Member
Registered: 2010-08-18
Posts: 749
Website

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

New message: focus_monitor.
New setting: monitor_focus_fallback.


gh · da · ds · cr · ab · fkr

Online

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

Sirsurthur
Member
Registered: 2009-02-02
Posts: 114

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

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 !

Offline

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

bloom
Member
Registered: 2010-08-18
Posts: 749
Website

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

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:


gh · da · ds · cr · ab · fkr

Online

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

Supplantr
Member
From: a state of sunshine
Registered: 2011-12-12
Posts: 149
Website

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

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?


I use linux and I dont understand nothing in this post.

Offline

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

bloom
Member
Registered: 2010-08-18
Posts: 749
Website

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

Supplantr wrote:

There is a problem with circulate

Should be fixed.


gh · da · ds · cr · ab · fkr

Online

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

Supplantr
Member
From: a state of sunshine
Registered: 2011-12-12
Posts: 149
Website

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

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)


I use linux and I dont understand nothing in this post.

Offline

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

bloom
Member
Registered: 2010-08-18
Posts: 749
Website

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

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.


gh · da · ds · cr · ab · fkr

Online

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

bloom
Member
Registered: 2010-08-18
Posts: 749
Website

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

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.


gh · da · ds · cr · ab · fkr

Online

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

aparthia
Member
Registered: 2010-09-04
Posts: 45

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

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)

Offline

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

bloom
Member
Registered: 2010-08-18
Posts: 749
Website

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

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?


gh · da · ds · cr · ab · fkr

Online

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

Supplantr
Member
From: a state of sunshine
Registered: 2011-12-12
Posts: 149
Website

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

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.


I use linux and I dont understand nothing in this post.

Offline

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

bloom
Member
Registered: 2010-08-18
Posts: 749
Website

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

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.


gh · da · ds · cr · ab · fkr

Online

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

aparthia
Member
Registered: 2010-09-04
Posts: 45

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

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!

Offline

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

milomouse
Member
Registered: 2009-03-24
Posts: 940
Website

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

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.

Offline

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

bloom
Member
Registered: 2010-08-18
Posts: 749
Website

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

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.


gh · da · ds · cr · ab · fkr

Online

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

bloom
Member
Registered: 2010-08-18
Posts: 749
Website

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

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


gh · da · ds · cr · ab · fkr

Online

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

milomouse
Member
Registered: 2009-03-24
Posts: 940
Website

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

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.

Offline

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

Supplantr
Member
From: a state of sunshine
Registered: 2011-12-12
Posts: 149
Website

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

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.


I use linux and I dont understand nothing in this post.

Offline

Board footer

Powered by FluxBB