Open robinchew opened 3 years ago
I'm wondering if it's possible to use xdotool to obtain more information about these transient windows:
#!/usr/bin/env bash
pid=$(pgrep firefox) # insert pid of android studio here
ws=$(xdotool search --pid $pid)
while true; do
wstmp=$(xdotool search --pid $pid)
wsnew=$(diff <(echo "$ws") <(echo "$wstmp") | awk '/^>/ {print $2}')
echo found windows: $wsnew
for win in $wsnew; do
xprop -id $win
done
ws=$wstmp
sleep 0.5
done
Hi your script fails because just running xdotool search --pid $pid
of android studio will give no outputs, whereas there were outputs if it was a pid of firefox instead.
That's odd. Does that mean that Android Studio starts submenus in a different process?
I have no idea how to search for Android Studio windows since I don't use it myself. Feel free to play around with the xdotool arguments, if this doesn't work: xdotool search --onlyvisible '' 2>/dev/null
In theory this should find all visible windows.
#!/usr/bin/env bash
search() {
xdotool search --onlyvisible '' 2>/dev/null
}
ws=$(search)
while true; do
wstmp=$(search)
wsnew=$(diff <(echo "$ws") <(echo "$wstmp") | awk '/^>/ {print $2}')
echo found windows: $wsnew
for win in $wsnew; do
xprop -id $win
done
ws=$wstmp
sleep 0.5
done
It finds some false positives (such as notion's own WGroupWS), but better too many than too few...
Awesome, I've modified your script as such:
#!/usr/bin/env bash
ws=$(xdotool search --onlyvisible --class 'jetbrains-studio')
while true; do
wstmp=$(xdotool search --onlyvisible --class 'jetbrains-studio')
wsnew=$(diff <(echo "$ws") <(echo "$wstmp") | awk '/^>/ {print $2}')
echo found windows: $wsnew
for win in $wsnew; do
xprop -id $win
done
ws=$wstmp
sleep 0.5
done
And I caught the following when I open a file menu or context menu.
WM_STATE(WM_STATE):
window state: Normal
icon window: 0x0
_NET_FRAME_EXTENTS(CARDINAL) = 0, 0, 0, 0
_NET_WM_ALLOWED_ACTIONS(ATOM) =
_NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_DIALOG
_NET_WM_STATE(ATOM) =
WM_HINTS(WM_HINTS):
Client accepts input or input focus: False
window id # of group leader: 0x220004e
WM_TRANSIENT_FOR(WINDOW): window id # 0x220004e
_NET_WM_PID(CARDINAL) = 70508
WM_CLIENT_MACHINE(STRING) = "silverstone"
WM_PROTOCOLS(ATOM): protocols
_MOTIF_WM_HINTS(_MOTIF_WM_HINTS) = 0x3, 0x0, 0x0, 0x0, 0x0
WM_NORMAL_HINTS(WM_SIZE_HINTS):
program specified location: 1081, 401
program specified size: 305 by 434
window gravity: NorthWest
WM_CLASS(STRING) = "sun-awt-X11-XWindowPeer", "jetbrains-studio"
WM_CLIENT_LEADER(WINDOW): window id # 0x220002f
_NET_WM_NAME(UTF8_STRING) = "win35"
WM_NAME(STRING) = "win35"
Just wondering, does it work? When you opened the issue you mentioned class = "sun-awt-X11-XFramePeer"
, but this one has WM_CLASS(STRING) = "sun-awt-X11-XWindowPeer",
You mean use kludges to fix it? I added the following:
defwinprop{
class = "jetbrains-studio",
acrobatic = true,
transient_mode = "current"
}
defwinprop{
class = "sun-awt-X11-XFramePeer",
acrobatic = true,
transient_mode = "current"
}
defwinprop{
class = "sun-awt-X11-XWindowPeer",
acrobatic = true,
transient_mode = "current"
}
But there has been no change.
After inspecting the source, there is a special case for _NET_WM_WINDOW_TYPE_DIALOG
in cfg_notion.lua
which seemingly defaults to false (at least it's set to false here but I don't remember setting it) and according to the comment might help and is commented out as true. You can inspect with notionflux(1) or the Lua prompt by evaluating print(ioncore.get()["window_dialog_float"])
.
Edit: I checked the code, it is initialized to ioncore_g.window_dialog_float=FALSE
in C. Firefox's menus are _NET_WM_WINDOW_TYPE_POPUP_MENU
. Whether or not globally handling that information is a good idea or should rather be a kludge ...not sure. The mysterious world of X11.
The menus are all anchored at the bottom of the screen. The menus takes up the whole width of the screen, with all the extra width in black background colour.
I can reproduce that
The context menu options are still selectable because the menu remains on mouse up. 3b. The top menus are not selectable because the menu disappears on mouse up.
Interesting, the top menus don't disappear on mouse up for me. But it obviously doesn't work well.
I'm wondering if it's possible to use xdotool to obtain more information about these transient windows
Neat! A trick I sometimes use is to save the output of xwininfo -root -tree
and one with sleep 5 && xwininfo -root -tree
to catch one with the dialog open, and then compare with vimdiff. This indeed suggests the dialog is ("sun-awt-X11-XWindowPeer" "jetbrains-studio")
AFAIK Android Studio is based in a large part on IntelliJ IDEA, which I use a lot and mostly works fine. For IntelliJ we do have some winprops, but I just tried without them and think they might no longer be relevant.
Looking at the IntelliJ IDEA menu's with xwinprop, however, they are ("jetbrains-idea-ce" "jetbrains-idea-ce")
rather than sun-awt-X11-XWindowPeer - so apparently they are different in this regard - even though the winprops look pretty similar:
_NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_DIALOG
_NET_WM_STATE(ATOM) = _NET_WM_STATE_SKIP_TASKBAR
WM_HINTS(WM_HINTS):
Client accepts input or input focus: False
window id # of group leader: 0x2a00042
WM_TRANSIENT_FOR(WINDOW): window id # 0x2a00042
_NET_WM_PID(CARDINAL) = 2521983
WM_CLIENT_MACHINE(STRING) = "rigter"
WM_PROTOCOLS(ATOM): protocols
_MOTIF_WM_HINTS(_MOTIF_WM_HINTS) = 0x3, 0x0, 0x0, 0x0, 0x0
WM_NORMAL_HINTS(WM_SIZE_HINTS):
program specified location: 2272, 893
program specified size: 607 by 782
window gravity: NorthWest
WM_CLASS(STRING) = "jetbrains-idea-ce", "jetbrains-idea-ce"
WM_CLIENT_LEADER(WINDOW): window id # 0x2a00023
_NET_WM_NAME(UTF8_STRING) = "win10"
WM_NAME(STRING) = "win10"
@raboof window_dialog_float = true
in cfg_notion.lua makes no difference?
@raboof
window_dialog_float = true
in cfg_notion.lua makes no difference?
Ha, I didn't get that far into this thread, sorry :).
I can confirm setting window_dialog_float = true
makes this work much more like it was intended, though it doesn't seem to work well in multi-monitor configurations...
Whether or not globally handling that information is a good idea or should rather be a kludge ...not sure.
I agree perhaps we should make this overridable at the kludge level... or lobby for android studio to take the same approach as IntelliJ IDEA ;).
I have a 3 monitor setup. Setting the following in ~/.notion/default-session--0/cfg_notion.lua
made no difference for me.
ioncore.set{
window_dialog_float = true,
}
FTR, [16:41] < Robin> Yes notion works fine with android studio 3
Today I noticed my Android Studio 4's menus are all anchored to the top left. I'm assuming it's because of:
-- cfg_notion.lua
ioncore.set{
window_dialog_float = true,
}
and I don't know why this has happened now instead of 2 days ago when I made the config change. That time I restarted Xorg and notion, and the menus were still taking up the whole width demonstrated in the video.
Although this change is an improvement, it's still a pain. For example clicking on File anchors the menu on the top left, then selecting New anchors the sub menu somewhere to the right. See screenshot
@raboof Just wondering, in IntelliJ, are menus _NET_WM_WINDOW_TYPE_DIALOG
or _NET_WM_WINDOW_TYPE_POPUP_MENU
?
Firefox "Do you want to quit?" dialog has the same type as Android Studio's dropdown menus, just to confirm that this is what a dialog is in usual terms — which indicates to me that Android Studio really seems to be off here:
_NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_DIALOG
For illustration, here's some other software and values their dropdown menus have: Firefox:
_NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_POPUP_MENU
Gimp:
_NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_DROPDOWN_MENU
GVim:
_NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_POPUP_MENU
Libreoffice: my script fails to obtain information besides the window id. Oops :)
Qt software: VirtualBox, quasselclient-qt5, OpenSCAD (iirc those were buggy but I can't remember details):
_NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_DROPDOWN_MENU, _NET_WM_WINDOW_TYPE_POPUP_MENU, _NET_WM_WINDOW_TYPE_NORMAL
Ultimaker Cura (PyQt5) — menu positions here also seem off:
_NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_NORMAL
Seems like there is no consensus between toolkits/implementations on this issue, either, and we can't fix every single package that has a different way of rendering popups. Maybe honoring the window position these programs explicitly request through size hints is the way to go? Taking a wild guess here that we don't already, I know very little about how notion handles any of this.
WM_PROTOCOLS(ATOM): protocols WM_DELETE_WINDOW, WM_TAKE_FOCUS, _NET_WM_PING, _NET_WM_SYNC_REQUEST
WM_NORMAL_HINTS(WM_SIZE_HINTS):
user specified location: 1324, 92
user specified size: 275 by 190
window gravity: Static
@raboof Just wondering, in IntelliJ, are menus
_NET_WM_WINDOW_TYPE_DIALOG
or_NET_WM_WINDOW_TYPE_POPUP_MENU
?
Just checked and it's really (though indeed oddly) _NET_WM_WINDOW_TYPE_DIALOG
dwm seems to deal with it by always setting dialogs floating: https://git.suckless.org/dwm/file/dwm.c.html#l2015 Haven't checked what other tiling WM's do.
So the problem came back again after messing with cfg_kludges.lua. So I don't know what combination of the following will cause what behaviour. But in any case, they are all difficult to work with:
-- cfg_kludges.lua
defwinprop{
class = "jetbrains-studio",
acrobatic = true,
transient_mode = "current"
}
defwinprop{
class = "sun-awt-X11-XFramePeer",
acrobatic = true,
transient_mode = "current"
}
defwinprop{
class = "sun-awt-X11-XWindowPeer",
acrobatic = true,
transient_mode = "current"
}
-- cfg_notion.lua
ioncore.set{
window_dialog_float = true,
}
Here's a video of the behaviour. https://youtu.be/TbYoW7vxvpM
xprop
on the menu, you can see the output ofxprop
on the main window in video.cfg_kludges.lua
the following, but has no effect:It makes Android Studio 4 unusable unfortunately.