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

Some X11 menus are not unmanaged #2128

Closed
emersion opened this issue Jun 11, 2018 · 1 comment
Closed

Some X11 menus are not unmanaged #2128

emersion opened this issue Jun 11, 2018 · 1 comment
Labels
bug Not working as intended

Comments

@emersion
Copy link
Member

Try syncplay for instance. Menus are tiled.

@emersion emersion added the bug Not working as intended label Jun 11, 2018
@NicholasAsimov
Copy link

git gui and gitk context menus are tiled as well (they are Tcl/Tk based gui).

Ongy pushed a commit to Ongy/wlroots that referenced this issue Jul 29, 2018
swaywm#1145 removed the
wlr_xwayland_is_unamanged function while fixing OR, because it was
belieived that it's supposed to work around the broken OR handling.

This was a misunderstanding. is_unmanaged is (while sort of a hack)
intended to work around inherent differences between "real" X sessions
and our Xwayland/wayland situation.

The main reason it exists is to support applications like rofi and dzen,
while not handing focus to other OR windows (which should *not* be
required).
Traditionally, these applications just grabbed input from X and didn't
need to be focused by any logic in the WM. Which of course doesn't work
in wayland compositors. So we have to give them focus in some way.
Giving *every* OR window focus, breaks other applications that don't
expect focus to change.

A testcase that was pointed out to me where wlr_xwayland_is_unamanged was
breaking things is swaywm/sway#2128 (syncplay,
gitk, gitgui)
Supposedly it broke using keyboard to navigate the menus.
I can't reproduce this with this patch. The popups can be navigated as
long as the parent has focus.
Ongy pushed a commit to Ongy/wlroots that referenced this issue Jul 29, 2018
153f37b (swaywm#1145) removed the
wlr_xwayland_is_unamanged function while fixing OR, because it was
belieived that it's supposed to work around the broken OR handling.

This was a misunderstanding. is_unmanaged is (while sort of a hack)
intended to work around inherent differences between "real" X sessions
and our Xwayland/wayland situation.

The main reason it exists is to support applications like rofi and dzen,
while not handing focus to other OR windows (which should *not* be
required).
Traditionally, these applications just grabbed input from X and didn't
need to be focused by any logic in the WM. Which of course doesn't work
in wayland compositors. So we have to give them focus in some way.
Giving *every* OR window focus, breaks other applications that don't
expect focus to change.

A testcase that was pointed out to me where wlr_xwayland_is_unamanged was
breaking things is swaywm/sway#2128 (syncplay,
gitk, gitgui)
Supposedly it broke using keyboard to navigate the menus.
I can't reproduce this with this patch. The popups can be navigated as
long as the parent has focus.
ddevault pushed a commit to swaywm/rootston that referenced this issue Aug 8, 2019
153f37bdf57c61e7fb09162a6791afe8b9b4d0ef (#1145) removed the
wlr_xwayland_is_unamanged function while fixing OR, because it was
belieived that it's supposed to work around the broken OR handling.

This was a misunderstanding. is_unmanaged is (while sort of a hack)
intended to work around inherent differences between "real" X sessions
and our Xwayland/wayland situation.

The main reason it exists is to support applications like rofi and dzen,
while not handing focus to other OR windows (which should *not* be
required).
Traditionally, these applications just grabbed input from X and didn't
need to be focused by any logic in the WM. Which of course doesn't work
in wayland compositors. So we have to give them focus in some way.
Giving *every* OR window focus, breaks other applications that don't
expect focus to change.

A testcase that was pointed out to me where wlr_xwayland_is_unamanged was
breaking things is swaywm/sway#2128 (syncplay,
gitk, gitgui)
Supposedly it broke using keyboard to navigate the menus.
I can't reproduce this with this patch. The popups can be navigated as
long as the parent has focus.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Not working as intended
Development

No branches or pull requests

2 participants