bspwm — A tiling window manager based on binary space partitioning

bloom · 2013-05-31 20:24:39

Supplantr wrote:

As you can see, the "active_border_color" is drawn below the other borders.
This happens when moving a window to or from a different monitor.
Selecting the window obviously changes the border color and draws it above the other borders as expected.

I'm afraid I'd need a more precise report.
Please post the output of:

bspc list_monitors; bspc list_history

Before and after sending the window to the other monitor.

Supplantr wrote:

Your responsiveness to bug reports and openness to feature requests should really be commended.

You're welcome.

Supplantr wrote:

The only way I'm able to "disconnect" the monitor is by killing the optirun + screenclone process from the script I use. I guess the end effect should be the same.
Anyway, the window on the disconnected monitor becomes visible on screen, but as though it's floating. It's drawn above everything on every desktop!

It should be fixed.

Supplantr wrote:

Also, as you can see, each time the monitor is "re-added" a new Desktop0X is created, but I suppose that's the intended behavior.

Yes this is expected: I'm not removing empty desktop when merging monitors because, when a desktop is removed, the rules referencing that desktop are removed too.

Supplantr wrote:

Upon further testing I've noticed that dmenu won't appear on an empty desktop when there is a second monitor.

I'll try to put my hands on a second monitor to investigate this.

Supplantr · 2013-06-01 08:56:43

bloom wrote:

Please post the output of:
bspc list_monitors; bspc list_history
Before and after sending the window to the other monitor.

Here's before and after. Let me know if I can provide any other information.

bloom wrote:

It should be fixed.

Confirmed; it's fixed.

Supplantr wrote:

Upon further testing I've noticed that dmenu won't appear on an empty desktop when there is a second monitor.

With the latest build it appears the situation is a bit different (or maybe I missed something last time).
dmenu appears on the monitor that has the mouse pointer unless the focused desktop contains a window, in which case it'll open on the monitor of that desktop. Is this how dmenu is supposed to work?

bloom · 2013-06-01 10:09:25

Supplantr wrote:

Is this how dmenu is supposed to work?

(dmenu is not managed by bspwm, so...)

... Yes it seems : here's the relevant comments from dmenu.c:

/* find top-level window containing current input focus */
/* find xinerama screen with which the window intersects most */
/* no focused window is on screen, so use pointer location instead */

bloom · 2013-06-01 10:45:42

bloom wrote:

Supplantr wrote:
Is this how dmenu is supposed to work?
(dmenu is not managed by bspwm, so...)
... Yes it seems : here's the relevant comments from dmenu.c:
/* find top-level window containing current input focus */
/* find xinerama screen with which the window intersects most */
/* no focused window is on screen, so use pointer location instead */

One possible workaround would be to use the following wrapper:

#!/bin/sh
set - $(bspc list_monitors --quiet | grep '#$' | cut -d ' ' -f 2 | tr -c '0-9' ' ')
dmenu -w $1 -x $3 -y $4

(Which requires a patched version of dmenu.)

Last edited by bloom (2013-06-01 12:00:33)

bloom · 2013-06-01 12:30:54

Supplantr wrote:

As you can see, the "active_border_color" is drawn below the other borders. This happens when moving a window to or from a different monitor.

Should be fixed.

Supplantr · 2013-06-01 22:06:36

bloom wrote:

(dmenu is not managed by bspwm, so...)
... Yes it seems : here's the relevant comments from dmenu.c

The comments reflect exactly what I was describing. How embarrassing. I'll make sure to delve a little deeper next time.

bloom wrote:

One possible workaround would be to use the following wrapper

Thanks for this, I'll check it out.

bloom wrote:

Should be fixed.

It's fixed, thanks!

---

I was going to suggest adding a remove desktop command, but you're one step ahead. It works as expected, thanks.

And a matter of pedantry: I was wondering why the new swap command needs the --swap-focus flag when that's the default behavior.

Also, is the intended usage of biggest something like:

xdo activate $(bspc biggest) && bspc swap

bloom · 2013-06-02 12:28:59

Supplantr wrote:

And a matter of pedantry: I was wondering why the new swap command needs the --swap-focus flag when that's the default behavior.

Fixed, thanks.

Supplantr wrote:

Also, is the intended usage of biggest something like:
xdo activate $(bspc biggest) && bspc swap

Yes, and also:

xdo activate $(bspc biggest)

---

I've added a send_desktop_to message.

Supplantr · 2013-06-02 14:01:08

bloom wrote:

I've added a send_desktop_to message.

I've experienced some issues with this already but I'll have to get back to you after establishing a way to reproduce them.

---

I've discovered a few issues involving the pointer. From here on out I'll refer to the initial monitor as M1 and the additional, external monitor as M2 for the sake of brevity.

focus_follows_pointer doesn't work properly on M1 when M2 is present.
I'm only able to focus with the pointer the windows on M1 that are closest to the top of the monitor (M2 is above M1), and only if the pointer enters a small area near the top of the window.
Moving the pointer from M1 to a window on M2 focuses that window as expected. Moving the pointer back to M1 seems to work if it's moved slowly, but again it'll only focus the windows closest to the top of the monitor.
Focus follows the pointer as intended on M2.

Unrelated to focus_follows_pointer, there's this: if a window is opened on M1, and the pointer is on the window, when switching focus to M2 (and there is not a window open on M2), the window on M1 still receives input. The reverse scenario is also true. This only happens if the mouse pointer is on the "active" but unfocused window.

---

Finally, unrelated to the pointer altogether, I've encountered another peculiarity:

Send a presel command, but don't open a new window
Focus another window, and the presel_border_color is drawn on this window
Change focus again or send a ratio command and the border returns to normal

bloom · 2013-06-02 20:08:53

Supplantr wrote:

bloom wrote:
I've added a send_desktop_to message.
I've experienced some issues with this already but I'll have to get back to you after establishing a way to reproduce them.

I've just fixed a bug related to this message, so the issues might not exist anymore.

Supplantr wrote:

focus_follows_pointer doesn't work properly on M1 when M2 is present.
I'm only able to focus with the pointer the windows on M1 that are closest to the top of the monitor (M2 is above M1), and only if the pointer enters a small area near the top of the window.
Moving the pointer from M1 to a window on M2 focuses that window as expected. Moving the pointer back to M1 seems to work if it's moved slowly, but again it'll only focus the windows closest to the top of the monitor.
Focus follows the pointer as intended on M2.

Might be fixed.

Supplantr wrote:

Unrelated to focus_follows_pointer, there's this: if a window is opened on M1, and the pointer is on the window, when switching focus to M2 (and there is not a window open on M2), the window on M1 still receives input. The reverse scenario is also true. This only happens if the mouse pointer is on the "active" but unfocused window.

And it happens only when focus_follows_pointer is enabled?

Supplantr wrote:

Finally, unrelated to the pointer altogether, I've encountered another peculiarity:
Send a presel command, but don't open a new window
Focus another window, and the presel_border_color is drawn on this window
Change focus again or send a ratio command and the border returns to normal

Fixed.

Supplantr · 2013-06-03 01:27:11

bloom wrote:

I've just fixed a bug related to this message, so the issues might not exist anymore.

I think "hiding" the desktop on send_desktop_to fixes what I experienced.
However, it now seems to duplicate desktops. Here is bspc list_monitors's output before and after sending desktop H to monitor LVDS1.

bloom wrote:

Might be fixed.

The problems with focus_follows_pointer still exist.

bloom wrote:

And it happens only when focus_follows_pointer is enabled?

Sorry for not being clear. This happens regardless of focus_follows_pointer's setting.

bloom · 2013-06-03 19:11:57

Supplantr wrote:

However, it now seems to duplicate desktops.

Hopefully resolved.

Supplantr wrote:

The problems with focus_follows_pointer still exist.

Could you:

Post the output of bspc list_monitors for that scenario,
Apply the following patch to bspwm-git's PKGBUILD: https://gist.github.com/baskerville/5687612 so that debug message appear on bspwm's standard output,
Redirect bspwm's standard output to a file and post the it here?

bloom · 2013-06-03 19:13:53

Supplantr wrote:

Unrelated to focus_follows_pointer, there's this: if a window is opened on M1, and the pointer is on the window, when switching focus to M2 (and there is not a window open on M2), the window on M1 still receives input. The reverse scenario is also true. This only happens if the mouse pointer is on the "active" but unfocused window.

Could you post the aforementioned informations for that scenario too?

Supplantr · 2013-06-04 01:17:28

bloom wrote:

Hopefully resolved.

This is fixed, thanks. Would it be possible to add a --follow flag to send_desktop_to or would that reintroduce the issue that was solved by hiding the desktop on send?

Supplantr wrote:

The problems with focus_follows_pointer still exist.

Actually, this is working with the latest git build.

bloom wrote:

Could you post the aforementioned informations for that scenario too?

I don't know if I was doing something wrong, but the file to which I was writing standard out seemed to only update after some amount of time.
Anyway, this is the debug output and this is the list_monitors output.
This is what I did, so hopefully you can follow along in the debug output:

Add second monitor; mouse pointer is moved to this monitor
Open terminal (id = E00009)
Enable focus_follows_pointer (because the motion recorder events didn't appear to be reported without this enabled)
Select other monitor
Move pointer to window on first monitor, it's obviously focused (I'm not sure why I didn't do this first)
Select other monitor again
Type and the terminal receives input
Select first monitor
Close terminal

It might be helpful to know that if a window is opened and then closed after focusing the other monitor (step 6) and before typing (step 7), the window on the first monitor won't receive input.

Last edited by Supplantr (2013-06-04 01:26:13)

bloom · 2013-06-04 13:36:39

Supplantr wrote:

Would it be possible to add a --follow flag?

Yes, done.

Supplantr wrote:

Select other monitor
Type and the terminal receives input

Unfortunately it seems to be related to how X handles input events.

After running the following program:

#include <stdlib.h>
#include <xcb/xcb.h>

int main(void)
{
    xcb_connection_t *dpy = xcb_connect(NULL, NULL);
    xcb_set_input_focus(dpy, XCB_INPUT_FOCUS_POINTER_ROOT, XCB_INPUT_FOCUS_POINTER_ROOT, XCB_CURRENT_TIME);
    xcb_flush(dpy);
    xcb_disconnect(dpy);
    return EXIT_SUCCESS;
}

The key press events are transmitted to whatever window is under the pointer.

(Setting the third argument of xcb_set_input_focus to XCB_NONE fixes it but also prevents clients to receive keyboard events.)

The only workaround I can think of would be a pointer_follows_focus setting...

Last edited by bloom (2013-06-04 14:50:31)

Supplantr · 2013-06-04 23:07:24

bloom wrote:

Yes, done.

I've noticed that when using send_desktop_to without the --follow flag the newly selected desktop isn't reported as selected. Maybe a put_status call is needed after moving the desktop?

As for the --follow flag, unfortunately there are some issues. It seems like the desktop is selected on the monitor to which it is moved, but the windows aren't drawn on this monitor. Selecting the desktop again then "moves" the windows to the correct monitor.

bloom wrote:

Unfortunately it seems to be related to how X handles input events.

I guess if it's a limitation of X there isn't much that can be done.

bloom wrote:

The only workaround I can think of would be a pointer_follows_focus setting...

I think this could be useful, especially if the pointer is centered on selected monitors, i.e. so it doesn't have to be moved across the entire screen from one monitor to another.

bloom · 2013-06-05 09:49:52

Supplantr wrote:

I've noticed that when using send_desktop_to without the --follow flag the newly selected desktop isn't reported as selected. Maybe a put_status call is needed after moving the desktop?
As for the --follow flag, unfortunately there are some issues. It seems like the desktop is selected on the monitor to which it is moved, but the windows aren't drawn on this monitor. Selecting the desktop again then "moves" the windows to the correct monitor.

Oh boy... that's why I prefer to be able to test before pushing
Should be fixed™.

Supplantr wrote:

bloom wrote:
The only workaround I can think of would be a pointer_follows_focus setting...
I think this could be useful, especially if the pointer is centered on selected monitors, i.e. so it doesn't have to be moved across the entire screen from one monitor to another.

So, pointer_follows_monitor would be sufficient?

Supplantr · 2013-06-05 10:54:41

Supplantr wrote:

As for the --follow flag, unfortunately there are some issues. It seems like the desktop is selected on the monitor to which it is moved, but the windows aren't drawn on this monitor. Selecting the desktop again then "moves" the windows to the correct monitor.

This is fixed.

Supplantr wrote:

I've noticed that when using send_desktop_to without the --follow flag the newly selected desktop isn't reported as selected. Maybe a put_status call is needed after moving the desktop?

This is still an issue. It only happens when not using the --follow flag. I think it's as simple as not calling put_status after moving the desktop because using bspc put_status or selecting a desktop/monitor corrects the status.

bloom wrote:

So, pointer_follows_monitor would be sufficient?

At least for me, I think this would suffice. The only graphical application I use on a regular basis is chromium, so the pointer is usually kept on its window. I suppose if someone used many graphical apps it might be handy to move the pointer on focus, but it'd probably be just as easy to enable focus_follows_pointer and move the pointer manually.

bloom · 2013-06-05 14:21:39

Supplantr wrote:

Supplantr wrote:
I've noticed that when using send_desktop_to without the --follow flag the newly selected desktop isn't reported as selected. Maybe a put_status call is needed after moving the desktop?
This is still an issue. It only happens when not using the --follow flag. I think it's as simple as not calling put_status after moving the desktop because using bspc put_status or selecting a desktop/monitor corrects the status.

In fact, put_status was called by both select_monitor and select_desktop and the function was actually called twice with --follow and once without.

I hope to have fixed this.

I've added a new setting: pointer_follows_monitor.

Last edited by bloom (2013-06-05 19:22:40)

Supplantr · 2013-06-05 21:32:31

bloom wrote:

I hope to have fixed this.

Unfortunately, it appears the issue has worsened. The status still doesn't update, and now, after selecting the desktop that was just moved, the windows on that desktop don't appear until another window is opened.

bloom wrote:

I've added a new setting: pointer_follows_monitor.

Thanks, it works as expected.

---

On an unrelated note, I was wondering if this is the intended behavior:

  V m 0.50
    m URxvt E0020F 39 4 484x292+718+1418 ----- *
    H m 0.50
      m URxvt E0021D 40 4 484x292+718+1418 -----
      m URxvt E0022B 41 4 484x292+718+1418 -----

  V m 0.50
    m URxvt E0020F 39 4 484x292+718+1418 f---- *
    H m 0.50
      m URxvt E0021D 40 4 484x292+718+1418 -----
      m URxvt E0022B 41 4 484x292+718+1418 -----

  V m 0.50
    m URxvt E0020F 39 4 484x292+718+1418 ----- *
    V m 0.50
      m URxvt E0021D 40 4 484x292+718+1418 -----
      m URxvt E0022B 41 4 484x292+718+1418 -----

After floating and un-floating E0020F, the manual split cycles between H and V. Is this supposed to happen?

bloom · 2013-06-06 09:52:24

Supplantr wrote:

Unfortunately, it appears the issue has worsened. The status still doesn't update, and now, after selecting the desktop that was just moved, the windows on that desktop don't appear until another window is opened.

Worsened for --follow?
Please post a before/after list_monitors, cat "$PANEL_FIFO" (kill your panel first) and the debug messages.

Supplantr wrote:

After floating and un-floating E0020F, the manual split cycles between H and V. Is this supposed to happen?

No, fixed, thanks.

bloom · 2013-06-06 15:01:57

bloom wrote:

Please post a before/after list_monitors, cat "$PANEL_FIFO" (kill your panel first) and the debug messages.

Never mind: I've created fake monitors to be able to investigate those issues.

Supplantr · 2013-06-06 19:26:50

bloom wrote:

Worsened for --follow?

Sorry, I meant without using --follow.
The issue I noted might be more pervasive than I originally thought (or maybe this is unrelated). Moving windows between desktops doesn't function properly now. For instance, if a window is moved from one desktop to another that is in tiling mode, the moved window will appear on top of the window already on that desktop until the layout is cycled to monocle and back to tiling, or if the recently moved window is floated and then un-floated. This also happens when the desktop is in monocle mode.

Supplantr wrote:

after selecting the desktop that was just moved, the windows on that desktop don't appear until another window is opened.

Actually, it seems as though the above issue has become: when a desktop is moved with send_desktop_to without --follow, the windows are still drawn on the previous monitor until a new window is opened (and they're drawn on top of windows of other desktops!), but the desktop is reported as being on the monitor to which it was moved.

bloom wrote:

Please post a before/after list_monitors, cat "$PANEL_FIFO" (kill your panel first) and the debug messages.

I can still do this if you need me to.

Last edited by Supplantr (2013-06-06 19:33:03)

bloom · 2013-06-06 22:06:09

Supplantr wrote:

The issue I noted might be more pervasive than I originally thought

That regression is fixed and send_desktop_to is working fine for me now.

Thanks for your diligence.

Supplantr · 2013-06-07 09:01:12

bloom wrote:

That regression is fixed and send_desktop_to is working fine for me now.

Everything that I previously reported seems to be fixed.

bloom wrote:

Thanks for your diligence.

I'm glad I could help!

---

However, I would like to point out that when pointer_follows_monitor is enabled, manually moving the pointer between monitors causes it to jump to the center, which is off-putting. This is the intended behavior, though, so would it be possible to only center the pointer if the monitor is focused via a bspc message?

While testing, I randomly came across another situation in which floating and un-floating a window changes the tiling layout (albeit, not permanently). Here is the relevant list_desktops information for before and after floating. The layout returns to its previous state when the window is un-floated.
EDIT: I just realized there was some automatic tiling in the above situation, so the behavior was probably expected. I'm too eager to report issues.

Last edited by Supplantr (2013-06-07 09:23:47)

bloom · 2013-06-07 10:18:30

Supplantr wrote:

However, I would like to point out that when pointer_follows_monitor is enabled, manually moving the pointer between monitors causes it to jump to the center, which is off-putting. This is the intended behavior, though, so would it be possible to only center the pointer if the monitor is focused via a bspc message?

Implemented.

Supplantr wrote:

I just realized there was some automatic tiling in the above situation, so the behavior was probably expected.

Yes it is.

Arch Linux

#276 2013-05-31 20:24:39

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

#277 2013-06-01 08:56:43

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

#278 2013-06-01 10:09:25

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

#279 2013-06-01 10:45:42

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

#280 2013-06-01 12:30:54

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

#281 2013-06-01 22:06:36

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

#282 2013-06-02 12:28:59

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

#283 2013-06-02 14:01:08

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

#284 2013-06-02 20:08:53

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

#285 2013-06-03 01:27:11

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

#286 2013-06-03 19:11:57

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

#287 2013-06-03 19:13:53

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

#288 2013-06-04 01:17:28

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

#289 2013-06-04 13:36:39

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

#290 2013-06-04 23:07:24

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

#291 2013-06-05 09:49:52

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

#292 2013-06-05 10:54:41

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

#293 2013-06-05 14:21:39

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

#294 2013-06-05 21:32:31

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

#295 2013-06-06 09:52:24

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

#296 2013-06-06 15:01:57

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

#297 2013-06-06 19:26:50

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

#298 2013-06-06 22:06:09

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

#299 2013-06-07 09:01:12

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

#300 2013-06-07 10:18:30

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

Board footer