Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Telegram not opening containing desktop #1303

Open
hariseldon78 opened this issue Jun 14, 2021 · 5 comments
Open

Telegram not opening containing desktop #1303

hariseldon78 opened this issue Jun 14, 2021 · 5 comments

Comments

@hariseldon78
Copy link

Hello. I use many desktops (bspc monitor $MONITOR --add-desktops "...").
And I use telegram. Telegram has an icon in the status bar, in the menu there is "Open telegram". If the window is already open in a current visible desktop then it gets correctly focused, but if it's in another, non visible, desktop, then nothing happens: no desktop changing, no "urgent" mark being set, nothing.
With other programs, like for example Skype, it correctly move to the containing desktop and focuses the window.

I understand that this is not a problem of bspwm, but probably telegram using an unconventional way to focus his own window, but I'd like to know if anyone knows any workaround, or at least how to investigate further, so I can open an issue with Telegram...

@ortango
Copy link

ortango commented Jun 18, 2021

but probably telegram using an unconventional way to focus his own window,

so it looks to me like qt5 doesn't really have a function to do this? (qt4 seems like it did it in a ewmh way.)

tdesktop is open source, so you could add support for _NET_ACTIVE_WINDOW (and have ignore_ewmh_focus = false).

@AdamantGarth
Copy link

@ortango That is a terrible idea. This is the kind of thing that the window manager should handle. And most of the popular ones do - Mutter, KWin, Xfwm, i3, awesome (not out of the box, but can be configured). i3, for example, has an option called focus_on_window_activation that controls how window manager behaves when a window requests activation. By default it activates the window when it's on the current desktop, but if it's on another desktop - it just gets marked as urgent. That option can be set so that window gets activated no matter where it is (which is what @hariseldon78 wants, I believe).

Telegram tried to "fix" this issue earlier, because Marco (MATE's WM) also doesn't activate windows from other desktops, but it broke all other window managers, that handle this correctly, so it got reverted. The "fix" forced Telegram to jump to the current desktop, so no matter what the user chose to happen in this situation (nothing, desktop switching to Telegram's desktop, or Telegram appearing on the current desktop) Telegram just jumped to the current desktop. It was especially irritating on tiling WMs, because it affected the window layout, but even on floating ones it wasn't pleasant. So please, fix this issue in a WM, there's nowhere else that it can be fixed correctly.

@ortango
Copy link

ortango commented Jun 30, 2021

@AdamantGarth

This is the kind of thing that the window manager should handle.

bspwm handles _NET_ACTIVE_WINDOW

i3, for example, has an option called focus_on_window_activation

is works on the logic that a window that asked for stacking above is to be focused. if that is standard, i was not familiar with the practice, apologies.

Telegram tried to "fix" this issue earlier, because Marco (MATE's WM) also doesn't activate windows from other desktops

it was using a function specifically to move telegram to the current desktop, which is what users in that report are complaining about. _NET_ACTIVE_WINDOW does not work that way.

so i don't think that it is a "terrible idea". it is how qt4 would handle things.

regardless, patching bspwm to focus windows that are raised should be easy enough. even this quick test seems to work (but i dont use any programs that actually expect raise()=activatewindow() for testing).

diff -ruN a/events.c b/events.c
--- a/events.c	2021-06-29 22:39:49.483949455
+++ b/events.c	2021-06-29 22:41:00.944476645
@@ -216,6 +216,12 @@
 
 		xcb_send_event(dpy, false, e->window, XCB_EVENT_MASK_STRUCTURE_NOTIFY, (const char *) &evt);
 	}
+    if (is_managed
+        && e->value_mask & XCB_CONFIG_WINDOW_STACK_MODE
+        && e->stack_mode == XCB_STACK_MODE_ABOVE
+        && !ignore_ewmh_focus) {
+        focus_node(loc.monitor, loc.desktop, loc.node);
+    }
 }
 
 void configure_notify(xcb_generic_event_t *evt)

@AdamantGarth
Copy link

This is the kind of thing that the window manager should handle.

bspwm handles _NET_ACTIVE_WINDOW

i3, for example, has an option called focus_on_window_activation

is works on the logic that a window that asked for stacking above is to be focused. if that is standard, i was not familiar with the practice, apologies.

I assumed that Telegram used _NET_ACTIVE_WINDOW, because in awesomeWM you can override request::activate (not request::stack_above or whatever) handler to focus the window that requests activation no matter what desktop it is on. But I'm not really knowledgeable on this topic and would be glad if you'd clarify this for me. Apparently, an application can either set _NET_ACTIVE_WINDOW or "ask for stacking above" of which bspwm only handles the former?

As for logic being standard - yeah, it is. Two most popular WMs (Mutter, KWin) do this out of the box, Xfwm, i3 and awesomeWM all have an option that enables the behavior that OP wants.

Telegram tried to "fix" this issue earlier, because Marco (MATE's WM) also doesn't activate windows from other desktops

it was using a function specifically to move telegram to the current desktop, which is what users in that report are complaining about. _NET_ACTIVE_WINDOW does not work that way.

so i don't think that it is a "terrible idea". it is how qt4 would handle things.

Sorry for "terrible idea", I just assumed that you proposed what Telegram already tried to do. Still, if other window managers already handle Telegram's (and some other applications', probably) activation correctly, I think it makes more sense to fix this on a WM level, not application.

@ortango
Copy link

ortango commented Jun 30, 2021

Apparently, an application can either set _NET_ACTIVE_WINDOW or "ask for stacking above" of which bspwm only handles the former?

yea

that short patch in the previous reply should enable it for raising the window also. it checks the same config option, ignore_ewmh_focus, in order to take effect. i'm not sure if that event should also set _NET_WM_STATE_ABOVE on the window. i don't think it should though.

bspwm only has true/false settings for ignore_ewmh_focus, but i'm sure more folks would be interested in an additional option to set urgent instead.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants